[GIT PULL] Networking for v6.13-rc7

[GIT PULL] Networking for v6.13-rc7

[Jakub Kicinski]

Hi Linus!

The following changes since commit aba74e639f8d76d29b94991615e33319d7371b63:

  Merge tag 'net-6.13-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net (2025-01-03 14:36:54 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.13-rc7

for you to fetch changes up to b5cf67a8f716afbd7f8416edfe898c2df460811a:

  Merge tag 'nf-25-01-09' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf (2025-01-09 08:54:49 -0800)

----------------------------------------------------------------
Including fixes from netfilter, Bluetooth and WPAN.

No outstanding fixes / investigations at this time.

Current release - new code bugs:

 - eth: fbnic: revert HWMON support, it doesn't work at all
   and revert is similar size as the fixes

Previous releases - regressions:

 - tcp: allow a connection when sk_max_ack_backlog is zero

 - tls: fix tls_sw_sendmsg error handling

Previous releases - always broken:

 - netdev netlink family:
   - prevent accessing NAPI instances from another namespace
   - don't dump Tx and uninitialized NAPIs

 - net: sysctl: avoid using current->nsproxy, fix null-deref if task
   is exiting and stick to opener's netns

 - sched: sch_cake: add bounds checks to host bulk flow fairness counts

Misc:

 - annual cleanup of inactive maintainers

Signed-off-by: Jakub Kicinski <kuba@kernel.org>

----------------------------------------------------------------
Antonio Pastor (1):
      net: 802: LLC+SNAP OID:PID lookup on start of skb data

Anumula Murali Mohan Reddy (1):
      cxgb4: Avoid removal of uninserted tid

Arkadiusz Kubalewski (1):
      ice: fix max values for dpll pin phase adjust

Benjamin Coddington (1):
      tls: Fix tls_sw_sendmsg error handling

Chenguang Zhao (1):
      net/mlx5: Fix variable not being completed when function returns

Chris Lu (1):
      Bluetooth: btmtk: Fix failed to send func ctrl for MediaTek devices.

Dan Carpenter (1):
      rtase: Fix a check for error in rtase_alloc_msix()

Daniel Borkmann (1):
      tcp: Annotate data-race around sk->sk_mark in tcp_v4_send_reset

En-Wei Wu (1):
      igc: return early when failing to read EECD register

Eric Dumazet (1):
      net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute

Hao Lan (4):
      net: hns3: fixed reset failure issues caused by the incorrect reset type
      net: hns3: fix missing features due to dev->features configuration too early
      net: hns3: Resolved the issue that the debugfs query result is inconsistent.
      net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue

Jakub Kicinski (20):
      selftests: tc-testing: reduce rshift value
      Merge tag 'ieee802154-for-net-2025-01-03' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan
      Merge branch 'bnxt_en-2-bug-fixes'
      net: don't dump Tx and uninitialized NAPIs
      eth: gve: use appropriate helper to set xdp_features
      netdev: prevent accessing NAPI instances from another namespace
      Merge branch 'there-are-some-bugfix-for-the-hns3-ethernet-driver'
      Merge tag 'for-net-2025-01-08' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
      Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue
      MAINTAINERS: mark Synopsys DW XPCS as Orphan
      MAINTAINERS: update maintainers for Microchip LAN78xx
      MAINTAINERS: remove Andy Gospodarek from bonding
      MAINTAINERS: mark stmmac ethernet as an Orphan
      MAINTAINERS: remove Mark Lee from MediaTek Ethernet
      MAINTAINERS: remove Ying Xue from TIPC
      MAINTAINERS: remove Noam Dagan from AMAZON ETHERNET
      MAINTAINERS: remove Lars Povlsen from Microchip Sparx5 SoC
      Merge branch 'maintainers-spring-2025-cleanup-of-networking-maintainers'
      Merge branch 'net-sysctl-avoid-using-current-nsproxy'
      Merge tag 'nf-25-01-09' of git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf

Jian Shen (2):
      net: hns3: don't auto enable misc vector
      net: hns3: initialize reset_timer before hclgevf_misc_irq_init()

Jiawen Wu (1):
      net: libwx: fix firmware mailbox abnormal return

Jie Wang (1):
      net: hns3: fix kernel crash when 1588 is sent on HIP08 devices

Kalesh AP (1):
      bnxt_en: Fix possible memory leak when hwrm_req_replace fails

Keisuke Nishimura (1):
      ieee802154: ca8210: Add missing check for kfifo_alloc() in ca8210_probe()

Kory Maincent (1):
      dt-bindings: net: pse-pd: Fix unusual character in documentation

Kuniyuki Iwashima (1):
      ipvlan: Fix use-after-free in ipvlan_get_iflink().

Leo Yang (1):
      mctp i3c: fix MCTP I3C driver multi-thread issue

Lizhi Xu (1):
      mac802154: check local interfaces before deleting sdata list

Luiz Augusto von Dentz (2):
      Bluetooth: hci_sync: Fix not setting Random Address when required
      Bluetooth: MGMT: Fix Add Device to responding before completing

Matthieu Baerts (NGI0) (9):
      mptcp: sysctl: avail sched: remove write access
      mptcp: sysctl: sched: avoid using current->nsproxy
      mptcp: sysctl: blackhole timeout: avoid using current->nsproxy
      sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxy
      sctp: sysctl: rto_min/max: avoid using current->nsproxy
      sctp: sysctl: auth_enable: avoid using current->nsproxy
      sctp: sysctl: udp_port: avoid using current->nsproxy
      sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxy
      rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy

Michael Chan (1):
      bnxt_en: Fix DIM shutdown

Neeraj Sanjay Kale (1):
      Bluetooth: btnxpuart: Fix driver sending truncated data

Pablo Neira Ayuso (2):
      netfilter: nf_tables: imbalance in flowtable binding
      netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Parker Newman (1):
      net: stmmac: dwmac-tegra: Read iommu stream id from device tree

Przemyslaw Korba (1):
      ice: fix incorrect PHY settings for 100 GB/s

Shannon Nelson (1):
      pds_core: limit loop over fw name list

Su Hui (1):
      eth: fbnic: Revert "eth: fbnic: Add hardware monitoring support via HWMON interface"

Toke Høiland-Jørgensen (1):
      sched: sch_cake: add bounds checks to host bulk flow fairness counts

Zhongqiu Duan (1):
      tcp/dccp: allow a connection when sk_max_ack_backlog is zero

 CREDITS                                            |  12 ++
 .../bindings/net/pse-pd/pse-controller.yaml        |   2 +-
 MAINTAINERS                                        |  16 +--
 drivers/bluetooth/btmtk.c                          |   7 ++
 drivers/bluetooth/btnxpuart.c                      |   1 +
 drivers/net/ethernet/amd/pds_core/devlink.c        |   2 +-
 drivers/net/ethernet/broadcom/bnxt/bnxt.c          |  38 +++++-
 drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c      |   3 +-
 drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c    |   5 +-
 drivers/net/ethernet/google/gve/gve_main.c         |  14 ++-
 drivers/net/ethernet/hisilicon/hns3/hnae3.h        |   3 -
 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c |  96 +++++---------
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c    |   1 -
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c    |  45 +++++--
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c |   3 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_regs.c    |   9 +-
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |  41 ++++--
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_regs.c  |   9 +-
 drivers/net/ethernet/intel/ice/ice_adminq_cmd.h    |   2 +
 drivers/net/ethernet/intel/ice/ice_dpll.c          |  35 ++++--
 drivers/net/ethernet/intel/ice/ice_ptp_consts.h    |   4 +-
 drivers/net/ethernet/intel/igc/igc_base.c          |   6 +
 drivers/net/ethernet/mellanox/mlx5/core/cmd.c      |   1 +
 drivers/net/ethernet/meta/fbnic/Makefile           |   1 -
 drivers/net/ethernet/meta/fbnic/fbnic.h            |   5 -
 drivers/net/ethernet/meta/fbnic/fbnic_fw.h         |   7 --
 drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c      |  81 ------------
 drivers/net/ethernet/meta/fbnic/fbnic_mac.c        |  22 ----
 drivers/net/ethernet/meta/fbnic/fbnic_mac.h        |   7 --
 drivers/net/ethernet/meta/fbnic/fbnic_pci.c        |   3 -
 drivers/net/ethernet/realtek/rtase/rtase_main.c    |   2 +-
 drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c  |  14 ++-
 drivers/net/ethernet/wangxun/libwx/wx_hw.c         |  24 ++--
 drivers/net/ieee802154/ca8210.c                    |   6 +-
 drivers/net/mctp/mctp-i3c.c                        |   4 +
 include/net/inet_connection_sock.h                 |   2 +-
 net/802/psnap.c                                    |   4 +-
 net/bluetooth/hci_sync.c                           |  11 +-
 net/bluetooth/mgmt.c                               |  38 +++++-
 net/bluetooth/rfcomm/tty.c                         |   4 +-
 net/core/dev.c                                     |  43 +++++--
 net/core/dev.h                                     |   3 +-
 net/core/link_watch.c                              |  10 +-
 net/core/netdev-genl.c                             |  11 +-
 net/ipv4/tcp_ipv4.c                                |   2 +-
 net/mac802154/iface.c                              |   4 +
 net/mptcp/ctrl.c                                   |  17 +--
 net/netfilter/nf_conntrack_core.c                  |   5 +-
 net/netfilter/nf_tables_api.c                      |  15 ++-
 net/rds/tcp.c                                      |  39 ++++--
 net/sched/cls_flow.c                               |   3 +-
 net/sched/sch_cake.c                               | 140 +++++++++++----------
 net/sctp/sysctl.c                                  |  14 ++-
 net/tls/tls_sw.c                                   |   2 +-
 .../tc-testing/tc-tests/filters/flow.json          |   4 +-
 55 files changed, 494 insertions(+), 408 deletions(-)
 delete mode 100644 drivers/net/ethernet/meta/fbnic/fbnic_hwmon.c

Re: [GIT PULL] Networking for v6.13-rc7

[pr-tracker-bot]

The pull request you sent on Thu,  9 Jan 2025 10:29:53 -0800:

> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.13-rc7

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c77cd47cee041bc1664b8e5fcd23036e5aab8e2a

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [GIT PULL] Networking for v6.13-rc7

[Jakub Kicinski]

On Thu, 09 Jan 2025 23:21:07 +0000 pr-tracker-bot@kernel.org wrote:
> The pull request you sent on Thu,  9 Jan 2025 10:29:53 -0800:
> 
> > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.13-rc7  
> 
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/c77cd47cee041bc1664b8e5fcd23036e5aab8e2a

Hi Linus!

After 76d5d4c53e68 ("mm/kmemleak: fix percpu memory leak detection
failure") we get this on every instance of our testing VMs:

unreferenced object 0x00042aa0 (size 64):
  comm "swapper/0", pid 0, jiffies 4294667296
  hex dump (first 32 bytes on cpu 2):
    00 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 0):
    pcpu_alloc_noprof+0x4ad/0xab0
    setup_zone_pageset+0x30/0x290
    setup_per_cpu_pageset+0x6a/0x1f0
    start_kernel+0x2a4/0x410
    x86_64_start_reservations+0x18/0x30
    x86_64_start_kernel+0xba/0x110
    common_startup_64+0x12c/0x138
unreferenced object 0x00042b00 (size 320):
  comm "swapper/0", pid 0, jiffies 4294667296
  hex dump (first 32 bytes on cpu 2):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff c0 74 78 98 ff ff ff ff  .........tx.....
  backtrace (crc 0):
    pcpu_alloc_noprof+0x4ad/0xab0
    setup_zone_pageset+0x6e/0x290
    setup_per_cpu_pageset+0x6a/0x1f0
    start_kernel+0x2a4/0x410
    x86_64_start_reservations+0x18/0x30
    x86_64_start_kernel+0xba/0x110
    common_startup_64+0x12c/0x138
unreferenced object 0x00042dc0 (size 48):
  comm "swapper/0", pid 0, jiffies 4294667296
  hex dump (first 32 bytes on cpu 2):
    18 07 01 0b f3 00 00 ea 00 00 00 00 00 00 00 00  ................
    00 00 09 09 17 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 0):
    pcpu_alloc_noprof+0x4ad/0xab0
    setup_per_cpu_pageset+0xd2/0x1f0
    start_kernel+0x2a4/0x410
    x86_64_start_reservations+0x18/0x30
    x86_64_start_kernel+0xba/0x110
    common_startup_64+0x12c/0x138

This is unlikely to be important, but I'm not getting any hits on lore
so I figured better safe than sorry...

Re: [GIT PULL] Networking for v6.13-rc7

[Catalin Marinas]

On Thu, Jan 16, 2025 at 07:38:21PM -0800, Jakub Kicinski wrote:
> On Thu, 09 Jan 2025 23:21:07 +0000 pr-tracker-bot@kernel.org wrote:
> > The pull request you sent on Thu,  9 Jan 2025 10:29:53 -0800:
> > 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-6.13-rc7  
> > 
> > has been merged into torvalds/linux.git:
> > https://git.kernel.org/torvalds/c/c77cd47cee041bc1664b8e5fcd23036e5aab8e2a
> 
> Hi Linus!
> 
> After 76d5d4c53e68 ("mm/kmemleak: fix percpu memory leak detection
> failure") we get this on every instance of our testing VMs:
> 
> unreferenced object 0x00042aa0 (size 64):
>   comm "swapper/0", pid 0, jiffies 4294667296
>   hex dump (first 32 bytes on cpu 2):
>     00 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00  ................
>     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
>   backtrace (crc 0):
>     pcpu_alloc_noprof+0x4ad/0xab0
>     setup_zone_pageset+0x30/0x290
>     setup_per_cpu_pageset+0x6a/0x1f0
>     start_kernel+0x2a4/0x410
>     x86_64_start_reservations+0x18/0x30
>     x86_64_start_kernel+0xba/0x110
>     common_startup_64+0x12c/0x138

I doubt that's related to the networking pull request but I can see it
caused by the above commit, now that we track per-cpu allocations. Most
likely it's a false positive. I'll try to reproduce it next week but
something like below might fix (untested):

diff --git a/mm/numa.c b/mm/numa.c
index e2eec07707d1..c594d853cfe8 100644
--- a/mm/numa.c
+++ b/mm/numa.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
 
+#include <linux/kmemleak.h>
 #include <linux/memblock.h>
 #include <linux/printk.h>
 #include <linux/numa.h>
@@ -23,6 +24,9 @@ void __init alloc_node_data(int nid)
 		      nd_size, nid);
 	nd = __va(nd_pa);
 
+	/* needed to track related allocation stored in node_data[] */
+	kmemleak_alloc(nd, nd_size, 0, 0);
+
 	/* report and initialize */
 	pr_info("NODE_DATA(%d) allocated [mem %#010Lx-%#010Lx]\n", nid,
 		nd_pa, nd_pa + nd_size - 1);

-- 
Catalin

Re: [GIT PULL] Networking for v6.13-rc7

[Catalin Marinas]

On Sat, Jan 18, 2025 at 01:45:18PM +0000, Catalin Marinas wrote:
> On Thu, Jan 16, 2025 at 07:38:21PM -0800, Jakub Kicinski wrote:
> > After 76d5d4c53e68 ("mm/kmemleak: fix percpu memory leak detection
> > failure") we get this on every instance of our testing VMs:
> > 
> > unreferenced object 0x00042aa0 (size 64):
> >   comm "swapper/0", pid 0, jiffies 4294667296
> >   hex dump (first 32 bytes on cpu 2):
> >     00 00 00 00 00 00 00 00 00 00 06 00 00 00 00 00  ................
> >     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> >   backtrace (crc 0):
> >     pcpu_alloc_noprof+0x4ad/0xab0
> >     setup_zone_pageset+0x30/0x290
> >     setup_per_cpu_pageset+0x6a/0x1f0
> >     start_kernel+0x2a4/0x410
> >     x86_64_start_reservations+0x18/0x30
> >     x86_64_start_kernel+0xba/0x110
> >     common_startup_64+0x12c/0x138
> 
> I doubt that's related to the networking pull request but I can see it
> caused by the above commit, now that we track per-cpu allocations. Most
> likely it's a false positive. I'll try to reproduce it next week but
> something like below might fix (untested):
> 
> diff --git a/mm/numa.c b/mm/numa.c
> index e2eec07707d1..c594d853cfe8 100644
> --- a/mm/numa.c
> +++ b/mm/numa.c
> @@ -1,5 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0-or-later
>  
> +#include <linux/kmemleak.h>
>  #include <linux/memblock.h>
>  #include <linux/printk.h>
>  #include <linux/numa.h>
> @@ -23,6 +24,9 @@ void __init alloc_node_data(int nid)
>  		      nd_size, nid);
>  	nd = __va(nd_pa);
>  
> +	/* needed to track related allocation stored in node_data[] */
> +	kmemleak_alloc(nd, nd_size, 0, 0);
> +
>  	/* report and initialize */
>  	pr_info("NODE_DATA(%d) allocated [mem %#010Lx-%#010Lx]\n", nid,
>  		nd_pa, nd_pa + nd_size - 1);

Hmm, I don't think this would make any difference as kmemleak does scan
the memblock allocations as long as they have a correspondent VA in the
linear map.

BTW, is NUMA enabled or disabled in your .config?

-- 
Catalin

Re: [GIT PULL] Networking for v6.13-rc7

[Jakub Kicinski]

On Mon, 20 Jan 2025 14:51:13 +0000 Catalin Marinas wrote:
> > +#include <linux/kmemleak.h>
> >  #include <linux/memblock.h>
> >  #include <linux/printk.h>
> >  #include <linux/numa.h>
> > @@ -23,6 +24,9 @@ void __init alloc_node_data(int nid)
> >  		      nd_size, nid);
> >  	nd = __va(nd_pa);
> >  
> > +	/* needed to track related allocation stored in node_data[] */
> > +	kmemleak_alloc(nd, nd_size, 0, 0);
> > +
> >  	/* report and initialize */
> >  	pr_info("NODE_DATA(%d) allocated [mem %#010Lx-%#010Lx]\n", nid,
> >  		nd_pa, nd_pa + nd_size - 1);  
> 
> Hmm, I don't think this would make any difference as kmemleak does scan
> the memblock allocations as long as they have a correspondent VA in the
> linear map.
> 
> BTW, is NUMA enabled or disabled in your .config?

It's pretty much kernel/configs/debug.config, with virtme-ng, booted
with 4 CPUs. LMK if you can't repro with that, I can provide exact
cmdline.

Re: [GIT PULL] Networking for v6.13-rc7

[Catalin Marinas]

On Mon, Jan 20, 2025 at 09:45:47AM -0800, Jakub Kicinski wrote:
> On Mon, 20 Jan 2025 14:51:13 +0000 Catalin Marinas wrote:
> > > +#include <linux/kmemleak.h>
> > >  #include <linux/memblock.h>
> > >  #include <linux/printk.h>
> > >  #include <linux/numa.h>
> > > @@ -23,6 +24,9 @@ void __init alloc_node_data(int nid)
> > >  		      nd_size, nid);
> > >  	nd = __va(nd_pa);
> > >  
> > > +	/* needed to track related allocation stored in node_data[] */
> > > +	kmemleak_alloc(nd, nd_size, 0, 0);
> > > +
> > >  	/* report and initialize */
> > >  	pr_info("NODE_DATA(%d) allocated [mem %#010Lx-%#010Lx]\n", nid,
> > >  		nd_pa, nd_pa + nd_size - 1);  
> > 
> > Hmm, I don't think this would make any difference as kmemleak does scan
> > the memblock allocations as long as they have a correspondent VA in the
> > linear map.
> > 
> > BTW, is NUMA enabled or disabled in your .config?
> 
> It's pretty much kernel/configs/debug.config, with virtme-ng, booted
> with 4 CPUs. LMK if you can't repro with that, I can provide exact
> cmdline.

Please do. I haven't tried to reproduce it yet on x86 as I don't have
any non-arm hardware around. It did not trigger on arm64. I think
virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
the end of the week, so more likely to try it next week.

-- 
Catalin

Re: [GIT PULL] Networking for v6.13-rc7

[Jakub Kicinski]

On Tue, 21 Jan 2025 11:09:20 +0000 Catalin Marinas wrote:
> > > Hmm, I don't think this would make any difference as kmemleak does scan
> > > the memblock allocations as long as they have a correspondent VA in the
> > > linear map.
> > > 
> > > BTW, is NUMA enabled or disabled in your .config?  
> > 
> > It's pretty much kernel/configs/debug.config, with virtme-ng, booted
> > with 4 CPUs. LMK if you can't repro with that, I can provide exact
> > cmdline.  
> 
> Please do. I haven't tried to reproduce it yet on x86 as I don't have
> any non-arm hardware around. It did not trigger on arm64. I think
> virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
> the end of the week, so more likely to try it next week.

vng -b -f tools/testing/selftests/net/config -f kernel/configs/debug.config

vng -r arch/x86_64/boot/bzImage --cpus 4 --user root -v --network loop

Re: [GIT PULL] Networking for v6.13-rc7

[Catalin Marinas]

On Tue, Jan 21, 2025 at 07:42:18AM -0800, Jakub Kicinski wrote:
> On Tue, 21 Jan 2025 11:09:20 +0000 Catalin Marinas wrote:
> > > > Hmm, I don't think this would make any difference as kmemleak does scan
> > > > the memblock allocations as long as they have a correspondent VA in the
> > > > linear map.
> > > > 
> > > > BTW, is NUMA enabled or disabled in your .config?  
> > > 
> > > It's pretty much kernel/configs/debug.config, with virtme-ng, booted
> > > with 4 CPUs. LMK if you can't repro with that, I can provide exact
> > > cmdline.  
> > 
> > Please do. I haven't tried to reproduce it yet on x86 as I don't have
> > any non-arm hardware around. It did not trigger on arm64. I think
> > virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
> > the end of the week, so more likely to try it next week.
> 
> vng -b -f tools/testing/selftests/net/config -f kernel/configs/debug.config
> 
> vng -r arch/x86_64/boot/bzImage --cpus 4 --user root -v --network loop

Great, thanks. I managed to reproduce it (after hacking vng to allow
x86_64 as non-host architecture). I'll try to debug towards the end of
the week or next week.

-- 
Catalin

Re: [GIT PULL] Networking for v6.13-rc7

[Matthieu Baerts]

Hi Catalin,

(+ cc Andrea)

On 21/01/2025 21:46, Catalin Marinas wrote:
> On Tue, Jan 21, 2025 at 07:42:18AM -0800, Jakub Kicinski wrote:
>> On Tue, 21 Jan 2025 11:09:20 +0000 Catalin Marinas wrote:
>>>>> Hmm, I don't think this would make any difference as kmemleak does scan
>>>>> the memblock allocations as long as they have a correspondent VA in the
>>>>> linear map.
>>>>>
>>>>> BTW, is NUMA enabled or disabled in your .config?  
>>>>
>>>> It's pretty much kernel/configs/debug.config, with virtme-ng, booted
>>>> with 4 CPUs. LMK if you can't repro with that, I can provide exact
>>>> cmdline.  
>>>
>>> Please do. I haven't tried to reproduce it yet on x86 as I don't have
>>> any non-arm hardware around. It did not trigger on arm64. I think
>>> virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
>>> the end of the week, so more likely to try it next week.
>>
>> vng -b -f tools/testing/selftests/net/config -f kernel/configs/debug.config
>>
>> vng -r arch/x86_64/boot/bzImage --cpus 4 --user root -v --network loop
> 
> Great, thanks. I managed to reproduce it

Thank you for investigating this issue!

Please note that on our side with MPTCP, I can only reproduce this issue
locally, but not from our CI on GitHub Actions. The main difference is
the kernel (6.8 on the CI, 6.12 here) and the fact our CI is launching
virtme-ng from a VM. The rest should be the same.

> (after hacking vng to allow x86_64 as non-host architecture).

Do not hesitate to report this issue + hack on vng's bug tracker :)

  https://github.com/arighi/virtme-ng/issues/new

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: [GIT PULL] Networking for v6.13-rc7

[Andrea Righi]

On Thu, Jan 23, 2025 at 06:11:16PM +0100, Matthieu Baerts wrote:
...
> Please note that on our side with MPTCP, I can only reproduce this issue
> locally, but not from our CI on GitHub Actions. The main difference is
> the kernel (6.8 on the CI, 6.12 here) and the fact our CI is launching
> virtme-ng from a VM. The rest should be the same.
> 
> > (after hacking vng to allow x86_64 as non-host architecture).

Ah right, we still don't support `--arch x86_64|amd64`, it's definitely
something we should add.

> 
> Do not hesitate to report this issue + hack on vng's bug tracker :)
> 
>   https://github.com/arighi/virtme-ng/issues/new

Yep, as pointed by Matt, feel free to post your hack there, otherwise I'll
take a look at this.

Thanks,
-Andrea

Re: [GIT PULL] Networking for v6.13-rc7

[Catalin Marinas]

On Thu, Jan 23, 2025 at 06:11:16PM +0100, Matthieu Baerts wrote:
> On 21/01/2025 21:46, Catalin Marinas wrote:
> > On Tue, Jan 21, 2025 at 07:42:18AM -0800, Jakub Kicinski wrote:
> >> On Tue, 21 Jan 2025 11:09:20 +0000 Catalin Marinas wrote:
> >>>>> Hmm, I don't think this would make any difference as kmemleak does scan
> >>>>> the memblock allocations as long as they have a correspondent VA in the
> >>>>> linear map.
> >>>>>
> >>>>> BTW, is NUMA enabled or disabled in your .config?  
> >>>>
> >>>> It's pretty much kernel/configs/debug.config, with virtme-ng, booted
> >>>> with 4 CPUs. LMK if you can't repro with that, I can provide exact
> >>>> cmdline.  
> >>>
> >>> Please do. I haven't tried to reproduce it yet on x86 as I don't have
> >>> any non-arm hardware around. It did not trigger on arm64. I think
> >>> virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
> >>> the end of the week, so more likely to try it next week.
> >>
> >> vng -b -f tools/testing/selftests/net/config -f kernel/configs/debug.config
> >>
> >> vng -r arch/x86_64/boot/bzImage --cpus 4 --user root -v --network loop
> > 
> > Great, thanks. I managed to reproduce it
> 
> Thank you for investigating this issue!
> 
> Please note that on our side with MPTCP, I can only reproduce this issue
> locally, but not from our CI on GitHub Actions. The main difference is
> the kernel (6.8 on the CI, 6.12 here) and the fact our CI is launching
> virtme-ng from a VM. The rest should be the same.

It won't show up in 6.8 as kmemleak did not report per-cpu allocation
leaks. But even with the latest kernel, it's probabilistic, some data
somewhere may look like a pointer and not be reported (I couldn't
reproduce it on arm64).

It turns out to be a false positive. The __percpu pointers are
referenced from node_data[]. The latter is populated in
alloc_node_data() and kmemleak registers the pg_data_t object from the
memblock allocation. However, due to an incorrect pfn range check
introduced by commit 84c326299191 ("mm: kmemleak: check physical address
when scan"), we ignore the node_data[0] allocation. Some printks in
alloc_node_data() show:

	nd_pa = 0x3ffda140
	nd_size = 0x4ec0
	min_low_pfn = 0x0
	max_low_pfn = 0x3ffdf
	nd_pa + nd_size == 0x3ffdf000

So the "PHYS_PFN(nd_pa + nd_size) >= max_low_pfn" check in kmemleak is
true and the whole pg_data_t object ignored (not scanned). The __percpu
pointers won't be detected. The fix is simple:

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 820ba3b5cbfc..bb7d61fc4da3 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1689,7 +1689,7 @@ static void kmemleak_scan(void)
 			unsigned long phys = object->pointer;

 			if (PHYS_PFN(phys) < min_low_pfn ||
-			    PHYS_PFN(phys + object->size) >= max_low_pfn)
+			    PHYS_PFN(phys + object->size) > max_low_pfn)
 				__paint_it(object, KMEMLEAK_BLACK);
 		}

I'll post this as a proper patch and I found some minor things to clean
up in kmemleak in the meantime.

> > (after hacking vng to allow x86_64 as non-host architecture).
> 
> Do not hesitate to report this issue + hack on vng's bug tracker :)

Done ;)

https://github.com/arighi/virtme-ng/issues/223

-- 
Catalin

Re: [GIT PULL] Networking for v6.13-rc7

[Matthieu Baerts]

Hi Catalin,

On 27/01/2025 15:27, Catalin Marinas wrote:
> On Thu, Jan 23, 2025 at 06:11:16PM +0100, Matthieu Baerts wrote:
>> On 21/01/2025 21:46, Catalin Marinas wrote:
>>> On Tue, Jan 21, 2025 at 07:42:18AM -0800, Jakub Kicinski wrote:
>>>> On Tue, 21 Jan 2025 11:09:20 +0000 Catalin Marinas wrote:
>>>>>>> Hmm, I don't think this would make any difference as kmemleak does scan
>>>>>>> the memblock allocations as long as they have a correspondent VA in the
>>>>>>> linear map.
>>>>>>>
>>>>>>> BTW, is NUMA enabled or disabled in your .config?  
>>>>>>
>>>>>> It's pretty much kernel/configs/debug.config, with virtme-ng, booted
>>>>>> with 4 CPUs. LMK if you can't repro with that, I can provide exact
>>>>>> cmdline.  
>>>>>
>>>>> Please do. I haven't tried to reproduce it yet on x86 as I don't have
>>>>> any non-arm hardware around. It did not trigger on arm64. I think
>>>>> virtme-ng may work with qemu. Anyway, I'll be off from tomorrow until
>>>>> the end of the week, so more likely to try it next week.
>>>>
>>>> vng -b -f tools/testing/selftests/net/config -f kernel/configs/debug.config
>>>>
>>>> vng -r arch/x86_64/boot/bzImage --cpus 4 --user root -v --network loop
>>>
>>> Great, thanks. I managed to reproduce it
>>
>> Thank you for investigating this issue!
>>
>> Please note that on our side with MPTCP, I can only reproduce this issue
>> locally, but not from our CI on GitHub Actions. The main difference is
>> the kernel (6.8 on the CI, 6.12 here) and the fact our CI is launching
>> virtme-ng from a VM. The rest should be the same.
> 
> It won't show up in 6.8 as kmemleak did not report per-cpu allocation
> leaks. But even with the latest kernel, it's probabilistic, some data
> somewhere may look like a pointer and not be reported (I couldn't
> reproduce it on arm64).

My bad, I was talking about the host kernel. Or to be precise, I should
say the kernel starting the test VM running a >=v6.13-rc7 kernel.

> It turns out to be a false positive. The __percpu pointers are
> referenced from node_data[]. The latter is populated in
> alloc_node_data() and kmemleak registers the pg_data_t object from the
> memblock allocation. However, due to an incorrect pfn range check
> introduced by commit 84c326299191 ("mm: kmemleak: check physical address
> when scan"), we ignore the node_data[0] allocation. Some printks in
> alloc_node_data() show:
> 
> 	nd_pa = 0x3ffda140
> 	nd_size = 0x4ec0
> 	min_low_pfn = 0x0
> 	max_low_pfn = 0x3ffdf
> 	nd_pa + nd_size == 0x3ffdf000
> 
> So the "PHYS_PFN(nd_pa + nd_size) >= max_low_pfn" check in kmemleak is
> true and the whole pg_data_t object ignored (not scanned). The __percpu
> pointers won't be detected. The fix is simple:
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 820ba3b5cbfc..bb7d61fc4da3 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -1689,7 +1689,7 @@ static void kmemleak_scan(void)
>  			unsigned long phys = object->pointer;
> 
>  			if (PHYS_PFN(phys) < min_low_pfn ||
> -			    PHYS_PFN(phys + object->size) >= max_low_pfn)
> +			    PHYS_PFN(phys + object->size) > max_low_pfn)
>  				__paint_it(object, KMEMLEAK_BLACK);
>  		}

Thank you for having looked at that and provided a fix quickly!

I confirm that it fixes the issue on my side! Just in case you want a
tested-by tag:

Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>

> I'll post this as a proper patch and I found some minor things to clean
> up in kmemleak in the meantime.

Great!

>>> (after hacking vng to allow x86_64 as non-host architecture).
>>
>> Do not hesitate to report this issue + hack on vng's bug tracker :)
> 
> Done ;)
> 
> https://github.com/arighi/virtme-ng/issues/223

Thank you! :)

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.