All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>, Vlastimil Babka <vbabka@suse.cz>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
Date: Mon, 16 Jan 2017 10:59:25 +0100	[thread overview]
Message-ID: <20170116095925.GE13641@dhcp22.suse.cz> (raw)
In-Reply-To: <20170116094851.GD32481@mtr-leonro.local>

On Mon 16-01-17 11:48:51, Leon Romanovsky wrote:
> On Mon, Jan 16, 2017 at 10:37:02AM +0100, Borislav Petkov wrote:
> > On Mon, Jan 16, 2017 at 11:28:40AM +0200, Leon Romanovsky wrote:
> > > On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> > > > From: Borislav Petkov <bp@suse.de>
> > > >
> > > > We wanna know who's doing such a thing. Like slab.c does that.
> > > >
> > > > Signed-off-by: Borislav Petkov <bp@suse.de>
> > > > ---
> > > >  mm/slub.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/mm/slub.c b/mm/slub.c
> > > > index 067598a00849..1b0fa7625d6d 100644
> > > > --- a/mm/slub.c
> > > > +++ b/mm/slub.c
> > > > @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > > >  		flags &= ~GFP_SLAB_BUG_MASK;
> > > >  		pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
> > > >  				invalid_mask, &invalid_mask, flags, &flags);
> > > > +		dump_stack();
> > >
> > > Will it make sense to change these two lines above to WARN(true, .....)?
> >
> > Should be equivalent.
> 
> Almost, except one point - pr_warn and dump_stack have different log
> levels. There is a chance that user won't see pr_warn message above, but
> dump_stack will be always present.
> 
> For WARN_XXX, users will always see message and stack at the same time.

On the other hand WARN* will taint the kernel and this sounds a bit
overreacting for something like a wrong gfp mask which is perfectly
recoverable. Not to mention users who care configured to panic on
warning.

So while I do not have a strong opinion on this I would rather stay with
the dump_stack.


-- 
Michal Hocko
SUSE Labs

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

WARNING: multiple messages have this Message-ID (diff)
From: Michal Hocko <mhocko@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>, Vlastimil Babka <vbabka@suse.cz>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check
Date: Mon, 16 Jan 2017 10:59:25 +0100	[thread overview]
Message-ID: <20170116095925.GE13641@dhcp22.suse.cz> (raw)
In-Reply-To: <20170116094851.GD32481@mtr-leonro.local>

On Mon 16-01-17 11:48:51, Leon Romanovsky wrote:
> On Mon, Jan 16, 2017 at 10:37:02AM +0100, Borislav Petkov wrote:
> > On Mon, Jan 16, 2017 at 11:28:40AM +0200, Leon Romanovsky wrote:
> > > On Mon, Jan 16, 2017 at 10:16:43AM +0100, Borislav Petkov wrote:
> > > > From: Borislav Petkov <bp@suse.de>
> > > >
> > > > We wanna know who's doing such a thing. Like slab.c does that.
> > > >
> > > > Signed-off-by: Borislav Petkov <bp@suse.de>
> > > > ---
> > > >  mm/slub.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/mm/slub.c b/mm/slub.c
> > > > index 067598a00849..1b0fa7625d6d 100644
> > > > --- a/mm/slub.c
> > > > +++ b/mm/slub.c
> > > > @@ -1623,6 +1623,7 @@ static struct page *new_slab(struct kmem_cache *s, gfp_t flags, int node)
> > > >  		flags &= ~GFP_SLAB_BUG_MASK;
> > > >  		pr_warn("Unexpected gfp: %#x (%pGg). Fixing up to gfp: %#x (%pGg). Fix your code!\n",
> > > >  				invalid_mask, &invalid_mask, flags, &flags);
> > > > +		dump_stack();
> > >
> > > Will it make sense to change these two lines above to WARN(true, .....)?
> >
> > Should be equivalent.
> 
> Almost, except one point - pr_warn and dump_stack have different log
> levels. There is a chance that user won't see pr_warn message above, but
> dump_stack will be always present.
> 
> For WARN_XXX, users will always see message and stack at the same time.

On the other hand WARN* will taint the kernel and this sounds a bit
overreacting for something like a wrong gfp mask which is perfectly
recoverable. Not to mention users who care configured to panic on
warning.

So while I do not have a strong opinion on this I would rather stay with
the dump_stack.


-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2017-01-16  9:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-16  9:16 [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check Borislav Petkov
2017-01-16  9:28 ` Leon Romanovsky
2017-01-16  9:37   ` Borislav Petkov
2017-01-16  9:48     ` Leon Romanovsky
2017-01-16  9:55       ` Borislav Petkov
2017-01-16 10:09         ` Leon Romanovsky
2017-01-16 10:13           ` Borislav Petkov
2017-01-16 10:18             ` Leon Romanovsky
2017-01-16  9:59       ` Michal Hocko [this message]
2017-01-16  9:59         ` Michal Hocko
2017-01-16  9:38 ` Michal Hocko
2017-01-16  9:38   ` Michal Hocko
2017-01-16 10:08 ` Vlastimil Babka
2017-01-16 10:08   ` Vlastimil Babka

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=20170116095925.GE13641@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=bp@alien8.de \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /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.