On Fri, 16 May 2014 15:51:16 +0200 Oleg Nesterov <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
