linux.git/fs/aio.c, branch v2.6.26

uml: activate_mm: remove the dead PF_BORROWED_MM check

2008-06-06T18:36:22+00:00

use_mm() was changed to use switch_mm() instead of activate_mm(), since
then nobody calls (and nobody should call) activate_mm() with
PF_BORROWED_MM bit set.

As Jeff Dike pointed out, we can also remove the "old != new" check, it is
always true.

Signed-off-by: Oleg Nesterov 
Cc: Jeff Dike 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

debugobjects: add timer specific object debugging code

2008-04-30T15:29:53+00:00

Add calls to the generic object debugging infrastructure and provide fixup
functions which allow to keep the system alive when recoverable problems have
been detected by the object debugging core code.

Signed-off-by: Thomas Gleixner 
Acked-by: Ingo Molnar 
Cc: Greg KH 
Cc: Randy Dunlap 
Cc: Kay Sievers 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

aio: fix misleading comments

2008-04-29T15:06:29+00:00

The FIXME comments are inaccurate.
The locking comment over lookup_ioctx() is wrong.

Signed-off-by: Jeff Moyer 
Signed-off-by: Zach Brown 
Signed-off-by: Shen Feng 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Remove duplicated unlikely() in IS_ERR()

2008-04-29T15:06:25+00:00

Some drivers have duplicated unlikely() macros.  IS_ERR() already has
unlikely() in itself.

This patch cleans up such pointless code.

Signed-off-by: Hirofumi Nakagawa 
Acked-by: David S. Miller 
Acked-by: Jeff Garzik 
Cc: Paul Clements 
Cc: Richard Purdie 
Cc: Alessandro Zummo 
Cc: David Brownell 
Cc: James Bottomley 
Cc: Michael Halcrow 
Cc: Anton Altaparmakov 
Cc: Al Viro 
Cc: Carsten Otte 
Cc: Patrick McHardy 
Cc: Paul Mundt 
Cc: Jaroslav Kysela 
Cc: Takashi Iwai 
Acked-by: Mike Frysinger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/aio.c: make 3 functions static

2008-04-29T15:06:00+00:00

Make the following needlessly global functions static:

- __put_ioctx()
- lookup_ioctx()
- io_submit_one()

Signed-off-by: Adrian Bunk 
Cc: Zach Brown 
Cc: Benjamin LaHaise 
Cc: Badari Pulavarty 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

aio: io_getevents() should return if io_destroy() is invoked

2008-04-28T15:58:17+00:00

This patch wakes up a thread waiting in io_getevents if another thread
destroys the context.  This was tested using a small program that spawns a
thread to wait in io_getevents while the parent thread destroys the io context
and then waits for the getevents thread to exit.  Without this patch, the
program hangs indefinitely.  With the patch, the program exits as expected.

Signed-off-by: Jeff Moyer 
Cc: Zach Brown 
Cc: Christopher Smith 
Cc: Benjamin LaHaise 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

eventfd/kaio integration fix

2008-04-11T15:06:43+00:00

Jeff Roberson discovered a race when using kaio eventfd based notifications.
When it occurs it can lead tomissed wakeups and hung userspace.

This patch fixes the race by moving the notification inside the spinlocked
section of kaio.  The operation is safe since eventfd spinlock and kaio one
are unrelated.

Signed-off-by: Davide Libenzi 
Cc: Zach Brown 
Cc: Jeff Roberson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

asmlinkage_protect sys_io_getevents

2008-04-11T00:28:26+00:00

Use asmlinkage_protect in sys_io_getevents, because GCC for i386 with
CONFIG_FRAME_POINTER=n can decide to clobber an argument word on the
stack, i.e. the user struct pt_regs.  Here the problem is not a tail
call, but just the compiler's use of the stack when it inlines and
optimizes the body of the called function.  This seems to avoid it.

Signed-off-by: Roland McGrath 
Signed-off-by: Linus Torvalds

aio: bad AIO race in aio_complete() leads to process hang

2008-03-20T01:53:35+00:00

My group ran into a AIO process hang on a 2.6.24 kernel with the process
sleeping indefinitely in io_getevents(2) waiting for the last wakeup to come
and it never would.

We ran the tests on x86_64 SMP.  The hang only occurred on a Xeon box
("Clovertown") but not a Core2Duo ("Conroe").  On the Xeon, the L2 cache isn't
shared between all eight processors, but is L2 is shared between between all
two processors on the Core2Duo we use.

My analysis of the hang is if you go down to the second while-loop
in read_events(), what happens on processor #1:
	1) add_wait_queue_exclusive() adds thread to ctx->wait
	2) aio_read_evt() to check tail
	3) if aio_read_evt() returned 0, call [io_]schedule() and sleep

In aio_complete() with processor #2:
	A) info->tail = tail;
	B) waitqueue_active(&ctx->wait)
	C) if waitqueue_active() returned non-0, call wake_up()

The way the code is written, step 1 must be seen by all other processors
before processor 1 checks for pending events in step 2 (that were recorded by
step A) and step A by processor 2 must be seen by all other processors
(checked in step 2) before step B is done.

The race I believed I was seeing is that steps 1 and 2 were
effectively swapped due to the __list_add() being delayed by the L2
cache not shared by some of the other processors.  Imagine:
proc 2: just before step A
proc 1, step 1: adds to ctx->wait, but is not visible by other processors yet
proc 1, step 2: checks tail and sees no pending events
proc 2, step A: updates tail
proc 1, step 3: calls [io_]schedule() and sleeps
proc 2, step B: checks ctx->wait, but sees no one waiting, skips wakeup
                so proc 1 sleeps indefinitely

My patch adds a memory barrier between steps A and B.  It ensures that the
update in step 1 gets seen on processor 2 before continuing.  If processor 1
was just before step 1, the memory barrier makes sure that step A (update
tail) gets seen by the time processor 1 makes it to step 2 (check tail).

Before the patch our AIO process would hang virtually 100% of the time.  After
the patch, we have yet to see the process ever hang.

Signed-off-by: Quentin Barnes 
Reviewed-by: Zach Brown 
Cc: Benjamin LaHaise 
Cc: 
Cc: Nick Piggin 
Signed-off-by: Andrew Morton 
[ We should probably disallow that "if (waitqueue_active()) wake_up()"
  coding pattern, because it's so often buggy wrt memory ordering ]
Signed-off-by: Linus Torvalds

aio: negative offset should return -EINVAL

2008-02-08T17:22:33+00:00

An AIO read or write should return -EINVAL if the offset is negative.
This check matches the one in pread and pwrite.

This was found by the libaio test suite.

Signed-off-by: Rusty Russell 
Acked-by: Zach Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds