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

[Peng Zhang]

在 2023/9/25 23:23, Liam R. Howlett 写道:
> * Peng Zhang <zhangpeng.00 at 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 at 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.
Actually, there is a third method that can be used to solve this
problem, which is to use an externally sleepable lock, such as
rw_semaphore.
> 
> 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.
I understand this now, and I will take this into consideration when
adding tests in the future.
> 
> ...
> 
>> 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/
> 
>