Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751915AbaDPGam (ORCPT ); Wed, 16 Apr 2014 02:30:42 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:28800 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751052AbaDPGak (ORCPT ); Wed, 16 Apr 2014 02:30:40 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsxSALMiTlN5LEcvPGdsb2JhbABYgwaDU4UKtgyFXoEcFwMBAQEBODWCJQEBAQMBJxMcIxAIAxgJJQ8FJQMHGhMbh1kHxWEXFo5MB4Q4BJhiimeJUoFRKw Date: Wed, 16 Apr 2014 16:30:38 +1000 From: Dave Chinner To: NeilBrown 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. Message-ID: <20140416063038.GH15995@dastard> References: <20140416033623.10604.69237.stgit@notabene.brown> <20140416040336.10604.67456.stgit@notabene.brown> <20140416054942.GD15995@dastard> <20140416162201.5dc9ff5c@notabene.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140416162201.5dc9ff5c@notabene.brown> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 16, 2014 at 04:22:01PM +1000, NeilBrown wrote: > On Wed, 16 Apr 2014 15:49:42 +1000 Dave Chinner 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: > > > > > > [] pcpu_alloc+0x49/0x960 > > > [] __alloc_percpu+0xb/0x10 > > > [] loopback_dev_init+0x17/0x60 > > > [] register_netdevice+0xec/0x550 > > > [] register_netdev+0x15/0x30 > > > > > > Signed-off-by: NeilBrown > > > > 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/