** Description changed:

- Issue found with 5.6.0-1048-oem
- 
- While debugging bug 1880631, I found that this test will cause dmesg flooded 
with:
+ [Impact]
+ While debugging bug 1880631, I found that this l2tp.sh test from 
kselftest/net will cause dmesg on Focal OEM 5.6 kernel flooded on with:
  "unregister_netdevice: waiting for eth0 to become free. Usage count = 1"
  for about every 10 secondes.
  
  Test log:
  $ sudo ./l2tp.sh
  TEST: IPv4 basic L2TP tunnel                                        [ OK ]
  TEST: IPv4 route through L2TP tunnel                                [ OK ]
  TEST: IPv6 basic L2TP tunnel                                        [ OK ]
  TEST: IPv6 route through L2TP tunnel                                [ OK ]
  TEST: IPv4 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv4 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv6 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv6 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv4 basic L2TP tunnel                                        [ OK ]
  TEST: IPv4 route through L2TP tunnel                                [ OK ]
  TEST: IPv6 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv6 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv4 basic L2TP tunnel - after IPsec teardown                 [ OK ]
  TEST: IPv4 route through L2TP tunnel - after IPsec teardown         [ OK ]
  TEST: IPv6 basic L2TP tunnel - after IPsec teardown                 [ OK ]
  TEST: IPv6 route through L2TP tunnel - after IPsec teardown         [ OK ]
  
  Tests passed:  16
  Tests failed:   0
  
  dmesg output:
  $ dmesg
  Message from syslogd@glameow at Mar 16 05:01:40 ...
-  kernel:[  739.608359] unregister_netdevice: waiting for eth0 to become free. 
Usage count = 1
+  kernel:[  739.608359] unregister_netdevice: waiting for eth0 to become free. 
Usage count = 1
  [  708.560589] eth1: renamed from tmp
  [  708.587396] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
  [  708.587472] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
  [  708.616950] eth2: renamed from tmp
  [  708.643341] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
  [  708.687057] l2tp_core: L2TP core driver, V2.0
  [  708.689380] l2tp_netlink: L2TP netlink interface
  [  708.695479] l2tp_ip: L2TP IP encapsulation support (L2TPv3)
  [  708.700061] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
  [  708.726295] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
  [  708.788973] Initializing XFRM netlink socket
  [  719.448364] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1
  [  729.528359] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1
  [  739.608359] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1
  
+ [Fix]
+ * 27d53323664c54 ("l2tp: remove skb_dst_set() from l2tp_xmit_skb()")
+ 
+ We have this patch in our generic kernels F/G/H and OEM-5.10, thus for
+ now I can see just OEM-5.6 is affected. For which this patch can be
+ cherry-picked.
+ 
+ [Test Case]
+ This can tested with the l2tp.sh script in the kernel tree:
+ # sh ./tools/testing/selftests/net/l2tp.sh
+ 
+ With the patched kernel, it won't get flooded with that
+ unregister_netdevice message anymore.
+ 
+ Also, I have it tested with ubuntu_stress_smoke_tests as well, to make
+ sure the sctp stressor won't trigger any issue like in bug 1854968.
+ 
+ Test kernel can be found here:
+ https://people.canonical.com/~phlin/kernel/lp-1919277-l2tp/
+ 
+ [Where problems could occur]
+ This change is testable. A quick search didn't show any know issue about this 
patch. And with the same fix running in generic kernel for a while I think the 
regression potential is minor.
+ 
+ 
  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.6.0-1048-oem 5.6.0-1048.52
  ProcVersionSignature: User Name 5.6.0-1048.52-oem 5.6.19
  Uname: Linux 5.6.0-1048-oem x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Mar 16 05:20:45 2021
  SourcePackage: linux-signed-oem-5.6
  UpgradeStatus: No upgrade log present (probably fresh install)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-5.6 in Ubuntu.
https://bugs.launchpad.net/bugs/1919277

Title:
  l2tp.sh from net in ubuntu_kernel_selftests cause dmesg flooded with
  "unregister_netdevice: waiting for eth0 to become free. Usage count =
  1" on F-OEM-5.6

Status in ubuntu-kernel-tests:
  In Progress
Status in linux-oem-5.6 package in Ubuntu:
  New
Status in linux-oem-5.6 source package in Focal:
  In Progress

Bug description:
  [Impact]
  While debugging bug 1880631, I found that this l2tp.sh test from 
kselftest/net will cause the dmesg output on Focal OEM 5.6 kernel flooded with:
  "unregister_netdevice: waiting for eth0 to become free. Usage count = 1"
  for about every 10 seconds.

  Test log:
  $ sudo ./l2tp.sh
  TEST: IPv4 basic L2TP tunnel                                        [ OK ]
  TEST: IPv4 route through L2TP tunnel                                [ OK ]
  TEST: IPv6 basic L2TP tunnel                                        [ OK ]
  TEST: IPv6 route through L2TP tunnel                                [ OK ]
  TEST: IPv4 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv4 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv6 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv6 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv4 basic L2TP tunnel                                        [ OK ]
  TEST: IPv4 route through L2TP tunnel                                [ OK ]
  TEST: IPv6 basic L2TP tunnel - with IPsec                           [ OK ]
  TEST: IPv6 route through L2TP tunnel - with IPsec                   [ OK ]
  TEST: IPv4 basic L2TP tunnel - after IPsec teardown                 [ OK ]
  TEST: IPv4 route through L2TP tunnel - after IPsec teardown         [ OK ]
  TEST: IPv6 basic L2TP tunnel - after IPsec teardown                 [ OK ]
  TEST: IPv6 route through L2TP tunnel - after IPsec teardown         [ OK ]

  Tests passed:  16
  Tests failed:   0

  dmesg output:
  $ dmesg
  Message from syslogd@glameow at Mar 16 05:01:40 ...
   kernel:[  739.608359] unregister_netdevice: waiting for eth0 to become free. 
Usage count = 1
  [  708.560589] eth1: renamed from tmp
  [  708.587396] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
  [  708.587472] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
  [  708.616950] eth2: renamed from tmp
  [  708.643341] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
  [  708.687057] l2tp_core: L2TP core driver, V2.0
  [  708.689380] l2tp_netlink: L2TP netlink interface
  [  708.695479] l2tp_ip: L2TP IP encapsulation support (L2TPv3)
  [  708.700061] l2tp_eth: L2TP ethernet pseudowire support (L2TPv3)
  [  708.726295] l2tp_ip6: L2TP IP encapsulation support for IPv6 (L2TPv3)
  [  708.788973] Initializing XFRM netlink socket
  [  719.448364] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1
  [  729.528359] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1
  [  739.608359] unregister_netdevice: waiting for eth0 to become free. Usage 
count = 1

  [Fix]
  * 27d53323664c54 ("l2tp: remove skb_dst_set() from l2tp_xmit_skb()")

  We have this patch in our generic kernels F/G/H and OEM-5.10, thus for
  now I can see just OEM-5.6 is affected. For which this patch can be
  cherry-picked.

  [Test Case]
  This can tested with the l2tp.sh script in the kernel tree:
  # sh ./tools/testing/selftests/net/l2tp.sh

  With the patched kernel, it won't get flooded with that
  unregister_netdevice message anymore.

  Also, I have it tested with ubuntu_stress_smoke_tests as well, to make
  sure the sctp stressor won't trigger any issue like in bug 1854968.

  Test kernel can be found here:
  https://people.canonical.com/~phlin/kernel/lp-1919277-l2tp/

  [Where problems could occur]
  This change is testable. A quick search didn't show any know issue regarding 
this patch. And with the same fix running in generic kernel for a while 
therefore I think the regression potential is low.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: linux-image-5.6.0-1048-oem 5.6.0-1048.52
  ProcVersionSignature: User Name 5.6.0-1048.52-oem 5.6.19
  Uname: Linux 5.6.0-1048-oem x86_64
  ApportVersion: 2.20.11-0ubuntu27.16
  Architecture: amd64
  CasperMD5CheckResult: skip
  Date: Tue Mar 16 05:20:45 2021
  SourcePackage: linux-signed-oem-5.6
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1919277/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to