* Re: [PATCH net-next] gtp: annotate PDP lookups under RTNL
From: Simon Horman @ 2026-07-08 10:35 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Runyu Xiao, laforge, andrew+netdev, davem, edumazet, kuba, pabeni,
osmocom-net-gprs, netdev, linux-kernel, jianhao.xu
In-Reply-To: <ak0SYEOvw6K_8C_w@chamomile>
On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
> Hi Simon,
>
> On Tue, Jul 07, 2026 at 03:28:20PM +0100, Simon Horman wrote:
> > On Wed, Jul 01, 2026 at 08:39:25PM +0800, Runyu Xiao wrote:
> > > The GTP PDP lookup helpers are shared by RCU-protected data and report
> > > paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The
> > > helpers walk RCU hlists, but they do not currently pass the RTNL
> > > condition for the control-path lookups.
> > >
> > > Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing
> > > RCU-reader callers remain valid because the RCU-list macros also accept
> > > an active RCU read-side section; the added condition only documents the
> > > non-RCU protection already used by RTNL control paths.
> > >
> > > This was found by our static analysis tool and then manually reviewed
> > > against the current tree. The dynamic triage evidence is a
> > > target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
> > > to documenting the existing protection contract.
> > >
> > > This is a lockdep annotation cleanup. It does not change PDP lifetime or
> > > hash updates.
> > >
> > > Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
> >
> > Reviewed-by: Simon Horman <horms@kernel.org>
> >
> > There is an AI-generated review of this patch available on sashko.dev.
> > While I don't believe that the issues raised there should impede progress
> > of this patch you may want to look into them as possible follow-up.
>
> This patch refers to the rtnl_lock, but it is the genetlink mutex that
> protects updates on the PDP context list.
>
> Then, from packet path, rcu lookups are performed.
>
> I think this patch is not correct.
Hi Pablo,
Of course you are correct.
Sorry for not realising this earlier.
^ permalink raw reply
* Re: [PATCH net-next 0/2] selftests: drv-net: run XDP tests with both IP versions
From: patchwork-bot+netdevbpf @ 2026-07-08 10:40 UTC (permalink / raw)
To: Nimrod Oren
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, shuah, ast, daniel,
hawk, john.fastabend, sdf, bobbyeshleman, willemb, weibunny, dw,
cratiu, netdev, linux-kselftest, linux-kernel, bpf
In-Reply-To: <20260702062348.2123960-1-noren@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 2 Jul 2026 09:23:46 +0300 you wrote:
> The driver selftest environment picks a single address family for tests
> which use the generic address fields. When both IPv4 and IPv6 are
> available it prefers IPv6, which can leave IPv4 paths untested and hide
> IPv4-only bugs.
>
> This happened recently in the XDP selftest, where an IPv4 checksum bug
> was missed when IPv6 was also configured. XDP traffic handling has
> IP-version-specific code paths, and the follow-up discussion concluded
> that the XDP tests should run against both IP versions [1].
>
> [...]
Here is the summary with links:
- [net-next,1/2] selftests: drv-net: allow switching env IP version
https://git.kernel.org/netdev/net-next/c/432f4bab1ada
- [net-next,2/2] selftests: drv-net: xdp: run with both IP versions
https://git.kernel.org/netdev/net-next/c/47467501cb88
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC] VEGA: a syzbot-like workflow for LLM-found kernel bugs
From: Laurent Pinchart @ 2026-07-08 10:47 UTC (permalink / raw)
To: Yuan Tan
Cc: linux-kernel, workflows, jhs, gregkh, sven, netdev,
netfilter-devel, linux-crypto
In-Reply-To: <20260708092247.4188498-1-yuantan098@gmail.com>
On Wed, Jul 08, 2026 at 02:22:47AM -0700, Yuan Tan wrote:
> Hi all,
>
> We would like to ask for feedback on a proposed workflow for reporting Linux
> kernel bugs found by an LLM-assisted code auditing tool that we have
> been developing since earlier this year.
>
> Since February, we have been developing an LLM-driven kernel code auditing
> tool called VEGA. It started as a side project, but the results became much
> substantial than we expected: VEGA has found hundreds of valid bugs in Linux
> kernel.
>
> That immediately created a practical problem: we do not want to dump a large
> pile of bug reports onto mail lists and annoy the maintainers.
>
> The first thing we tried was to fix as many as we could ourselves. We
> started working with a group of student volunteers. Most of them are
> college students, so we have been training them, reviewing their patches,
> and trying to build an internal review process before anything is sent to
> the mailing list. The goal is to turn these findings into useful fixes, and
> also to help new contributors grow into people who can reduce maintainer
> workload instead of adding to it.
>
> The process was not perfect. Some patches were not good enough, and we also
> made some mistakes early on when deciding what should be called a security
> issue. Our internal review process has been improving with the help of the
> community.
>
> Since March, we picked up non-root triggerable bug first and have worked on
> fixes for more than 100 validated kernel bugs. we especially want to thank
> the students and professor who have helped a lot with this effort.
>
> But the remaining queue is still too large for us to handle.
>
> Recently Jamal pointed out problems around our tags. That made me realize
> that we should probably stop treating this as an ad-hoc patch effort and
> build something closer to syzbot: public, reproducible, trackable,
> deduplicated, and useful to maintainers.
>
> So this mail is an RFC for a VEGA reporting workflow.
>
> The rough idea
> ==============
>
> VEGA would have a public dashboard, similar to syzbot, and would
> send selected bug reports to the relevant kernel mailing lists.
>
> The goal is to send reports that contain enough information for maintainers
> or other developers to pick up, understand, reproduce and fix the issue.
>
> For each public report, we expect to include:
>
> - a description of the bug
> - the tested kernel tree and commit
> - the kernel config and environment
> - the crash log
> - a minimized user-space reproducer
> - the suspected introducing commit
> - a suggested fix patch
>
> The suggested fix patch is meant to reduce maintainer burden. It still need
> human review, but hopefully it can save a lot time from building a patch
> from scratch.
Will the information included in the public report (including the
suggested fix) be written by a human or an LLM ? In the latter case I
don't see how you could reasonably claim to reduce maintainer burden, so
that would be a big NACK as far as I'm concerned.
> What will be public
> ===================
>
> All VEGA findings that we have evaluated as not having major security
> impact can be published on the VEGA dashboard. The dashboard would make it
> possible to see what VEGA found, whether the issue was reproduced, whether
> a fix exists, whether it was reported to a mailing list, and whether it has
> been fixed upstream.
>
> For issues that we have validated as having possible serious security
> impact, we will not publish it on the public dashboard before going through
> the appropriate kernel security process.
>
> Dumping everything onto the mailing list may be annoying. During the initial
> stage, reports will be rate-limited and sent manually. We will check for
> duplicates against lore/upstream, and make sure the issue is not already
> fixed or reported.
>
> Report identity and tags
> ========================
>
> Each public VEGA report will have a stable identity, similar to
> syzbot reports.
>
> One possible format is:
>
> Reported-by: VEGA <vega+HASH@DOMAIN>
> Closes: <public dashboard URL>
>
> =========
>
> We would like to hear what maintainers think about this before we start
> sending these reports.
>
> We do not want VEGA to become another source of mailing list noise. The goal
> is to make LLM-based bug finding transparent and useful, and to make sure
> the reports come with enough context, reproducers, suggested fixes, and
> tracking so that they reduce work rather than create more.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH net-next v4 1/3] net: devmem: allow rx-buf-size > PAGE_SIZE per dmabuf binding
From: Paolo Abeni @ 2026-07-08 10:50 UTC (permalink / raw)
To: Mina Almasry, Bobby Eshleman
Cc: Donald Hunter, Jakub Kicinski, David S. Miller, Eric Dumazet,
Simon Horman, Andrew Lunn, Gerd Hoffmann, Vivek Kasireddy,
Sumit Semwal, Christian König, Shuah Khan, netdev,
linux-kernel, dri-devel, linux-media, linaro-mm-sig,
linux-kselftest, sdf, razor, daniel, matttbe, skhawaja, dw,
Joe Damato, Bobby Eshleman
In-Reply-To: <CAHS8izNdJ1LTOr_pLjXef6Yv-=JOFPe1GcZtcbStD93Tkpy1XQ@mail.gmail.com>
On 7/7/26 10:36 PM, Mina Almasry wrote:
> On Wed, Jul 1, 2026 at 12:22 PM Bobby Eshleman <bobbyeshleman@gmail.com> wrote:
>>
>> From: Bobby Eshleman <bobbyeshleman@meta.com>
>>
>> Every devmem dmabuf binding today hands the page_pool PAGE_SIZE niovs.
>> This caps a single RX descriptor at PAGE_SIZE, burning CPU on buffer
>> churn for large flows.
>>
>> Add a bind-time netlink attribute, NETDEV_A_DMABUF_RX_BUF_SIZE, that
>> lets userspace request a larger niov size. The value must be a power of
>> two >= PAGE_SIZE.
>>
>> Measurements
>> ------------
Checkpatch complains about this separator usage:
ERROR: Invalid commit separator - some tools may have problems applying this
#15:
------------
Please replace or remove it in the next revision
>> @@ -90,16 +90,17 @@ net_devmem_alloc_dmabuf(struct net_devmem_dmabuf_binding *binding)
>> struct dmabuf_genpool_chunk_owner *owner;
>> unsigned long dma_addr;
>> struct net_iov *niov;
>> - ssize_t offset;
>> - ssize_t index;
>> + size_t offset;
>> + size_t index;
>>
>
> nit: I would keep this signed. Some of the most frustrating issues I
> ran into is some of the underflowing and then passing a > check or
> something. Although if the LLM is not complaining about this
> particular case, there is probably no issue with it. I also notice a
> lot of existing code that deals with indexes and offsets goes for
> signed.
At very least the above change should go in a separate patch, as is
quite unrelated from the rest.
/P
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: convert microchip,lan78xx.txt to YAML schema
From: Krzysztof Kozlowski @ 2026-07-08 10:56 UTC (permalink / raw)
To: Mikhail Lukianchikov
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rengarajan Sundararajan, UNGLinuxDriver, netdev, devicetree,
linux-kernel
In-Reply-To: <20260707165840.107409-1-avermoal@gmail.com>
On Tue, Jul 07, 2026 at 10:58:40PM +0600, Mikhail Lukianchikov wrote:
> Convert the Microchip LAN78xx family (LAN7800, LAN7801, LAN7850) binding
> documentation from plain text to DT schema format using YAML.
Subject: there is no YAML schema
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
> The conversion was validated with 'make dt_binding_check'
Drop, irrelevant and not even true. There is no point in writing in
commit msg that you performed the absolute minimal expected build
testing. It is expected.
>
> Signed-off-by: Mikhail Lukianchikov <avermoal@gmail.com>
...
You left stale maintainer entry. Checkpatch told you that, no? Did you
run checkpatch?
If this is your first contribution then you need to read carefully
guidelines how to contribute and then actually follow these guidelines.
What does evry guideline speak about? Checkpatch.
> diff --git a/Documentation/devicetree/bindings/net/microchip,lan78xx.yaml b/Documentation/devicetree/bindings/net/microchip,lan78xx.yaml
> new file mode 100644
> index 000000000000..743667c1e761
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,lan78xx.yaml
microchip,lan7800.yaml
> @@ -0,0 +1,113 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,lan78xx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip LAN78xx Gigabit Ethernet controller
> +
> +maintainers:
> + - Rengarajan Sundararajan <Rengarajan.S@microchip.com>
> + - UNGLinuxDriver <UNGLinuxDriver@microchip.com>
Drop last email.
> +
> +description:
> + The LAN78XX devices are usually configured by programming their OTP or with
> + an external EEPROM, but some platforms (e.g. Raspberry Pi 3 B+) have neither.
> + The Device Tree properties, if present, override the OTP and EEPROM.
> +
> +allOf:
> + - $ref: /schemas/usb/usb-device.yaml#
> + - $ref: /schemas/net/ethernet-controller.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - usb424,7800
> + - usb424,7801
> + - usb424,7850
Odd format. Missing blank lines. Look at existing code to understand how
this is supposed to look like.
> + reg:
> + maxItems: 1
> + description: USB port number
> + local-mac-address:
> + $ref: /schemas/types.yaml#/definitions/uint8-array
> + minItems: 6
> + maxItems: 6
> + description:
> + MAC address to use if not stored in OTP or EEPROM. If present,
> + overrides OTP/EEPROM.
> + mdio:
> + $ref: /schemas/net/mdio.yaml#
> + unevaluatedProperties: false
> +
> +patternProperties:
> + "^ethernet-phy(@[0-9a-f]+)?$":
> + type: object
> + description: |
> + PHY node for the embedded or external PHY. The PHY address is
> + given by the 'reg' property.
> + properties:
> + reg:
> + maxItems: 1
> + description: PHY address.
> + microchip,led-modes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + minItems: 1
> + maxItems: 4
> + description:
> + Array of LED mode values for each of up to 4 LEDs.
> + Omitted LEDs are turned off. Allowed values are defined
> + in include/dt-bindings/net/microchip-lan78xx.h.
> + required:
> + - reg
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/net/microchip-lan78xx.h>
> + / {
> + usb: usb {
> + compatible = "usb-host";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> + &usb {
Drop all this, irrelevant and not even close to expected style.
> + usb-port@1 {
> + compatible = "usb424,2514";
Drop node
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb-port@1 {
> + compatible = "usb424,2514";
Drop node, not relevant to this binding.
Again, look at other bindings to understand what to write. Or read
DTS101 slides.
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v3 1/2] net: mana: Validate the packet length reported by the NIC
From: Paolo Abeni @ 2026-07-08 10:57 UTC (permalink / raw)
To: Dexuan Cui, kys, haiyangz, wei.liu, longli, andrew+netdev, davem,
edumazet, kuba, kotaranov, horms, ernis, dipayanroy, kees,
jacob.e.keller, ssengar, linux-hyperv, netdev, linux-kernel,
linux-rdma
Cc: stable
In-Reply-To: <20260702041237.617719-2-decui@microsoft.com>
On 7/2/26 6:12 AM, Dexuan Cui wrote:
> Validate the packet length reported in the RX CQE before passing it
> to skb processing. The CQE is supplied by the NIC device and should
> not be blindly trusted.
>
> Cc: stable@vger.kernel.org
This need a Fixes: tag, to help stable team backport.
No need to repost: just reply here, and I'll add it while applying the
patch.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net v2 2/2] vsock/test: add test for small packets under pressure
From: Michael S. Tsirkin @ 2026-07-08 10:59 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, Jason Wang, Xuan Zhuo, Eric Dumazet, Eugenio Pérez,
Simon Horman, Stefan Hajnoczi, David S. Miller, linux-kernel, kvm,
Paolo Abeni, virtualization, Jakub Kicinski, Jason Wang
In-Reply-To: <20260708102904.50732-3-sgarzare@redhat.com>
On Wed, Jul 08, 2026 at 12:29:04PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> Add a test that sends 2 MB of data using randomly sized small packets
> (129-512 bytes) over a SOCK_STREAM connection. Packets above
> GOOD_COPY_LEN (128) bypass the in-place coalescing in recv_enqueue(),
> forcing each one into its own skb.
>
> Without receive queue collapsing, the per-skb overhead eventually
> exceeds buf_alloc and the connection is reset. The test verifies
> that all data arrives and that content integrity is preserved.
>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
maybe cut down SO_VM_SOCKETS_BUFFER_SIZE? will make it easier to
trigger?
anyway
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> tools/testing/vsock/vsock_test.c | 87 ++++++++++++++++++++++++++++++++
> 1 file changed, 87 insertions(+)
>
> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
> index 76be0e4a7f0e..b4ff9f946565 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -2347,6 +2347,88 @@ static void test_stream_tx_credit_bounds_server(const struct test_opts *opts)
> close(fd);
> }
>
> +/* Test that many small packets don't cause a connection reset under pressure
> + * and that data integrity is preserved. Packet sizes vary randomly between
> + * 129 and 512 bytes, above GOOD_COPY_LEN (128) to bypass in-place coalescing
> + * in recv_enqueue, forcing each one into its own skb. Without receive queue
> + * collapsing, the per-skb overhead eventually exceeds buf_alloc and the
> + * connection is reset.
> + */
> +#define COLLAPSE_PKT_MIN 129
> +#define COLLAPSE_PKT_MAX 512
> +#define COLLAPSE_TOTAL (2 * 1024 * 1024)
> +
> +static void test_stream_collapse_client(const struct test_opts *opts)
> +{
> + unsigned char *data;
> + unsigned long hash;
> + size_t offset = 0;
> + int i, fd;
> +
> + data = malloc(COLLAPSE_TOTAL);
> + if (!data) {
> + perror("malloc");
> + exit(EXIT_FAILURE);
> + }
> +
> + for (i = 0; i < COLLAPSE_TOTAL; i++)
> + data[i] = rand() & 0xff;
> +
> + fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
> + if (fd < 0) {
> + perror("connect");
> + exit(EXIT_FAILURE);
> + }
> +
> + while (offset < COLLAPSE_TOTAL) {
> + size_t pkt_size = COLLAPSE_PKT_MIN +
> + rand() % (COLLAPSE_PKT_MAX - COLLAPSE_PKT_MIN + 1);
> +
> + pkt_size = min(pkt_size, COLLAPSE_TOTAL - offset);
> +
> + send_buf(fd, data + offset, pkt_size, 0, pkt_size);
> + offset += pkt_size;
> + }
> +
> + hash = hash_djb2(data, COLLAPSE_TOTAL);
> + control_writeulong(hash);
> +
> + free(data);
> + close(fd);
> +}
> +
> +static void test_stream_collapse_server(const struct test_opts *opts)
> +{
> + unsigned long hash, remote_hash;
> + unsigned char *data;
> + int fd;
> +
> + data = malloc(COLLAPSE_TOTAL);
> + if (!data) {
> + perror("malloc");
> + exit(EXIT_FAILURE);
> + }
> +
> + fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
> + if (fd < 0) {
> + perror("accept");
> + exit(EXIT_FAILURE);
> + }
> +
> + recv_buf(fd, data, COLLAPSE_TOTAL, 0, COLLAPSE_TOTAL);
> +
> + hash = hash_djb2(data, COLLAPSE_TOTAL);
> + remote_hash = control_readulong();
> + if (hash != remote_hash) {
> + fprintf(stderr, "hash mismatch: local %lu remote %lu\n",
> + hash, remote_hash);
> + exit(EXIT_FAILURE);
> + }
> +
> + free(data);
> + close(fd);
> +}
> +
> static struct test_case test_cases[] = {
> {
> .name = "SOCK_STREAM connection reset",
> @@ -2546,6 +2628,11 @@ static struct test_case test_cases[] = {
> .run_client = test_stream_msg_peek_client,
> .run_server = test_stream_peek_after_recv_server,
> },
> + {
> + .name = "SOCK_STREAM small packets backpressure",
> + .run_client = test_stream_collapse_client,
> + .run_server = test_stream_collapse_server,
> + },
> {},
> };
>
> --
> 2.55.0
^ permalink raw reply
* Re: [PATCH net v2 1/2] vsock/virtio: collapse receive queue under memory pressure
From: Michael S. Tsirkin @ 2026-07-08 11:00 UTC (permalink / raw)
To: Stefano Garzarella
Cc: netdev, Jason Wang, Xuan Zhuo, Eric Dumazet, Eugenio Pérez,
Simon Horman, Stefan Hajnoczi, David S. Miller, linux-kernel, kvm,
Paolo Abeni, virtualization, Jakub Kicinski, Jason Wang, stable,
Brien Oberstein
In-Reply-To: <20260708102904.50732-2-sgarzare@redhat.com>
On Wed, Jul 08, 2026 at 12:29:03PM +0200, Stefano Garzarella wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> When many small packets accumulate in the receive queue, the skb overhead
> can exceed buf_alloc even while the payload is within bounds. This causes
> virtio_transport_inc_rx_pkt() to reject packets, leading to connection
> resets during large transfers under backpressure.
>
> The issue was reported by Brien, who has a reproducer, but it is also
> easily reproducible with iperf-vsock [1] using a small packet size:
>
> iperf3 --vsock -c $CID -l 129
>
> which fails immediately without this patch but with commit 059b7dbd20a6
> ("vsock/virtio: fix potential unbounded skb queue").
>
> Inspired by TCP's tcp_collapse() which solves a similar problem, add
> virtio_transport_collapse_rx_queue() that walks the receive queue and
> re-copies data into compact linear skbs to reduce the overhead.
>
> The collapse is triggered proactively from when the number of skb queued
> is close to exceeding the overhead budget.
>
> A pre-scan counts the eligible bytes to size each allocation precisely,
> avoiding waste for isolated small packets. Partially consumed skbs are
> kept as-is to preserve buf_used/fwd_cnt accounting, EOM-marked skbs to
> maintain SEQPACKET message boundaries, and skbs already larger than the
> collapse target because they already have a good data-to-overhead ratio.
>
> Walking a large queue may take a significant amount of time and cache
> misses, causing traffic burstiness. To limit this, the collapse stops
> once enough room is freed for this packet and the next one, but may
> opportunistically free more to fill each collapsed skb to capacity.
>
> [1] https://github.com/stefano-garzarella/iperf-vsock
>
> Fixes: 059b7dbd20a6 ("vsock/virtio: fix potential unbounded skb queue")
> Cc: stable@vger.kernel.org
> Reported-by: Brien Oberstein <brienpub@gmail.com>
> Closes: https://lore.kernel.org/netdev/618701dd023e$063de350$12b9a9f0$@gmail.com/
> Tested-by: Brien Oberstein <brienpub@gmail.com>
> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
this is the right approach
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> v2:
> - defined MAX_COLLAPSE_LEN macro instead of using a variable [Paolo]
> - added a threshold to avoid walking all the queue while collapsing
> [Paolo]
> - collapsed the queue before calling virtio_transport_inc_rx_pkt().
> While working on the threshold, I figured out that the check I was
> introducing can also be used to proactively trigger the collapse, so I
> moved the call to virtio_transport_collapse_rx_queue() before acquiring
> the rx_lock to have also a better diff to simplify backports
> - improved code readability (removed `out` label, `keep` initialization,
> etc.) [Paolo + other small stuff]
> - Brien kindly retested this version as well (thank you so much)
> ---
> net/vmw_vsock/virtio_transport_common.c | 165 +++++++++++++++++++++++-
> 1 file changed, 164 insertions(+), 1 deletion(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 09475007165b..8becad81279c 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -26,6 +26,13 @@
> /* Threshold for detecting small packets to copy */
> #define GOOD_COPY_LEN 128
>
> +/* Max payload that can be collapsed into a single linear skb, using the same
> + * allocation threshold as virtio_vsock_alloc_skb() to avoid adding pressure
> + * on the page allocator.
> + */
> +#define MAX_COLLAPSE_LEN \
> + SKB_MAX_ORDER(VIRTIO_VSOCK_SKB_HEADROOM, PAGE_ALLOC_COSTLY_ORDER)
> +
> static void virtio_transport_cancel_close_work(struct vsock_sock *vsk,
> bool cancel_timeout);
> static s64 virtio_transport_has_space(struct virtio_vsock_sock *vvs);
> @@ -420,6 +427,145 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> return ret;
> }
>
> +static bool virtio_transport_can_collapse(struct sk_buff *skb)
> +{
> + /* skbs that are partially consumed, mark a SEQPACKET message boundary,
> + * or are already large enough should not be collapsed: they either
> + * need special accounting, carry protocol state, or already have a
> + * good data-to-overhead ratio.
> + */
> + if (VIRTIO_VSOCK_SKB_CB(skb)->offset)
> + return false;
> + if (le32_to_cpu(virtio_vsock_hdr(skb)->flags) & VIRTIO_VSOCK_SEQ_EOM)
> + return false;
> + if (skb->len >= MAX_COLLAPSE_LEN)
> + return false;
> + return true;
> +}
> +
> +/* Iterate through the packets in the queue starting from the current skb to
> + * count the number of bytes we can collapse.
> + */
> +static unsigned int
> +virtio_transport_collapse_size(struct sk_buff *skb, struct sk_buff_head *queue)
> +{
> + unsigned int target = skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset;
> +
> + while ((skb = skb_peek_next(skb, queue)) &&
> + virtio_transport_can_collapse(skb)) {
> + unsigned int len = skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset;
> +
> + if (len > MAX_COLLAPSE_LEN - target)
> + return target;
> +
> + target += len;
> + }
> +
> + return target;
> +}
> +
> +/* Called under lock_sock to compact the receive queue by merging small skbs.
> + * @min_to_free: minimum number of skbs to eliminate from the queue. May free
> + * more to fill each collapsed skb to capacity.
> + */
> +static void
> +virtio_transport_collapse_rx_queue(struct virtio_vsock_sock *vvs,
> + u32 min_to_free)
> +{
> + struct sk_buff *skb, *next_skb, *new_skb = NULL;
> + struct sk_buff_head new_queue;
> + u32 saved = 0;
> +
> + __skb_queue_head_init(&new_queue);
> +
> + skb_queue_walk_safe(&vvs->rx_queue, skb, next_skb) {
> + struct virtio_vsock_hdr *hdr = virtio_vsock_hdr(skb);
> + u32 src_off = VIRTIO_VSOCK_SKB_CB(skb)->offset;
> + u32 src_len = skb->len - src_off;
> + bool keep;
> +
> + keep = !virtio_transport_can_collapse(skb);
> + if (keep) {
> + /* Finalize pending collapsed skb to preserve packet
> + * ordering.
> + */
> + if (new_skb) {
> + __skb_queue_tail(&new_queue, new_skb);
> + new_skb = NULL;
> + saved--;
> + }
> + goto next;
> + }
> +
> + /* Finalize if this packet won't fit in the remaining tailroom,
> + * so we can allocate a right-sized new_skb.
> + */
> + if (new_skb && src_len > skb_tailroom(new_skb)) {
> + __skb_queue_tail(&new_queue, new_skb);
> + new_skb = NULL;
> + saved--;
> + }
> +
> + if (!new_skb) {
> + unsigned int alloc_size;
> +
> + /* Check after finalizing to opportunistically fill
> + * each collapsed skb to capacity, merging more skbs
> + * than strictly required.
> + */
> + if (saved >= min_to_free)
> + break;
> +
> + alloc_size = virtio_transport_collapse_size(skb, &vvs->rx_queue);
> +
> + /* Only this skb's data is eligible, nothing to merge
> + * with. Keep as-is.
> + */
> + if (alloc_size <= src_len) {
> + keep = true;
> + goto next;
> + }
> +
> + new_skb = virtio_vsock_alloc_linear_skb(alloc_size +
> + VIRTIO_VSOCK_SKB_HEADROOM, GFP_KERNEL);
> + if (!new_skb)
> + break;
> +
> + memcpy(virtio_vsock_hdr(new_skb), hdr,
> + sizeof(struct virtio_vsock_hdr));
> + virtio_vsock_hdr(new_skb)->len = 0;
> + }
> +
> + /* Cannot fail since src_off/src_len are within bounds, but if
> + * it does, discard new_skb to avoid queuing corrupted data.
> + */
> + if (WARN_ON_ONCE(skb_copy_bits(skb, src_off,
> + skb_put(new_skb, src_len),
> + src_len))) {
> + kfree_skb(new_skb);
> + new_skb = NULL;
> + break;
> + }
> +
> + le32_add_cpu(&virtio_vsock_hdr(new_skb)->len, src_len);
> + virtio_vsock_hdr(new_skb)->flags |= hdr->flags;
> +
> +next:
> + __skb_unlink(skb, &vvs->rx_queue);
> + if (keep) {
> + __skb_queue_tail(&new_queue, skb);
> + } else {
> + consume_skb(skb);
> + saved++;
> + }
> + }
> +
> + if (new_skb)
> + __skb_queue_tail(&new_queue, new_skb);
> +
> + skb_queue_splice(&new_queue, &vvs->rx_queue);
> +}
> +
> static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> u32 len)
> {
> @@ -1354,12 +1500,29 @@ virtio_transport_recv_enqueue(struct vsock_sock *vsk,
> {
> struct virtio_vsock_sock *vvs = vsk->trans;
> bool can_enqueue, free_pkt = false;
> + u32 len, queue_max, queue_len;
> struct virtio_vsock_hdr *hdr;
> - u32 len;
>
> hdr = virtio_vsock_hdr(skb);
> len = le32_to_cpu(hdr->len);
>
> + /* virtio_transport_inc_rx_pkt() rejects packets when the per-skb
> + * overhead (skb_queue_len * SKB_TRUESIZE(0)) exceeds buf_alloc.
> + * Proactively collapse the queue before that happens.
> + * No rx_lock needed: lock_sock is held by caller, preventing
> + * concurrent enqueue or dequeue.
> + */
> + queue_max = vvs->buf_alloc / SKB_TRUESIZE(0);
> + queue_len = skb_queue_len(&vvs->rx_queue);
> + if (queue_len >= queue_max) {
> + /* Walking a large queue may take a significant amount of time
> + * and cache misses, causing traffic burstiness. Limit the
> + * collapse to freeing room for this packet and the next one.
> + * It may free more to fill each collapsed skb to capacity.
> + */
> + virtio_transport_collapse_rx_queue(vvs, queue_len + 2 - queue_max);
> + }
> +
> spin_lock_bh(&vvs->rx_lock);
>
> can_enqueue = virtio_transport_inc_rx_pkt(vvs, len);
> --
> 2.55.0
^ permalink raw reply
* Re: [PATCH v1 net-next] net: phy: Drop #inclusion of <linux/mod_devicetable.h> from <linux/mdio.h>
From: Uwe Kleine-König (The Capable Hub) @ 2026-07-08 11:02 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Heiner Kallweit, Russell King, netdev, linux-kernel
In-Reply-To: <2f07f731-0b97-4a23-8ccd-f01638fc1c7e@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
On Tue, Jul 07, 2026 at 02:10:56PM +0200, Andrew Lunn wrote:
> On Tue, Jul 07, 2026 at 09:15:35AM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > Hello Andrew,
> >
> > On Mon, Jul 06, 2026 at 11:28:33PM +0200, Andrew Lunn wrote:
> > > > That's exactly my thought, and there is commit ad428f5811bd
> > > > ("mod_devicetable.h: Split into per subsystem headers") that is part of
> > > > v7.2-rc2 and that does exactly that (apart from the filename).
> > >
> > > Ah, O.K. net-next tends to great dragged along the -rcX versions. So
> > > you can probably submit the networking changes in a weeks time. Just
> > > make sure they apply to
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
> >
> > Note that while I created the patch under discussion on top of -rc2, the
> > justification is also valid on -rc1 and the patch doesn't use the new
> > headers, so it can be applied to the above repo already now.
>
> Yes, our patchwork instance and its CI agree:
>
> https://patchwork.kernel.org/project/netdevbpf/patch/ca270a534d0f230a939a3fb4a661808b35d6436d.1783329817.git.u.kleine-koenig@baylibre.com/
That's great.
> but i was actually meaning the patches which swaps to the broken out
> header with only struct mdio_device_id. I assume that patch is the one
> which really reduces the number of files which get recompiled on
> unrelated changes. That patch can be submitted to netdev probably next
> week.
Ah, indeed. After 995832b2cebe6969d1b42635db698803ee31294d and its
parent there are not many left affecting netdev. But ack, I will wait a
bit before tackling drivers/net/wireless/intel/iwlwifi/iwl-config.h
(which is the only remaining user of <linux/mod_devicetable.h> in
drivers/net).
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] nfc: pn533: fix use-after-free in pn533_recv_frame
From: Simon Horman @ 2026-07-07 18:06 UTC (permalink / raw)
To: dddddd
Cc: Simon Horman, netdev, david, error27, krzk, kees, kuba, sameo,
michael.thalmeier, dzm91, hust-os-kernel-patches
In-Reply-To: <20260627131345.1548407-1-dddddd@hust.edu.cn>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
nfc: pn533: fix use-after-free in pn533_recv_frame
This commit adds a spinlock cmd_state_lock to serialize access to dev->cmd
in pn533_recv_frame() and the command completion worker. It aims to prevent
a use-after-free when a command is detached and freed while being
concurrently received.
> diff --git a/drivers/nfc/pn533/pn533.c b/drivers/nfc/pn533/pn533.c
> index d7bdbc82e2ba2..921e93a5f16f5 100644
> --- a/drivers/nfc/pn533/pn533.c
> +++ b/drivers/nfc/pn533/pn533.c
[ ... ]
> @@ -458,10 +477,10 @@ static int __pn533_send_async(struct pn533 *dev, u8 cmd_code,
> mutex_lock(&dev->cmd_lock);
>
> if (!dev->cmd_pending) {
> - dev->cmd = cmd;
> + pn533_set_current_cmd(dev, cmd);
> rc = dev->phy_ops->send_frame(dev, req);
> if (rc) {
> - dev->cmd = NULL;
> + pn533_set_current_cmd(dev, NULL);
[Severity: High]
This is a pre-existing issue, but if dev->phy_ops->send_frame() fails, it
jumps to the error label and frees cmd. If a concurrent receive scheduled
the complete work, could that work also free cmd, causing a double free?
> goto error;
> }
[ ... ]
> @@ -569,10 +588,10 @@ static void pn533_wq_cmd(struct work_struct *work)
>
> mutex_unlock(&dev->cmd_lock);
>
> - dev->cmd = cmd;
> + pn533_set_current_cmd(dev, cmd);
> rc = dev->phy_ops->send_frame(dev, cmd->req);
> if (rc < 0) {
> - dev->cmd = NULL;
> + pn533_set_current_cmd(dev, NULL);
[Severity: High]
This isn't a bug introduced by this patch, but if dev->phy_ops->send_frame()
fails in pn533_wq_cmd(), cmd is freed. Does a race condition exist here
similar to __pn533_send_async(), where concurrent complete work could also
free cmd?
[Severity: High]
Additionally, this is also a pre-existing issue, but does this error path
drop the command without calling complete_cb and without clearing
dev->cmd_pending? Could this leave the command queue permanently hung
upon transient bus errors?
> dev_kfree_skb(cmd->req);
> kfree(cmd);
> return;
> }
[ ... ]
> @@ -2165,6 +2184,15 @@ static int pn533_data_exchange_complete(struct pn533 *dev, void *_arg,
> */
> void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status)
> {
> + unsigned long flags;
> +
> + /*
> + * Hold cmd_state_lock across the whole receive path so the current
> + * command cannot be freed by pn533_send_async_complete() between the
> + * dev->cmd check and the stores into it.
> + */
> + spin_lock_irqsave(&dev->cmd_state_lock, flags);
> +
> if (!dev->cmd)
> goto sched_wq;
[Severity: Medium]
This isn't a bug introduced by this patch, but if there is no active command
(!dev->cmd), this jumps to sched_wq without freeing the skb. Does this leak
the skb if an unexpected frame arrives?
>
> dev->cmd->status = status;
[ ... ]
> @@ -2182,6 +2210,7 @@ void pn533_recv_frame(struct pn533 *dev, struct sk_buff *skb, int status)
>
> if (pn533_rx_frame_is_ack(skb->data)) {
> dev_dbg(dev->dev, "%s: Received ACK frame\n", __func__);
> + spin_unlock_irqrestore(&dev->cmd_state_lock, flags);
> dev_kfree_skb(skb);
> return;
> }
[Severity: High]
This is a pre-existing issue, but does pn533_rx_frame_is_ack() safely read
from skb->data here? Since there doesn't appear to be a check for skb->len
before calling it, could this result in an out-of-bounds read if a malformed
or short frame is received?
^ permalink raw reply
* Re: [PATCH net-next] gtp: annotate PDP lookups under RTNL
From: Paolo Abeni @ 2026-07-08 11:10 UTC (permalink / raw)
To: Simon Horman, Pablo Neira Ayuso
Cc: Runyu Xiao, laforge, andrew+netdev, davem, edumazet, kuba,
osmocom-net-gprs, netdev, linux-kernel, jianhao.xu
In-Reply-To: <20260708103525.GJ1364329@horms.kernel.org>
On 7/8/26 12:35 PM, Simon Horman wrote:
> On Tue, Jul 07, 2026 at 04:51:12PM +0200, Pablo Neira Ayuso wrote:
>> On Tue, Jul 07, 2026 at 03:28:20PM +0100, Simon Horman wrote:
>>> On Wed, Jul 01, 2026 at 08:39:25PM +0800, Runyu Xiao wrote:
>>>> The GTP PDP lookup helpers are shared by RCU-protected data and report
>>>> paths and RTNL-protected control paths such as gtp_genl_new_pdp(). The
>>>> helpers walk RCU hlists, but they do not currently pass the RTNL
>>>> condition for the control-path lookups.
>>>>
>>>> Pass lockdep_rtnl_is_held() to the PDP hlist iterators. Existing
>>>> RCU-reader callers remain valid because the RCU-list macros also accept
>>>> an active RCU read-side section; the added condition only documents the
>>>> non-RCU protection already used by RTNL control paths.
>>>>
>>>> This was found by our static analysis tool and then manually reviewed
>>>> against the current tree. The dynamic triage evidence is a
>>>> target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
>>>> to documenting the existing protection contract.
>>>>
>>>> This is a lockdep annotation cleanup. It does not change PDP lifetime or
>>>> hash updates.
>>>>
>>>> Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
>>>
>>> Reviewed-by: Simon Horman <horms@kernel.org>
>>>
>>> There is an AI-generated review of this patch available on sashko.dev.
>>> While I don't believe that the issues raised there should impede progress
>>> of this patch you may want to look into them as possible follow-up.
>>
>> This patch refers to the rtnl_lock, but it is the genetlink mutex that
>> protects updates on the PDP context list.
>>
>> Then, from packet path, rcu lookups are performed.
>>
>> I think this patch is not correct.
>
> Hi Pablo,
>
> Of course you are correct.
> Sorry for not realising this earlier.
Human slop here made me wrongly apply this patch. Could either of you
please share a formal revert?
Thanks!
Paolo
^ permalink raw reply
* Re: [PATCH v3 05/20] driver core: update kerneldoc for platform_device_alloc()
From: Andy Shevchenko @ 2026-07-08 11:11 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Lee Jones, Mark Brown, Thierry Reding, Sebastian Hesselbarth,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel,
Will Deacon, Robin Murphy, Doug Berger, Florian Fainelli,
Broadcom internal kernel review list, Ulf Hansson, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Matthew Brost, Thomas Hellström, Rodrigo Vivi, David Airlie,
Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu, Philipp Zabel,
Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt, linux-kernel, netdev,
linux-arm-msm, linux-sound, driver-core, devicetree, linuxppc-dev,
linux-i2c, iommu, linux-pm, imx, linux-arm-kernel, intel-xe,
dri-devel, linux-usb, linux-mips, platform-driver-x86, mfd,
Manuel Ebner, Bartosz Golaszewski
In-Reply-To: <CAMRc=Md7-XMBKpdPuZ4=epfTn6F-PXKJBZNPGuz5xbVy58BHsg@mail.gmail.com>
On Wed, Jul 08, 2026 at 12:42:58AM -0700, Bartosz Golaszewski wrote:
> On Tue, 7 Jul 2026 18:05:29 +0200, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> said:
> > On Mon, Jul 06, 2026 at 02:44:17PM +0200, Bartosz Golaszewski wrote:
> >> Users of platform_device_alloc() + platform_device_add() must not modify
> >> certain fields of the dynamically created platform device object. Update
> >> the kernel doc to say which fields are affected and which functions to
> >> use.
> >
> > Consider using __private checker attribute for them as well. It will make
> > sparse scream.
>
> Sure but let's leave it for another series.
Sure, just a side note comment that you know that we have some facilities for
that type of problems.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] dpaa2-switch: put MAC endpoint device on disconnect
From: Guangshuo Li @ 2026-07-08 11:10 UTC (permalink / raw)
To: Ioana Ciornei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Cc: Guangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
taken through device_find_child(). The switch port connect path stores
that device in mac->mc_dev and keeps it for the lifetime of the connected
MAC object.
However, the disconnect path only closes the MAC and frees the dpaa2_mac
object. It does not drop the endpoint device reference stored in
mac->mc_dev, so every successful connect leaks that device reference when
the MAC is later disconnected.
Drop the endpoint device reference before freeing the dpaa2_mac object.
Fixes: 84cba72956fd ("dpaa2-switch: integrate the MAC endpoint support")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
index 858ba844ac51..dd4f60031d0c 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
@@ -1560,6 +1560,7 @@ static void dpaa2_switch_port_disconnect_mac(struct ethsw_port_priv *port_priv)
dpaa2_mac_disconnect(mac);
dpaa2_mac_close(mac);
+ put_device(&mac->mc_dev->dev);
kfree(mac);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v4] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Paolo Abeni @ 2026-07-08 11:15 UTC (permalink / raw)
To: Minxi Hou, netdev
Cc: aconole, echaudro, i.maximets, davem, edumazet, kuba, horms,
shuah, dev, linux-kselftest
In-Reply-To: <20260702075044.1176798-1-houminxi@gmail.com>
On 7/2/26 9:50 AM, Minxi Hou wrote:
> Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
> icmpv6(type=...) can be used in flow specifications. Without this
> registration the parser silently drops the token and the kernel
> rejects the flow with EINVAL because the expected ICMPv6 key
> attribute is missing.
>
> While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp
> fields_map entries so that specifying a field value produces the
> correct wildcard mask. The IPv6 flow label uses convert_int(20) to
> produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in
> flow_netlink.c that rejects masks with bits 20-31 set; byte-wide
> fields use convert_int(8). The ipv4 counterpart already does this via
> convert_int(); the ipv6 and icmp classes were simply missing the fifth
> tuple element. Existing callers that pass empty parentheses are
> unaffected because convert_int("") returns (0, 0).
>
> Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses
> static neighbour entries with nud permanent to prevent racy NDP, then
> verifies in three steps: install icmpv6(type=128) and
> icmpv6(type=129) flows and confirm ping works, remove the flows and
> confirm ping fails, reinstall and confirm recovery.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
Does not apply cleanly anymore. Please rebase and resend. Note that you
can retain Aaron's ack.
/P
^ permalink raw reply
* Re: [PATCH net-next v3] net: skb: isolate skb data area allocations into a separate bucket
From: Pedro Falcato @ 2026-07-08 11:16 UTC (permalink / raw)
To: Paolo Abeni
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Simon Horman,
Jason Xing, Kuniyuki Iwashima, netdev, linux-kernel,
linux-hardening, Kees Cook, linux-mm, Vlastimil Babka, Harry Yoo
In-Reply-To: <04debe19-bbe8-4b5f-9668-753d1f97832d@redhat.com>
On Wed, Jul 08, 2026 at 10:30:50AM +0200, Paolo Abeni wrote:
> On 7/2/26 7:07 PM, Pedro Falcato wrote:> @@ -586,6 +586,8 @@ struct
> sk_buff *napi_build_skb(void *data, unsigned int frag_size)
> > }
> > EXPORT_SYMBOL(napi_build_skb);
> >
> > +static kmem_buckets *skb_data_buckets __ro_after_init;
> > +
> > static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
> > {
> > if (!gfp_pfmemalloc_allowed(flags))
> > @@ -593,7 +595,8 @@ static void *kmalloc_pfmemalloc(size_t obj_size, gfp_t flags, int node)
> > if (!obj_size)
> > return kmem_cache_alloc_node(net_hotdata.skb_small_head_cache,
> > flags, node);
> > - return kmalloc_node_track_caller(obj_size, flags, node);
> > + return kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
> > + flags, node);
>
> Sashiko noted that some drivers may require GFP_DMA buckets, and the
> above may break them:
>
> https://sashiko.dev/#/patchset/20260702170728.168755-1-pfalcato%40suse.de
Oh, this is really awkward. Adding linux-mm and slab maintainers for input here.
Considering the current slab bucketing does not seem to duplicate DMA or
CGROUP caches, could it make sense to duplicate those as well? Otherwise we
could add a branch like:
if (gfp_flags & __GFP_DMA)
/* use the global dma kmalloc caches */
>
> > }
> >
> > /*
> > @@ -634,7 +637,7 @@ static void *kmalloc_reserve(unsigned int *size, gfp_t flags, int node,
> > * Try a regular allocation, when that fails and we're not entitled
> > * to the reserves, fail.
> > */
> > - obj = kmalloc_node_track_caller(obj_size,
> > + obj = kmem_buckets_alloc_node_track_caller(skb_data_buckets, obj_size,
> > flags | __GFP_NOMEMALLOC | __GFP_NOWARN,
> > node);
>
> Minor nit: checkpatch laments WRT brackets alignment.
Will fix, thanks.
--
Pedro
^ permalink raw reply
* [PATCH] dpaa2-eth: put MAC endpoint device on disconnect
From: Guangshuo Li @ 2026-07-08 11:17 UTC (permalink / raw)
To: Ioana Ciornei, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
Cc: Guangshuo Li
fsl_mc_get_endpoint() returns the MAC endpoint device with a reference
taken through device_find_child(). The Ethernet connect path stores that
device in mac->mc_dev and keeps it for the lifetime of the connected MAC
object.
However, the disconnect path only disconnects and closes the MAC before
freeing the dpaa2_mac object. It does not drop the endpoint device
reference stored in mac->mc_dev, so every successful connect leaks that
device reference when the MAC is later disconnected.
Drop the endpoint device reference after closing the MAC and before
freeing the dpaa2_mac object.
Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
index 9335703768a9..764d2a09668f 100644
--- a/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
+++ b/drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
@@ -4732,6 +4732,7 @@ static void dpaa2_eth_disconnect_mac(struct dpaa2_eth_priv *priv)
dpaa2_mac_disconnect(mac);
dpaa2_mac_close(mac);
+ put_device(&mac->mc_dev->dev);
kfree(mac);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] ppp/ppp_{async,synctty}: drop unused {a,}syncppp::bytes_{sent,rcvd}
From: patchwork-bot+netdevbpf @ 2026-07-08 11:20 UTC (permalink / raw)
To: Jiri Slaby
Cc: kuba, linux-kernel, andrew+netdev, davem, edumazet, pabeni,
linux-ppp, netdev
In-Reply-To: <20260702060420.95023-1-jirislaby@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 2 Jul 2026 08:04:20 +0200 you wrote:
> The bytes_sent and bytes_rcvd members of structs asyncppp and syncppp
> are not used. Drop them.
>
> Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
>
> [...]
Here is the summary with links:
- ppp/ppp_{async,synctty}: drop unused {a,}syncppp::bytes_{sent,rcvd}
https://git.kernel.org/netdev/net-next/c/155c68aef239
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net-next] net: ipip: use tunnel parameters for fill_forward_path route lookup
From: Lorenzo Bianconi @ 2026-07-08 11:25 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Pablo Neira Ayuso,
Florian Westphal
Cc: netdev, netfilter-devel, Lorenzo Bianconi
Pass source address, DSCP and output interface from the tunnel
configuration to ip_route_output() in ipip_fill_forward_path(), aligning
the route lookup with the slow path in ipip_tunnel_xmit().
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
net/ipv4/ipip.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c
index b643194f57d2..d1aa048a6099 100644
--- a/net/ipv4/ipip.c
+++ b/net/ipv4/ipip.c
@@ -360,8 +360,9 @@ static int ipip_fill_forward_path(struct net_device_path_ctx *ctx,
const struct iphdr *tiph = &tunnel->parms.iph;
struct rtable *rt;
- rt = ip_route_output(dev_net(ctx->dev), tiph->daddr, 0, 0, 0,
- RT_SCOPE_UNIVERSE);
+ rt = ip_route_output(dev_net(ctx->dev), tiph->daddr, tiph->saddr,
+ inet_dsfield_to_dscp(tiph->tos),
+ tunnel->parms.link, RT_SCOPE_UNIVERSE);
if (IS_ERR(rt))
return PTR_ERR(rt);
---
base-commit: 155c68aef2397f8c5d72ef10acf48ae159bf1869
change-id: 20260708-ipip-route-lookup-fill_forward_path-6a8a1f45084c
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH net] net: airoha: Fix potential use-after-free in airoha_ppe_deinit()
From: Wayen Yan @ 2026-07-08 11:16 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
airoha_ppe_deinit() replaces the NPU pointer with NULL via
rcu_replace_pointer() but does not wait for existing RCU readers
to exit before calling ppe_deinit() and airoha_npu_put(). This can
cause a use-after-free if a reader in an RCU read-side critical
section still holds a reference to the NPU when it is freed.
The init path (airoha_ppe_init) already calls synchronize_rcu()
after rcu_assign_pointer(), but the deinit path introduced in
commit 6abcf751bc08 ("net: airoha: Fix schedule while atomic in
airoha_ppe_deinit()") omitted the matching barrier when switching
from rcu_read_lock()/rcu_dereference() to rcu_replace_pointer().
Add synchronize_rcu() before ppe_deinit() to ensure all existing
RCU readers have completed before the NPU resources are released.
Fixes: 6abcf751bc084804a9e5b3051442e8a2ce67f48a ("net: airoha: Fix schedule while atomic in airoha_ppe_deinit()")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_ppe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index e7c78293002a..f6396925722d 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -1659,6 +1659,7 @@ void airoha_ppe_deinit(struct airoha_eth *eth)
npu = rcu_replace_pointer(eth->npu, NULL,
lockdep_is_held(&flow_offload_mutex));
if (npu) {
+ synchronize_rcu();
npu->ops.ppe_deinit(npu);
airoha_npu_put(npu);
}
--
2.51.0
^ permalink raw reply related
* [PATCH net] net: airoha: Fix DMA direction for NPU mailbox buffer
From: Wayen Yan @ 2026-07-08 11:35 UTC (permalink / raw)
To: netdev
Cc: lorenzo, horms, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
airoha_npu_send_msg() always maps the mailbox buffer with DMA_TO_DEVICE,
but some callers expect the NPU to write response data back into the
same buffer:
- airoha_npu_wlan_msg_get() (NPU_OP_GET): NPU writes response into
the buffer, then the caller reads it via memcpy()
- airoha_npu_ppe_stats_setup() (NPU_OP_SET): NPU writes back
npu_stats_addr field in the response
On non-cache-coherent architectures like EN7581 (Cortex-A53 without
hardware cache coherency for NPU DMA), DMA_TO_DEVICE unmap is a no-op
— it does not invalidate the CPU cache. If the NPU-written cache line
is still present in the CPU cache when the caller reads the buffer,
the CPU observes stale data instead of the NPU response.
This is a timing-sensitive bug: small mailbox buffers (~24 bytes)
typically fit in a single cache line and may survive in the cache
until the caller reads them, producing silent data corruption rather
than a crash. The bug is more likely to trigger when the caller reads
the response immediately after dma_unmap_single() without intervening
cache-evicting operations.
Fix by using DMA_BIDIRECTIONAL for both map and unmap, which ensures
dma_unmap_single() invalidates the CPU cache on non-coherent systems.
The mailbox buffers are small so there is no performance concern.
Fixes: c52918744ee1e49cea86622a2633b9782446428f ("net: airoha: npu: Move memory allocation in airoha_npu_send_msg() caller")
Signed-off-by: Wayen Yan <win847@gmail.com>
---
drivers/net/ethernet/airoha/airoha_npu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_npu.c b/drivers/net/ethernet/airoha/airoha_npu.c
index 870d61fdd9c6..b679bed952de 100644
--- a/drivers/net/ethernet/airoha/airoha_npu.c
+++ b/drivers/net/ethernet/airoha/airoha_npu.c
@@ -168,7 +168,7 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
dma_addr_t dma_addr;
int ret;
- dma_addr = dma_map_single(npu->dev, p, size, DMA_TO_DEVICE);
+ dma_addr = dma_map_single(npu->dev, p, size, DMA_BIDIRECTIONAL);
ret = dma_mapping_error(npu->dev, dma_addr);
if (ret)
return ret;
@@ -191,7 +191,7 @@ static int airoha_npu_send_msg(struct airoha_npu *npu, int func_id,
spin_unlock_bh(&npu->cores[core].lock);
- dma_unmap_single(npu->dev, dma_addr, size, DMA_TO_DEVICE);
+ dma_unmap_single(npu->dev, dma_addr, size, DMA_BIDIRECTIONAL);
return ret;
}
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next 1/6] dt-bindings: net: mediatek-dwmac: add support for MT8189 SoC
From: Louis-Alexis Eyraud @ 2026-07-08 11:36 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Matthias Brugger, AngeloGioacchino Del Regno,
Biao Huang, Maxime Coquelin, Alexandre Torgue, maxime.chevallier,
rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <b810b9cd-8f5e-4c9d-8496-908aae55dac1@lunn.ch>
Hi Andrew,
On Tue, 2026-07-07 at 14:42 +0200, Andrew Lunn wrote:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - mediatek,mt8189-gmac
> > + then:
> > + properties:
> > + clocks:
> > + items:
> > + - description: MAC Main clock
> > + - description: PTP clock
> > + - description: RMII reference clock provided by MAC
>
> Since this is a MAC, it sounds like it is consuming its own clock?
In the driver ([1]), this clock is described as being only used and
needed in RMII when MAC provides the reference clock, and useless
otherwise (RGMII/MII or RMII when PHY provides the reference clock).
Its use and configuration also depends on the "mediatek,rmii-clk-from-
mac" vendor property ([2]) presence in devicetree.
Do you wish this clock description be reworded in the dt-bindings for
both occurrences?
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/net/ethernet/stmicro/stmmac/dwmac-mediatek.c#n480
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml#n108
Regards,
Louis-Alexis
>
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/6] net: stmmac: mediatek: add PERI_ETH_CTRLx register offset in platform data
From: Louis-Alexis Eyraud @ 2026-07-08 11:44 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Matthias Brugger, AngeloGioacchino Del Regno,
Biao Huang, Maxime Coquelin, Alexandre Torgue, maxime.chevallier,
rmk+kernel, kernel, netdev, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-stm32
In-Reply-To: <3e135fe0-4ef9-45be-a962-d131c8a2e9e0@lunn.ch>
Hi Andrew
On Tue, 2026-07-07 at 14:45 +0200, Andrew Lunn wrote:
> > + .peri_eth_ctrl_offset = MT8195_PERI_ETH_CTRL_BASE,
>
> nitpick:
>
> Could the naming be more consistent? offset vs base?
>
> Andrew
Ack.
The commit description and subject also use offset terminology and not
base so better keep the consistency.
I'll rename this define to MT8195_PERI_ETH_CTRL_OFFSET in the v2
version and do the same for the MT8189 one in patch 6.
Regards,
Louis-Alexis
^ permalink raw reply
* Re: [PATCH net] netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()
From: Florian Westphal @ 2026-07-08 11:45 UTC (permalink / raw)
To: Xiang Mei (Microsoft)
Cc: Pablo Neira Ayuso, Phil Sutter, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netfilter-devel,
coreteam, netdev, linux-kernel, AutonomousCodeSecurity, tgopinath,
kys
In-Reply-To: <20260706232850.3333016-1-xmei5@asu.edu>
Xiang Mei (Microsoft) <xmei5@asu.edu> wrote:
> br_ip6_fragment() gets prevhdr, a pointer into the skb head, from
> ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb
> skb_checksum_help() reallocates the head via pskb_expand_head(), leaving
> prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a
> use-after-free write.
>
> Re-find prevhdr after skb_checksum_help() so it points into the current
> head.
>
> BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857)
> Write of size 1 at addr ffff888013ff5016 by task exploit/141
> Call Trace:
> ...
> kasan_report (mm/kasan/report.c:595)
> ip6_frag_next (net/ipv6/ip6_output.c:857)
> br_ip6_fragment (net/ipv6/netfilter.c:212)
> nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407)
> nf_hook_slow (net/netfilter/core.c:619)
> br_forward_finish (net/bridge/br_forward.c:66)
> __br_forward (net/bridge/br_forward.c:115)
> maybe_deliver (net/bridge/br_forward.c:191)
> br_flood (net/bridge/br_forward.c:245)
> br_handle_frame_finish (net/bridge/br_input.c:229)
> br_handle_frame (net/bridge/br_input.c:442)
> ...
> packet_sendmsg (net/packet/af_packet.c:3114)
> ...
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
> Kernel panic - not syncing: Fatal exception in interrupt
>
> Fixes: 764dd163ac92 ("netfilter: nf_conntrack_bridge: add support for IPv6")
> Reported-by: AutonomousCodeSecurity@microsoft.com
> Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu>
> ---
> net/ipv6/netfilter.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv6/netfilter.c b/net/ipv6/netfilter.c
> index 6d80f85e55fa..547879da9532 100644
> --- a/net/ipv6/netfilter.c
> +++ b/net/ipv6/netfilter.c
> @@ -147,6 +147,10 @@ int br_ip6_fragment(struct net *net, struct sock *sk, struct sk_buff *skb,
> (err = skb_checksum_help(skb)))
> goto blackhole;
>
> + err = ip6_find_1stfragopt(skb, &prevhdr);
> + if (err < 0)
> + goto blackhole;
Would you mind sending a v2 that solves this the same way that it was
fixed in ipv6 output engine?
See
ef0efcd3bd3f ("ipv6: Fix dangling pointer when ipv6 fragment")
Thanks!
^ permalink raw reply
* [PATCH net-next 0/2] nfc: llcp: Move to .getsockopt_iter
From: Breno Leitao @ 2026-07-08 11:51 UTC (permalink / raw)
To: David Heidelberg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, sdf.kernel, Breno Leitao,
kernel-team
Continue to convert the protocols to getsockopt_iter callback.
Proto llcp is one of the last to be converted, and it was waiting for
the following fixes to land first, avoiding merge conflicts.
* commit 000fb5bc757a ("nfc: llcp: read llcp_sock->local under the
socket lock in getsockopt")
* commit 81e676dec04f4 ("nfc: llcp: avoid userspace overflow on invalid
optlen")
Now that they have landed, let's move llcp to .getsockopt_iter callback
Regarding the whole project migration, this is where we are:
Missing proto_ops migration (as of net-next)
net/can/isotp.c:1707 isotp_ops (.getsockopt = isotp_getsockopt) [1]
net/can/j1939/socket.c:1375 j1939_ops (.getsockopt = j1939_sk_getsockopt) [1]
net/ieee802154/socket.c:410 ieee802154_raw_ops (.getsockopt = sock_common_getsockopt)
net/ieee802154/socket.c:972 ieee802154_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1060 inet_stream_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1096 inet_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv4/af_inet.c:1128 inet_sockraw_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/af_inet6.c:660 inet6_stream_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/af_inet6.c:696 inet6_dgram_ops (.getsockopt = sock_common_getsockopt)
net/ipv6/raw.c:1276 inet6_sockraw_ops (.getsockopt = sock_common_getsockopt)
net/l2tp/l2tp_ip.c:628 l2tp_ip_ops (.getsockopt = sock_common_getsockopt)
net/l2tp/l2tp_ip6.c:757 l2tp_ip6_ops (.getsockopt = sock_common_getsockopt)
net/mptcp/protocol.c:4567 mptcp_stream_ops (.getsockopt = sock_common_getsockopt)
net/mptcp/protocol.c:4676 mptcp_v6_stream_ops (.getsockopt = sock_common_getsockopt)
net/phonet/socket.c:451 phonet_stream_ops (.getsockopt = sock_common_getsockopt)
net/sctp/ipv6.c:1043 inet6_seqpacket_ops (.getsockopt = sock_common_getsockopt)
net/sctp/protocol.c:1106 inet_seqpacket_ops (.getsockopt = sock_common_getsockopt)
net/smc/af_smc.c:3330 smc_sock_ops (.getsockopt = smc_getsockopt)
net/smc/smc_inet.c:33 smc_inet_stream_ops (.getsockopt = smc_getsockopt)
net/smc/smc_inet.c:80 smc_inet6_stream_ops (.getsockopt = smc_getsockopt)
Link: https://lore.kernel.org/all/20260507-getsock_two_can-v1-0-3c2ae9edfadc@debian.org/ [1]
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (2):
nfc: llcp: widen getsockopt value locals to u32
nfc: llcp: convert to getsockopt_iter
net/nfc/llcp_sock.c | 25 ++++++++++++-------------
1 file changed, 12 insertions(+), 13 deletions(-)
---
base-commit: 5c73cd9f0819c1c44e373e3dabb68318b1de1a12
change-id: 20260706-getsockopt_phase3-34f7b5eb3e0b
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* [PATCH net-next 2/2] nfc: llcp: convert to getsockopt_iter
From: Breno Leitao @ 2026-07-08 11:51 UTC (permalink / raw)
To: David Heidelberg, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: oe-linux-nfc, netdev, linux-kernel, sdf.kernel, Breno Leitao,
kernel-team
In-Reply-To: <20260708-getsockopt_phase3-v1-0-d8394f2fc554@debian.org>
Convert nfc_llcp_getsockopt() to the getsockopt_iter proto_ops callback.
It takes a sockopt_t and writes each value with copy_to_iter() instead of
a put_user() into optval; the socket layer builds the sockopt_t and copies
the length back. The socket lock and optlen validation are unchanged.
No functional change.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/nfc/llcp_sock.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index 94850fbe3620d..0f9cd03294074 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -302,21 +302,20 @@ static int nfc_llcp_setsockopt(struct socket *sock, int level, int optname,
}
static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
- char __user *optval, int __user *optlen)
+ sockopt_t *opt)
{
struct nfc_llcp_local *local;
struct sock *sk = sock->sk;
struct nfc_llcp_sock *llcp_sock = nfc_llcp_sock(sk);
+ u32 miux, remote_miu, remote_lto, remote_rw, rw;
int len, err = 0;
- u32 miux, remote_miu, rw;
pr_debug("%p optname %d\n", sk, optname);
if (level != SOL_NFC)
return -ENOPROTOOPT;
- if (get_user(len, optlen))
- return -EFAULT;
+ len = opt->optlen;
if (len < 0)
return -EINVAL;
@@ -337,7 +336,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
switch (optname) {
case NFC_LLCP_RW:
rw = llcp_sock->rw > LLCP_MAX_RW ? local->rw : llcp_sock->rw;
- if (put_user(rw, (u32 __user *) optval))
+ if (copy_to_iter(&rw, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -346,7 +345,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
miux = be16_to_cpu(llcp_sock->miux) > LLCP_MAX_MIUX ?
be16_to_cpu(local->miux) : be16_to_cpu(llcp_sock->miux);
- if (put_user(miux, (u32 __user *) optval))
+ if (copy_to_iter(&miux, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -355,19 +354,21 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
remote_miu = llcp_sock->remote_miu > LLCP_MAX_MIU ?
local->remote_miu : llcp_sock->remote_miu;
- if (put_user(remote_miu, (u32 __user *) optval))
+ if (copy_to_iter(&remote_miu, len, &opt->iter_out) != len)
err = -EFAULT;
break;
case NFC_LLCP_REMOTE_LTO:
- if (put_user(local->remote_lto / 10, (u32 __user *) optval))
+ remote_lto = local->remote_lto / 10;
+ if (copy_to_iter(&remote_lto, len, &opt->iter_out) != len)
err = -EFAULT;
break;
case NFC_LLCP_REMOTE_RW:
- if (put_user(llcp_sock->remote_rw, (u32 __user *) optval))
+ remote_rw = llcp_sock->remote_rw;
+ if (copy_to_iter(&remote_rw, len, &opt->iter_out) != len)
err = -EFAULT;
break;
@@ -379,8 +380,7 @@ static int nfc_llcp_getsockopt(struct socket *sock, int level, int optname,
release_sock(sk);
- if (put_user(len, optlen))
- return -EFAULT;
+ opt->optlen = len;
return err;
}
@@ -937,7 +937,7 @@ static const struct proto_ops llcp_sock_ops = {
.listen = llcp_sock_listen,
.shutdown = sock_no_shutdown,
.setsockopt = nfc_llcp_setsockopt,
- .getsockopt = nfc_llcp_getsockopt,
+ .getsockopt_iter = nfc_llcp_getsockopt,
.sendmsg = llcp_sock_sendmsg,
.recvmsg = llcp_sock_recvmsg,
.mmap = sock_no_mmap,
--
2.53.0-Meta
^ permalink raw reply related
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