XPost: linux.kernel   
   From: rschwarzkopf@mathematik.uni-marburg.de   
      
   Hi all,   
      
   On 12/18/25 20:50, Salvatore Bonaccorso wrote:   
   > Hi all,   
   >   
   > Roland Schwarzkopf reported to the Debian mailing list a problem which   
   > he encountered once updating in Debian from 5.10.244 to 5.10.247. The   
   > report is quoted below and found in   
   > https://lists.debian.org/debian-kernel/2025/12/msg00223.html   
   >   
   > Roland did bisect the changes between 5.10.244 to 5.10.247 and found   
   > that the issue is introduced with 1550f3673972 ("net: rtnetlink: add   
   > bulk delete support flag") which is the backport to the 5.10.y series.   
   >   
   > On Thu, Dec 18, 2025 at 02:59:55PM +0100, Roland Schwarzkopf wrote:   
   >> Hi Salvatore,   
   >>   
   >> On 12/17/25 20:28, Salvatore Bonaccorso wrote:   
   >>> Hi Roland,   
   >>>   
   >>> I'm CC'ing Ben Hutchings directly as well as he takes care of the   
   >>> Debian LTS kernel updates. Idellly we make this as well a proper bug   
   >>> for easier tracking.   
   >>>   
   >>> On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote:   
   >>>> Hi there,   
   >>>>   
   >>>> after upgrading to the latest kernel on Debian 11   
   >>>> (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm   
   >>>> virtual machines and macvtap networking. When a machine is shut down,   
   >>>> libvirt can not delete the corresponding macvtap device. Thus, starting   
   the   
   >>>> machine again is not possible. After manually removing the macvtap device   
   >>>> using `ip link delete` the vm can be started again.   
   >>>>   
   >>>> In the journal the following message is shown:   
   >>>>   
   >>>> Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device   
   macvtap0: Operation not supported   
   >>>>   
   >>>> After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem   
   >>>> disappears. I tested this on a fresh minimal install of Debian 11 - to   
   >>>> exclude that anything else on my production machines is causing this   
   issue.   
   >>>>   
   >>>> Since the older kernel does not have this issue, I assume this is related   
   to   
   >>>> the kernel and not to libvirt?   
   >>>>   
   >>>> I tried to check for bug reports of the kernel package, but the bug   
   tracker   
   >>>> finds no reports and even states that the package does not exist (I used   
   the   
   >>>> "Bug reports" link on   
   >>>> https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This   
   left   
   >>>> me a bit puzzled. Since I don't have experience with the debian bug   
   >>>> reporting process, I had no other idea than writing to this list.   
   >>> You would need to search for inhttps://bugs.debian.org/src:linux ,   
   >>> but that said I'm not aware of any bug reports in that direction.   
   >>>   
   >>> Would you be in the position of bisecting the problem as you can say   
   >>> that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do   
   >>> that that would involve compiling a couple of kernels to narrow down   
   >>> where the problem is introduced:   
   >>>   
   >>>       git clone --single-branch -b linux-5.10.yhttps://git.k   
   rnel.org/pub/scm/linux/kernel/git/stable/linux-stable.git   
   >>>       cd linux-stable   
   >>>       git checkout v5.10.244   
   >>>       cp /boot/config-$(uname -r) .config   
   >>>       yes '' | make localmodconfig   
   >>>       make savedefconfig   
   >>>       mv defconfig arch/x86/configs/my_defconfig   
   >>>   
   >>>       # test 5.10.244 to ensure this is "good"   
   >>>       make my_defconfig   
   >>>       make -j $(nproc) bindeb-pkg   
   >>>       ... install the resulting .deb package and confirm it successfully   
   boots / problem does not exist   
   >>>   
   >>>       # test 5.10.247 to ensure this is "bad"   
   >>>       git checkout v5.10.247   
   >>>       make my_defconfig   
   >>>       make -j $(nproc) bindeb-pkg   
   >>>       ... install the resulting .deb package and confirm it fails to boot   
   / problem exists   
   >>>   
   >>> With that confirmed, the bisection can start:   
   >>>   
   >>>       git bisect start   
   >>>       git bisect good v5.10.244   
   >>>       git bisect bad v5.10.247   
   >>>   
   >>> In each bisection step git checks out a state between the oldest   
   >>> known-bad and the newest known-good commit. In each step test using:   
   >>>   
   >>>       make my_defconfig   
   >>>       make -j $(nproc) bindeb-pkg   
   >>>       ... install, try to boot / verify if problem exists   
   >>>   
   >>> and if the problem is hit run:   
   >>>   
   >>>       git bisect bad   
   >>>   
   >>> and if the problem doesn't trigger run:   
   >>>   
   >>>       git bisect good   
   >>>   
   >>> . Please pay attention to always select the just built kernel for   
   >>> booting, it won't always be the default kernel picked up by grub.   
   >>>   
   >>> Iterate until git announces to have identified the first bad commit.   
   >>>   
   >>> Then provide the output of   
   >>>   
   >>>       git bisect log   
   >>>   
   >>> In the course of the bisection you might have to uninstall previous   
   >>> kernels again to not exhaust the disk space in /boot. Also in the end   
   >>> uninstall all self-built kernels again.   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)