From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 13D3C7F4E for ; Wed, 16 Apr 2014 00:49:50 -0500 (CDT) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id DF85F8F8049 for ; Tue, 15 Apr 2014 22:49:49 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id oortFk9al9iZPpM2 for ; Tue, 15 Apr 2014 22:49:48 -0700 (PDT) Date: Wed, 16 Apr 2014 15:49:42 +1000 From: Dave Chinner Subject: Re: [PATCH 13/19] MM: set PF_FSTRANS while allocating per-cpu memory to avoid deadlock. Message-ID: <20140416054942.GD15995@dastard> References: <20140416033623.10604.69237.stgit@notabene.brown> <20140416040336.10604.67456.stgit@notabene.brown> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140416040336.10604.67456.stgit@notabene.brown> List-Id: XFS Filesystem from SGI List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: xfs-bounces@oss.sgi.com Sender: xfs-bounces@oss.sgi.com To: NeilBrown Cc: linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, xfs@oss.sgi.com 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... 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@fromorbit.com _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs