next: WARNING: CPU: 0 PID: 1200 at mm/page_alloc.c:4744 __alloc_pages+0x2e8/0x3a0

0 views
Skip to first unread message

Naresh Kamboju

unread,
May 12, 2023, 8:45:16 AM5/12/23
to open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Dan Carpenter, Andrey Ryabinin
Following kernel warning has been noticed on qemu-arm64 while running kunit
tests while booting Linux 6.4.0-rc1-next-20230512 and It was started from
6.3.0-rc7-next-20230420.

Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>

This is always reproducible on qemu-arm64, qemu-arm, qemu-x86 and qemu-i386.
Is this expected warning as a part of kunit tests ?

Crash log:
-----------

[ 663.530868] KTAP version 1
[ 663.531545] # Subtest: Handshake API tests
[ 663.533521] 1..11
[ 663.534424] KTAP version 1
[ 663.535406] # Subtest: req_alloc API fuzzing
[ 663.542460] ok 1 handshake_req_alloc NULL proto
[ 663.550345] ok 2 handshake_req_alloc CLASS_NONE
[ 663.558041] ok 3 handshake_req_alloc CLASS_MAX
[ 663.565790] ok 4 handshake_req_alloc no callbacks
[ 663.573882] ok 5 handshake_req_alloc no done callback
[ 663.580284] ------------[ cut here ]------------
[ 663.582129] WARNING: CPU: 0 PID: 1200 at mm/page_alloc.c:4744
__alloc_pages+0x2e8/0x3a0
[ 663.585675] Modules linked in:
[ 663.587808] CPU: 0 PID: 1200 Comm: kunit_try_catch Tainted: G
N 6.4.0-rc1-next-20230512 #1
[ 663.589817] Hardware name: linux,dummy-virt (DT)
[ 663.591426] pstate: 22400005 (nzCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
[ 663.592978] pc : __alloc_pages+0x2e8/0x3a0
[ 663.594236] lr : __kmalloc_large_node+0xbc/0x160
[ 663.595548] sp : ffff80000a317bc0
[ 663.596577] x29: ffff80000a317bc0 x28: 0000000000000000 x27: 0000000000000000
[ 663.598863] x26: ffff0000c8925b20 x25: 0000000000000000 x24: 0000000000000015
[ 663.601098] x23: 0000000000040dc0 x22: ffffbf424e7420c8 x21: ffffbf424e7420c8
[ 663.603100] x20: 1ffff00001462f88 x19: 0000000000040dc0 x18: 0000000078b4155a
[ 663.605582] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 663.607328] x14: 0000000000000000 x13: 6461657268745f68 x12: ffff60001913bc5a
[ 663.609355] x11: 1fffe0001913bc59 x10: ffff60001913bc59 x9 : 1fffe0001913bc59
[ 663.611004] x8 : 0000000041b58ab3 x7 : ffff700001462f88 x6 : dfff800000000000
[ 663.613556] x5 : 00000000f1f1f1f1 x4 : 00000000f2f2f200 x3 : 0000000000000000
[ 663.615364] x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffbf42516818e2
[ 663.617753] Call trace:
[ 663.618486] __alloc_pages+0x2e8/0x3a0
[ 663.619613] __kmalloc_large_node+0xbc/0x160
[ 663.621454] __kmalloc+0x84/0x94
[ 663.622551] handshake_req_alloc+0x74/0xe8
[ 663.623801] handshake_req_alloc_case+0xa0/0x170
[ 663.625467] kunit_try_run_case+0x7c/0x100
[ 663.626592] kunit_generic_run_threadfn_adapter+0x30/0x4c
[ 663.628998] kthread+0x1d4/0x1e4
[ 663.629715] ret_from_fork+0x10/0x20
[ 663.631094] ---[ end trace 0000000000000000 ]---
[ 663.643101] ok 6 handshake_req_alloc excessive privsize
[ 663.649446] ok 7 handshake_req_alloc all good
[ 663.651032] # req_alloc API fuzzing: pass:7 fail:0 skip:0 total:7
[ 663.653941] ok 1 req_alloc API fuzzing
[ 663.665951] ok 2 req_submit NULL req arg
[ 663.674278] ok 3 req_submit NULL sock arg
[ 663.682968] ok 4 req_submit NULL sock->file
[ 663.694323] ok 5 req_lookup works
[ 663.703604] ok 6 req_submit max pending
[ 663.714655] ok 7 req_submit multiple
[ 663.725174] ok 8 req_cancel before accept
[ 663.733780] ok 9 req_cancel after accept
[ 663.742528] ok 10 req_cancel after done
[ 663.750637] ok 11 req_destroy works
[ 663.751884] # Handshake API tests: pass:11 fail:0 skip:0 total:11
[ 663.753579] # Totals: pass:17 fail:0 skip:0 total:17

links:
------

- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230512/testrun/16901289/suite/log-parser-boot/test/check-kernel-exception/log
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230512/testrun/16901289/suite/log-parser-boot/tests/
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230420/testrun/16385677/suite/log-parser-boot/test/check-kernel-warning-ac79d2ca0f443d407d9749244f1738c9a2b123c609820f82d9e8907c756f5340/log
- https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20230512/testrun/16901289/suite/log-parser-boot/test/check-kernel-warning-ac79d2ca0f443d407d9749244f1738c9a2b123c609820f82d9e8907c756f5340/history/


--
Linaro LKFT
https://lkft.linaro.org

Dan Carpenter

unread,
May 12, 2023, 9:32:32 AM5/12/23
to Naresh Kamboju, Chuck Lever, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin
I'm pretty sure Chuck Lever did this intentionally, but he's not on the
CC list. Let's add him.

regards,
dan carpenter

Chuck Lever III

unread,
May 12, 2023, 9:56:37 AM5/12/23
to Dan Carpenter, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin


> On May 12, 2023, at 6:32 AM, Dan Carpenter <dan.ca...@linaro.org> wrote:
>
> I'm pretty sure Chuck Lever did this intentionally, but he's not on the
> CC list. Let's add him.
>
> regards,
> dan carpenter
>
> On Fri, May 12, 2023 at 06:15:04PM +0530, Naresh Kamboju wrote:
>> Following kernel warning has been noticed on qemu-arm64 while running kunit
>> tests while booting Linux 6.4.0-rc1-next-20230512 and It was started from
>> 6.3.0-rc7-next-20230420.
>>
>> Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>
>>
>> This is always reproducible on qemu-arm64, qemu-arm, qemu-x86 and qemu-i386.
>> Is this expected warning as a part of kunit tests ?

Dan's correct, this Kunit test is supposed to check the
behavior of the API when a too-large privsize is specified.

I'm not sure how to make this work without the superfluous
warning. Would adding GFP_NOWARN to the allocation help?
--
Chuck Lever


Mike Rapoport

unread,
May 12, 2023, 12:17:11 PM5/12/23
to Chuck Lever III, Dan Carpenter, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin
On Fri, May 12, 2023 at 01:56:30PM +0000, Chuck Lever III wrote:
>
>
> > On May 12, 2023, at 6:32 AM, Dan Carpenter <dan.ca...@linaro.org> wrote:
> >
> > I'm pretty sure Chuck Lever did this intentionally, but he's not on the
> > CC list. Let's add him.
> >
> > regards,
> > dan carpenter
> >
> > On Fri, May 12, 2023 at 06:15:04PM +0530, Naresh Kamboju wrote:
> >> Following kernel warning has been noticed on qemu-arm64 while running kunit
> >> tests while booting Linux 6.4.0-rc1-next-20230512 and It was started from
> >> 6.3.0-rc7-next-20230420.
> >>
> >> Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>
> >>
> >> This is always reproducible on qemu-arm64, qemu-arm, qemu-x86 and qemu-i386.
> >> Is this expected warning as a part of kunit tests ?
>
> Dan's correct, this Kunit test is supposed to check the
> behavior of the API when a too-large privsize is specified.
>
> I'm not sure how to make this work without the superfluous
> warning. Would adding GFP_NOWARN to the allocation help?

Yes, it should.
--
Sincerely yours,
Mike.

Dan Carpenter

unread,
May 13, 2023, 4:52:35 AM5/13/23
to Chuck Lever III, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin
On Fri, May 12, 2023 at 01:56:30PM +0000, Chuck Lever III wrote:
>
>
> > On May 12, 2023, at 6:32 AM, Dan Carpenter <dan.ca...@linaro.org> wrote:
> >
> > I'm pretty sure Chuck Lever did this intentionally, but he's not on the
> > CC list. Let's add him.
> >
> > regards,
> > dan carpenter
> >
> > On Fri, May 12, 2023 at 06:15:04PM +0530, Naresh Kamboju wrote:
> >> Following kernel warning has been noticed on qemu-arm64 while running kunit
> >> tests while booting Linux 6.4.0-rc1-next-20230512 and It was started from
> >> 6.3.0-rc7-next-20230420.
> >>
> >> Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>
> >>
> >> This is always reproducible on qemu-arm64, qemu-arm, qemu-x86 and qemu-i386.
> >> Is this expected warning as a part of kunit tests ?
>
> Dan's correct, this Kunit test is supposed to check the
> behavior of the API when a too-large privsize is specified.
>
> I'm not sure how to make this work without the superfluous
> warning. Would adding GFP_NOWARN to the allocation help?

That would silence the splat, yes.

regards,
dan carpenter

Geert Uytterhoeven

unread,
Jun 25, 2023, 4:46:37 AM6/25/23
to Dan Carpenter, Chuck Lever III, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin
But introduce a build failure, as GFP_NOWARN does not exist.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Chuck Lever III

unread,
Jun 25, 2023, 11:17:00 AM6/25/23
to Geert Uytterhoeven, Dan Carpenter, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin


> On Jun 25, 2023, at 4:46 AM, Geert Uytterhoeven <ge...@linux-m68k.org> wrote:
>
> On Sat, May 13, 2023 at 10:54 AM Dan Carpenter <dan.ca...@linaro.org> wrote:
>> On Fri, May 12, 2023 at 01:56:30PM +0000, Chuck Lever III wrote:
>>>> On May 12, 2023, at 6:32 AM, Dan Carpenter <dan.ca...@linaro.org> wrote:
>>>> I'm pretty sure Chuck Lever did this intentionally, but he's not on the
>>>> CC list. Let's add him.
>>>>
>>>> regards,
>>>> dan carpenter
>>>>
>>>> On Fri, May 12, 2023 at 06:15:04PM +0530, Naresh Kamboju wrote:
>>>>> Following kernel warning has been noticed on qemu-arm64 while running kunit
>>>>> tests while booting Linux 6.4.0-rc1-next-20230512 and It was started from
>>>>> 6.3.0-rc7-next-20230420.
>>>>>
>>>>> Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>
>>>>>
>>>>> This is always reproducible on qemu-arm64, qemu-arm, qemu-x86 and qemu-i386.
>>>>> Is this expected warning as a part of kunit tests ?
>>>
>>> Dan's correct, this Kunit test is supposed to check the
>>> behavior of the API when a too-large privsize is specified.
>>>
>>> I'm not sure how to make this work without the superfluous
>>> warning. Would adding GFP_NOWARN to the allocation help?
>>
>> That would silence the splat, yes.
>
> But introduce a build failure, as GFP_NOWARN does not exist.

This is the fix that went in:

commit b21c7ba6d9a5532add3827a3b49f49cbc0cb9779
Author: Chuck Lever <chuck...@oracle.com>
AuthorDate: Fri May 19 13:12:50 2023 -0400
Commit: Jakub Kicinski <ku...@kernel.org>
CommitDate: Mon May 22 19:24:52 2023 -0700

net/handshake: Squelch allocation warning during Kunit test

The "handshake_req_alloc excessive privsize" kunit test is intended
to check what happens when the maximum privsize is exceeded. The
WARN_ON_ONCE_GFP at mm/page_alloc.c:4744 can be disabled safely for
this test.

Reported-by: Linux Kernel Functional Testing <lk...@linaro.org>
Fixes: 88232ec1ec5e ("net/handshake: Add Kunit tests for the handshake consumer API")
Signed-off-by: Chuck Lever <chuck...@oracle.com>
Link: https://lore.kernel.org/r/168451636052.47152.960...@oracle-102.nfsv4bat.org
Signed-off-by: Jakub Kicinski <ku...@kernel.org>

diff --git a/net/handshake/handshake-test.c b/net/handshake/handshake-test.c
index e6adc5dec11a..6193e46ee6d9 100644
--- a/net/handshake/handshake-test.c
+++ b/net/handshake/handshake-test.c
@@ -102,7 +102,7 @@ struct handshake_req_alloc_test_param handshake_req_alloc_params[] = {
{
.desc = "handshake_req_alloc excessive privsize",
.proto = &handshake_req_alloc_proto_6,
- .gfp = GFP_KERNEL,
+ .gfp = GFP_KERNEL | __GFP_NOWARN,
.expect_success = false,
},
{

Is there a platform where __GPF_NOWARN is not defined?


--
Chuck Lever


Geert Uytterhoeven

unread,
Jun 25, 2023, 11:34:18 AM6/25/23
to Chuck Lever III, Dan Carpenter, Naresh Kamboju, open list, linux-mm, kasan-dev, kuni...@googlegroups.com, lkft-...@lists.linaro.org, Marco Elver, Andrew Morton, Mel Gorman, Andrey Ryabinin
Hi Chuck,
"git grep" says all of them, as you misspelled it in your question ;-)

"__GFP_NOWARN" is defined in include/linux/gfp_types.h,
so it should be available everywhere.

Note the use of "__GFP_NOWARN" instead of "GFP_NOWARN".
Once in a while, people do submit patches using "GFP_NOWARN"...
Reply all
Reply to author
Forward
0 new messages