On Wed, Apr 16, 2014 at 02:03:36PM +1000, NeilBrown wrote: > lockdep reports a locking chain > > sk_lock-AF_INET --> rtnl_mutex --> pcpu_alloc_mutex > > As sk_lock may be needed to reclaim memory, allowing that > reclaim while pcu_alloc_mutex is held can lead to deadlock. > So set PF_FSTRANS while it is help to avoid the FS reclaim. > > pcpu_alloc_mutex can be taken when rtnl_mutex is held: > > [<ffffffff8117f979>] pcpu_alloc+0x49/0x960 > [<ffffffff8118029b>] __alloc_percpu+0xb/0x10 > [<ffffffff8193b9f7>] loopback_dev_init+0x17/0x60 > [<ffffffff81aaf30c>] register_netdevice+0xec/0x550 > [<ffffffff81aaf785>] register_netdev+0x15/0x30 > > Signed-off-by: NeilBrown <ne...@suse.de>
This looks like a workaround to avoid passing a gfp mask around to describe the context in which the allocation is taking place. Whether or not that's the right solution, I can't say, but spreading this "we can turn off all reclaim of filesystem objects" mechanism all around the kernel doesn't sit well with me... And, again, PF_FSTRANS looks plainly wrong in this code - it sure isn't a fs transaction context we are worried about here... -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
