[Intel-wired-lan] [REGRESSION] Deadlock since commit 6faee3d4ee8b ("igb: Add lock to avoid data race")

[Lin Ma]

Hello Paul and Corinna,

Since I didn't have the exact ens5f2 driver as you guys, I just test the module loading and unloading in my QEMU environment.
I turned on the CONFIG_PROVE_LOCKING option but failed to reproduce the deadlock.

root at syzkaller:/# insmod igb.ko
[  116.192730] igb: Intel(R) Gigabit Ethernet Network Driver
[  116.193128] igb: Copyright (c) 2007-2014 Intel Corporation.
root at syzkaller:/# lsmod
Module                  Size  Used by
igb                   225280  0
root at syzkaller:/# rmmod igb
rmmod: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open builtin file '/lib/modules/6.1.0/modules.builtin.bin'
root at syzkaller:/# lsmod
lsmod
Module                  Size  Used by

I guess the command "echo 2 > /sys/class/net/ens5f2/device/sriov_numvfs" must do something interesting but I
didn't find the relevant code there. Could you guys take a look?

Regards
Lin



> From: "Paul Menzel" <pmenzel at molgen.mpg.de>
> Sent Time: 2023-03-07 18:19:18 (Tuesday)
> To: "Lin Ma" <linma at zju.edu.cn>, "Corinna Vinschen" <vinschen at redhat.com>
> Cc: intel-wired-lan at lists.osuosl.org, regressions at lists.linux.dev
> Subject: Re: [Intel-wired-lan] [REGRESSION] Deadlock since commit 6faee3d4ee8b ("igb: Add lock to avoid data race")
> 
> [Add Corinna back to Cc:, who was removed by Mozilla Thunderbird because 
> Reply-To header was set for some reason in the original report.]
> 
> Am 07.03.23 um 11:12 schrieb Paul Menzel:
> > [Adding regressions at lists.linux.dev]
> > 
> > #regzbot ^introduced: 6faee3d4ee8b
> > 
> > Am 07.03.23 um 10:54 schrieb Corinna Vinschen:
> >> Hi,
> >>
> >>
> >> After patch 6faee3d4ee8b ("igb: Add lock to avoid data race"), we see
> >> a deadlock scenario when trying to unload the igb module.
> >>
> >> The reproducer is pretty simple:
> >>
> >>    # echo 2 > /sys/class/net/ens5f2/device/sriov_numvfs
> >>    # modprobe -r igb
> >>
> >> The hang is quite thorough, I assume it's suffering a deadlock between
> >> the rtnl_lock and the spinlock introduced by 6faee3d4ee8b.
> >>
> >> Any chance you could have a look?
> >>
> >>
> >> Thanks,
> >> Corinna