* Re: [PATCH net 0/3] rxrpc: Miscellaneous fixes
From: patchwork-bot+netdevbpf @ 2026-04-23 21:50 UTC (permalink / raw)
To: David Howells
Cc: netdev, marc.dionne, kuba, davem, edumazet, pabeni, horms,
anderson, linux-afs, linux-kernel
In-Reply-To: <20260423200909.3049438-1-dhowells@redhat.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 23 Apr 2026 21:09:05 +0100 you wrote:
> Here are some fixes for rxrpc, as found by Sashiko[1]:
>
> (1) Fix rxrpc_input_call_event() to only unshare DATA packets.
>
> (2) Fix re-decryption of RESPONSE packets where a partially decrypted
> skbuff gets requeued if there was a failure due to ENOMEM.
>
> [...]
Here is the summary with links:
- [net,1/3] rxrpc: Fix rxrpc_input_call_event() to only unshare DATA packets
https://git.kernel.org/netdev/net/c/55b2984c96c3
- [net,2/3] rxrpc: Fix re-decryption of RESPONSE packets
https://git.kernel.org/netdev/net/c/0422e7a4883f
- [net,3/3] rxrpc: Fix error handling in rxgk_extract_token()
https://git.kernel.org/netdev/net/c/3476c8bb960f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2 10/15] drivers: net: cirrus: mac89x0: Remove this driver
From: Jakub Kicinski @ 2026-04-23 22:02 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Daniel Palmer, Geert Uytterhoeven, Andrew Lunn, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Jonathan Corbet, Shuah Khan, Michael Fritscher, Byron Stanoszek,
linux-kernel, netdev, linux-doc, linux-m68k
In-Reply-To: <aee0393e2a2bd5a5d0bf8aee758122633e54aa06.camel@physik.fu-berlin.de>
On Thu, 23 Apr 2026 11:28:11 +0200 John Paul Adrian Glaubitz wrote:
> > > Retrocomputing still is not well regarded by some maintainers, it seems :-(.
> >
> > I've found bugs in drivers by plugging those things into exotic
> > hardware like my Amiga 4000 and Ultra5 [0].
> > So, it's not totally pointless. And having a shader capable Amiga[1]
> > is pretty cool.
>
> Not only that. Those exotic architectures also help iron out generic kernel
> bugs and give new maintainers an possibility to get their feet wet.
>
> > Sad to see fun stuff getting pushed out by basically spam bots. :(
>
> It's not so much pushed out by spam bots but by the commercialization of the
> Linux kernel. Many developers think that the sole purpose of the Linux kernel
> is to run on modern commodity hardware.
Please send that MAINTAINERS patch to designate yourselves
as maintainers (like Daniel already did for another driver).
This is the ideal outcome.
We want to be welcoming in the community. But being a part
of the community means participating in _work_.
^ permalink raw reply
* [PATCH net] MAINTAINERS: add pcnet_cs to PCMCIA
From: Jakub Kicinski @ 2026-04-23 22:08 UTC (permalink / raw)
To: davem; +Cc: netdev, edumazet, pabeni, andrew+netdev, horms, Jakub Kicinski,
linux
Per discussion under the Link make sure Dominik can help
with the patches to drivers/net/ethernet/8390/pcnet_cs.c
cc: linux@dominikbrodowski.net
Link: https://lore.kernel.org/aeomUh5JqFvkLTH7@scops.dominikbrodowski.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index dd7d9a55327c..27a298c13424 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20567,6 +20567,7 @@ M: Dominik Brodowski <linux@dominikbrodowski.net>
S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git
F: Documentation/pcmcia/
+F: drivers/net/ethernet/8390/pcnet_cs.c
F: drivers/pcmcia/
F: include/pcmcia/
F: tools/pcmcia/
--
2.53.0
^ permalink raw reply related
* [PATCH bpf v1 1/1] bpf: Fix sk_local_storage diag dumping uninitialized special fields
From: Amery Hung @ 2026-04-23 22:23 UTC (permalink / raw)
To: bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, ameryhung, kernel-team
Call check_and_init_map_value() after the copy_map_value() to zero out
special field regions. diag_get() copies sk_local_storage map values
into a netlink message using copy_map_value{_locked}(), which
intentionally skip special fields. However, the destination buffer from
nla_reserve_64bit() is not zeroed and the skipped regions contain
uninitialized skb data can be sent to userspace.
Fixes: 1ed4d92458a9 ("bpf: INET_DIAG support in bpf_sk_storage")
Signed-off-by: Amery Hung <ameryhung@gmail.com>
---
net/core/bpf_sk_storage.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
index 14eb7812bda4..b50d26a542ed 100644
--- a/net/core/bpf_sk_storage.c
+++ b/net/core/bpf_sk_storage.c
@@ -558,6 +558,7 @@ static int diag_get(struct bpf_local_storage_data *sdata, struct sk_buff *skb)
sdata->data, true);
else
copy_map_value(&smap->map, nla_data(nla_value), sdata->data);
+ check_and_init_map_value(&smap->map, nla_data(nla_value));
nla_nest_end(skb, nla_stg);
return 0;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net 1/1] ovpn: fix race between deleting interface and adding new peer
From: Sabrina Dubroca @ 2026-04-23 22:27 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Antonio Quartulli, netdev, Ralf Lici, Paolo Abeni, Andrew Lunn,
David S. Miller, Eric Dumazet, Hyunwoo Kim
In-Reply-To: <20260423103628.4ce6fc05@kernel.org>
2026-04-23, 10:36:28 -0700, Jakub Kicinski wrote:
> On Thu, 23 Apr 2026 18:37:49 +0200 Sabrina Dubroca wrote:
> > We could also wrap all of ovpn_peer_add (including the new reg_state
> > check) in netdev_lock, since we can't move to NETREG_UNREGISTERING
> > until netdev_lock is released (then I think we wouldn't need the
> > READ_ONCE(reg_state)). But I don't know if that's an acceptable use of
> > netdev_lock.
>
> Yup, fwiw it's a perfectly legitimate use case.
Ok. There's still a worrying bit in nesting lock_sock under
netdev_lock (ovpn_peer_add -> netdev_lock -> ovpn_peer_add_p2p ->
unlock_ovpn -> ovpn_socket_release -> lock_sock).
--
Sabrina
^ permalink raw reply
* Re: [PATCH v1 1/2] vfio: add callback to get tph info for dma-buf
From: Jason Gunthorpe @ 2026-04-23 22:46 UTC (permalink / raw)
To: Alex Williamson
Cc: Zhiping Zhang, Stanislav Fomichev, Keith Busch, Leon Romanovsky,
Bjorn Helgaas, linux-rdma, linux-pci, netdev, dri-devel,
Yochai Cohen, Yishai Hadas
In-Reply-To: <20260423132016.4a25e074@shazbot.org>
On Thu, Apr 23, 2026 at 01:20:16PM -0600, Alex Williamson wrote:
> My suggestion would be that we leave VFIO_DEVICE_FEATURE_DMA_BUF
> unchanged and add a VFIO_DEVICE_FEATURE_DMA_BUF_TPH ioctl which takes
> the fd from VFIO_DEVICE_FEATURE_DMA_BUF, along with a steering tag and
> processing hint. It would fdget() the dmabuf fd, validate it's a
> dmabuf via f_ops, validate it's a vfio exported dmabuf via dmabuf->ops,
> find the matching vfio_pci_dma_buf via priv under memory_lock, and
> stuff the provided TPH values into the object. It would be left to the
> user to sequence setting the TPH values on the dmabuf before the dmabuf
> is consumed by the importer.
>
> Is that a more reasonable uAPI? Thanks,
Off hand I think it can work, with the proviso that if userspace uses
the dmabuf before setting the tph the importer may ignore it. I don't
think that is a problem in practice.
Jason
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Amery Hung @ 2026-04-23 22:46 UTC (permalink / raw)
To: Eduard Zingerman
Cc: Amery Hung, bpf, netdev, alexei.starovoitov, andrii, daniel,
memxor, martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <c84a7beccd4ae527981797a6e5a6af840ba9c312.camel@gmail.com>
On Wed, Apr 22, 2026 at 3:50 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Wed, 2026-04-22 at 15:45 -0700, Amery Hung wrote:
> > On Wed, Apr 22, 2026 at 2:46 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
> > >
> > > On Tue, 2026-04-21 at 15:10 -0700, Amery Hung wrote:
> > > > Assign reg->id when getting referenced kptr from read program context
> > > > to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> > > > referenced skb in qdisc programs using a new field reg->parent_id in
> > > > a later patch.
> > > >
> > > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > > ---
> > > > kernel/bpf/verifier.c | 5 +++--
> > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > index 41e4ea41c72e..93003a2a96b0 100644
> > > > --- a/kernel/bpf/verifier.c
> > > > +++ b/kernel/bpf/verifier.c
> > > > @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > > } else {
> > > > mark_reg_known_zero(env, regs,
> > > > value_regno);
> > > > - if (type_may_be_null(info.reg_type))
> > > > - regs[value_regno].id = ++env->id_gen;
> > > > /* A load of ctx field could have different
> > > > * actual load size with the one encoded in the
> > > > * insn. When the dst is PTR, it is for sure not
> > > > @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> > > > if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> > > > regs[value_regno].btf = info.btf;
> > > > regs[value_regno].btf_id = info.btf_id;
> > > > + regs[value_regno].id = info.ref_obj_id;
> > > > regs[value_regno].ref_obj_id = info.ref_obj_id;
> > > > }
> > >
> > > Hi Amery,
> > >
> > > Could you please help me double-check my understanding of this change?
> > >
> > > It adds a new behavior, if struct_ops method parameter is annotated
> > > with __ref, then if a field is read from such struct_ops context
> > > the destination register would now have it's .id == ref_obj_id
> > > allocated for the parameter at the beginning of do_check().
> > > E.g. for `rB = *(T *)(rA + off)`, if `rA` is a pointer to struct_ops
> > > context and parameter corresponding to `off` has `__ref` annotation
> > > the `rB.id` will be assigned, contrary to old behavior, when it remained 0.
> > >
> >
> > Right
>
> Ack, thank you.
>
> > > This change in behavior, however, becomes visible only after the
> > > changes to release_reference() later in the series.
> > > There the `rB.id` is used to initiate `mark_reg_invalid(env, reg)` for
> > > the `rB`.
> > >
> >
> > I probably should mention it in the commit message. The purpose of the
> > patch is to make the implementation consistent with the design:
> > parent_id tracks the id of the parent objects.
> >
> > Without this patch, it should still work since in this case ref_obj_id
> > always equals to id. When release_reference() is called on a
> > KF_RELEASE kfunc, the children objects will still be invalidated
> > correctly.
>
> bpf_qdisc_fail__invalid_dynptr_cross_frame.c:invalid_dynptr_cross_frame
> fails if I comment out the line `regs[value_regno].id = info.ref_obj_id;`.
> The added .id link is used to propagate invalidation triggered by
> `free_skb(skb);` to `hdr`.
> The patch seem mandatory for the series.
Ah yes... because an skb dynptr do track parent's id in
check_kfunc_args(). Thanks for the correction.
ret = process_dynptr_func(env, regno, insn_idx, dynptr_arg_type,
meta->ref_obj_id ? meta->id : 0, &meta->dynptr);
^ permalink raw reply
* Re: [PATCH] tipc: crypto: require a NUL-terminated AEAD algorithm name
From: Pengpeng Hou @ 2026-04-23 22:53 UTC (permalink / raw)
To: Jon Maloy, David S. Miller
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, netdev,
tipc-discussion, linux-kernel, pengpeng
In-Reply-To: <20260417075353.30662-1-pengpeng@iscas.ac.cn>
Hi Tung,
Thanks for the correction.
Agreed, I missed the TIPC-specific guarantee here, including that the
supported algorithm name is fixed to "gcm(aes)" and is NUL-terminated.
I'll drop this patch.
Thanks,
Pengpeng
^ permalink raw reply
* Re: [PATCH net 01/18] drivers: net: 3com: 3c509: Remove this driver
From: Maciej W. Rozycki @ 2026-04-23 23:10 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
linux-kernel, netdev, linux-doc
In-Reply-To: <20260421-v7-0-0-net-next-driver-removal-v1-v1-1-69517c689d1f@lunn.ch>
On Tue, 21 Apr 2026, Andrew Lunn wrote:
> The 3c509 was written by Donald Becker between 1993-2000. It is an ISA
> device, so unlikely to be used with modern kernels.
FWIW I'm still using this device and driver at my lab:
eisa 00:08: EISA: slot 8: TCM5094 detected
eth0: 3c5x9 found at 0x8000, 10baseT port, address 00:a0:24:xx:xx:xx, IRQ 12.
No issues in a decade or so, so why bother doing anything at all?
Maciej
^ permalink raw reply
* Re: [PATCH bpf v1 1/1] bpf: Fix sk_local_storage diag dumping uninitialized special fields
From: Mykyta Yatsenko @ 2026-04-23 23:50 UTC (permalink / raw)
To: Amery Hung, bpf
Cc: netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, kernel-team
In-Reply-To: <20260423222356.155387-1-ameryhung@gmail.com>
On 4/23/26 11:23 PM, Amery Hung wrote:
> Call check_and_init_map_value() after the copy_map_value() to zero out
> special field regions. diag_get() copies sk_local_storage map values
> into a netlink message using copy_map_value{_locked}(), which
> intentionally skip special fields. However, the destination buffer from
> nla_reserve_64bit() is not zeroed and the skipped regions contain
> uninitialized skb data can be sent to userspace.
>
> Fixes: 1ed4d92458a9 ("bpf: INET_DIAG support in bpf_sk_storage")
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
> net/core/bpf_sk_storage.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/core/bpf_sk_storage.c b/net/core/bpf_sk_storage.c
> index 14eb7812bda4..b50d26a542ed 100644
> --- a/net/core/bpf_sk_storage.c
> +++ b/net/core/bpf_sk_storage.c
> @@ -558,6 +558,7 @@ static int diag_get(struct bpf_local_storage_data *sdata, struct sk_buff *skb)
> sdata->data, true);
> else
> copy_map_value(&smap->map, nla_data(nla_value), sdata->data);
> + check_and_init_map_value(&smap->map, nla_data(nla_value));
>
I think check_and_init_map_value() should be moved before the
copy_map_value(), because copy_map_value_locked() already uses
spin lock special field, which if uninitialized can deadlock?
> nla_nest_end(skb, nla_stg);
> return 0;
^ permalink raw reply
* [GIT PULL] Networking deletions for 7.1
From: Jakub Kicinski @ 2026-04-23 23:54 UTC (permalink / raw)
To: torvalds; +Cc: kuba, davem, netdev, linux-kernel, pabeni
Hi Linus!
I've been trying to figure out how to survive the change in rate
of submissions and we're doing 3 things in parallel:
- more/better LLM code review tools
- email bots guiding noobs and if needed throttling submissions
- deleting long-orphaned code (unless someone steps up immediately)
This PR is part of the 3rd point. I did move what could be built
as a module to a GH repo, in case it helps someone.
But I assume this is all basically unused code.
For the LLM reviewer part tweaking local prompts is showing its limits.
They are missing 50%+ of bugs Sashiko finds. (Sashiko is using LLM APIs
directly.) Sashiko/Gemini finds a lot of real issues but it reports
side-issues and occasional false positives. Paolo says we spend
~40% of our time checking LLM outputs, sounds about right. I hacked up
a Sashiko/Claude/semcode combo which is _much_ better in terms of
false positives. But it also misses real things Sashiko/Gemini finds.
Magic bullet I was hoping for yet to be found.
The following changes since commit 1f5ffc672165ff851063a5fd044b727ab2517ae3:
Fix mismerge of the arm64 / timer-core interrupt handling changes (2026-04-14 23:03:02 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git tags/net-deletions
for you to fetch changes up to 0c22ed0fadcad620277a56c0ba2867d4850d053a:
Merge branch 'remove-a-number-of-isa-and-pcmcia-ethernet-drivers' (2026-04-23 15:57:10 -0700)
----------------------------------------------------------------
Delete some obsolete networking code
Old code like amateur radio and NFC have long been a burden
to core networking developers. syzbot loves to find bugs
in BKL-era code, and noobs try to fix them.
If we want to have a fighting chance of surviving the LLM-pocalypse
this code needs to find a dedicated owner or get deleted.
We've talked about these deletions multiple times in the past
and every time someone wanted the code to stay. It is never
very clear to me how many of those people actually use the code
vs are just nostalgic to see it go. Amateur radio did have
occasional users (or so I think) but most users switched
to user space implementations since its all super slow stuff.
Nobody stepped up to maintain the kernel code.
We were lucky enough to find someone who wants to help with NFC
so we're giving that a chance. Let's try to put the rest of
this code behind us.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
----------------------------------------------------------------
Andrew Lunn (12):
drivers: net: 3com: 3c509: Remove this driver
drivers: net: 3com: 3c515: Remove this driver
drivers: net: 3com: 3c574: Remove this driver
drivers: net: 3com: 3c589: Remove this driver
drivers: net: amd: lance: Remove this driver
drivers: net: amd: nmclan: Remove this driver
drivers: net: smsc: smc9194: Remove this driver
drivers: net: smsc: smc91c92: Remove this driver
drivers: net: fujitsu: fmvj18x: Remove this driver
drivers: net: 8390: AX88190: Remove this driver
drivers: net: 8390: ultra: Remove this driver
drivers: net: 8390: wd80x3: Remove this driver
Jakub Kicinski (6):
caif: remove CAIF NETWORK LAYER
net: remove ISDN subsystem and Bluetooth CMTP
net: remove ax25 and amateur radio (hamradio) subsystem
net: remove unused ATM protocols and legacy ATM device drivers
Merge branch 'net-packetengines-remove-obsolete-pci-drivers'
Merge branch 'remove-a-number-of-isa-and-pcmcia-ethernet-drivers'
Mingyu Wang (2):
net: packetengines: remove obsolete hamachi driver
net: packetengines: remove obsolete yellowfin driver and vendor dir
CREDITS | 5 +
Documentation/.renames.txt | 6 -
Documentation/admin-guide/kernel-parameters.txt | 18 -
Documentation/isdn/credits.rst | 73 -
Documentation/isdn/index.rst | 14 -
Documentation/isdn/interface_capi.rst | 336 --
Documentation/isdn/m_isdn.rst | 9 -
Documentation/networking/6pack.rst | 191 -
Documentation/networking/ax25.rst | 17 -
Documentation/networking/caif/caif.rst | 138 -
Documentation/networking/caif/index.rst | 12 -
Documentation/networking/caif/linux_caif.rst | 195 -
.../networking/device_drivers/atm/fore200e.rst | 66 -
.../networking/device_drivers/atm/index.rst | 2 -
.../networking/device_drivers/atm/iphase.rst | 193 -
.../device_drivers/ethernet/3com/3c509.rst | 249 -
.../networking/device_drivers/ethernet/index.rst | 2 -
.../device_drivers/ethernet/smsc/smc9.rst | 48 -
.../networking/device_drivers/hamradio/baycom.rst | 174 -
.../networking/device_drivers/hamradio/index.rst | 12 -
.../device_drivers/hamradio/z8530drv.rst | 686 ---
Documentation/networking/device_drivers/index.rst | 1 -
Documentation/networking/index.rst | 3 -
Documentation/staging/magic-number.rst | 3 -
Documentation/subsystem-apis.rst | 1 -
.../translations/it_IT/staging/magic-number.rst | 3 -
.../translations/sp_SP/process/magic-number.rst | 3 -
.../translations/zh_CN/networking/index.rst | 1 -
.../translations/zh_CN/process/magic-number.rst | 3 -
.../translations/zh_TW/process/magic-number.rst | 3 -
MAINTAINERS | 105 +-
arch/alpha/configs/defconfig | 1 -
arch/arm/configs/ixp4xx_defconfig | 4 -
arch/arm/configs/neponset_defconfig | 1 -
arch/arm/configs/u8500_defconfig | 1 -
arch/mips/configs/bcm47xx_defconfig | 1 -
arch/mips/configs/bigsur_defconfig | 10 -
arch/mips/configs/db1xxx_defconfig | 1 -
arch/mips/configs/gpr_defconfig | 24 -
arch/mips/configs/mtx1_defconfig | 32 -
arch/mips/configs/rb532_defconfig | 1 -
arch/mips/configs/rm200_defconfig | 7 -
arch/mips/configs/rt305x_defconfig | 1 -
arch/mips/configs/xway_defconfig | 1 -
arch/powerpc/configs/ppc6xx_defconfig | 19 -
drivers/Kconfig | 2 -
drivers/Makefile | 1 -
drivers/atm/.gitignore | 5 -
drivers/atm/Kconfig | 300 --
drivers/atm/Makefile | 29 -
drivers/atm/adummy.c | 202 -
drivers/atm/atmtcp.c | 513 --
drivers/atm/eni.c | 2321 --------
drivers/atm/eni.h | 136 -
drivers/atm/fore200e.c | 3012 -----------
drivers/atm/fore200e.h | 973 ----
drivers/atm/he.c | 2861 ----------
drivers/atm/he.h | 845 ---
drivers/atm/idt77105.c | 376 --
drivers/atm/idt77105.h | 92 -
drivers/atm/idt77252.c | 3797 --------------
drivers/atm/idt77252.h | 816 ---
drivers/atm/idt77252_tables.h | 781 ---
drivers/atm/iphase.c | 3283 ------------
drivers/atm/iphase.h | 1452 -----
drivers/atm/lanai.c | 2603 ---------
drivers/atm/midway.h | 266 -
drivers/atm/nicstar.c | 2759 ----------
drivers/atm/nicstar.h | 759 ---
drivers/atm/nicstarmac.c | 244 -
drivers/atm/nicstarmac.copyright | 61 -
drivers/atm/suni.c | 391 --
drivers/atm/suni.h | 242 -
drivers/atm/tonga.h | 21 -
drivers/atm/zeprom.h | 35 -
drivers/isdn/Kconfig | 27 -
drivers/isdn/Makefile | 8 -
drivers/isdn/capi/Kconfig | 32 -
drivers/isdn/capi/Makefile | 6 -
drivers/isdn/capi/capi.c | 1435 -----
drivers/isdn/capi/capiutil.c | 677 ---
drivers/isdn/capi/kcapi.c | 933 ----
drivers/isdn/capi/kcapi.h | 182 -
drivers/isdn/capi/kcapi_proc.c | 231 -
drivers/isdn/hardware/Makefile | 6 -
drivers/isdn/hardware/mISDN/Kconfig | 98 -
drivers/isdn/hardware/mISDN/Makefile | 19 -
drivers/isdn/hardware/mISDN/avmfritz.c | 1164 ----
drivers/isdn/hardware/mISDN/hfc_multi.h | 1236 -----
drivers/isdn/hardware/mISDN/hfc_multi_8xx.h | 167 -
drivers/isdn/hardware/mISDN/hfc_pci.h | 214 -
drivers/isdn/hardware/mISDN/hfcmulti.c | 5540 --------------------
drivers/isdn/hardware/mISDN/hfcpci.c | 2360 ---------
drivers/isdn/hardware/mISDN/hfcsusb.c | 2157 --------
drivers/isdn/hardware/mISDN/hfcsusb.h | 425 --
drivers/isdn/hardware/mISDN/iohelper.h | 96 -
drivers/isdn/hardware/mISDN/ipac.h | 393 --
drivers/isdn/hardware/mISDN/isar.h | 256 -
drivers/isdn/hardware/mISDN/isdnhdlc.c | 617 ---
drivers/isdn/hardware/mISDN/isdnhdlc.h | 69 -
drivers/isdn/hardware/mISDN/mISDNinfineon.c | 1168 -----
drivers/isdn/hardware/mISDN/mISDNipac.c | 1636 ------
drivers/isdn/hardware/mISDN/mISDNisar.c | 1694 ------
drivers/isdn/hardware/mISDN/netjet.c | 1154 ----
drivers/isdn/hardware/mISDN/netjet.h | 44 -
drivers/isdn/hardware/mISDN/speedfax.c | 520 --
drivers/isdn/hardware/mISDN/w6692.c | 1417 -----
drivers/isdn/hardware/mISDN/w6692.h | 177 -
drivers/isdn/mISDN/Kconfig | 48 -
drivers/isdn/mISDN/Makefile | 14 -
drivers/isdn/mISDN/clock.c | 197 -
drivers/isdn/mISDN/core.c | 400 --
drivers/isdn/mISDN/core.h | 69 -
drivers/isdn/mISDN/dsp.h | 277 -
drivers/isdn/mISDN/dsp_audio.c | 421 --
drivers/isdn/mISDN/dsp_biquad.h | 51 -
drivers/isdn/mISDN/dsp_blowfish.c | 667 ---
drivers/isdn/mISDN/dsp_cmx.c | 1949 -------
drivers/isdn/mISDN/dsp_core.c | 1227 -----
drivers/isdn/mISDN/dsp_dtmf.c | 313 --
drivers/isdn/mISDN/dsp_ecdis.h | 96 -
drivers/isdn/mISDN/dsp_hwec.c | 122 -
drivers/isdn/mISDN/dsp_hwec.h | 10 -
drivers/isdn/mISDN/dsp_pipeline.c | 300 --
drivers/isdn/mISDN/dsp_tones.c | 550 --
drivers/isdn/mISDN/fsm.c | 176 -
drivers/isdn/mISDN/fsm.h | 58 -
drivers/isdn/mISDN/hwchannel.c | 516 --
drivers/isdn/mISDN/l1oip.h | 92 -
drivers/isdn/mISDN/l1oip_codec.c | 358 --
drivers/isdn/mISDN/l1oip_core.c | 1505 ------
drivers/isdn/mISDN/layer1.c | 415 --
drivers/isdn/mISDN/layer1.h | 16 -
drivers/isdn/mISDN/layer2.c | 2266 --------
drivers/isdn/mISDN/layer2.h | 131 -
drivers/isdn/mISDN/socket.c | 825 ---
drivers/isdn/mISDN/stack.c | 654 ---
drivers/isdn/mISDN/tei.c | 1416 -----
drivers/isdn/mISDN/timerdev.c | 295 --
drivers/net/Kconfig | 2 -
drivers/net/Makefile | 2 -
drivers/net/Space.c | 15 -
drivers/net/caif/Kconfig | 33 -
drivers/net/caif/Makefile | 8 -
drivers/net/caif/caif_serial.c | 443 --
drivers/net/caif/caif_virtio.c | 791 ---
drivers/net/ethernet/3com/3c509.c | 1448 -----
drivers/net/ethernet/3com/3c515.c | 1566 ------
drivers/net/ethernet/3com/3c574_cs.c | 1164 ----
drivers/net/ethernet/3com/3c589_cs.c | 974 ----
drivers/net/ethernet/3com/Kconfig | 45 -
drivers/net/ethernet/3com/Makefile | 4 -
drivers/net/ethernet/8390/Kconfig | 41 -
drivers/net/ethernet/8390/Makefile | 3 -
drivers/net/ethernet/8390/axnet_cs.c | 1707 ------
drivers/net/ethernet/8390/smc-ultra.c | 630 ---
drivers/net/ethernet/8390/wd.c | 575 --
drivers/net/ethernet/Kconfig | 2 -
drivers/net/ethernet/Makefile | 2 -
drivers/net/ethernet/amd/Kconfig | 21 -
drivers/net/ethernet/amd/Makefile | 2 -
drivers/net/ethernet/amd/lance.c | 1317 -----
drivers/net/ethernet/amd/nmclan_cs.c | 1508 ------
drivers/net/ethernet/fujitsu/Kconfig | 30 -
drivers/net/ethernet/fujitsu/Makefile | 6 -
drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 1176 -----
drivers/net/ethernet/packetengines/Kconfig | 44 -
drivers/net/ethernet/packetengines/Makefile | 7 -
drivers/net/ethernet/packetengines/hamachi.c | 1967 -------
drivers/net/ethernet/packetengines/yellowfin.c | 1438 -----
drivers/net/ethernet/smsc/Kconfig | 27 -
drivers/net/ethernet/smsc/Makefile | 2 -
drivers/net/ethernet/smsc/smc9194.c | 1535 ------
drivers/net/ethernet/smsc/smc91c92_cs.c | 2059 --------
drivers/net/hamradio/6pack.c | 912 ----
drivers/net/hamradio/Kconfig | 162 -
drivers/net/hamradio/Makefile | 22 -
drivers/net/hamradio/baycom_epp.c | 1316 -----
drivers/net/hamradio/baycom_par.c | 598 ---
drivers/net/hamradio/baycom_ser_fdx.c | 678 ---
drivers/net/hamradio/baycom_ser_hdx.c | 727 ---
drivers/net/hamradio/bpqether.c | 593 ---
drivers/net/hamradio/hdlcdrv.c | 747 ---
drivers/net/hamradio/mkiss.c | 980 ----
drivers/net/hamradio/scc.c | 2179 --------
drivers/net/hamradio/yam.c | 1191 -----
drivers/net/hamradio/z8530.h | 246 -
include/linux/hdlcdrv.h | 276 -
include/linux/isdn/capilli.h | 95 -
include/linux/isdn/capiutil.h | 60 -
include/linux/kernelcapi.h | 45 -
include/linux/mISDNdsp.h | 40 -
include/linux/mISDNhw.h | 192 -
include/linux/mISDNif.h | 603 ---
include/linux/netdevice.h | 5 +-
include/linux/scc.h | 86 -
include/linux/virtio_caif.h | 24 -
include/linux/yam.h | 67 -
include/net/Space.h | 5 -
include/net/atmclip.h | 53 -
include/net/ax25.h | 476 +-
include/net/caif/caif_dev.h | 128 -
include/net/caif/caif_device.h | 55 -
include/net/caif/caif_layer.h | 277 -
include/net/caif/cfcnfg.h | 90 -
include/net/caif/cfctrl.h | 130 -
include/net/caif/cffrml.h | 21 -
include/net/caif/cfmuxl.h | 20 -
include/net/caif/cfpkt.h | 232 -
include/net/caif/cfserl.h | 13 -
include/net/caif/cfsrvl.h | 61 -
include/net/netrom.h | 273 -
include/net/rose.h | 263 +-
include/uapi/linux/baycom.h | 40 -
include/uapi/linux/caif/caif_socket.h | 195 -
include/uapi/linux/caif/if_caif.h | 35 -
include/uapi/linux/capi.h | 134 -
include/uapi/linux/hdlcdrv.h | 111 -
include/uapi/linux/isdn/capicmd.h | 117 -
include/uapi/linux/kernelcapi.h | 48 -
include/uapi/linux/netrom.h | 37 -
include/uapi/linux/rose.h | 91 -
include/uapi/linux/scc.h | 174 -
net/Kconfig | 2 -
net/Makefile | 4 -
net/atm/Kconfig | 37 -
net/atm/Makefile | 4 -
net/atm/clip.c | 960 ----
net/atm/ioctl.c | 14 -
net/atm/lec.c | 2274 --------
net/atm/lec.h | 155 -
net/atm/lec_arpc.h | 97 -
net/atm/mpc.c | 1538 ------
net/atm/mpc.h | 65 -
net/atm/mpoa_caches.c | 565 --
net/atm/mpoa_caches.h | 99 -
net/atm/mpoa_proc.c | 307 --
net/atm/proc.c | 11 -
net/ax25/Kconfig | 108 -
net/ax25/Makefile | 12 -
net/ax25/af_ax25.c | 2089 --------
net/ax25/ax25_addr.c | 303 --
net/ax25/ax25_dev.c | 200 -
net/ax25/ax25_ds_in.c | 298 --
net/ax25/ax25_ds_subr.c | 204 -
net/ax25/ax25_ds_timer.c | 235 -
net/ax25/ax25_iface.c | 214 -
net/ax25/ax25_in.c | 455 --
net/ax25/ax25_ip.c | 247 -
net/ax25/ax25_out.c | 398 --
net/ax25/ax25_route.c | 416 --
net/ax25/ax25_std_in.c | 443 --
net/ax25/ax25_std_subr.c | 83 -
net/ax25/ax25_std_timer.c | 175 -
net/ax25/ax25_subr.c | 296 --
net/ax25/ax25_timer.c | 224 -
net/ax25/ax25_uid.c | 204 -
net/ax25/sysctl_net_ax25.c | 181 -
net/bluetooth/Kconfig | 3 -
net/bluetooth/Makefile | 1 -
net/bluetooth/cmtp/Kconfig | 12 -
net/bluetooth/cmtp/Makefile | 8 -
net/bluetooth/cmtp/capi.c | 579 --
net/bluetooth/cmtp/cmtp.h | 129 -
net/bluetooth/cmtp/core.c | 519 --
net/bluetooth/cmtp/sock.c | 271 -
net/bridge/br.c | 7 -
net/bridge/br_fdb.c | 29 -
net/bridge/br_private.h | 4 -
net/caif/Kconfig | 54 -
net/caif/Makefile | 16 -
net/caif/caif_dev.c | 586 ---
net/caif/caif_socket.c | 1114 ----
net/caif/caif_usb.c | 216 -
net/caif/cfcnfg.c | 612 ---
net/caif/cfctrl.c | 631 ---
net/caif/cfdbgl.c | 55 -
net/caif/cfdgml.c | 113 -
net/caif/cffrml.c | 204 -
net/caif/cfmuxl.c | 267 -
net/caif/cfpkt_skbuff.c | 373 --
net/caif/cfrfml.c | 299 --
net/caif/cfserl.c | 192 -
net/caif/cfsrvl.c | 224 -
net/caif/cfutill.c | 104 -
net/caif/cfveil.c | 101 -
net/caif/cfvidl.c | 65 -
net/caif/chnl_net.c | 531 --
net/core/dev.c | 7 -
net/ipv4/arp.c | 1 -
net/netrom/Makefile | 10 -
net/netrom/af_netrom.c | 1536 ------
net/netrom/nr_dev.c | 178 -
net/netrom/nr_in.c | 301 --
net/netrom/nr_loopback.c | 73 -
net/netrom/nr_out.c | 272 -
net/netrom/nr_route.c | 989 ----
net/netrom/nr_subr.c | 280 -
net/netrom/nr_timer.c | 249 -
net/netrom/sysctl_net_netrom.c | 156 -
net/rose/Makefile | 10 -
net/rose/af_rose.c | 1687 ------
net/rose/rose_dev.c | 141 -
net/rose/rose_in.c | 301 --
net/rose/rose_link.c | 289 -
net/rose/rose_loopback.c | 133 -
net/rose/rose_out.c | 122 -
net/rose/rose_route.c | 1333 -----
net/rose/rose_subr.c | 556 --
net/rose/rose_timer.c | 227 -
net/rose/sysctl_net_rose.c | 125 -
311 files changed, 14 insertions(+), 138161 deletions(-)
delete mode 100644 Documentation/isdn/credits.rst
delete mode 100644 Documentation/isdn/index.rst
delete mode 100644 Documentation/isdn/interface_capi.rst
delete mode 100644 Documentation/isdn/m_isdn.rst
delete mode 100644 Documentation/networking/6pack.rst
delete mode 100644 Documentation/networking/ax25.rst
delete mode 100644 Documentation/networking/caif/caif.rst
delete mode 100644 Documentation/networking/caif/index.rst
delete mode 100644 Documentation/networking/caif/linux_caif.rst
delete mode 100644 Documentation/networking/device_drivers/atm/fore200e.rst
delete mode 100644 Documentation/networking/device_drivers/atm/iphase.rst
delete mode 100644 Documentation/networking/device_drivers/ethernet/3com/3c509.rst
delete mode 100644 Documentation/networking/device_drivers/ethernet/smsc/smc9.rst
delete mode 100644 Documentation/networking/device_drivers/hamradio/baycom.rst
delete mode 100644 Documentation/networking/device_drivers/hamradio/index.rst
delete mode 100644 Documentation/networking/device_drivers/hamradio/z8530drv.rst
delete mode 100644 drivers/atm/.gitignore
delete mode 100644 drivers/atm/adummy.c
delete mode 100644 drivers/atm/atmtcp.c
delete mode 100644 drivers/atm/eni.c
delete mode 100644 drivers/atm/eni.h
delete mode 100644 drivers/atm/fore200e.c
delete mode 100644 drivers/atm/fore200e.h
delete mode 100644 drivers/atm/he.c
delete mode 100644 drivers/atm/he.h
delete mode 100644 drivers/atm/idt77105.c
delete mode 100644 drivers/atm/idt77105.h
delete mode 100644 drivers/atm/idt77252.c
delete mode 100644 drivers/atm/idt77252.h
delete mode 100644 drivers/atm/idt77252_tables.h
delete mode 100644 drivers/atm/iphase.c
delete mode 100644 drivers/atm/iphase.h
delete mode 100644 drivers/atm/lanai.c
delete mode 100644 drivers/atm/midway.h
delete mode 100644 drivers/atm/nicstar.c
delete mode 100644 drivers/atm/nicstar.h
delete mode 100644 drivers/atm/nicstarmac.c
delete mode 100644 drivers/atm/nicstarmac.copyright
delete mode 100644 drivers/atm/suni.c
delete mode 100644 drivers/atm/suni.h
delete mode 100644 drivers/atm/tonga.h
delete mode 100644 drivers/atm/zeprom.h
delete mode 100644 drivers/isdn/Kconfig
delete mode 100644 drivers/isdn/Makefile
delete mode 100644 drivers/isdn/capi/Kconfig
delete mode 100644 drivers/isdn/capi/Makefile
delete mode 100644 drivers/isdn/capi/capi.c
delete mode 100644 drivers/isdn/capi/capiutil.c
delete mode 100644 drivers/isdn/capi/kcapi.c
delete mode 100644 drivers/isdn/capi/kcapi.h
delete mode 100644 drivers/isdn/capi/kcapi_proc.c
delete mode 100644 drivers/isdn/hardware/Makefile
delete mode 100644 drivers/isdn/hardware/mISDN/Kconfig
delete mode 100644 drivers/isdn/hardware/mISDN/Makefile
delete mode 100644 drivers/isdn/hardware/mISDN/avmfritz.c
delete mode 100644 drivers/isdn/hardware/mISDN/hfc_multi.h
delete mode 100644 drivers/isdn/hardware/mISDN/hfc_multi_8xx.h
delete mode 100644 drivers/isdn/hardware/mISDN/hfc_pci.h
delete mode 100644 drivers/isdn/hardware/mISDN/hfcmulti.c
delete mode 100644 drivers/isdn/hardware/mISDN/hfcpci.c
delete mode 100644 drivers/isdn/hardware/mISDN/hfcsusb.c
delete mode 100644 drivers/isdn/hardware/mISDN/hfcsusb.h
delete mode 100644 drivers/isdn/hardware/mISDN/iohelper.h
delete mode 100644 drivers/isdn/hardware/mISDN/ipac.h
delete mode 100644 drivers/isdn/hardware/mISDN/isar.h
delete mode 100644 drivers/isdn/hardware/mISDN/isdnhdlc.c
delete mode 100644 drivers/isdn/hardware/mISDN/isdnhdlc.h
delete mode 100644 drivers/isdn/hardware/mISDN/mISDNinfineon.c
delete mode 100644 drivers/isdn/hardware/mISDN/mISDNipac.c
delete mode 100644 drivers/isdn/hardware/mISDN/mISDNisar.c
delete mode 100644 drivers/isdn/hardware/mISDN/netjet.c
delete mode 100644 drivers/isdn/hardware/mISDN/netjet.h
delete mode 100644 drivers/isdn/hardware/mISDN/speedfax.c
delete mode 100644 drivers/isdn/hardware/mISDN/w6692.c
delete mode 100644 drivers/isdn/hardware/mISDN/w6692.h
delete mode 100644 drivers/isdn/mISDN/Kconfig
delete mode 100644 drivers/isdn/mISDN/Makefile
delete mode 100644 drivers/isdn/mISDN/clock.c
delete mode 100644 drivers/isdn/mISDN/core.c
delete mode 100644 drivers/isdn/mISDN/core.h
delete mode 100644 drivers/isdn/mISDN/dsp.h
delete mode 100644 drivers/isdn/mISDN/dsp_audio.c
delete mode 100644 drivers/isdn/mISDN/dsp_biquad.h
delete mode 100644 drivers/isdn/mISDN/dsp_blowfish.c
delete mode 100644 drivers/isdn/mISDN/dsp_cmx.c
delete mode 100644 drivers/isdn/mISDN/dsp_core.c
delete mode 100644 drivers/isdn/mISDN/dsp_dtmf.c
delete mode 100644 drivers/isdn/mISDN/dsp_ecdis.h
delete mode 100644 drivers/isdn/mISDN/dsp_hwec.c
delete mode 100644 drivers/isdn/mISDN/dsp_hwec.h
delete mode 100644 drivers/isdn/mISDN/dsp_pipeline.c
delete mode 100644 drivers/isdn/mISDN/dsp_tones.c
delete mode 100644 drivers/isdn/mISDN/fsm.c
delete mode 100644 drivers/isdn/mISDN/fsm.h
delete mode 100644 drivers/isdn/mISDN/hwchannel.c
delete mode 100644 drivers/isdn/mISDN/l1oip.h
delete mode 100644 drivers/isdn/mISDN/l1oip_codec.c
delete mode 100644 drivers/isdn/mISDN/l1oip_core.c
delete mode 100644 drivers/isdn/mISDN/layer1.c
delete mode 100644 drivers/isdn/mISDN/layer1.h
delete mode 100644 drivers/isdn/mISDN/layer2.c
delete mode 100644 drivers/isdn/mISDN/layer2.h
delete mode 100644 drivers/isdn/mISDN/socket.c
delete mode 100644 drivers/isdn/mISDN/stack.c
delete mode 100644 drivers/isdn/mISDN/tei.c
delete mode 100644 drivers/isdn/mISDN/timerdev.c
delete mode 100644 drivers/net/caif/Kconfig
delete mode 100644 drivers/net/caif/Makefile
delete mode 100644 drivers/net/caif/caif_serial.c
delete mode 100644 drivers/net/caif/caif_virtio.c
delete mode 100644 drivers/net/ethernet/3com/3c509.c
delete mode 100644 drivers/net/ethernet/3com/3c515.c
delete mode 100644 drivers/net/ethernet/3com/3c574_cs.c
delete mode 100644 drivers/net/ethernet/3com/3c589_cs.c
delete mode 100644 drivers/net/ethernet/8390/axnet_cs.c
delete mode 100644 drivers/net/ethernet/8390/smc-ultra.c
delete mode 100644 drivers/net/ethernet/8390/wd.c
delete mode 100644 drivers/net/ethernet/amd/lance.c
delete mode 100644 drivers/net/ethernet/amd/nmclan_cs.c
delete mode 100644 drivers/net/ethernet/fujitsu/Kconfig
delete mode 100644 drivers/net/ethernet/fujitsu/Makefile
delete mode 100644 drivers/net/ethernet/fujitsu/fmvj18x_cs.c
delete mode 100644 drivers/net/ethernet/packetengines/Kconfig
delete mode 100644 drivers/net/ethernet/packetengines/Makefile
delete mode 100644 drivers/net/ethernet/packetengines/hamachi.c
delete mode 100644 drivers/net/ethernet/packetengines/yellowfin.c
delete mode 100644 drivers/net/ethernet/smsc/smc9194.c
delete mode 100644 drivers/net/ethernet/smsc/smc91c92_cs.c
delete mode 100644 drivers/net/hamradio/6pack.c
delete mode 100644 drivers/net/hamradio/Kconfig
delete mode 100644 drivers/net/hamradio/Makefile
delete mode 100644 drivers/net/hamradio/baycom_epp.c
delete mode 100644 drivers/net/hamradio/baycom_par.c
delete mode 100644 drivers/net/hamradio/baycom_ser_fdx.c
delete mode 100644 drivers/net/hamradio/baycom_ser_hdx.c
delete mode 100644 drivers/net/hamradio/bpqether.c
delete mode 100644 drivers/net/hamradio/hdlcdrv.c
delete mode 100644 drivers/net/hamradio/mkiss.c
delete mode 100644 drivers/net/hamradio/scc.c
delete mode 100644 drivers/net/hamradio/yam.c
delete mode 100644 drivers/net/hamradio/z8530.h
delete mode 100644 include/linux/hdlcdrv.h
delete mode 100644 include/linux/isdn/capilli.h
delete mode 100644 include/linux/isdn/capiutil.h
delete mode 100644 include/linux/kernelcapi.h
delete mode 100644 include/linux/mISDNdsp.h
delete mode 100644 include/linux/mISDNhw.h
delete mode 100644 include/linux/mISDNif.h
delete mode 100644 include/linux/scc.h
delete mode 100644 include/linux/virtio_caif.h
delete mode 100644 include/linux/yam.h
delete mode 100644 include/net/atmclip.h
delete mode 100644 include/net/caif/caif_dev.h
delete mode 100644 include/net/caif/caif_device.h
delete mode 100644 include/net/caif/caif_layer.h
delete mode 100644 include/net/caif/cfcnfg.h
delete mode 100644 include/net/caif/cfctrl.h
delete mode 100644 include/net/caif/cffrml.h
delete mode 100644 include/net/caif/cfmuxl.h
delete mode 100644 include/net/caif/cfpkt.h
delete mode 100644 include/net/caif/cfserl.h
delete mode 100644 include/net/caif/cfsrvl.h
delete mode 100644 include/net/netrom.h
delete mode 100644 include/uapi/linux/baycom.h
delete mode 100644 include/uapi/linux/caif/caif_socket.h
delete mode 100644 include/uapi/linux/caif/if_caif.h
delete mode 100644 include/uapi/linux/capi.h
delete mode 100644 include/uapi/linux/hdlcdrv.h
delete mode 100644 include/uapi/linux/isdn/capicmd.h
delete mode 100644 include/uapi/linux/kernelcapi.h
delete mode 100644 include/uapi/linux/netrom.h
delete mode 100644 include/uapi/linux/rose.h
delete mode 100644 include/uapi/linux/scc.h
delete mode 100644 net/atm/clip.c
delete mode 100644 net/atm/lec.c
delete mode 100644 net/atm/lec.h
delete mode 100644 net/atm/lec_arpc.h
delete mode 100644 net/atm/mpc.c
delete mode 100644 net/atm/mpc.h
delete mode 100644 net/atm/mpoa_caches.c
delete mode 100644 net/atm/mpoa_caches.h
delete mode 100644 net/atm/mpoa_proc.c
delete mode 100644 net/ax25/Kconfig
delete mode 100644 net/ax25/Makefile
delete mode 100644 net/ax25/af_ax25.c
delete mode 100644 net/ax25/ax25_addr.c
delete mode 100644 net/ax25/ax25_dev.c
delete mode 100644 net/ax25/ax25_ds_in.c
delete mode 100644 net/ax25/ax25_ds_subr.c
delete mode 100644 net/ax25/ax25_ds_timer.c
delete mode 100644 net/ax25/ax25_iface.c
delete mode 100644 net/ax25/ax25_in.c
delete mode 100644 net/ax25/ax25_ip.c
delete mode 100644 net/ax25/ax25_out.c
delete mode 100644 net/ax25/ax25_route.c
delete mode 100644 net/ax25/ax25_std_in.c
delete mode 100644 net/ax25/ax25_std_subr.c
delete mode 100644 net/ax25/ax25_std_timer.c
delete mode 100644 net/ax25/ax25_subr.c
delete mode 100644 net/ax25/ax25_timer.c
delete mode 100644 net/ax25/ax25_uid.c
delete mode 100644 net/ax25/sysctl_net_ax25.c
delete mode 100644 net/bluetooth/cmtp/Kconfig
delete mode 100644 net/bluetooth/cmtp/Makefile
delete mode 100644 net/bluetooth/cmtp/capi.c
delete mode 100644 net/bluetooth/cmtp/cmtp.h
delete mode 100644 net/bluetooth/cmtp/core.c
delete mode 100644 net/bluetooth/cmtp/sock.c
delete mode 100644 net/caif/Kconfig
delete mode 100644 net/caif/Makefile
delete mode 100644 net/caif/caif_dev.c
delete mode 100644 net/caif/caif_socket.c
delete mode 100644 net/caif/caif_usb.c
delete mode 100644 net/caif/cfcnfg.c
delete mode 100644 net/caif/cfctrl.c
delete mode 100644 net/caif/cfdbgl.c
delete mode 100644 net/caif/cfdgml.c
delete mode 100644 net/caif/cffrml.c
delete mode 100644 net/caif/cfmuxl.c
delete mode 100644 net/caif/cfpkt_skbuff.c
delete mode 100644 net/caif/cfrfml.c
delete mode 100644 net/caif/cfserl.c
delete mode 100644 net/caif/cfsrvl.c
delete mode 100644 net/caif/cfutill.c
delete mode 100644 net/caif/cfveil.c
delete mode 100644 net/caif/cfvidl.c
delete mode 100644 net/caif/chnl_net.c
delete mode 100644 net/netrom/Makefile
delete mode 100644 net/netrom/af_netrom.c
delete mode 100644 net/netrom/nr_dev.c
delete mode 100644 net/netrom/nr_in.c
delete mode 100644 net/netrom/nr_loopback.c
delete mode 100644 net/netrom/nr_out.c
delete mode 100644 net/netrom/nr_route.c
delete mode 100644 net/netrom/nr_subr.c
delete mode 100644 net/netrom/nr_timer.c
delete mode 100644 net/netrom/sysctl_net_netrom.c
delete mode 100644 net/rose/Makefile
delete mode 100644 net/rose/af_rose.c
delete mode 100644 net/rose/rose_dev.c
delete mode 100644 net/rose/rose_in.c
delete mode 100644 net/rose/rose_link.c
delete mode 100644 net/rose/rose_loopback.c
delete mode 100644 net/rose/rose_out.c
delete mode 100644 net/rose/rose_route.c
delete mode 100644 net/rose/rose_subr.c
delete mode 100644 net/rose/rose_timer.c
delete mode 100644 net/rose/sysctl_net_rose.c
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net] ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
From: Nowlin, Alexander @ 2026-04-23 23:57 UTC (permalink / raw)
To: Oros, Petr, netdev@vger.kernel.org
Cc: Michal Swiatkowski, Greenwalt, Paul, Daniel Zahka,
Kitszel, Przemyslaw, Nikolay Aleksandrov, Eric Dumazet,
linux-kernel@vger.kernel.org, Loktionov, Aleksandr, Andrew Lunn,
Nguyen, Anthony L, Ertman, David M, Keller, Jacob E,
Jakub Kicinski, Paolo Abeni, David S. Miller,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <20260413191420.3524013-1-poros@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of Petr Oros
> Sent: Monday, April 13, 2026 12:14 PM
> To: netdev@vger.kernel.org
> Cc: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>; Greenwalt, Paul <paul.greenwalt@intel.com>; Daniel Zahka <daniel.zahka@gmail.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Nikolay Aleksandrov <razor@blackwall.org>; Eric Dumazet <edumazet@google.com>; linux-
> kernel@vger.kernel.org; Loktionov, Aleksandr <aleksandr.loktionov@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Ertman, David M <david.m.ertman@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; David S. Miller <davem@davemloft.net>; intel-wired-lan@lists.osuosl.org
> Subject: [Intel-wired-lan] [PATCH iwl-net] ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw
>
> On certain E810 configurations where firmware supports Tx scheduler topology switching (tx_sched_topo_comp_mode_en), ice_cfg_tx_topo() may need to apply a new 5-layer or 9-layer topology from the DDP package. If the AQ command to set the topology fails (e.g. due to invalid DDP data or firmware
> limitations), the global configuration lock must still be cleared via a CORER reset.
>
> Commit 86aae43f21cf ("ice: don't leave device non-functional if Tx scheduler config fails") correctly fixed this by refactoring
> ice_cfg_tx_topo() to always trigger CORER after acquiring the global lock and re-initialize hardware via ice_init_hw() afterwards.
>
> However, commit 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths") later moved ice_init_dev_hw() into ice_init_hw(), breaking the reinit path introduced by 86aae43f21cf. This creates an infinite recursive call chain:
>
> ice_init_hw()
> ice_init_dev_hw()
> ice_cfg_tx_topo() # topology change needed
> ice_deinit_hw()
> ice_init_hw() # reinit after CORER
> ice_init_dev_hw() # recurse
> ice_cfg_tx_topo()
> ... # stack overflow
>
> Fix by moving ice_init_dev_hw() back out of ice_init_hw() and calling it explicitly from ice_probe() and ice_devlink_reinit_up(). The third caller, ice_cfg_tx_topo(), intentionally does not need ice_init_dev_hw() during its reinit, it only needs the core HW reinitialization. This breaks the recursion cleanly without
> adding flags or guards.
>
> The deinit ordering changes from commit 8a37f9e2ff40 ("ice: move
> ice_deinit_dev() to the end of deinit paths") which fixed slow rmmod are preserved, only the init-side placement of ice_init_dev_hw() is reverted.
> Fixes: 8a37f9e2ff40 ("ice: move ice_deinit_dev() to the end of deinit paths")
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 ++
> drivers/net/ethernet/intel/ice/ice_common.c | 2 --
> drivers/net/ethernet/intel/ice/ice_main.c | 2 ++
> 3 files changed, 4 insertions(+), 2 deletions(-)
Tested-by: Alexander Nowlin <alexander.nowlin@intel.com>
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/9] Refactor verifier object relationship tracking
From: Andrii Nakryiko @ 2026-04-24 0:04 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-1-ameryhung@gmail.com>
On Tue, Apr 21, 2026 at 3:10 PM Amery Hung <ameryhung@gmail.com> wrote:
>
> Hi all,
>
> This patchset cleans up dynptr handling, refactors object relationship
> tracking in the verifier by introducing parent_id, and fixes dynptr
> use-after-free bugs where file/skb dynptrs are not invalidated when
> the parent referenced object is freed.
>
>
> * Motivation *
>
Very nice and approachable cover letter, thanks for improving it!
> In BPF qdisc programs, an skb can be freed through kfuncs. However,
> since dynptr does not track the parent referenced object (e.g., skb),
> the verifier does not invalidate the dynptr after the skb is freed,
> resulting in use-after-free. The same issue also affects file dynptr.
>
[...]
^ permalink raw reply
* Re: [PATCH bpf-next v3 1/9] bpf: Unify dynptr handling in the verifier
From: Andrii Nakryiko @ 2026-04-24 0:04 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-2-ameryhung@gmail.com>
On Tue, Apr 21, 2026 at 3:10 PM Amery Hung <ameryhung@gmail.com> wrote:
>
> Simplify dynptr checking for helper and kfunc by unifying it. Remember
> the initialized dynptr (i.e.,g !(arg_type |= MEM_UNINIT)) pass to a
> dynptr kfunc during process_dynptr_func() so that we can easily
> retrieve the information for verification later. By saving it in
> meta->dynptr, there is no need to call dynptr helpers such as
> dynptr_id(), dynptr_ref_obj_id() and dynptr_type() in check_func_arg().
>
> Remove and open code the helpers in process_dynptr_func() when
> saving id, ref_obj_id, and type. It is okay to drop spi < 0 check as
> is_dynptr_reg_valid_init() has made sure the dynptr is valid.
>
> Besides, since dynptr ref_obj_id information is now pass around in
> meta->bpf_dynptr_desc, drop the check in helper_multiple_ref_obj_use.
>
> Acked-by: Eduard Zingerman <eddyz87@gmail.com>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
> include/linux/bpf_verifier.h | 12 ++-
> kernel/bpf/verifier.c | 178 +++++++----------------------------
> 2 files changed, 41 insertions(+), 149 deletions(-)
>
[...]
> @@ -7433,7 +7426,8 @@ static int process_kptr_func(struct bpf_verifier_env *env, int regno,
> * and checked dynamically during runtime.
> */
> static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn_idx,
> - enum bpf_arg_type arg_type, int clone_ref_obj_id)
> + enum bpf_arg_type arg_type, int clone_ref_obj_id,
> + struct bpf_dynptr_desc *dynptr)
> {
> struct bpf_reg_state *reg = reg_state(env, regno);
> int err;
> @@ -7499,6 +7493,20 @@ static int process_dynptr_func(struct bpf_verifier_env *env, int regno, int insn
> }
>
> err = mark_dynptr_read(env, reg);
if mark_dynptr_read() fails, should we exit instead of proceeding to
fill out dynptr info?.. even if mark_dynptr_read() cannot fail because
of is_dynptr_reg_valid_init(), it still looks wrong and error-prone
> +
> + if (dynptr) {
> + struct bpf_func_state *state = bpf_func(env, reg);
> + int spi;
> +
> + if (reg->type != CONST_PTR_TO_DYNPTR) {
> + spi = dynptr_get_spi(env, reg);
> + reg = &state->stack[spi].spilled_ptr;
> + }
> +
> + dynptr->id = reg->id;
> + dynptr->type = reg->dynptr.type;
> + dynptr->ref_obj_id = reg->ref_obj_id;
> + }
> }
> return err;
> }
[...]
^ permalink raw reply
* Re: [PATCH bpf-next v3 2/9] bpf: Assign reg->id when getting referenced kptr from ctx
From: Andrii Nakryiko @ 2026-04-24 0:04 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-3-ameryhung@gmail.com>
On Tue, Apr 21, 2026 at 3:10 PM Amery Hung <ameryhung@gmail.com> wrote:
>
> Assign reg->id when getting referenced kptr from read program context
> to be consistent with R0 of KF_ACQUIRE kfunc. skb dynptr will track the
> referenced skb in qdisc programs using a new field reg->parent_id in
> a later patch.
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
> kernel/bpf/verifier.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
LGTM
Acked-by: Andrii Nakryiko <andrii@kernel.org>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 41e4ea41c72e..93003a2a96b0 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -6448,8 +6448,6 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> } else {
> mark_reg_known_zero(env, regs,
> value_regno);
> - if (type_may_be_null(info.reg_type))
> - regs[value_regno].id = ++env->id_gen;
> /* A load of ctx field could have different
> * actual load size with the one encoded in the
> * insn. When the dst is PTR, it is for sure not
> @@ -6459,8 +6457,11 @@ static int check_mem_access(struct bpf_verifier_env *env, int insn_idx, u32 regn
> if (base_type(info.reg_type) == PTR_TO_BTF_ID) {
> regs[value_regno].btf = info.btf;
> regs[value_regno].btf_id = info.btf_id;
> + regs[value_regno].id = info.ref_obj_id;
> regs[value_regno].ref_obj_id = info.ref_obj_id;
> }
> + if (type_may_be_null(info.reg_type) && !regs[value_regno].id)
> + regs[value_regno].id = ++env->id_gen;
> }
> regs[value_regno].type = info.reg_type;
> }
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH bpf-next v3 3/9] bpf: Preserve reg->id of pointer objects after null-check
From: Andrii Nakryiko @ 2026-04-24 0:04 UTC (permalink / raw)
To: Amery Hung
Cc: bpf, netdev, alexei.starovoitov, andrii, daniel, eddyz87, memxor,
martin.lau, mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-4-ameryhung@gmail.com>
On Tue, Apr 21, 2026 at 3:10 PM Amery Hung <ameryhung@gmail.com> wrote:
>
> Preserve reg->id of pointer objects after null-checking the register so
> that children objects derived from it can still refer to it in the new
> object relationship tracking mechanism introduced in a later patch. This
> change incurs a slight increase in the number of states in one selftest
> bpf object, rbtree_search.bpf.o. For Meta bpf objects, the increase of
> states is also negligible.
>
> Selftest BPF objects with insns_diff > 0
>
> Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
> ------------------------ --------- --------- -------------- ---------- ---------- -------------
> rbtree_search 6820 7326 +506 (+7.42%) 379 398 +19 (+5.01%)
>
> Meta BPF objects with insns_diff > 0
>
> Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)
> ------------------------ --------- --------- -------------- ---------- ---------- -------------
> ned_imex_be_tclass 52 57 +5 (+9.62%) 5 6 +1 (+20.00%)
> ned_imex_be_tclass 52 57 +5 (+9.62%) 5 6 +1 (+20.00%)
> ned_skop_auto_flowlabel 523 526 +3 (+0.57%) 39 40 +1 (+2.56%)
> ned_skop_mss 289 292 +3 (+1.04%) 20 20 +0 (+0.00%)
> ned_skopt_bet_classifier 78 82 +4 (+5.13%) 8 8 +0 (+0.00%)
> dctcp_update_alpha 252 320 +68 (+26.98%) 21 27 +6 (+28.57%)
> dctcp_update_alpha 252 320 +68 (+26.98%) 21 27 +6 (+28.57%)
> ned_ts_func 119 126 +7 (+5.88%) 6 7 +1 (+16.67%)
> tw_egress 1119 1128 +9 (+0.80%) 95 96 +1 (+1.05%)
> tw_ingress 1128 1137 +9 (+0.80%) 95 96 +1 (+1.05%)
> tw_tproxy_router 4380 4465 +85 (+1.94%) 114 118 +4 (+3.51%)
> tw_tproxy_router4 3093 3170 +77 (+2.49%) 83 88 +5 (+6.02%)
> ttls_tc_ingress 34656 35717 +1061 (+3.06%) 936 970 +34 (+3.63%)
> tw_twfw_egress 222327 222338 +11 (+0.00%) 10563 10564 +1 (+0.01%)
> tw_twfw_ingress 78295 78299 +4 (+0.01%) 3825 3826 +1 (+0.03%)
> tw_twfw_tc_eg 222839 222859 +20 (+0.01%) 10584 10585 +1 (+0.01%)
> tw_twfw_tc_in 78295 78299 +4 (+0.01%) 3825 3826 +1 (+0.03%)
> tw_twfw_egress 8080 8085 +5 (+0.06%) 456 456 +0 (+0.00%)
> tw_twfw_ingress 8053 8056 +3 (+0.04%) 454 454 +0 (+0.00%)
> tw_twfw_tc_eg 8154 8174 +20 (+0.25%) 456 457 +1 (+0.22%)
> tw_twfw_tc_in 8060 8063 +3 (+0.04%) 455 455 +0 (+0.00%)
> tw_twfw_egress 222327 222338 +11 (+0.00%) 10563 10564 +1 (+0.01%)
> tw_twfw_ingress 78295 78299 +4 (+0.01%) 3825 3826 +1 (+0.03%)
> tw_twfw_tc_eg 222839 222859 +20 (+0.01%) 10584 10585 +1 (+0.01%)
> tw_twfw_tc_in 78295 78299 +4 (+0.01%) 3825 3826 +1 (+0.03%)
> tw_twfw_egress 8080 8085 +5 (+0.06%) 456 456 +0 (+0.00%)
> tw_twfw_ingress 8053 8056 +3 (+0.04%) 454 454 +0 (+0.00%)
> tw_twfw_tc_eg 8154 8174 +20 (+0.25%) 456 457 +1 (+0.22%)
> tw_twfw_tc_in 8060 8063 +3 (+0.04%) 455 455 +0 (+0.00%)
>
> Looking into rbtree_search, the reason for such increase is that the
> verifier has to explore the main loop shown below for one more iteration
> until state pruning decides the current state is safe.
>
> long rbtree_search(void *ctx)
> {
> ...
> bpf_spin_lock(&glock0);
> rb_n = bpf_rbtree_root(&groot0);
> while (can_loop) {
> if (!rb_n) {
> bpf_spin_unlock(&glock0);
> return __LINE__;
> }
>
> n = rb_entry(rb_n, struct node_data, r0);
> if (lookup_key == n->key0)
> break;
> if (nr_gc < NR_NODES)
> gc_ns[nr_gc++] = rb_n;
> if (lookup_key < n->key0)
> rb_n = bpf_rbtree_left(&groot0, rb_n);
> else
> rb_n = bpf_rbtree_right(&groot0, rb_n);
> }
> ...
> }
>
> Below is what the verifier sees at the start of each iteration
> (65: may_goto) after preserving id of rb_n. Without id of rb_n, the
> verifier stops exploring the loop at iter 16.
>
> rb_n gc_ns[15]
> iter 15 257 257
>
> iter 16 290 257 rb_n: idmap add 257->290
> gc_ns[15]: check 257 != 290 --> state not equal
>
> iter 17 325 257 rb_n: idmap add 290->325
> gc_ns[15]: idmap add 257->257 --> state safe
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
> ---
> kernel/bpf/verifier.c | 13 ++++---------
> 1 file changed, 4 insertions(+), 9 deletions(-)
>
totally seems worth doing
Acked-by: Andrii Nakryiko <andrii@kernel.org>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 93003a2a96b0..0313b7d5f6c9 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -15886,15 +15886,10 @@ static void mark_ptr_or_null_reg(struct bpf_func_state *state,
>
> mark_ptr_not_null_reg(reg);
>
> - if (!reg_may_point_to_spin_lock(reg)) {
> - /* For not-NULL ptr, reg->ref_obj_id will be reset
> - * in release_reference().
> - *
> - * reg->id is still used by spin_lock ptr. Other
> - * than spin_lock ptr type, reg->id can be reset.
> - */
> - reg->id = 0;
> - }
> + /*
> + * reg->id is preserved for object relationship tracking
> + * and spin_lock lock state tracking
> + */
> }
> }
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH bpf-next v3 4/9] bpf: Refactor object relationship tracking and fix dynptr UAF bug
From: Andrii Nakryiko @ 2026-04-24 0:04 UTC (permalink / raw)
To: Amery Hung
Cc: Mykyta Yatsenko, bpf, netdev, alexei.starovoitov, andrii, daniel,
eddyz87, memxor, martin.lau, kernel-team
In-Reply-To: <CAMB2axO5TJwmYyvRheoZGH4ktRa0d8ig-UGK5E269iVoDH-zPw@mail.gmail.com>
On Thu, Apr 23, 2026 at 11:44 AM Amery Hung <ameryhung@gmail.com> wrote:
>
> On Thu, Apr 23, 2026 at 11:19 AM Mykyta Yatsenko
> <mykyta.yatsenko5@gmail.com> wrote:
> >
> >
> >
> > On 4/21/26 11:10 PM, Amery Hung wrote:
> > > Refactor object relationship tracking in the verifier and fix a dynptr
> > > use-after-free bug where file/skb dynptrs are not invalidated when the
> > > parent referenced object is freed.
> > >
> > > Add parent_id to bpf_reg_state to precisely track child-parent
> > > relationships. A child object's parent_id points to the parent object's
> > > id. This replaces the PTR_TO_MEM-specific dynptr_id and does not
> > > increase the size of bpf_reg_state on 64-bit machines as there is
> > > existing padding.
> > >
> > > When calling dynptr constructors (i.e., process_dynptr_func() with
> > > MEM_UNINIT argument), track the parent's id if the parent is a
> > > referenced object. This only applies to file dynptr and skb dynptr,
> > > so only pass parent reg->id to kfunc constructors.
> > >
> > > For release_reference(), invalidating an object now also invalidates
> > > all descendants by traversing the object tree. This is done using
> > > stack-based DFS to avoid recursive call chains of release_reference() ->
> > > unmark_stack_slots_dynptr() -> release_reference(). Referenced objects
> > > encountered during tree traversal cannot be indirectly released. They
> > > require an explicit helper/kfunc call to release the acquired resources.
> > >
> > > While the new design changes how object relationships are tracked in
> > > the verifier, it does not change the verifier's behavior. Here is the
> > > implication for dynptr, pointer casting, and owning/non-owning
> > > references:
> > >
> > > Dynptr:
> > >
> > > When initializing a dynptr, referenced dynptrs acquire a reference for
> > > ref_obj_id. If the dynptr has a referenced parent, parent_id tracks the
> > > parent's id. When cloning, ref_obj_id and parent_id are copied from the
> > > original. Releasing a referenced dynptr via release_reference(ref_obj_id)
> > > invalidates all clones and derived slices. For non-referenced dynptrs,
> > > only the specific dynptr and its children are invalidated.
> > >
> > > Pointer casting:
> > >
> > > Referenced socket pointers and their casted counterparts share the same
> > > lifetime but have different nullness — they have different id but the
> > > same ref_obj_id.
> > >
> > > Owning to non-owning reference conversion:
> > >
> > > After converting owning to non-owning by clearing ref_obj_id (e.g.,
> > > object(id=1, ref_obj_id=1) -> object(id=1, ref_obj_id=0)), the
> > > verifier only needs to release the reference state, so it calls
> > > release_reference_nomark() instead of release_reference().
> > >
> > > Note that the error message "reference has not been acquired before" in
> > > the helper and kfunc release paths is removed. This message was already
> > > unreachable. The verifier only calls release_reference() after
> > > confirming meta.ref_obj_id is valid, so the condition could never
> > > trigger in practice (no selftest exercises it either). With the
> > > refactor, release_reference() can now be called with non-acquired ids
> > > and have different error conditions. Report directly in
> > > release_reference() instead.
> > >
> > > Fixes: 870c28588afa ("bpf: net_sched: Add basic bpf qdisc kfuncs")
> > > Signed-off-by: Amery Hung <ameryhung@gmail.com>
> > > ---
> > > include/linux/bpf_verifier.h | 22 ++-
> > > kernel/bpf/log.c | 4 +-
> > > kernel/bpf/states.c | 9 +-
> > > kernel/bpf/verifier.c | 264 +++++++++++++++++------------------
> > > 4 files changed, 152 insertions(+), 147 deletions(-)
> > >
[...]
> > > @@ -673,82 +675,56 @@ static int mark_stack_slots_dynptr(struct bpf_verifier_env *env, struct bpf_reg_
> > > mark_dynptr_stack_regs(env, &state->stack[spi].spilled_ptr,
> > > &state->stack[spi - 1].spilled_ptr, type);
> > >
> > > - if (dynptr_type_refcounted(type)) {
> > > - /* The id is used to track proper releasing */
> > > - int id;
> > > -
> > > - if (clone_ref_obj_id)
> > > - id = clone_ref_obj_id;
> > > - else
> > > - id = acquire_reference(env, insn_idx);
> > > -
> > > - if (id < 0)
> > > - return id;
> > > -
> > > - state->stack[spi].spilled_ptr.ref_obj_id = id;
> > > - state->stack[spi - 1].spilled_ptr.ref_obj_id = id;
is id assigned somewhere else now? where?
> > > + if (dynptr->type == BPF_DYNPTR_TYPE_INVALID) { /* dynptr constructors */
> > > + if (dynptr_type_referenced(type)) {
> > > + ref_obj_id = acquire_reference(env, insn_idx);
> > > + if (ref_obj_id < 0)
> > > + return ref_obj_id;
> > > + }
> > > + } else { /* bpf_dynptr_clone() */
> > > + ref_obj_id = dynptr->ref_obj_id;
> > > + parent_id = dynptr->parent_id;
> > > }
> > >
> > > + state->stack[spi].spilled_ptr.ref_obj_id = ref_obj_id;
> > > + state->stack[spi - 1].spilled_ptr.ref_obj_id = ref_obj_id;
> > > + state->stack[spi].spilled_ptr.parent_id = parent_id;
> > > + state->stack[spi - 1].spilled_ptr.parent_id = parent_id;
> > > +
> > > return 0;
> > > }
> > >
[...]
> > > -/* The pointer with the specified id has released its reference to kernel
> > > - * resources. Identify all copies of the same pointer and clear the reference.
> > > - *
> > > - * This is the release function corresponding to acquire_reference(). Idempotent.
> > > - */
> > > -static int release_reference(struct bpf_verifier_env *env, int ref_obj_id)
> > > +static int idstack_push(struct bpf_idmap *idmap, u32 id)
> > > +{
> > > + int i;
> > > +
> > > + if (!id)
> > > + return 0;
> > > +
> > > + for (i = 0; i < idmap->cnt; i++)
> > > + if (idmap->map[i].old == id)
> > > + return 0;
> > > +
> > > + if (WARN_ON_ONCE(idmap->cnt >= BPF_ID_MAP_SIZE))
> > > + return -EFAULT;
> >
> > It feels like this check belongs above, maybe the first thing to do.
>
> Shouldn't it allow the verification to continue when pushing an id
> that already exists in the stack?
yep
>
> >
> > > +
> > > + idmap->map[idmap->cnt++].old = id;
> > > + return 0;
> > > +}
> > > +
> > > +static int idstack_pop(struct bpf_idmap *idmap)
> > > {
> > > + if (!idmap->cnt)
> > > + return 0;
> > > +
> > > + return idmap->map[--idmap->cnt].old;
> > > +}
> > > +
> > > +/* Release id and objects referencing the id iteratively in a DFS manner */
> > > +static int release_reference(struct bpf_verifier_env *env, int id)
> > > +{
> > > + u32 mask = (1 << STACK_SPILL) | (1 << STACK_DYNPTR);
> > > struct bpf_verifier_state *vstate = env->cur_state;
> > > + struct bpf_idmap *idstack = &env->idmap_scratch;
> > > + struct bpf_stack_state *stack;
> > > struct bpf_func_state *state;
> > > struct bpf_reg_state *reg;
> > > - int err;
> > > + int root_id = id, err;
> > >
> > > - err = release_reference_nomark(vstate, ref_obj_id);
> > > - if (err)
> > > - return err;
> > > + idstack->cnt = 0;
> > > + idstack_push(idstack, id);
> > >
> > > - bpf_for_each_reg_in_vstate(vstate, state, reg, ({
> > > - if (reg->ref_obj_id == ref_obj_id)
> > > - mark_reg_invalid(env, reg);
> > > - }));
> > > + if (find_reference_state(vstate, id))
> > > + WARN_ON_ONCE(release_reference_nomark(vstate, id));
> > > +
> > > + while ((id = idstack_pop(idstack))) {
> > > + bpf_for_each_reg_in_vstate_mask(vstate, state, reg, stack, mask, ({
> > > + if (reg->id != id && reg->parent_id != id && reg->ref_obj_id != id)
> > > + continue;
> > > +
> > > + if (reg->ref_obj_id && id != root_id) {
> >
> > Does this line check that the only ref_obj_id we should see is either
> > 0 or root_id? can we rewrite it as
> > if (reg->ref_obj_id && reg->ref_obj_id != root_id)
> >
> > this is simpler, because id can also be reg->id/reg->parent_id, which is
> > hard to reason what that means.
> >
>
> Looking at it again, I think my release_reference() is wrong. It first
> calls release_reference_nomark() if the id is a ref_obj_id. This will
> invalidate all registers with the same ref_obj_id without traversing
> their children.
>
hm, will it? from what I see, release_reference_nomark() doesn't do
anything with registers/stack slots, just removes the reference from
state->refs
> I should remember the root_ref_obj_id instead of calling
> release_reference_nomark(). Then, the check you mentioned should be:
> if (reg->ref_obj_id && reg->ref_obj_id != root_ref_obj_id)
>
> I will write a selftest to confirm the issue and include it in the
> next respin if this turns out to be a bug.
^ permalink raw reply
* Re: [GIT PULL] Networking for v7.1-rc1
From: pr-tracker-bot @ 2026-04-24 0:13 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: torvalds, kuba, davem, netdev, linux-kernel, pabeni
In-Reply-To: <20260423214441.1357981-1-kuba@kernel.org>
The pull request you sent on Thu, 23 Apr 2026 14:44:41 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-7.1-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e728258debd553c95d2e70f9cd97c9fde27c7130
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [syzbot] [wireless?] [usb?] KASAN: stack-out-of-bounds Write in carl9170_handle_command_response
From: syzbot @ 2026-04-24 0:23 UTC (permalink / raw)
To: chunkeey, linux-kernel, linux-usb, linux-wireless, netdev,
syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 2e6803928193 Merge tag 'tracefs-v7.1-2' of git://git.kerne..
git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
console output: https://syzkaller.appspot.com/x/log.txt?x=113342ce580000
kernel config: https://syzkaller.appspot.com/x/.config?x=37c3a614a8bc8d27
dashboard link: https://syzkaller.appspot.com/bug?extid=5c1ca6ccaa1215781cac
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12acb1ba580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16acb1ba580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/592131f484c3/disk-2e680392.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2ca791aa3d9c/vmlinux-2e680392.xz
kernel image: https://storage.googleapis.com/syzbot-assets/3aaca7d6d8d9/bzImage-2e680392.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5c1ca6ccaa1215781cac@syzkaller.appspotmail.com
usb 4-1: received invalid command response:got 60, instead of 0
usb 4-1: restart device (9)
usb 4-1: received invalid command response:got -2, instead of 0
usb 4-1: received invalid command response:got 60, instead of 4
==================================================================
BUG: KASAN: stack-out-of-bounds in carl9170_cmd_callback drivers/net/wireless/ath/carl9170/rx.c:153 [inline]
BUG: KASAN: stack-out-of-bounds in carl9170_handle_command_response+0x21f/0xc50 drivers/net/wireless/ath/carl9170/rx.c:168
Write of size 60 at addr ffffc900001e7a38 by task swapper/1/0
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:378 [inline]
print_report+0x13d/0x4b0 mm/kasan/report.c:482
kasan_report+0xdf/0x1d0 mm/kasan/report.c:595
check_region_inline mm/kasan/generic.c:186 [inline]
kasan_check_range+0x10f/0x1e0 mm/kasan/generic.c:200
__asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106
carl9170_cmd_callback drivers/net/wireless/ath/carl9170/rx.c:153 [inline]
carl9170_handle_command_response+0x21f/0xc50 drivers/net/wireless/ath/carl9170/rx.c:168
carl9170_usb_rx_irq_complete+0xfc/0x1b0 drivers/net/wireless/ath/carl9170/usb.c:307
__usb_hcd_giveback_urb+0x38d/0x610 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x3ca/0x4a0 drivers/usb/core/hcd.c:1741
dummy_timer+0xda1/0x36c0 drivers/usb/gadget/udc/dummy_hcd.c:2005
__run_hrtimer kernel/time/hrtimer.c:1930 [inline]
__hrtimer_run_queues+0x470/0xa00 kernel/time/hrtimer.c:1994
hrtimer_run_softirq+0x17d/0x2c0 kernel/time/hrtimer.c:2011
handle_softirqs+0x1dd/0x9e0 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0x160/0x210 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1061 [inline]
sysvec_apic_timer_interrupt+0x8f/0xb0 arch/x86/kernel/apic/apic.c:1061
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:697
RIP: 0010:pv_native_safe_halt+0xf/0x20 arch/x86/kernel/paravirt.c:63
Code: d4 b4 01 c3 cc cc cc cc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 63 9d 15 00 fb f4 <e9> 7c f2 02 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 90 90 90 90 90
RSP: 0018:ffffc9000013fe00 EFLAGS: 00000246
RAX: 0000000000046e1b RBX: ffff8881022d9dc0 RCX: ffffffff8770e3f5
RDX: 0000000000000000 RSI: ffffffff890d1d42 RDI: ffffffff87b03fe0
RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed103eae673d
R10: ffff8881f57339eb R11: 0000000000000000 R12: 0000000000000001
R13: ffffed102045b3b8 R14: 0000000000000001 R15: ffffffff8af1a1d0
arch_safe_halt arch/x86/include/asm/paravirt.h:62 [inline]
default_idle+0x9/0x10 arch/x86/kernel/process.c:767
default_idle_call+0x6c/0xb0 kernel/sched/idle.c:122
cpuidle_idle_call kernel/sched/idle.c:199 [inline]
do_idle+0x464/0x590 kernel/sched/idle.c:352
cpu_startup_entry+0x4f/0x60 kernel/sched/idle.c:451
start_secondary+0x21d/0x2d0 arch/x86/kernel/smpboot.c:312
common_startup_64+0x13e/0x148
</TASK>
The buggy address belongs to a 8-page vmalloc region starting at 0xffffc900001e0000 allocated at kernel_clone+0x12e/0x9c0 kernel/fork.c:2723
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102aa7
flags: 0x200000000000000(node=0|zone=2)
raw: 0200000000000000 ffffea00040aa9c8 ffffea00040aa9c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x29c2(GFP_NOWAIT|__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_ZERO), pid 2, tgid 2 (kthreadd), ts 2543325669, free_ts 0
set_page_owner include/linux/page_owner.h:32 [inline]
post_alloc_hook+0x153/0x170 mm/page_alloc.c:1858
prep_new_page mm/page_alloc.c:1866 [inline]
get_page_from_freelist+0xf34/0x3a90 mm/page_alloc.c:3946
__alloc_frozen_pages_noprof+0x273/0x28a0 mm/page_alloc.c:5226
__alloc_pages_noprof+0xb/0x110 mm/page_alloc.c:5260
__alloc_pages_node_noprof include/linux/gfp.h:289 [inline]
alloc_pages_node_noprof include/linux/gfp.h:316 [inline]
vm_area_alloc_pages mm/vmalloc.c:3655 [inline]
__vmalloc_area_node mm/vmalloc.c:3878 [inline]
__vmalloc_node_range_noprof+0xe0c/0x1630 mm/vmalloc.c:4064
__vmalloc_node_noprof+0xad/0xf0 mm/vmalloc.c:4124
alloc_thread_stack_node kernel/fork.c:357 [inline]
dup_task_struct kernel/fork.c:926 [inline]
copy_process+0x7fb/0x7d20 kernel/fork.c:2088
kernel_clone+0x12e/0x9c0 kernel/fork.c:2723
kernel_thread+0xdb/0x120 kernel/fork.c:2784
create_kthread kernel/kthread.c:459 [inline]
kthreadd+0x498/0x7a0 kernel/kthread.c:817
ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
page_owner free stack trace missing
Memory state around the buggy address:
ffffc900001e7900: f1 f1 f1 00 00 00 f3 f3 f3 f3 f3 00 00 00 00 00
ffffc900001e7980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffffc900001e7a00: 00 f1 f1 f1 f1 f1 f1 04 f2 04 f3 f3 f3 00 00 00
^
ffffc900001e7a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffc900001e7b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================
----------------
Code disassembly (best guess), 1 bytes skipped:
0: b4 01 mov $0x1,%ah
2: c3 ret
3: cc int3
4: cc int3
5: cc int3
6: cc int3
7: 0f 1f 00 nopl (%rax)
a: 90 nop
b: 90 nop
c: 90 nop
d: 90 nop
e: 90 nop
f: 90 nop
10: 90 nop
11: 90 nop
12: 90 nop
13: 90 nop
14: 90 nop
15: 90 nop
16: 90 nop
17: 90 nop
18: 90 nop
19: 90 nop
1a: f3 0f 1e fa endbr64
1e: 66 90 xchg %ax,%ax
20: 0f 00 2d 63 9d 15 00 verw 0x159d63(%rip) # 0x159d8a
27: fb sti
28: f4 hlt
* 29: e9 7c f2 02 00 jmp 0x2f2aa <-- trapping instruction
2e: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1)
35: 00 00 00
38: 66 90 xchg %ax,%ax
3a: 90 nop
3b: 90 nop
3c: 90 nop
3d: 90 nop
3e: 90 nop
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH bpf v3] bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths
From: Martin KaFai Lau @ 2026-04-24 0:41 UTC (permalink / raw)
To: Weiming Shi
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Martin KaFai Lau, Alexei Starovoitov, Amery Hung,
Leon Hwang, Kees Cook, Fushuai Wang, Menglong Dong, netdev, bpf,
Xiang Mei
In-Reply-To: <20260422065411.1007737-2-bestswngs@gmail.com>
On Tue, Apr 21, 2026 at 11:54:12PM -0700, Weiming Shi wrote:
> @@ -668,7 +670,11 @@ int bpf_sk_storage_diag_put(struct bpf_sk_storage_diag *diag,
>
> diag_size += nla_value_size(diag->maps[i]->value_size);
This is the same issue pointed out as v1. diag_size is updated with
a smap in diag->maps[i]...
>
> - if (nla_stgs && diag_get(sdata, skb))
> + smap = rcu_dereference(sdata->smap);
> + if (!smap)
> + continue;
... and then nothing is stored in skb, so diag_size is incorrectly inflated.
> +
> + if (nla_stgs && diag_get(smap, sdata, skb))
diag->maps[i] can be directly used here. I fixed it up before applying.
> /* Continue to learn diag_size */
> err = -EMSGSIZE;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH bpf-next v3 0/9] Refactor verifier object relationship tracking
From: Alexei Starovoitov @ 2026-04-24 0:55 UTC (permalink / raw)
To: Amery Hung, bpf
Cc: netdev, andrii, daniel, eddyz87, memxor, martin.lau,
mykyta.yatsenko5, kernel-team
In-Reply-To: <20260421221016.2967924-1-ameryhung@gmail.com>
On Tue Apr 21, 2026 at 3:10 PM PDT, Amery Hung wrote:
>
> (3) Referenced dynptr with referenced parent:
>
> file (1,1,0)
> ^ ^
> bpf_dynptr_from_file | +-------------------------------+
> | bpf_dynptr_clone(A, C) |
> dynptr A (2,3,1) dynptr C (4,3,1)
> ^ ^
> | |
> dynptr A and C have the same lifetime
If I understand the proposal correctly above should be:
file (1,0,0)
^
bpf_dynptr_from_file +-------------------------------+
ref_obj_id will be inited bpf_dynptr_clone() as 3 into A and C.
but original file->ref_obj_id will be zero.
?
^ permalink raw reply
* Re: [PATCH net v2 10/15] drivers: net: cirrus: mac89x0: Remove this driver
From: Finn Thain @ 2026-04-24 1:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: John Paul Adrian Glaubitz, Daniel Palmer, Geert Uytterhoeven,
Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Michael Fritscher, Byron Stanoszek, linux-kernel, netdev,
linux-doc, linux-m68k
In-Reply-To: <20260423150240.07c350a2@kernel.org>
On Thu, 23 Apr 2026, Jakub Kicinski wrote:
> We want to be welcoming in the community. But being a part of the
> community means participating in _work_.
>
The work of testing drivers requires that maintainers have ready access to
actual hardware. Behavioural simulation like QEMU does not cut it.
Therefore, it sounds like you're going to need someone with actual clout
to mandate that drivers must have maintainers and those maintainers must
have access to working hardware, or those drivers get placed on a removal
schedule along with _every_ other orphaned module across the entire tree.
That way, you get to chase _all_ freeloaders regardless of whether they
are unpaid enthusiasts or foundation sponsors. Surely you'd find out what
"welcoming" really means -- but you would get to remove a _lot_ of code.
Far more likely, you'd find out that the typical Linux user is actually a
retro computing enthusiast because he's using some device that's over 5
years old, and the employer of the maintainer of the relevant driver got
assigned to something more profitable years ago and all their old hardware
got tossed out in the last office move. (What was that saying about those
who live in silica houses?)
Anyway, I think there is a better way. Let's score every module based on
cost/benefit to the "community". We can use retail sales volume as a proxy
for the former quantity (in unadjusted dollars) and use module size (in
lines of code) as proxy for the latter. If nothing else, that would show
us which modules are more or less valuable to the community, relative to
the average module.
^ permalink raw reply
* Re: [PATCH net 2/4] gve: Fix backward stats when interface goes down or configuration is adjusted
From: Pin-yen Lin @ 2026-04-24 1:17 UTC (permalink / raw)
To: Paolo Abeni
Cc: Harshitha Ramamurthy, netdev, joshwash, andrew+netdev, davem,
edumazet, kuba, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel, Debarghya Kundu
In-Reply-To: <0e1c941e-dcaa-40fb-9df2-ac1db429f60a@redhat.com>
Hi Paolo,
On Thu, Apr 23, 2026 at 4:47 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/20/26 7:18 PM, Harshitha Ramamurthy wrote:
> > From: Debarghya Kundu <debarghyak@google.com>
> >
> > gve_get_base_stats() sets all the stats to 0, so the stats go backwards
> > when interface goes down or configuration is adjusted.
> >
> > Fix this by persisting baseline stats across interface down.
> >
> > This was discovered by drivers/net/stats.py selftest.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 2e5e0932dff5 ("gve: add support for basic queue stats")
> > Signed-off-by: Debarghya Kundu <debarghyak@google.com>
> > Signed-off-by: Pin-yen Lin <treapking@google.com>
> > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > ---
> > drivers/net/ethernet/google/gve/gve.h | 6 ++
> > drivers/net/ethernet/google/gve/gve_main.c | 64 +++++++++++++++++++---
> > 2 files changed, 63 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/google/gve/gve.h b/drivers/net/ethernet/google/gve/gve.h
> > index cbdf3a842cfe..ff7797043908 100644
> > --- a/drivers/net/ethernet/google/gve/gve.h
> > +++ b/drivers/net/ethernet/google/gve/gve.h
> > @@ -794,6 +794,10 @@ struct gve_ptp {
> > struct gve_priv *priv;
> > };
> >
> > +struct gve_ring_err_stats {
> > + u64 rx_alloc_fails;
> > +};
> > +
> > struct gve_priv {
> > struct net_device *dev;
> > struct gve_tx_ring *tx; /* array of tx_cfg.num_queues */
> > @@ -882,6 +886,8 @@ struct gve_priv {
> > unsigned long service_task_flags;
> > unsigned long state_flags;
> >
> > + struct gve_ring_err_stats base_ring_err_stats;
> > + struct rtnl_link_stats64 base_net_stats;
> > struct gve_stats_report *stats_report;
> > u64 stats_report_len;
> > dma_addr_t stats_report_bus; /* dma address for the stats report */
> > diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> > index 675382e9756c..8617782791e0 100644
> > --- a/drivers/net/ethernet/google/gve/gve_main.c
> > +++ b/drivers/net/ethernet/google/gve/gve_main.c
> > @@ -105,9 +105,22 @@ static netdev_tx_t gve_start_xmit(struct sk_buff *skb, struct net_device *dev)
> > return gve_tx_dqo(skb, dev);
> > }
> >
> > -static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
> > +static void gve_add_base_stats(struct gve_priv *priv,
> > + struct rtnl_link_stats64 *s)
> > +{
> > + struct rtnl_link_stats64 *base_stats = &priv->base_net_stats;
> > +
> > + s->rx_packets += base_stats->rx_packets;
> > + s->rx_bytes += base_stats->rx_bytes;
> > + s->rx_dropped += base_stats->rx_dropped;
> > + s->tx_packets += base_stats->tx_packets;
> > + s->tx_bytes += base_stats->tx_bytes;
> > + s->tx_dropped += base_stats->tx_dropped;
> > +}
Sashiko says:
Can this result in torn reads on 32-bit architectures?
The base_net_stats struct accumulates 64-bit network statistics in gve_close()
under rtnl_lock, but these stats are read here via ndo_get_stats64 which can
execute concurrently without rtnl_lock.
On 32-bit systems, a concurrent update might result in torn reads since 64-bit
memory reads are not atomic.
Should u64_stats_sync sequence counters or atomic types be used here?
We will add u64_stats_fetch_(begin|retry) to guard this in v2.
> > +
> > +static void gve_get_ring_stats(struct gve_priv *priv,
> > + struct rtnl_link_stats64 *s)
> > {
> > - struct gve_priv *priv = netdev_priv(dev);
> > unsigned int start;
> > u64 packets, bytes;
> > int num_tx_queues;
> > @@ -142,6 +155,14 @@ static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
> > }
> > }
> >
> > +static void gve_get_stats(struct net_device *dev, struct rtnl_link_stats64 *s)
> > +{
> > + struct gve_priv *priv = netdev_priv(dev);
> > +
> > + gve_get_ring_stats(priv, s);
> > + gve_add_base_stats(priv, s);
> > +}
> > +
> > static int gve_alloc_flow_rule_caches(struct gve_priv *priv)
> > {
> > struct gve_flow_rules_cache *flow_rules_cache = &priv->flow_rules_cache;
> > @@ -1493,6 +1514,23 @@ static int gve_queues_stop(struct gve_priv *priv)
> > return gve_reset_recovery(priv, false);
> > }
> >
> > +static void gve_get_ring_err_stats(struct gve_priv *priv,
> > + struct gve_ring_err_stats *err_stats)
> > +{
> > + int ring;
> > +
> > + for (ring = 0; ring < priv->rx_cfg.num_queues; ring++) {
> > + unsigned int start;
> > + struct gve_rx_ring *rx = &priv->rx[ring];
> > +
> > + do {
> > + start = u64_stats_fetch_begin(&rx->statss);
> > + err_stats->rx_alloc_fails +=
> > + rx->rx_skb_alloc_fail + rx->rx_buf_alloc_fail;
> > + } while (u64_stats_fetch_retry(&rx->statss, start));
>
> Sashiko says:
>
> Could this loop improperly inflate the baseline metric by double counting?
> If a concurrent update causes the sequence counter to change,
> u64_stats_fetch_retry() forces the loop to restart. Because the addition
> is performed in-place on err_stats->rx_alloc_fails, the same ring's
> error values will be added again.
> Would it be safer to use local variables inside the retry loop and update
> the global accumulator only after the loop completes successfully, similar
> to the pattern established in gve_get_ring_stats()?
>
We'll fix this by using local variables in v2.
>
> > + }
> > +}
> > +
> > static int gve_close(struct net_device *dev)
> > {
> > struct gve_priv *priv = netdev_priv(dev);
> > @@ -1502,6 +1540,10 @@ static int gve_close(struct net_device *dev)
> > if (err)
> > return err;
> >
> > + /* Save ring queue and err stats before closing the interface */
> > + gve_get_ring_stats(priv, &priv->base_net_stats);
> > + gve_get_ring_err_stats(priv, &priv->base_ring_err_stats);
>
> Sashiko says:
>
> Does this create a temporary spike in reported statistics?
> During gve_close(), the active ring stats are added to base_net_stats.
> However, priv->rx and priv->tx are not set to NULL until the memory
> teardown completes in gve_queues_mem_remove().
> If ndo_get_stats64 is called concurrently during this window, it will
> add both the active ring stats and the newly updated base stats together.
> This causes the reported statistics to temporarily double until the
> teardown finishes.
As Sashiko mentioned, this is an existing concurrency issue between
gve_close() and gve_get_stats() (i.e., .ndo_get_stats64() callback of
gve driver):
gve_queues_mem_remove(priv);
This is a pre-existing issue, but can this lead to a use-after-free
during concurrent stats retrieval?
When gve_queues_mem_remove() frees the ring memory, priv->rx and
priv->tx are not set to NULL until after the memory is freed. If
gve_get_stats() executes during this window, it may iterate over and
dereference the already freed ring memory.
We will send out a separate patch to fix this.
>
> Note that you are expected to proactively comment/reply on the ML to the
> concerns raised by sashiko reviews.
Thanks for the reminder.
>
> Thanks,
>
> Paolo
>
Regards,
Pin-yen
^ permalink raw reply
* [PATCH] devlink/param: replace deprecated strcpy() with strscpy()
From: Álvaro Costa @ 2026-04-24 1:20 UTC (permalink / raw)
To: jiri
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, Álvaro Costa
Replace strcpy() call used to extract a string parameter from param_data
with strscpy(). Since strscpy() already performs bounds checking and
ensures the destination string is NUL-terminated, remove the string
length check as well.
Signed-off-by: Álvaro Costa <alvaroc.dev@gmail.com>
---
net/devlink/param.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/devlink/param.c b/net/devlink/param.c
index cf95268da5b0..26695b7e2861 100644
--- a/net/devlink/param.c
+++ b/net/devlink/param.c
@@ -536,11 +536,9 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
value->vu64 = nla_get_u64(param_data);
break;
case DEVLINK_PARAM_TYPE_STRING:
- len = strnlen(nla_data(param_data), nla_len(param_data));
- if (len == nla_len(param_data) ||
- len >= __DEVLINK_PARAM_MAX_STRING_VALUE)
+ len = strscpy(value->vstr, nla_data(param_data));
+ if (len < 0)
return -EINVAL;
- strcpy(value->vstr, nla_data(param_data));
break;
case DEVLINK_PARAM_TYPE_BOOL:
if (param_data && nla_len(param_data))
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net 4/4] gve: Make ethtool config changes synchronous
From: Pin-yen Lin @ 2026-04-24 1:23 UTC (permalink / raw)
To: Paolo Abeni
Cc: Harshitha Ramamurthy, netdev, joshwash, andrew+netdev, davem,
edumazet, kuba, willemb, maolson, nktgrg, jfraker, ziweixiao,
jacob.e.keller, pkaligineedi, shailend, jordanrhee, stable,
linux-kernel
In-Reply-To: <d0981984-b55f-495e-848b-6e9611f0c2ff@redhat.com>
Hi Paolo,
On Thu, Apr 23, 2026 at 6:25 AM Paolo Abeni <pabeni@redhat.com> wrote:
>
> On 4/20/26 7:18 PM, Harshitha Ramamurthy wrote:
> > From: Pin-yen Lin <treapking@google.com>
> >
> > When modifying device features via ethtool, the driver queues the
> > carrier status update to its workqueue (gve_wq). This leads to a
> > short link-down state after running the ethtool command.
> >
> > Use `gve_turnup_and_check_status()` instead of `gve_turnup()` in
> > `gve_queues_start()` to update the carrier status before returning to
> > the userspace.
> >
> > This was discovered by drivers/net/ping.py selftest. The test calls
> > ping command right after an ethtool configuration, but the interface
> > could be down without this fix.
> >
> > Cc: stable@vger.kernel.org
> > Fixes: 5f08cd3d6423 ("gve: Alloc before freeing when adjusting queues")
> > Reviewed-by: Joshua Washington <joshwash@google.com>
> > Signed-off-by: Pin-yen Lin <treapking@google.com>
> > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > ---
> > drivers/net/ethernet/google/gve/gve_main.c | 56 +++++++++++-----------
> > 1 file changed, 28 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/google/gve/gve_main.c b/drivers/net/ethernet/google/gve/gve_main.c
> > index 8617782791e0..d3b4bec38de5 100644
> > --- a/drivers/net/ethernet/google/gve/gve_main.c
> > +++ b/drivers/net/ethernet/google/gve/gve_main.c
> > @@ -1374,6 +1374,33 @@ static void gve_queues_mem_remove(struct gve_priv *priv)
> > priv->rx = NULL;
> > }
> >
> > +static void gve_handle_link_status(struct gve_priv *priv, bool link_status)
> > +{
> > + if (!gve_get_napi_enabled(priv))
> > + return;
> > +
> > + if (link_status == netif_carrier_ok(priv->dev))
> > + return;
> > +
> > + if (link_status) {
> > + netdev_info(priv->dev, "Device link is up.\n");
> > + netif_carrier_on(priv->dev);
> > + } else {
> > + netdev_info(priv->dev, "Device link is down.\n");
> > + netif_carrier_off(priv->dev);
> > + }
> > +}
> > +
> > +static void gve_turnup_and_check_status(struct gve_priv *priv)
> > +{
> > + u32 status;
> > +
> > + gve_turnup(priv);
> > + status = ioread32be(&priv->reg_bar0->device_status);
> > + gve_handle_link_status(priv,
> > + GVE_DEVICE_STATUS_LINK_STATUS_MASK & status);
> > +}
> > +
> > /* The passed-in queue memory is stored into priv and the queues are made live.
> > * No memory is allocated. Passed-in memory is freed on errors.
> > */
> > @@ -1434,8 +1461,7 @@ static int gve_queues_start(struct gve_priv *priv,
> > round_jiffies(jiffies +
> > msecs_to_jiffies(priv->stats_report_timer_period)));
> >
> > - gve_turnup(priv);
> > - queue_work(priv->gve_wq, &priv->service_task);
> > + gve_turnup_and_check_status(priv);
>
> Sashiko says:
>
> Since gve_handle_link_status() can now be called from process context
> via gve_turnup_and_check_status(), while also being concurrently
> executed by gve_service_task() on the workqueue, could this create a
> time-of-check to time-of-use race?
> If the physical link toggles rapidly, could the workqueue thread sample
> the later hardware state (e.g. OFF) but see the software state is
> already OFF and return early, while the process context thread sampled
> the earlier state (e.g. ON), evaluated netif_carrier_ok() as OFF, and
> proceeded to call netif_carrier_on()?
> This might leave the software carrier state stuck ON when the most
> recent hardware state is OFF, because the condition check and update are
> no longer serialized by the workqueue.
>
This is a legitimate concern, but it is not introduced by this series.
gve_turnup_and_check_status() is an existing function. And, given that
there is no locking around gve_service_task(), there could be
concurrency issues on gve_handle_link_status().
We will upload a separate patch to fix this.
> Notes that there more comments:
>
> https://sashiko.dev/#/patchset/20260420171837.455487-1-hramamurthy%40google.com
>
> but I'm not sure if they are actual regressions introduced by this series.
Thanks for the pointers. I'll reply to all the Sashiko comments on the
mailing list.
>
> /P
>
Regards,
Pin-yen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox