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.
