On Sat, Jan 15, 2011 at 1:52 AM, Jeff Moyer <jmoyer@xxxxxxxxxx> wrote: > Nick Piggin <npiggin@xxxxxxxxx> writes: > >> Hi, >> >> While hunting down a bug in NFS's AIO, I believe I found this >> buggy code... >> >> fs: aio fix rcu ioctx lookup >> >> aio-dio-invalidate-failure GPFs in aio_put_req from io_submit. >> >> lookup_ioctx doesn't implement the rcu lookup pattern properly. >> rcu_read_lock does not prevent refcount going to zero, so we >> might take a refcount on a zero count ioctx. > > So, does this patch fix the problem? You didn't actually say.... No, it seemd to be an NFS AIO problem, although it was a slightly older kernel so I'll re test after -rc1 if I haven't heard back about it. Do you agree with the theoretical problem? I didn't try to write a racer to break it yet. Inserting a delay before the get_ioctx might do the trick. >> Signed-off-by: Nick Piggin <npiggin@xxxxxxxxx> >> >> Index: linux-2.6/fs/aio.c >> =================================================================== >> --- linux-2.6.orig/fs/aio.c 2011-01-14 00:29:00.000000000 +1100 >> +++ linux-2.6/fs/aio.c 2011-01-14 11:31:47.000000000 +1100 >> @@ -239,15 +239,23 @@ static void __put_ioctx(struct kioctx *c >> call_rcu(&ctx->rcu_head, ctx_rcu_free); >> } >> >> -#define get_ioctx(kioctx) do { \ >> - BUG_ON(atomic_read(&(kioctx)->users) <= 0); \ >> - atomic_inc(&(kioctx)->users); \ >> -} while (0) >> -#define put_ioctx(kioctx) do { \ >> - BUG_ON(atomic_read(&(kioctx)->users) <= 0); \ >> - if (unlikely(atomic_dec_and_test(&(kioctx)->users))) \ >> - __put_ioctx(kioctx); \ >> -} while (0) >> +static inline void get_ioctx(struct kioctx *kioctx) >> +{ >> + BUG_ON(atomic_read(&kioctx->users) <= 0); >> + atomic_inc(&kioctx->users); >> +} >> + >> +static inline int try_get_ioctx(struct kioctx *kioctx) >> +{ >> + return atomic_inc_not_zero(&kioctx->users); >> +} >> + >> +static inline void put_ioctx(struct kioctx *kioctx) >> +{ >> + BUG_ON(atomic_read(&kioctx->users) <= 0); >> + if (unlikely(atomic_dec_and_test(&kioctx->users))) >> + __put_ioctx(kioctx); >> +} > > Why did you switch from macros? Personal preference? Can you at least > mention it in the changelog? Yeah, I couldn't bring myself to add another macro :) I can mention it, sure. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html