* Re: lib/test_overflow.c causes WARNING and tainted kernel [not found] ` <CAGXu5j+yRt_yf2CwvaZDUiEUMwTRRiWab6aeStxqodx9i+BR4g@mail.gmail.com> @ 2019-05-25 15:33 ` Randy Dunlap 2019-05-27 7:53 ` Rasmus Villemoes 0 siblings, 1 reply; 4+ messages in thread From: Randy Dunlap @ 2019-05-25 15:33 UTC (permalink / raw) To: Kees Cook Cc: LKML, Dan Carpenter, Rasmus Villemoes, Matthew Wilcox, Linux MM, Andrew Morton On 3/13/19 7:53 PM, Kees Cook wrote: > Hi! > > On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@infradead.org> wrote: >> >> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT. >> >> In the first test_kmalloc() in test_overflow_allocation(): >> >> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0 >> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540 >> [...] >> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]--- >> [54375.079313] test_overflow: kmalloc detected saturation > > Yup! This is expected and operating as intended: it is exercising the > allocator's detection of insane allocation sizes. :) > > If we want to make it less noisy, perhaps we could add a global flag > the allocators could check before doing their WARNs? > > -Kees I didn't like that global flag idea. I also don't like the kernel becoming tainted by this test. Would it make sense to change the WARN_ON_ONCE() to a call to warn_alloc() instead? or use a plain raw printk_once()? warn_alloc() does the _NOWARN check and does rate limiting. --- lnx-51-rc2.orig/mm/page_alloc.c +++ lnx-51-rc2/mm/page_alloc.c @@ -4581,7 +4581,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, u * so bail out early if the request is out of bound. */ if (unlikely(order >= MAX_ORDER)) { - WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN)); + warn_alloc(gfp_mask, NULL, + "page allocation failure: order:%u", order); return NULL; } -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lib/test_overflow.c causes WARNING and tainted kernel 2019-05-25 15:33 ` lib/test_overflow.c causes WARNING and tainted kernel Randy Dunlap @ 2019-05-27 7:53 ` Rasmus Villemoes 2019-05-28 22:47 ` Kees Cook 0 siblings, 1 reply; 4+ messages in thread From: Rasmus Villemoes @ 2019-05-27 7:53 UTC (permalink / raw) To: Randy Dunlap, Kees Cook Cc: LKML, Dan Carpenter, Matthew Wilcox, Linux MM, Andrew Morton On 25/05/2019 17.33, Randy Dunlap wrote: > On 3/13/19 7:53 PM, Kees Cook wrote: >> Hi! >> >> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@infradead.org> wrote: >>> >>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT. >>> >>> In the first test_kmalloc() in test_overflow_allocation(): >>> >>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0 >>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540 >>> [...] >>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]--- >>> [54375.079313] test_overflow: kmalloc detected saturation >> >> Yup! This is expected and operating as intended: it is exercising the >> allocator's detection of insane allocation sizes. :) >> >> If we want to make it less noisy, perhaps we could add a global flag >> the allocators could check before doing their WARNs? >> >> -Kees > > I didn't like that global flag idea. I also don't like the kernel becoming > tainted by this test. Me neither. Can't we pass __GFP_NOWARN from the testcases, perhaps with a module parameter to opt-in to not pass that flag? That way one can make the overflow module built-in (and thus run at boot) without automatically tainting the kernel. The vmalloc cases do not take gfp_t, would they still cause a warning? BTW, I noticed that the 'wrap to 8K' depends on 64 bit and pagesize==4096; for 32 bit the result is 20K, while if the pagesize is 64K one gets 128K and 512K for 32/64 bit size_t, respectively. Don't know if that's a problem, but it's easy enough to make it independent of pagesize (just make it 9*4096 explicitly), and if we use 5 instead of 9 it also becomes independent of sizeof(size_t) (wrapping to 16K). Rasmus ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: lib/test_overflow.c causes WARNING and tainted kernel 2019-05-27 7:53 ` Rasmus Villemoes @ 2019-05-28 22:47 ` Kees Cook 2019-05-28 23:13 ` Randy Dunlap 0 siblings, 1 reply; 4+ messages in thread From: Kees Cook @ 2019-05-28 22:47 UTC (permalink / raw) To: Rasmus Villemoes Cc: Randy Dunlap, LKML, Dan Carpenter, Matthew Wilcox, Linux MM, Andrew Morton On Mon, May 27, 2019 at 09:53:33AM +0200, Rasmus Villemoes wrote: > On 25/05/2019 17.33, Randy Dunlap wrote: > > On 3/13/19 7:53 PM, Kees Cook wrote: > >> Hi! > >> > >> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@infradead.org> wrote: > >>> > >>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT. > >>> > >>> In the first test_kmalloc() in test_overflow_allocation(): > >>> > >>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0 > >>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540 > >>> [...] > >>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]--- > >>> [54375.079313] test_overflow: kmalloc detected saturation > >> > >> Yup! This is expected and operating as intended: it is exercising the > >> allocator's detection of insane allocation sizes. :) > >> > >> If we want to make it less noisy, perhaps we could add a global flag > >> the allocators could check before doing their WARNs? > >> > >> -Kees > > > > I didn't like that global flag idea. I also don't like the kernel becoming > > tainted by this test. > > Me neither. Can't we pass __GFP_NOWARN from the testcases, perhaps with > a module parameter to opt-in to not pass that flag? That way one can > make the overflow module built-in (and thus run at boot) without > automatically tainting the kernel. > > The vmalloc cases do not take gfp_t, would they still cause a warning? They still warn, but they don't seem to taint. I.e. this patch: diff --git a/lib/test_overflow.c b/lib/test_overflow.c index fc680562d8b6..c922f0d86181 100644 --- a/lib/test_overflow.c +++ b/lib/test_overflow.c @@ -486,11 +486,12 @@ static int __init test_overflow_shift(void) * Deal with the various forms of allocator arguments. See comments above * the DEFINE_TEST_ALLOC() instances for mapping of the "bits". */ -#define alloc010(alloc, arg, sz) alloc(sz, GFP_KERNEL) -#define alloc011(alloc, arg, sz) alloc(sz, GFP_KERNEL, NUMA_NO_NODE) +#define alloc_GFP (GFP_KERNEL | __GFP_NOWARN) +#define alloc010(alloc, arg, sz) alloc(sz, alloc_GFP) +#define alloc011(alloc, arg, sz) alloc(sz, alloc_GFP, NUMA_NO_NODE) #define alloc000(alloc, arg, sz) alloc(sz) #define alloc001(alloc, arg, sz) alloc(sz, NUMA_NO_NODE) -#define alloc110(alloc, arg, sz) alloc(arg, sz, GFP_KERNEL) +#define alloc110(alloc, arg, sz) alloc(arg, sz, alloc_GFP | __GFP_NOWARN) #define free0(free, arg, ptr) free(ptr) #define free1(free, arg, ptr) free(arg, ptr) will remove the tainting behavior but is still a bit "noisy". I can't find a way to pass __GFP_NOWARN to a vmalloc-based allocation, though. Randy, is removing taint sufficient for you? > BTW, I noticed that the 'wrap to 8K' depends on 64 bit and > pagesize==4096; for 32 bit the result is 20K, while if the pagesize is > 64K one gets 128K and 512K for 32/64 bit size_t, respectively. Don't > know if that's a problem, but it's easy enough to make it independent of > pagesize (just make it 9*4096 explicitly), and if we use 5 instead of 9 > it also becomes independent of sizeof(size_t) (wrapping to 16K). Ah! Yes, all excellent points. I've adjusted that too now. I'll send the result to Andrew. Thanks! -- Kees Cook ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: lib/test_overflow.c causes WARNING and tainted kernel 2019-05-28 22:47 ` Kees Cook @ 2019-05-28 23:13 ` Randy Dunlap 0 siblings, 0 replies; 4+ messages in thread From: Randy Dunlap @ 2019-05-28 23:13 UTC (permalink / raw) To: Kees Cook, Rasmus Villemoes Cc: LKML, Dan Carpenter, Matthew Wilcox, Linux MM, Andrew Morton On 5/28/19 3:47 PM, Kees Cook wrote: > On Mon, May 27, 2019 at 09:53:33AM +0200, Rasmus Villemoes wrote: >> On 25/05/2019 17.33, Randy Dunlap wrote: >>> On 3/13/19 7:53 PM, Kees Cook wrote: >>>> Hi! >>>> >>>> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@infradead.org> wrote: >>>>> >>>>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT. >>>>> >>>>> In the first test_kmalloc() in test_overflow_allocation(): >>>>> >>>>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0 >>>>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540 >>>>> [...] >>>>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]--- >>>>> [54375.079313] test_overflow: kmalloc detected saturation >>>> >>>> Yup! This is expected and operating as intended: it is exercising the >>>> allocator's detection of insane allocation sizes. :) >>>> >>>> If we want to make it less noisy, perhaps we could add a global flag >>>> the allocators could check before doing their WARNs? >>>> >>>> -Kees >>> >>> I didn't like that global flag idea. I also don't like the kernel becoming >>> tainted by this test. >> >> Me neither. Can't we pass __GFP_NOWARN from the testcases, perhaps with >> a module parameter to opt-in to not pass that flag? That way one can >> make the overflow module built-in (and thus run at boot) without >> automatically tainting the kernel. >> >> The vmalloc cases do not take gfp_t, would they still cause a warning? > > They still warn, but they don't seem to taint. I.e. this patch: > > diff --git a/lib/test_overflow.c b/lib/test_overflow.c > index fc680562d8b6..c922f0d86181 100644 > --- a/lib/test_overflow.c > +++ b/lib/test_overflow.c > @@ -486,11 +486,12 @@ static int __init test_overflow_shift(void) > * Deal with the various forms of allocator arguments. See comments above > * the DEFINE_TEST_ALLOC() instances for mapping of the "bits". > */ > -#define alloc010(alloc, arg, sz) alloc(sz, GFP_KERNEL) > -#define alloc011(alloc, arg, sz) alloc(sz, GFP_KERNEL, NUMA_NO_NODE) > +#define alloc_GFP (GFP_KERNEL | __GFP_NOWARN) > +#define alloc010(alloc, arg, sz) alloc(sz, alloc_GFP) > +#define alloc011(alloc, arg, sz) alloc(sz, alloc_GFP, NUMA_NO_NODE) > #define alloc000(alloc, arg, sz) alloc(sz) > #define alloc001(alloc, arg, sz) alloc(sz, NUMA_NO_NODE) > -#define alloc110(alloc, arg, sz) alloc(arg, sz, GFP_KERNEL) > +#define alloc110(alloc, arg, sz) alloc(arg, sz, alloc_GFP | __GFP_NOWARN) > #define free0(free, arg, ptr) free(ptr) > #define free1(free, arg, ptr) free(arg, ptr) > > will remove the tainting behavior but is still a bit "noisy". I can't > find a way to pass __GFP_NOWARN to a vmalloc-based allocation, though. > > Randy, is removing taint sufficient for you? Yes it is. Thanks. >> BTW, I noticed that the 'wrap to 8K' depends on 64 bit and >> pagesize==4096; for 32 bit the result is 20K, while if the pagesize is >> 64K one gets 128K and 512K for 32/64 bit size_t, respectively. Don't >> know if that's a problem, but it's easy enough to make it independent of >> pagesize (just make it 9*4096 explicitly), and if we use 5 instead of 9 >> it also becomes independent of sizeof(size_t) (wrapping to 16K). > > Ah! Yes, all excellent points. I've adjusted that too now. I'll send > the result to Andrew. > > Thanks! > -- ~Randy ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-28 23:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <9fa84db9-084b-cf7f-6c13-06131efb0cfa@infradead.org> [not found] ` <CAGXu5j+yRt_yf2CwvaZDUiEUMwTRRiWab6aeStxqodx9i+BR4g@mail.gmail.com> 2019-05-25 15:33 ` lib/test_overflow.c causes WARNING and tainted kernel Randy Dunlap 2019-05-27 7:53 ` Rasmus Villemoes 2019-05-28 22:47 ` Kees Cook 2019-05-28 23:13 ` Randy Dunlap
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).