* [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check @ 2017-01-16 9:16 Borislav Petkov 2017-01-16 9:28 ` Leon Romanovsky ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Borislav Petkov @ 2017-01-16 9:16 UTC (permalink / raw) To: Michal Hocko, Vlastimil Babka; +Cc: Linux MM, LKML 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(); } return allocate_slab(s, -- 2.11.0 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 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:38 ` Michal Hocko 2017-01-16 10:08 ` Vlastimil Babka 2 siblings, 1 reply; 14+ messages in thread From: Leon Romanovsky @ 2017-01-16 9:28 UTC (permalink / raw) To: Borislav Petkov; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML [-- Attachment #1: Type: text/plain, Size: 814 bytes --] 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, .....)? > } > > return allocate_slab(s, > -- > 2.11.0 > [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:28 ` Leon Romanovsky @ 2017-01-16 9:37 ` Borislav Petkov 2017-01-16 9:48 ` Leon Romanovsky 0 siblings, 1 reply; 14+ messages in thread From: Borislav Petkov @ 2017-01-16 9:37 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML 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. I'd even go a step further and make this a small inline function, something like warn_unexpected_gfp(flags) or so and call it from both from slab.c and slub.c. Depending on what mm folks prefer, that is. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:37 ` Borislav Petkov @ 2017-01-16 9:48 ` Leon Romanovsky 2017-01-16 9:55 ` Borislav Petkov 2017-01-16 9:59 ` Michal Hocko 0 siblings, 2 replies; 14+ messages in thread From: Leon Romanovsky @ 2017-01-16 9:48 UTC (permalink / raw) To: Borislav Petkov; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML [-- Attachment #1: Type: text/plain, Size: 1581 bytes --] 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. > > I'd even go a step further and make this a small inline function, > something like warn_unexpected_gfp(flags) or so and call it from both > from slab.c and slub.c. > > Depending on what mm folks prefer, that is. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:48 ` Leon Romanovsky @ 2017-01-16 9:55 ` Borislav Petkov 2017-01-16 10:09 ` Leon Romanovsky 2017-01-16 9:59 ` Michal Hocko 1 sibling, 1 reply; 14+ messages in thread From: Borislav Petkov @ 2017-01-16 9:55 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML On Mon, Jan 16, 2017 at 11:48:51AM +0200, Leon Romanovsky wrote: > Almost, except one point - pr_warn and dump_stack have different log Actually, Michal pointed out on IRC a more relevant difference: WARN() taints the kernel and we don't want that for GFP flags misuse. Also, from looking at __warn(), it checks panic_on_warn and we explode if set. So no, we probably don't want WARN() here. -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:55 ` Borislav Petkov @ 2017-01-16 10:09 ` Leon Romanovsky 2017-01-16 10:13 ` Borislav Petkov 0 siblings, 1 reply; 14+ messages in thread From: Leon Romanovsky @ 2017-01-16 10:09 UTC (permalink / raw) To: Borislav Petkov; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML [-- Attachment #1: Type: text/plain, Size: 708 bytes --] On Mon, Jan 16, 2017 at 10:55:22AM +0100, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 11:48:51AM +0200, Leon Romanovsky wrote: > > Almost, except one point - pr_warn and dump_stack have different log > > Actually, Michal pointed out on IRC a more relevant difference: > > WARN() taints the kernel and we don't want that for GFP flags misuse. And doesn't dump_stack do the same? It pollutes the log too. > Also, from looking at __warn(), it checks panic_on_warn and we explode > if set. Right, it is very valid point. > > So no, we probably don't want WARN() here. I understand, Thanks. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 10:09 ` Leon Romanovsky @ 2017-01-16 10:13 ` Borislav Petkov 2017-01-16 10:18 ` Leon Romanovsky 0 siblings, 1 reply; 14+ messages in thread From: Borislav Petkov @ 2017-01-16 10:13 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML On Mon, Jan 16, 2017 at 12:09:30PM +0200, Leon Romanovsky wrote: > And doesn't dump_stack do the same? It pollutes the log too. It is not about polluting the log - it is about tainting. __warn()->add_taint(taint, LOCKDEP_STILL_OK); -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 10:13 ` Borislav Petkov @ 2017-01-16 10:18 ` Leon Romanovsky 0 siblings, 0 replies; 14+ messages in thread From: Leon Romanovsky @ 2017-01-16 10:18 UTC (permalink / raw) To: Borislav Petkov; +Cc: Michal Hocko, Vlastimil Babka, Linux MM, LKML [-- Attachment #1: Type: text/plain, Size: 498 bytes --] On Mon, Jan 16, 2017 at 11:13:10AM +0100, Borislav Petkov wrote: > On Mon, Jan 16, 2017 at 12:09:30PM +0200, Leon Romanovsky wrote: > > And doesn't dump_stack do the same? It pollutes the log too. > > It is not about polluting the log - it is about tainting. > > __warn()->add_taint(taint, LOCKDEP_STILL_OK); Thanks, I had something different in mind for word "taint". Sorry for that. > > -- > Regards/Gruss, > Boris. > > Good mailing practices for 400: avoid top-posting and trim the reply. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:48 ` Leon Romanovsky @ 2017-01-16 9:59 ` Michal Hocko 2017-01-16 9:59 ` Michal Hocko 1 sibling, 0 replies; 14+ messages in thread From: Michal Hocko @ 2017-01-16 9:59 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Borislav Petkov, Vlastimil Babka, Linux MM, LKML 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check @ 2017-01-16 9:59 ` Michal Hocko 0 siblings, 0 replies; 14+ messages in thread From: Michal Hocko @ 2017-01-16 9:59 UTC (permalink / raw) To: Leon Romanovsky; +Cc: Borislav Petkov, Vlastimil Babka, Linux MM, LKML 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:16 [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check Borislav Petkov @ 2017-01-16 9:38 ` Michal Hocko 2017-01-16 9:38 ` Michal Hocko 2017-01-16 10:08 ` Vlastimil Babka 2 siblings, 0 replies; 14+ messages in thread From: Michal Hocko @ 2017-01-16 9:38 UTC (permalink / raw) To: Borislav Petkov; +Cc: Vlastimil Babka, Linux MM, LKML, Andrew Morton [Let's add Andrew] On Mon 16-01-17 10:16:43, Borislav Petkov wrote: > From: Borislav Petkov <bp@suse.de> > > We wanna know who's doing such a thing. Like slab.c does that. Yes this was an omission on my side in 72baeef0c271 ("slab: do not panic on invalid gfp_mask"). > > Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Michal Hocko <mhocko@suse.com> Thanks! > --- > 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(); > } > > return allocate_slab(s, > -- > 2.11.0 -- Michal Hocko SUSE Labs ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check @ 2017-01-16 9:38 ` Michal Hocko 0 siblings, 0 replies; 14+ messages in thread From: Michal Hocko @ 2017-01-16 9:38 UTC (permalink / raw) To: Borislav Petkov; +Cc: Vlastimil Babka, Linux MM, LKML, Andrew Morton [Let's add Andrew] On Mon 16-01-17 10:16:43, Borislav Petkov wrote: > From: Borislav Petkov <bp@suse.de> > > We wanna know who's doing such a thing. Like slab.c does that. Yes this was an omission on my side in 72baeef0c271 ("slab: do not panic on invalid gfp_mask"). > > Signed-off-by: Borislav Petkov <bp@suse.de> Acked-by: Michal Hocko <mhocko@suse.com> Thanks! > --- > 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(); > } > > return allocate_slab(s, > -- > 2.11.0 -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check 2017-01-16 9:16 [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check Borislav Petkov @ 2017-01-16 10:08 ` Vlastimil Babka 2017-01-16 9:38 ` Michal Hocko 2017-01-16 10:08 ` Vlastimil Babka 2 siblings, 0 replies; 14+ messages in thread From: Vlastimil Babka @ 2017-01-16 10:08 UTC (permalink / raw) To: Borislav Petkov, Michal Hocko; +Cc: Linux MM, LKML On 01/16/2017 10:16 AM, 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> Acked-by: Vlastimil Babka <vbabka@suse.cz> > --- > 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(); > } > > return allocate_slab(s, > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] mm/slub: Add a dump_stack() to the unexpected GFP check @ 2017-01-16 10:08 ` Vlastimil Babka 0 siblings, 0 replies; 14+ messages in thread From: Vlastimil Babka @ 2017-01-16 10:08 UTC (permalink / raw) To: Borislav Petkov, Michal Hocko; +Cc: Linux MM, LKML On 01/16/2017 10:16 AM, 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> Acked-by: Vlastimil Babka <vbabka@suse.cz> > --- > 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(); > } > > return allocate_slab(s, > -- 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> ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-01-16 10:18 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.