On 2023/01/04 1:20, Felix Kuehling wrote:
>
> Am 2023-01-03 um 11:05 schrieb Waiman Long:
>> On 1/3/23 10:39, Felix Kuehling wrote:
>>> The regression point doesn't make sense. The kernel config doesn't enable CONFIG_DRM_AMDGPU, so there is no way that a change in AMDGPU could have caused this regression.
>>>
>> I agree. It is likely a pre-existing problem or caused by another commit that got triggered because of the change in cacheline alignment caused by commit c0d9271ecbd ("drm/amdgpu: Delete user queue doorbell variable").
> I don't think the change can affect cache line alignment. The entire amdgpu driver doesn't even get compiled in the kernel config that was used, and the change doesn't touch any files outside drivers/gpu/drm/amd/amdgpu:
>
> # CONFIG_DRM_AMDGPU is not set
>
> My guess would be that it's an intermittent bug that is confusing bisect.
>
> Regards,
> Felix
This was already explained in https://groups.google.com/g/syzkaller-bugs/c/1rmGDmbXWIw/m/nIQm0EmxBAAJ .
Jakub Sitnicki suggested
What if we revisit Eric's lockdep splat fix in 37159ef2c1ae ("l2tp: fix
a lockdep splat") and:
1. remove the lockdep_set_class_and_name(...) call in l2tp; it looks
like an odd case within the network stack, and
2. switch to bh_lock_sock_nested in l2tp_xmit_core so that we don't
break what has been fixed in 37159ef2c1ae.
and we are waiting for response from Eric Dumazet.
