From: Dave Chinner <david@fromorbit.com>
To: NeilBrown <neilb@suse.de>
Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org,
linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 13/19] MM: set PF_FSTRANS while allocating per-cpu memory to avoid deadlock.
Date: Wed, 16 Apr 2014 16:30:38 +1000 [thread overview]
Message-ID: <20140416063038.GH15995@dastard> (raw)
In-Reply-To: <20140416162201.5dc9ff5c@notabene.brown>
On Wed, Apr 16, 2014 at 04:22:01PM +1000, NeilBrown wrote:
> On Wed, 16 Apr 2014 15:49:42 +1000 Dave Chinner <david@fromorbit.com> 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@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...
>
> 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).
Given that we've had problems getting gfp flags propagated into the
VM code (vmalloc, I'm looking at you!) making the current task
carry the valid memory allocation and reclaim context mask woul dbe
a good idea. That's effectively the problem PF_MEMALLOC_NOIO is
working around, and we've recently added it to XFS to silence all
the lockdep warnings using vm_map_ram in GFP_NOFS contexts have been
causing us....
> > 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?
Better than PF_FSTRANS, that's for sure ;)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-04-16 6:30 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 4:03 [PATCH/RFC 00/19] Support loop-back NFS mounts NeilBrown
2014-04-16 4:03 ` [PATCH 13/19] MM: set PF_FSTRANS while allocating per-cpu memory to avoid deadlock NeilBrown
2014-04-16 5:49 ` Dave Chinner
2014-04-16 6:22 ` NeilBrown
2014-04-16 6:30 ` Dave Chinner [this message]
2014-04-16 4:03 ` [PATCH 02/19] lockdep: lockdep_set_current_reclaim_state should save old value NeilBrown
2014-04-16 4:03 ` [PATCH 09/19] XFS: ensure xfs_file_*_read cannot deadlock in memory allocation NeilBrown
2014-04-16 6:04 ` Dave Chinner
2014-04-16 6:27 ` NeilBrown
2014-04-16 6:31 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 07/19] nfsd and VM: use PF_LESS_THROTTLE to avoid throttle in shrink_inactive_list NeilBrown
2014-04-16 4:03 ` [PATCH 14/19] driver core: set PF_FSTRANS while holding gdp_mutex NeilBrown
2014-04-16 4:03 ` [PATCH 11/19] FS: set PF_FSTRANS while holding mmap_sem in exec.c NeilBrown
2014-04-16 4:03 ` [PATCH 10/19] NET: set PF_FSTRANS while holding sk_lock NeilBrown
2014-04-16 5:13 ` Eric Dumazet
2014-04-16 5:47 ` NeilBrown
2014-04-16 13:00 ` David Miller
2014-04-17 2:38 ` NeilBrown
2014-04-16 4:03 ` [PATCH 12/19] NET: set PF_FSTRANS while holding rtnl_lock NeilBrown
2014-04-16 4:03 ` [PATCH 01/19] Promote current_{set, restore}_flags_nested from xfs to global NeilBrown
2014-04-16 4:03 ` [PATCH 04/19] Make effect of PF_FSTRANS to disable __GFP_FS universal NeilBrown
2014-04-16 5:37 ` Dave Chinner
2014-04-16 6:17 ` NeilBrown
2014-04-17 1:03 ` NeilBrown
2014-04-17 4:41 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 05/19] SUNRPC: track whether a request is coming from a loop-back interface NeilBrown
2014-04-16 14:47 ` Jeff Layton
2014-04-16 23:25 ` NeilBrown
2014-04-16 4:03 ` [PATCH 08/19] Set PF_FSTRANS while write_cache_pages calls ->writepage NeilBrown
2014-04-16 4:03 ` [PATCH 03/19] lockdep: improve scenario messages for RECLAIM_FS errors NeilBrown
2014-04-16 7:22 ` Peter Zijlstra
2014-04-16 4:03 ` [PATCH 06/19] nfsd: set PF_FSTRANS for nfsd threads NeilBrown
2014-04-16 7:28 ` Peter Zijlstra
2014-04-16 4:03 ` [PATCH 15/19] nfsd: set PF_FSTRANS when client_mutex is held NeilBrown
2014-04-16 4:03 ` [PATCH 18/19] nfsd: set PF_FSTRANS during nfsd4_do_callback_rpc NeilBrown
2014-04-16 4:03 ` [PATCH 16/19] VFS: use GFP_NOFS rather than GFP_KERNEL in __d_alloc NeilBrown
2014-04-16 6:25 ` Dave Chinner
2014-04-16 6:49 ` NeilBrown
2014-04-16 9:00 ` Dave Chinner
2014-04-17 0:51 ` NeilBrown
2014-04-17 5:58 ` Dave Chinner
2014-04-16 4:03 ` [PATCH 17/19] VFS: set PF_FSTRANS while namespace_sem is held NeilBrown
2014-04-16 4:46 ` Al Viro
2014-04-16 5:52 ` NeilBrown
[not found] ` <20140416155230.4d02e4b9-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2014-04-16 16:37 ` Al Viro
2014-04-16 4:03 ` [PATCH 19/19] XFS: set PF_FSTRANS while ilock is held in xfs_free_eofblocks NeilBrown
2014-04-16 6:18 ` Dave Chinner
2014-04-16 14:42 ` [PATCH/RFC 00/19] Support loop-back NFS mounts Jeff Layton
2014-04-17 0:20 ` NeilBrown
2014-04-17 1:27 ` Dave Chinner
2014-04-17 1:50 ` NeilBrown
2014-04-17 4:23 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140416063038.GH15995@dastard \
--to=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox