On Wed, 16 Apr 2014 15:49:42 +1000 Dave Chinner <david@xxxxxxxxxxxxx> wrote: > 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... We are (effectively) passing a gfp mask around, except that it lives in 'current' rather than lots of other places. I actually like the idea of discarding PF_MEMALLOC, PF_FSTRANS and PF_MEMALLOC_NOIO, and just having current->gfp_allowed_mask (to match the global variable of the same name). > > And, again, PF_FSTRANS looks plainly wrong in this code - it sure > isn't a fs transaction context we are worried about here... So would PF_MEMALLOC_NOFS work for you? NeilBrown
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
