Re: [linux-next:master] [maple_tree] 2041864a22: BUG:sleeping_function_called_from_invalid_context_at_include/linux/sched/mm.h

["Liam R. Howlett" <Liam.Howlett@Oracle.com>]

* Peng Zhang <zhangpeng.00@bytedance.com> [230925 08:47]:
> 
> 
> 在 2023/9/25 20:39, Jaeseon Sim 写道:
> > > Hello,
> > > 
> > > kernel test robot noticed "BUG:sleeping_function_called_from_invalid_context_at_include/linux/sched/mm.h" on:
> > > 
> > > commit: 2041864a22d4f4e900d0a3def4985432a21d8e6d ("maple_tree: use mas_node_count_gfp() in mas_expected_entries()")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> > > 
> > > [test failed on linux-next/master 940fcc189c51032dd0282cbee4497542c982ac59]
> > > 
> > > in testcase: boot
> > > 
> > > compiler: gcc-9
> > > test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G
> > > 
> > > (please refer to attached dmesg/kmsg for entire log/backtrace)
> > > 
> > > 
> > > 
> > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > the same patch/commit), kindly add following tags
> > > | Reported-by: kernel test robot <oliver.sang@intel.com>
> > > | Closes: https://lore.kernel.org/oe-lkp/202309242123.7ebe65b5-oliver.sang@intel.com
> > > 
> > > 
> > > [  113.582828][    T1] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
> > > [  113.583602][    T1] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0
> > > [  113.584246][    T1] preempt_count: 1, expected: 0
> > > [  113.584613][    T1] RCU nest depth: 0, expected: 0
> > > [  113.584983][    T1] 1 lock held by swapper/0/1:
> > > [ 113.585344][ T1] #0: ffffc9000001fc10 (&mt->ma_lock){+.+.}-{2:2}, at: check_forking+0x1e0/0x5c0
> > Dear Liam,
> > 
> > mas_expected_entries() in check_forking() tried to sleep while holding spinlock, and panic occurred.
> > I think mas_expected_entries() in lib/test_maple_tree.c need to be modified to align with commit 2041864a22d4f.
> > Do you have any idea for it? or Could you give some guide?

There are two ways we could fix this: one is to pass through the GFP
flag and use different flags in the test module, the other is to move
the testing out of the module and into the userspace tests.

Adding the GFP flag to the interface might be needed in the future but
there's no need for that now.  I was concerned about too large of a
change to the existing code, and this would increase the runtime code
changes - although not a lot.

I think the best thing would be to move the forking test out of the
module into the userspace testing (tools/testing/radix-tree/maple.c)

> This is just a test module. The work[1] I'm doing modifies this place
> and it will fix this bug.

Thanks Peng.  This is a temporary fix for upstream, but is needed for
the LTS kernels as well.  I've mentioned your patches to others, so
don't think they aren't noticed - they are eagerly awaited.

Since your patch adds the necessary GFP flag, we could move the
check_forking test back in your update, (patch 7/9 [1]) which avoids the
GFP_KERNEL flag (thanks!), if it is moved.  I think it's worth while to
do since you already have a lot of userspace tests as well that uses
GFP_KERNEL (4/9 [2]) and it's good to keep as much in the kernel module
as possible.

By the way Peng, I have gotten complaints (I cannot find a reference
quickly) from older CPUs taking a long time on the test module.  You are
making things faster, but I just wanted you to be aware of that in case
you add tests in the future that cause complaints :)  I still think it
is worth keeping as much as possible in that module - it's a more valid
test scenario and it still runs from the userspace testing.

...

> Thanks.
> 
> [1] https://lore.kernel.org/lkml/20230925035617.84767-1-zhangpeng.00@bytedance.com/

...

Thanks,
Liam

[1] https://lore.kernel.org/lkml/20230925035617.84767-8-zhangpeng.00@bytedance.com/
[2] https://lore.kernel.org/lkml/20230925035617.84767-5-zhangpeng.00@bytedance.com/