>>在 2023/9/25 23:23, Liam R. Howlett 写道:
>>> * Peng Zhang <zhangpeng.00@xxxxxxxxxxxxx> [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@xxxxxxxxx>
>>>>>> | Closes: https://lore.kernel.org/oe-lkp/202309242123.7ebe65b5-oliver.sang@xxxxxxxxx
>>>>>>
>>>>>>
>>>>>> [ 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@xxxxxxxxxxxxx/
>>>
>>> ...
>>>
>>> Thanks,
>>> Liam
>>>
>>> [1] https://lore.kernel.org/lkml/20230925035617.84767-8-zhangpeng.00@xxxxxxxxxxxxx/
>>> [2] https://lore.kernel.org/lkml/20230925035617.84767-5-zhangpeng.00@xxxxxxxxxxxxx/
>>>
>>>
I think it would be better to wait for Peng's revision..
Thanks to all
Jaeseon
