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 <neilb@xxxxxxx> 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 david@xxxxxxxxxxxxx -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>