linux-kernel - Re: [kthread] 40966e316f: WARNING:at_kernel/sched/core.c:#sched

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 23 Dec 2021 10:48:00 +0800
From:   Oliver Sang <oliver.sang@...el.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, lkp@...ts.01.org,
        lkp@...el.com
Subject: Re: [kthread]  40966e316f: WARNING:at_kernel/sched/core.c:#sched_init

hi Eric,

On Fri, Dec 17, 2021 at 11:01:41AM -0600, Eric W. Biederman wrote:
> kernel test robot <oliver.sang@...el.com> writes:
> 
> > Greeting,
> >
> > FYI, we noticed the following commit (built with gcc-9):
> >
> > commit: 40966e316f86b8cfd83abd31ccb4df729309d3e7 ("kthread: Ensure struct kthread is present for all kthreads")
> > https://git.kernel.org/cgit/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.17
> >
> > in testcase: trinity
> > version: trinity-x86_64-608712d8-1_20211207
> > with following parameters:
> >
> > 	runtime: 300s
> >
> > test-description: Trinity is a linux system call fuzz tester.
> > test-url: http://codemonkey.org.uk/projects/trinity/
> >
> >
> > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> >
> > caused below changes (please refer to attached dmesg/kmsg for entire
> > log/backtrace):
> 
> 
> Ok. That is very weird.  I will dig into it.
> 
> Silly question is there anything in this testing to cause memory
> allocations to fail early in boot?

we didn't observe it. actually test could finish for both this
commit (though with reported warning) and parent. the only diff seems
the reported warning.

cead18552660702a 40966e316f86b8cfd83abd31ccb
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :8          100%           8:8     dmesg.RIP:sched_init
           :8          100%           8:8     dmesg.WARNING:at_kernel/sched/core.c:#sched_init

but could you check in dmesg we attached in original report for any suspicous
memory issue?

or could you help check the config we used (also attached in original report)
to see if we can make some changes then to expose the possible memory issue,
in case our current config cannot capture? Thanks



> 
> Eric