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