19 Oct, 2005
12 commits
-
This is needed by NFSv4 for atomicity reasons: our open command is in
fact a lookup+open, so we need to be able to propagate open context
information from lookup() into the resulting struct file's
private_data field.Signed-off-by: Trond Myklebust
-
...and fix a memory corruption bug due to improper use of memcpy() on
a struct file_lock.Signed-off-by: Trond Myklebust
-
Signed-off-by: Trond Myklebust
-
Currently we fail to do so if the process was signalled.
Signed-off-by: Trond Myklebust
-
Signed-off-by: Trond Myklebust
-
We no longer need to worry about collisions between close() and the state
recovery code, since the new close will automatically recheck the
file state once it is done waiting on its sequence slot.Ditto for the nfs4_proc_locku() procedure.
Signed-off-by: Trond Myklebust
-
OPEN, CLOSE, etc no longer need these semaphores to ensure ordering of
requests.Signed-off-by: Trond Myklebust
-
Once the state_owner and lock_owner semaphores get removed, it will be
possible for other OPEN requests to reopen the same file if they have
lower sequence ids than our CLOSE call.
This patch ensures that we recheck the file state once
nfs_wait_on_sequence() has completed waiting.Signed-off-by: Trond Myklebust
-
NFSv4 file state-changing functions such as OPEN, CLOSE, LOCK,... are all
labelled with "sequence identifiers" in order to prevent the server from
reordering RPC requests, as this could cause its file state to
become out of sync with the client.Currently the NFS client code enforces this ordering locally using
semaphores to restrict access to structures until the RPC call is done.
This, of course, only works with synchronous RPC calls, since the
user process must first grab the semaphore.
By dropping semaphores, and instead teaching the RPC engine to hold
the RPC calls until they are ready to be sent, we can extend this
process to work nicely with asynchronous RPC calls too.This patch adds a new list called "rpc_sequence" that defines the order
of the RPC calls to be sent. We add one such list for each state_owner.
When an RPC call is ready to be sent, it checks if it is top of the
rpc_sequence list. If so, it proceeds. If not, it goes back to sleep,
and loops until it hits top of the list.
Once the RPC call has completed, it can then bump the sequence id counter,
and remove itself from the rpc_sequence list, and then wake up the next
sleeper.Note that the state_owner sequence ids and lock_owner sequence ids are
all indexed to the same rpc_sequence list, so OPEN, LOCK,... requests
are all ordered w.r.t. each other.Signed-off-by: Trond Myklebust
-
Currently, call_encode will cause the entire RPC call to abort if it returns
an error. This is unnecessarily rigid, and gets in the way of attempts
to allow the NFSv4 layer to order RPC calls that carry sequence ids.Signed-off-by: Trond Myklebust
-
After a server crash/reboot, rebinding should always retry, otherwise
requests on "hard" mounts will fail when they shouldn't.Test plan:
Run a lock-intensive workload against a server while rebooting the server
repeatedly.Signed-off-by: Chuck Lever
Signed-off-by: Trond Myklebust
18 Oct, 2005
14 commits
-
The following build error happens with 2.6.14-rc4 when CONFIG_KALLSYMS is
not defined. The error message in a fragment of the output was:CC arch/i386/lib/usercopy.o
AR arch/i386/lib/lib.a
/bin/sh: line 1: +@: command not found
make[3]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule.
CHK include/linux/compile.hSigned-off-by: Mark Rustad
Signed-off-by: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
lock_kiocb() was introduced to serialize retrying and cancellation. In the
process of doing so it tried to sleep waiting for KIF_LOCKED while holding
the ctx_lock spinlock. Recent fixes have ensured that multiple concurrent
retries won't be attempted for a given iocb. Cancel has other problems and
has no significant in-tree users that have been complaining about it. So
for the immediate future we'll revert sleeping with the lock held and will
address proper cancellation and retry serialization in the future.Signed-off-by: Zach Brown
Acked-by: Benjamin LaHaise
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Only signal completion after marking request slot as free, otherwise other
processor can free request structure before we finish using it.Signed-off-by: Dmitry Torokhov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix -EIO on /proc/acpi/events after suspends. This actually breaks
suspending by power button in many setups.Signed-off-by: Pavel Machek
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Since Revision 1.10 was released the n_r3964 module wasn't able to receive any
data. The reason for that behavior is because there were some wrong calls of
mod_timer(...) in the function receive_char (...). This patch should fix this
problem and was successfully tested with talking to some kuka industrial
robots.Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Currently you do not get all the map entries on nommu systems because the
start function doesn't index into the list using the value of "pos".Signed-off-by: David McCullough
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This makes call_rcu() keep track of how many events there are on the RCU
list, and cause a reschedule event when the list gets too long.This helps keep RCU event lists down.
Signed-off-by: Linus Torvalds
-
This change makes quirk_intel_ide_combined() dependent on the precise
conditions under which it is needed:* IDE is built in
* IDE SATA option is not set
* ata_piix or ahci drivers are enabledThis fixes an issue where some modular configurations would not cause
the quirk to be enabled.Signed-off-by: Jeff Garzik
Signed-off-by: Linus torvalds -
Make sure we release the task struct properly when releasing pending
timers.release_task() does write_lock_irq(&tasklist_lock), so it can't race
with run_posix_cpu_timers() on any cpu.Signed-off-by: Oleg Nesterov
Signed-off-by: Linus Torvalds -
Oopsable since nfs_wait_on_inode() can get called as part of iput_final().
Unnecessary since the caller had better be damned sure that the inode won't
disappear from underneath it anyway.Signed-off-by: Trond Myklebust
Signed-off-by: Linus Torvalds -
If the data cache has been marked as potentially invalid by nfs_refresh_inode,
we should invalidate it rather than assume that changes are due to our own
activity.Also ensure that we always start with a valid cache before declaring it
to be protected by a delegation.Signed-off-by: Trond Myklebust
Signed-off-by: Linus Torvalds -
During the development of an USB device I found a bug in the handling of
Highspeed HID devices in the kernel.What happened?
Highspeed HID devices are correctly recognized and enumerated by the
kernel. But even if usbhid kernel module is loaded, no HID reports are
received by the kernel.The output of the hardware USB analyzer told me that the host doesn't
even poll for interrupt IN transfers (even the "interrupt in" USB
transfer are polled by the host).After some debugging in hid-core.c I've found the reason.
In case of a highspeed device, the endpoint interval is re-calculated in
driver/usb/input/hid-core.c:line 1669:
/* handle potential highspeed HID correctly */
interval = endpoint->bInterval;
if (dev->speed == USB_SPEED_HIGH)
interval = 1 << (interval - 1);Basically this calculation is correct (refer to USB 2.0 spec, 9.6.6).
This new calculated value of "interval" is used as input for
usb_fill_int_urb:line 1685:
usb_fill_int_urb(hid->urbin, dev, pipe, hid->inbuf, 0,
hid_irq_in, hid, interval);Unfortunately the same calculation as above is done a second time in
usb_fill_int_urb in the file include/linux/usb.h:line 933:
if (dev->speed == USB_SPEED_HIGH)
urb->interval = 1 << (interval - 1);
else
urb->interval = interval;This means, that if the endpoint descriptor (of a high speed device)
specifies e.g. bInterval = 7, the urb->interval gets the value:hid-core.c: interval = 1 << (7-1) = 0x40 = 64
urb->interval = 1 << (interval -1) = 1 << (63) = integer overflowBecause of this the value of urb->interval is sometimes negative and is
rejected in core/urb.c:
line 353:
/* too small? */
if (urb->interval
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds -
Increased use of scatter-gather by usb-storage driver after 2.6.13 has
exposed a buggy codepath in isp116x-hcd, which was probably never
visited before: bug happened only for those urbs, for which
URB_SHORT_NOT_OK was set AND short transfer occurred.The fix attached was tested in 2 ways: (a) it fixed failing
initialization of a flash drive with an embedded hub; (b) the fix was
tested with 'usbtest' against a modified g_zero driver (on top of
net2280), which generated short bulk IN transfers of various lengths
including multiples and non-multiples of max_packet_length.Signed-off-by: Olav Kongas
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds -
Dipankar made RCU limit the batch size to improve latency, but that
approach is unworkable: it can cause the RCU queues to grow without
bounds, since the batch limiter ended up limiting the callbacks.So make the limit much higher, and start planning on instead limiting
the batch size by doing RCU callbacks more often if the queue looks like
it might be growing too long.Signed-off-by: Linus Torvalds
17 Oct, 2005
5 commits
-
Fix the fact that the svideo input will only give input in black/white in
some circumstances. Reason is that in the PCI controller driver (zr36067),
after setting input, we reset norm, which overwrites the input register
with the default. This patch makes it always set the correct value for the
input when changing norm.Signed-off-by: Ronald S. Bultje
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix bug #5404 in kernel bugzilla.
It basically updates the vpx3220 initialization tables with some newer
values that we've had in CVS for a while (and that, for some reason, never
ended up in the kernel... must've gotten lost). Those fix a ~16 pixels
noise at the top of the picture in at least SECAM, although (now that I
think about it) PAL was probably affected, also.Signed-off-by: Ronald S. Bultje
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Fix bug 5441.
I didn't know about messy programs like svgatextmode... Couldn't this be
integrated in some linux/drivers/video/console/svgacon.c ?... So because
of the existence of the svgatextmode program, the kernel is not supposed to
touch to CRT_OVERFLOW/SYNC_END/DISP/DISP_END/OFFSET ?Disabling the check in vgacon_resize() might help indeed, but I'm really
not sure whether it will work for any chipset: in my patch, CRT registers
are set at each console switch, since stty rows/cols apply to consoles
separately...The attached solution is to keep the test, but if it fails, we assume that
the caller knows what it does (i.e. it is svgatextmode) and then disable
any further call to vgacon_doresize. Svgatextmode is usually used to
_expand_ the display, not to shrink it. And it is harmless in the case of
a too big stty rows/cols: the display will just be cropped. I tested it on
my laptop, and it works fine with svgatextmode.A better solution would be that svgatextmode explicitely tells the kernel
not to care about video timing, but for this an interface needs be defined
and svgatextmode be patched.Signed-off-by: Samuel Thibault
Cc: "Antonino A. Daplas"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
It seems that all the list_*_rcu primitives are missing a memory barrier
on the very first dereference. For example,#define list_for_each_rcu(pos, head) \
for (pos = (head)->next; prefetch(pos->next), pos != (head); \
pos = rcu_dereference(pos->next))It will go something like:
pos = (head)->next
prefetch(pos->next)
pos != (head)
do stuff
We're missing a barrier here.
pos = rcu_dereference(pos->next)
fetch pos->next
barrier given by rcu_dereference(pos->next)
store pos
Without the missing barrier, the pos->next value may turn out to be stale.
In fact, if "do stuff" were also dereferencing pos and relying on
list_for_each_rcu to provide the barrier then it may also break.So here is a patch to make sure that we have a barrier for the first
element in the list.Signed-off-by: Herbert Xu
Acked-by: "Paul E. McKenney"
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
As noticed by Nick Piggin, we need to make sure that we check the page
count before we check for PageDirty, since the dirty check is only valid
if the count implies that we're the only possible ones holding the page.We always did do this, but the code needs a read-memory-barrier to make
sure that the orderign is also honored by the CPU.(The writer side is ordered due to the atomic decrement and test on the
page count, see the discussion on linux-kernel)Signed-off-by: Linus Torvalds
16 Oct, 2005
2 commits
-
... otherwise, things like alpha and sparc64 break and break
badly. They define cpu_possible_map to something else in smp.h
*AFTER* having included cpumask.h.If that puppy is a macro, expansion will happen at the actual
caller, when we'd already seen #define cpu_possible_map ... and we will
get the right thing used.As an inline helper it will be tokenized before we get to that
define and that's it; no matter what we define later, it won't affect
anything. We get modules with dependency on cpu_possible_map instead
of the right symbol (phys_cpu_present_map in case of sparc64), or outright
link errors if they are built-in.Signed-off-by: Al Viro
Signed-off-by: David S. Miller -
Signed-off-by: Andrew Morton
Signed-off-by: David S. Miller
15 Oct, 2005
7 commits
-
Kernel version 2.6.13 introduced a regression in the generic USB
serial converter driver (usbserial.o, drivers/usb/serial/generic.c).
The bug manifests, as far as I can tell, whenever you attempt to write
to the device -- the write will never complete (write() returns 0, or
blocks).Signed-off-by: Randall Nortman
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Linus Torvalds -
I am taking over all Megaraid SCSI drivers. Here is the patch for the
MAINTENERS file.Signed-off-by: Neela Syam Kolli
Cc: James Bottomley
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Argument does not agree.
Signed-off-by: Yoshinori Sato
Cc: Paul Mundt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
"proc_smaps_operations" is not defined in case of "CONFIG_MMU=n".
Signed-off-by: Yoshinori Sato
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
