Re: [PATCH 0/1] ptrace: task_clear_jobctl_trapping()->wake_up_bit() needs mb()

[Andrew Morton]

On Fri, 16 May 2014 15:51:16 +0200 Oleg Nesterov <oleg@xxxxxxxxxx> wrote:

> On 05/14, Peter Zijlstra wrote:
> >
> > On Wed, May 14, 2014 at 06:11:52PM +0200, Oleg Nesterov wrote:
> > >
> > > I mean, we do not need mb() before __wake_up(). We need it only because
> > > __wake_up_bit() checks waitqueue_active().
> > >
> > >
> > > And at least
> > >
> > > 	fs/cachefiles/namei.c:cachefiles_delete_object()
> > > 	fs/block_dev.c:blkdev_get()
> > > 	kernel/signal.c:task_clear_jobctl_trapping()
> > > 	security/keys/gc.c:key_garbage_collector()
> > >
> > > look obviously wrong.
> > >
> > > I would be happy to send the fix, but do I need to split it per-file?
> > > Given that it is trivial, perhaps I can send a single patch?
> >
> > Since its all the same issue a single patch would be fine I think.
> 
> Actually blkdev_get() is fine, it relies on bdev_lock. But bd_prepare_to_claim()
> is the good example of abusing bit_waitqueue(). Not only it is itself suboptimal,
> this doesn't allow to optimize wake_up_bit-like paths. And there are more, say,
> inode_sleep_on_writeback(). Plus we have wait_on_atomic_t() which I think should
> be generalized or even unified with the regular wait_on_bit(). Perhaps I'll try
> to do this later, fortunately the recent patch from Neil greatly reduced the
> number of "action" functions.
> 
> As for cachefiles_walk_to_object() and key_garbage_collector(), it still seems
> to me they need smp_mb__after_clear_bit() but I'll leave this to David, I am
> not comfortable to change the code I absolutely do not understand. In particular,
> I fail to understand why key_garbage_collector() does smp_mb() before clear_bit().
> At least it could be smp_mb__before_clear_bit().

This is all quite convincing evidence that these interfaces are too
tricky for regular kernel developers to use. 

Can we fix them?

One way would be to make the interfaces safe to use and provide
lower-level no-barrier interfaces for use by hot-path code where the
author knows what he/she is doing.  And there are probably other ways.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/