All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Qu Wenruo <quwenruo@cn.fujitsu.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	xfs@oss.sgi.com, linux-mm@kvack.org,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: Xfs lockdep warning with for-dave-for-4.6 branch
Date: Thu, 2 Jun 2016 17:11:16 +0200	[thread overview]
Message-ID: <20160602151116.GD3190@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160602145048.GS1995@dhcp22.suse.cz>

On Thu, Jun 02, 2016 at 04:50:49PM +0200, Michal Hocko wrote:
> On Wed 01-06-16 20:16:17, Peter Zijlstra wrote:

> > 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

Bugger :/ You're right, that would fail.

So how about doing:

#define __GFP_NOLOCKDEP	(1u << __GFP_BITS_SHIFT)

this means it cannot be part of address_space::flags or
radix_tree_root::gfp_mask, but that might not be a bad thing.

And this solves the scarcity thing, because per pagemap we need to have
5 'spare' bits anyway.

> 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.

With scope I mostly meant the fact that you have two calls that you need
to pair up. That's not really nice as you can 'annotate' a _lot_ of code
in between. I prefer the narrower annotations where you annotate a
single specific site.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Michal Hocko <mhocko@kernel.org>
Cc: Dave Chinner <david@fromorbit.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Qu Wenruo <quwenruo@cn.fujitsu.com>,
	xfs@oss.sgi.com, linux-mm@kvack.org,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: Xfs lockdep warning with for-dave-for-4.6 branch
Date: Thu, 2 Jun 2016 17:11:16 +0200	[thread overview]
Message-ID: <20160602151116.GD3190@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160602145048.GS1995@dhcp22.suse.cz>

On Thu, Jun 02, 2016 at 04:50:49PM +0200, Michal Hocko wrote:
> On Wed 01-06-16 20:16:17, Peter Zijlstra wrote:

> > 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

Bugger :/ You're right, that would fail.

So how about doing:

#define __GFP_NOLOCKDEP	(1u << __GFP_BITS_SHIFT)

this means it cannot be part of address_space::flags or
radix_tree_root::gfp_mask, but that might not be a bad thing.

And this solves the scarcity thing, because per pagemap we need to have
5 'spare' bits anyway.

> 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.

With scope I mostly meant the fact that you have two calls that you need
to pair up. That's not really nice as you can 'annotate' a _lot_ of code
in between. I prefer the narrower annotations where you annotate a
single specific site.

--
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>

  reply	other threads:[~2016-06-02 15:11 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-12  5:53 Xfs lockdep warning with for-dave-for-4.6 branch Qu Wenruo
2016-05-12  5:57 ` Darrick J. Wong
2016-05-12  8:03   ` Dave Chinner
2016-05-13 16:03     ` Michal Hocko
2016-05-13 16:03       ` Michal Hocko
2016-05-16 10:41       ` Peter Zijlstra
2016-05-16 10:41         ` Peter Zijlstra
2016-05-16 13:05         ` Michal Hocko
2016-05-16 13:05           ` Michal Hocko
2016-05-16 13:25           ` Peter Zijlstra
2016-05-16 13:25             ` Peter Zijlstra
2016-05-16 23:10             ` Dave Chinner
2016-05-16 23:10               ` Dave Chinner
2016-05-17 14:49               ` Peter Zijlstra
2016-05-17 14:49                 ` Peter Zijlstra
2016-05-17 22:35                 ` Dave Chinner
2016-05-17 22:35                   ` Dave Chinner
2016-05-18  7:20                   ` Peter Zijlstra
2016-05-18  7:20                     ` Peter Zijlstra
2016-05-18  8:25                     ` Michal Hocko
2016-05-18  8:25                       ` Michal Hocko
2016-05-18  9:49                       ` Peter Zijlstra
2016-05-18  9:49                         ` Peter Zijlstra
2016-05-18 11:31                         ` Michal Hocko
2016-05-18 11:31                           ` Michal Hocko
2016-05-19  8:11                   ` Peter Zijlstra
2016-05-19  8:11                     ` Peter Zijlstra
2016-05-20  0:17                     ` Dave Chinner
2016-05-20  0:17                       ` Dave Chinner
2016-06-01 13:17                       ` Michal Hocko
2016-06-01 13:17                         ` Michal Hocko
2016-06-01 18:16                         ` Peter Zijlstra
2016-06-01 18:16                           ` Peter Zijlstra
2016-06-02 14:50                           ` Michal Hocko
2016-06-02 14:50                             ` Michal Hocko
2016-06-02 15:11                             ` Peter Zijlstra [this message]
2016-06-02 15:11                               ` Peter Zijlstra
2016-06-02 15:46                               ` Michal Hocko
2016-06-02 15:46                                 ` Michal Hocko
2016-06-02 23:22                                 ` Dave Chinner
2016-06-02 23:22                                   ` Dave Chinner
2016-06-06 12:20                                   ` Michal Hocko
2016-06-06 12:20                                     ` Michal Hocko
2016-06-15  7:21                                     ` Dave Chinner
2016-06-15  7:21                                       ` Dave Chinner
2016-06-21 14:26                                       ` Michal Hocko
2016-06-21 14:26                                         ` Michal Hocko
2016-06-22  1:03                                         ` Dave Chinner
2016-06-22  1:03                                           ` Dave Chinner
2016-06-22 12:38                                           ` Michal Hocko
2016-06-22 12:38                                             ` Michal Hocko
2016-06-22 22:58                                             ` Dave Chinner
2016-06-22 22:58                                               ` Dave Chinner
2016-06-23 11:35                                               ` Michal Hocko
2016-06-23 11:35                                                 ` Michal Hocko
2016-10-06 13:04                           ` Michal Hocko
2016-10-06 13:04                             ` Michal Hocko
2016-10-17 13:49                             ` Michal Hocko
2016-10-17 13:49                               ` Michal Hocko
2016-10-19  0:33                             ` Dave Chinner
2016-10-19  0:33                               ` Dave Chinner
2016-10-19  5:30                               ` Dave Chinner
2016-10-19  5:30                                 ` Dave Chinner
2016-10-19  8:33                             ` Peter Zijlstra
2016-10-19  8:33                               ` Peter Zijlstra
2016-10-19 12:06                               ` Michal Hocko
2016-10-19 12:06                                 ` Michal Hocko
2016-10-19 21:49                                 ` Dave Chinner
2016-10-19 21:49                                   ` Dave Chinner
2016-10-20  7:15                                   ` Michal Hocko
2016-10-20  7:15                                     ` Michal Hocko

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=20160602151116.GD3190@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=darrick.wong@oracle.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.