From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 88C2D7CA3 for ; Thu, 2 Jun 2016 09:50:53 -0500 (CDT) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4A9A6304062 for ; Thu, 2 Jun 2016 07:50:53 -0700 (PDT) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by cuda.sgi.com with ESMTP id 9Rvim8EJDedoXNhq (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 02 Jun 2016 07:50:51 -0700 (PDT) Received: by mail-wm0-f48.google.com with SMTP id a136so234159450wme.0 for ; Thu, 02 Jun 2016 07:50:51 -0700 (PDT) Date: Thu, 2 Jun 2016 16:50:49 +0200 From: Michal Hocko Subject: Re: Xfs lockdep warning with for-dave-for-4.6 branch Message-ID: <20160602145048.GS1995@dhcp22.suse.cz> References: <20160516104130.GK3193@twins.programming.kicks-ass.net> <20160516130519.GJ23146@dhcp22.suse.cz> <20160516132541.GP3193@twins.programming.kicks-ass.net> <20160516231056.GE18496@dastard> <20160517144912.GZ3193@twins.programming.kicks-ass.net> <20160517223549.GV26977@dastard> <20160519081146.GS3193@twins.programming.kicks-ass.net> <20160520001714.GC26977@dastard> <20160601131758.GO26601@dhcp22.suse.cz> <20160601181617.GV3190@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160601181617.GV3190@twins.programming.kicks-ass.net> 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: Peter Zijlstra Cc: Qu Wenruo , "Darrick J. Wong" , xfs@oss.sgi.com, linux-mm@kvack.org, Ingo Molnar On Wed 01-06-16 20:16:17, Peter Zijlstra wrote: > On Wed, Jun 01, 2016 at 03:17:58PM +0200, Michal Hocko wrote: > > Thanks Dave for your detailed explanation again! Peter do you have any > > other idea how to deal with these situations other than opt out from > > lockdep reclaim machinery? > > > > If not I would rather go with an annotation than a gfp flag to be honest > > but if you absolutely hate that approach then I will try to check wheter > > a CONFIG_LOCKDEP GFP_FOO doesn't break something else. Otherwise I would > > steal the description from Dave's email and repost my patch. > > > > I plan to repost my scope gfp patches in few days and it would be good > > to have some mechanism to drop those GFP_NOFS to paper over lockdep > > false positives for that. > > Right; sorry I got side-tracked in other things again. > > So my favourite is the dedicated GFP flag, but if that's unpalatable for > the mm folks then something like the below might work. It should be > similar in effect to your proposal, except its more limited in scope. [...] > @@ -2876,11 +2883,36 @@ static void __lockdep_trace_alloc(gfp_t gfp_mask, unsigned long flags) > if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))) > return; > > + /* > + * Skip _one_ allocation as per the lockdep_skip_alloc() request. > + * Must be done last so that we don't loose the annotation for > + * GFP_ATOMIC like things from IRQ or other nesting contexts. > + */ > + if (current->lockdep_reclaim_gfp & __GFP_SKIP_ALLOC) { > + current->lockdep_reclaim_gfp &= ~__GFP_SKIP_ALLOC; > + return; > + } > + > mark_held_locks(curr, RECLAIM_FS); > } I might be missing something but does this work actually? Say you would want a kmalloc(size), it would call slab_alloc_node slab_pre_alloc_hook lockdep_trace_alloc [...] ____cache_alloc_node cache_grow_begin kmem_getpages __alloc_pages_node __alloc_pages_nodemask lockdep_trace_alloc I understand your concerns about the scope but usually all allocations have to be __GFP_NOFS or none in the same scope so I would see it as a huge deal. -- Michal Hocko SUSE Labs _______________________________________________ xfs mailing list xfs@oss.sgi.com http://oss.sgi.com/mailman/listinfo/xfs