* Re: [PATCH] compiler_types: Introduce inline_for_performance
From: Nick Desaulniers @ 2026-07-17 16:56 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Laight, Andrew Morton, linux-kernel, netdev, Jakub Kicinski,
Eric Dumazet, Paolo Abeni, Nicolas Pitre, nathan, ajordanr
In-Reply-To: <CANn89iJVQe=wedLheJmjZjOTJsWHijT0jZs=iRxKssJZbjAxHw@mail.gmail.com>
On Mon, Jan 19, 2026 at 11:33:29AM +0100, Eric Dumazet wrote:
> > Many __always_inline came because of clang's reluctance to inline
> > small things, even if the resulting code size is bigger and slower.
> >
> > It is a bit unclear, this seems to happen when callers are 'big
> > enough'.
Haha, yes, and I've read LLVM's inline cost model before and "a bit
unclear" is how I feel about it. At this point, some of your Google
compatriots have even resorted to AI for inlining.
https://arxiv.org/pdf/2101.04808
> > noinstr (callers) functions are also a problem.
> >
> > Let's take the list_add() call from dev_gro_receive() : clang does not
> > inline it, for some reason.
> >
> > After adding __always_inline to list_add() and __list_add() we have
> > smaller and more efficient code,
> > for real workloads, not only benchmarks.
Yeah, ChromeOS is hitting this now, too. They're deploying AutoFDO
where you collect traces with LBR (x86) / ETM,TRBE,BRBE,SPE (ARM) then
feed that back into the compiler. Then they're getting modpost warnings
from section mismatches when constant propagation sinks addresses of
initdata globals into specialized copies of list_add that are then not
inlined (so not placed in .init).
https://github.com/ClangBuiltLinux/linux/issues/2173
I think list_add, __list_add, and probably __list_del_entry_valid should
be always_inline, possibly except for the different definitions when
CONFIG_LIST_HARDENED is set.
^ permalink raw reply
* Re: [PATCH net-next v6 1/2] net: dsa: realtek: rtl8365mb: add SGMII support for RTL8367S
From: Mieczyslaw Nalewaj @ 2026-07-17 16:28 UTC (permalink / raw)
To: Stanislaw, Johan Alvarado
Cc: Linus Walleij, Alvin Sipraga, Andrew Lunn, Vladimir Oltean,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Maxime Chevallier, Luiz Angelo Daros de Luca,
netdev, linux-kernel
In-Reply-To: <20260717125155.18915-1-kuncy7@gmail.com>
Hi Stanisław
On 7/17/2026 2:51 PM, Stanislaw wrote:
> Hi,
>
> I have been testing this series on a second RTL8367S board: a TP-Link
> Archer AX55 v1, where the switch SerDes runs HSGMII (2500base-x) on
> external interface 1 to an IPQ5018 gmac1 (stmmac, fixed-link), on an
> OpenWrt 6.12 kernel. Some cold-boot results that may be relevant to the
> calibration discussion.
>
> Test image carried, on top of the v6 series:
> - the SDS indirect-access busy-wait fix, and
> - the ~98 ms PLL-settle delay plus the 0x060C-0x060F "Local Jam
> Table" analog calibration proposed in this thread.
>
Please repeat the test only with the fix "the ~98 ms PLL-settle delay plus the 0x060C-0x060F Local Jam Table analog calibration". Only the result of these changes can tell us something.
Best regards,
Mieczysław
^ permalink raw reply
* Re: [PATCH v5 2/2] selftest/bpf: added selftest sockmap_basic/sockmap recvfrom eagain
From: bot+bpf-ci @ 2026-07-17 16:36 UTC (permalink / raw)
To: nnamdio, nnamdio
Cc: bpf, davem, edumazet, horms, jakub, jiayuan.chen, john.fastabend,
kuba, kuniyu, ncardwell, netdev, pabeni, sashiko-reviews,
linux-kernel, ast, andrii, daniel, martin.lau, eddyz87,
yonghong.song, clm, ihor.solodrai
In-Reply-To: <20260717155348.54975-3-nnamdio@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
> selftest/bpf: added selftest sockmap_basic/sockmap recvfrom eagain
>
> These selftests exercise the tcp_bpf_recvmsg() and tcp_bpf_recvmsg_parser()
> functions, to ensure that they are properly handling spurious wakeups in
> tcp_msg_wait_data().
>
> The expected behaviour is that recvfrom() does not return an EAGAIN
> error. If the spurious wakeups are incorrectly handled, this assertion
> will fail.
>
> Signed-off-by: Nnamdi Onyeyiri <nnamdio@gmail.com>
this isn't a bug, but could the subject use the imperative mood, for
example "selftests/bpf: add sockmap recvfrom EAGAIN selftest", to match
the changelog convention and the sibling commit in the series? The
current "added selftest sockmap_basic/sockmap recvfrom eagain" also
repeats "selftest".
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/29595053560
^ permalink raw reply
* Re: [PATCH] vhost-scsi: Prevent OOM from invalid protection SGL count
From: Michael S. Tsirkin @ 2026-07-17 16:31 UTC (permalink / raw)
To: Mike Christie
Cc: Jia Jia, jasowang, Linfeng Sun, pbonzini, stefanha, eperezma,
virtualization, kvm, netdev, linux-kernel, stable
In-Reply-To: <8f5b5350-0be9-4b79-a6c9-069d418dee30@oracle.com>
On Fri, Jul 17, 2026 at 10:13:36AM -0500, Mike Christie wrote:
> cc'ing Linfeng.
>
> Linfeng also reported this bug and provided a patch that has your check and
> an extra check to avoid calling into the function in the first place. It's
> been stuck in some other list.
>
> I think it might be best for Linfeng to re-submit their patch now so it can
> get merged. For that patch, I think there was one outstanding question left
> where Michael had asked if the issue was found with AI so the proper tag
> could be added. I don't think that question was responded to.
Right, was waiting for that.
>
> On 7/17/26 9:22 AM, Jia Jia wrote:
> > The protection SGL path passes the result of vhost_scsi_calc_sgls()
> > directly to sg_alloc_table_chained(). The helper returns a negative
> > errno when the iterator is invalid or the request exceeds the segment
> > limit. The negative errno is then treated as a very large unsigned count
> > and sends the request into the SGL allocation path with an invalid size.
> >
> > Repeated malformed T10-PI submissions from a host-side application caused
> > memory usage to rise sharply. MemAvailable fell to about 200 MB, and PSI
> > full avg10 reached about 1.46. The OOM killer terminated several userspace
> > processes before the endpoint cleanup completed. The kernel log included:
> >
> > [17036.451028] Out of memory: Killed process 2345 (systemd)
> > [17036.493325] Out of memory: Killed process 2349 (sd-pam)
> > [17078.265127] Out of memory: Killed process 1793 (networkd-dispat)
> >
> > Return the calculation error before setting up the protection SGL. This
> > keeps the protection path consistent with the data SGL path and prevents
> > the invalid count from entering the allocation path.
> >
> > Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> > ---
> > drivers/vhost/scsi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> > index 9a1253b9d..8486652fd 100644
> > --- a/drivers/vhost/scsi.c
> > +++ b/drivers/vhost/scsi.c
> > @@ -972,6 +972,9 @@ vhost_scsi_mapal(struct vhost_scsi *vs, struct vhost_scsi_cmd *cmd,
> > if (prot_bytes) {
> > sgl_count = vhost_scsi_calc_sgls(prot_iter, prot_bytes,
> > VHOST_SCSI_PREALLOC_PROT_SGLS);
> > + if (sgl_count < 0)
> > + return sgl_count;
> > +
> > cmd->prot_table.sgl = cmd->prot_sgl;
> > ret = sg_alloc_table_chained(&cmd->prot_table, sgl_count,
> > cmd->prot_table.sgl,
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v2] selftests: Open /dev/udmabuf O_RDONLY
From: T.J. Mercier @ 2026-07-17 16:29 UTC (permalink / raw)
To: Shuah Khan
Cc: kraxel, vivek.kasireddy, kuba, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kselftest, linux-kernel, netdev,
bpf, Bobby Eshleman
In-Reply-To: <akbPrI67h5btdI44@devvm29614.prn0.facebook.com>
On Thu, Jul 2, 2026 at 1:53 PM Bobby Eshleman <bobbyeshleman@gmail.com> wrote:
>
> On Wed, Jul 01, 2026 at 12:22:08PM -0700, T.J. Mercier wrote:
> > Write permissions on the /dev/udmabuf device file are not required to
> > issue ioctls and allocate udmabufs. Applications should be opening this
> > file as O_RDONLY. The BPF dmabuf_iter selftest already does this. [1]
> >
> > Users are pointing to these selftests as examples of how use udmabuf,
> > and encountering permission errors on systems where write permissions
> > are not available on /dev/udmabuf. Apply the principle of least
> > privilege to selftests which use udmabuf by removing the write access
> > mode from drivers/dma-buf/udmabuf.c and drivers/net/hw/ncdevmem.c.
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/prog_tests/dmabuf_iter.c?h=v7.1#n49
> >
> > Signed-off-by: T.J. Mercier <tjmercier@google.com>
> > ---
> > tools/testing/selftests/drivers/dma-buf/udmabuf.c | 2 +-
> > tools/testing/selftests/drivers/net/hw/ncdevmem.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/testing/selftests/drivers/dma-buf/udmabuf.c b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
> > index d78aec662586..ced0b95c876c 100644
> > --- a/tools/testing/selftests/drivers/dma-buf/udmabuf.c
> > +++ b/tools/testing/selftests/drivers/dma-buf/udmabuf.c
> > @@ -140,7 +140,7 @@ int main(int argc, char *argv[])
> > ksft_print_header();
> > ksft_set_plan(7);
> >
> > - devfd = open("/dev/udmabuf", O_RDWR);
> > + devfd = open("/dev/udmabuf", O_RDONLY);
> > if (devfd < 0) {
> > ksft_print_msg(
> > "%s: [skip,no-udmabuf: Unable to access DMA buffer device file]\n",
> > diff --git a/tools/testing/selftests/drivers/net/hw/ncdevmem.c b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
> > index e098d6534c3c..8114a29692fd 100644
> > --- a/tools/testing/selftests/drivers/net/hw/ncdevmem.c
> > +++ b/tools/testing/selftests/drivers/net/hw/ncdevmem.c
> > @@ -149,7 +149,7 @@ static struct memory_buffer *udmabuf_alloc(size_t size)
> >
> > ctx->size = size;
> >
> > - ctx->devfd = open("/dev/udmabuf", O_RDWR);
> > + ctx->devfd = open("/dev/udmabuf", O_RDONLY);
> > if (ctx->devfd < 0) {
> > pr_err("[skip,no-udmabuf: Unable to access DMA buffer device file]");
> > goto err_free_ctx;
> >
> > base-commit: fbb7ad31ab376c5101b2ac7205fad0344fd2de60
> > --
> > 2.55.0.rc0.799.gd6f94ed593-goog
> >
>
> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Thanks Bobby.
Shuah, would you mind picking this up?
^ permalink raw reply
* Re: [PATCH net] net: sxgbe: fix null pointer dereference in probe error path
From: Andrew Lunn @ 2026-07-17 16:11 UTC (permalink / raw)
To: Chenguang Zhao
Cc: bh74.an, andrew+netdev, davem, edumazet, kuba, pabeni, netdev,
Chenguang Zhao
In-Reply-To: <20260717091423.1557737-1-chenguang.zhao@linux.dev>
On Fri, Jul 17, 2026 at 05:14:23PM +0800, Chenguang Zhao wrote:
> From: Chenguang Zhao <zhaochenguang@kylinos.cn>
>
> The platform drvdata is not set until all IRQs have been mapped, so the
> local net_device pointer is NULL when IRQ mapping fails. Remove the device
> allocated by sxgbe_drv_probe() through priv instead.
>
> Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver")
> Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH v3 net-next] net: rnpgbe: Delete a null pointer check in rnpgbe_rm_adapter()
From: Andrew Lunn @ 2026-07-17 16:07 UTC (permalink / raw)
To: Markus Elfring
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Julia Lawall, MD Danish Anwar, Michael Grzeschik,
Paolo Abeni, Uwe Kleine-König, Vadim Fedorenko, Yibo Dong,
LKML, kernel-janitors, Dan Carpenter
In-Reply-To: <7a9ea765-2c75-4a16-aaf9-510f2450beb3@web.de>
On Fri, Jul 17, 2026 at 10:38:32AM +0200, Markus Elfring wrote:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Fri, 17 Jul 2026 10:20:15 +0200
>
> The check for the pointer “mucse” was identified as redundant because
> the relevant address information was preserved according to calls of
> the functions “pci_set_drvdata” and “pci_get_drvdata”.
> Thus remove it.
>
> This issue was detected by using the Coccinelle software.
>
> See also:
> Reconsidering pointer dereferences before null pointer checks (with SmPL)
> 2023-04-09
> https://lore.kernel.org/cocci/1a11455f-ab57-dce0-1677-6beb8492a257@web.de/
> https://sympa.inria.fr/sympa/arc/cocci/2023-04/msg00021.html
>
> Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH v5 2/2] selftest/bpf: added selftest sockmap_basic/sockmap recvfrom eagain
From: Nnamdi Onyeyiri @ 2026-07-17 15:53 UTC (permalink / raw)
To: nnamdio
Cc: bpf, davem, edumazet, horms, jakub, jiayuan.chen, john.fastabend,
kuba, kuniyu, ncardwell, netdev, pabeni, sashiko-reviews,
linux-kernel
In-Reply-To: <20260717155348.54975-1-nnamdio@gmail.com>
These selftests exercise the tcp_bpf_recvmsg() and tcp_bpf_recvmsg_parser()
functions, to ensure that they are properly handling spurious wakeups in
tcp_msg_wait_data().
The expected behaviour is that recvfrom() does not return an EAGAIN
error. If the spurious wakeups are incorrectly handled, this assertion
will fail.
Signed-off-by: Nnamdi Onyeyiri <nnamdio@gmail.com>
---
.../selftests/bpf/prog_tests/sockmap_basic.c | 115 ++++++++++++++++++
1 file changed, 115 insertions(+)
diff --git a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
index cb3229711f93..852a12b17e6b 100644
--- a/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
+++ b/tools/testing/selftests/bpf/prog_tests/sockmap_basic.c
@@ -1373,6 +1373,117 @@ static void test_sockmap_multi_channels(int sotype)
test_sockmap_pass_prog__destroy(skel);
}
+static void *test_sockmap_recvfrom_eagain_thread(void *arg)
+{
+ int fd = *(int *)arg;
+ char buf[1024];
+ void *result = NULL;
+
+ while (true) {
+ ssize_t len = recvfrom(fd, buf, sizeof(buf), 0, NULL, NULL);
+
+ if (len == -1) {
+ if (errno == EINTR)
+ continue;
+ result = (void *)1;
+ break;
+ }
+
+ if (!len || buf[len - 1] == 'e')
+ break;
+ }
+
+ send(fd, "test", 4, MSG_NOSIGNAL);
+
+ return result;
+}
+
+static void test_sockmap_recvfrom_eagain(bool with_verdict)
+{
+ struct test_sockmap_pass_prog *skel = NULL;
+ struct bpf_program *prog = NULL;
+ size_t buflen = 1024 * 1024 * 25;
+ char *buf = NULL;
+ int map, err;
+
+ skel = test_sockmap_pass_prog__open_and_load();
+ if (!ASSERT_OK_PTR(skel, "open_and_load"))
+ return;
+
+ map = bpf_map__fd(skel->maps.sock_map_msg);
+
+ if (with_verdict) {
+ prog = skel->progs.prog_skb_verdict;
+ err = bpf_prog_attach(bpf_program__fd(prog), map, BPF_SK_SKB_STREAM_VERDICT, 0);
+ if (!ASSERT_OK(err, "bpf_prog_attach verdict"))
+ goto cleanup;
+ }
+
+ buf = malloc(buflen);
+ if (!ASSERT_OK_PTR(buf, "malloc buf"))
+ goto cleanup;
+ memset(buf, 0, buflen);
+ buf[buflen - 1] = 'e';
+
+ for (int i = 0; i < 200; ++i) {
+ ssize_t sent;
+ char ignored[128];
+ pthread_t thread;
+ bool thread_created = false;
+ size_t rem = buflen;
+ int c = -1, p = -1, zero = 0;
+ bool success = false;
+
+ err = create_pair(AF_INET, SOCK_STREAM, &c, &p);
+ if (!ASSERT_OK(err, "create_pair"))
+ goto end_attempt;
+
+ err = pthread_create(&thread, NULL, &test_sockmap_recvfrom_eagain_thread, &p);
+ if (!ASSERT_OK(err, "pthread_create"))
+ goto end_attempt;
+ thread_created = true;
+
+ err = bpf_map_update_elem(map, &zero, &c, BPF_ANY);
+ if (!ASSERT_OK(err, "bpf_map_update_elem"))
+ goto end_attempt;
+
+ while (rem) {
+ sent = xsend(c, buf + (buflen - rem), rem, 0);
+ if (sent == -1)
+ goto end_attempt;
+ rem -= sent;
+ }
+
+ err = recvfrom(c, ignored, sizeof(ignored), 0, NULL, NULL);
+ if (err < 0 && !ASSERT_NEQ(errno, EAGAIN, "recvfrom eagain"))
+ goto end_attempt;
+
+ success = true;
+
+end_attempt:
+ if (c >= 0)
+ close(c);
+
+ if (thread_created) {
+ void *retval = NULL;
+
+ pthread_join(thread, &retval);
+ ASSERT_NULL(retval, "retval");
+ }
+
+ if (p >= 0)
+ close(p);
+ if (!success)
+ break;
+ }
+
+cleanup:
+ if (buf)
+ free(buf);
+
+ test_sockmap_pass_prog__destroy(skel);
+}
+
void test_sockmap_basic(void)
{
if (test__start_subtest("sockmap create_update_free"))
@@ -1451,4 +1562,8 @@ void test_sockmap_basic(void)
test_sockmap_multi_channels(SOCK_STREAM);
if (test__start_subtest("sockmap udp multi channels"))
test_sockmap_multi_channels(SOCK_DGRAM);
+ if (test__start_subtest("sockmap recvfrom eagain"))
+ test_sockmap_recvfrom_eagain(false);
+ if (test__start_subtest("sockmap recvfrom eagain with verdict"))
+ test_sockmap_recvfrom_eagain(true);
}
--
2.52.0
^ permalink raw reply related
* [PATCH v5 1/2] bpf, sockmap: handle spurious tcp_msg_wait_data() wakeup
From: Nnamdi Onyeyiri @ 2026-07-17 15:53 UTC (permalink / raw)
To: nnamdio
Cc: bpf, davem, edumazet, horms, jakub, jiayuan.chen, john.fastabend,
kuba, kuniyu, ncardwell, netdev, pabeni, sashiko-reviews,
linux-kernel
In-Reply-To: <20260717155348.54975-1-nnamdio@gmail.com>
recvfrom()/recv() are documented as only returning EAGAIN for blocking sockets
when they have a receive timeout configured. However, adding a blocking
ipv4 tcp socket without a receive timeout to a sockmap will cause EAGAIN errors
sporadically. A socket with a receive timeout may return EAGAIN before the
timeout expires.
There are 2 code paths affected by this:
1. tcp_bpf_recvmsg() - Used when the socket has been added to a sockmap
that has no verdict program attached.
2. tcp_bpf_recvmsg_parser() - Used when the socket has been added to a
sockmap that has a verdict program. To reproduce this issue, it is
enough for the verdict program to do nothing but return SK_PASS.
In both cases this happens when tcp_msg_wait_data() wakes spuriously
(returning 0). To fix it, we now loop back to msg_bytes_ready instead
of returning -EAGAIN on spurious wakeup.
To ensure the looping does not cause sockets with a SO_RCVTIMEO set to
wait excessively long, tcp_msg_wait_data() now takes a pointer to timeo,
allowing sk_wait_event() to update it as appropriate.
The logic in tcp_bpf_recvmsg_parser() that allow it to handle signals,
socket errors and closuers in its loop was also added to tcp_bpf_recvmsg().
Signed-off-by: Nnamdi Onyeyiri <nnamdio@gmail.com>
---
net/ipv4/tcp_bpf.c | 69 ++++++++++++++++++++++++++++++++++++++++------
1 file changed, 60 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_bpf.c b/net/ipv4/tcp_bpf.c
index cc0bd73f36b6..aa5c5d741599 100644
--- a/net/ipv4/tcp_bpf.c
+++ b/net/ipv4/tcp_bpf.c
@@ -179,7 +179,7 @@ EXPORT_SYMBOL_GPL(tcp_bpf_sendmsg_redir);
#ifdef CONFIG_BPF_SYSCALL
static int tcp_msg_wait_data(struct sock *sk, struct sk_psock *psock,
- long timeo)
+ long *timeo)
{
DEFINE_WAIT_FUNC(wait, woken_wake_function);
int ret = 0;
@@ -187,12 +187,12 @@ static int tcp_msg_wait_data(struct sock *sk, struct sk_psock *psock,
if (sk->sk_shutdown & RCV_SHUTDOWN)
return 1;
- if (!timeo)
+ if (!*timeo)
return ret;
add_wait_queue(sk_sleep(sk), &wait);
sk_set_bit(SOCKWQ_ASYNC_WAITDATA, sk);
- ret = sk_wait_event(sk, &timeo,
+ ret = sk_wait_event(sk, timeo,
!list_empty(&psock->ingress_msg) ||
!skb_queue_empty_lockless(&sk->sk_receive_queue), &wait);
sk_clear_bit(SOCKWQ_ASYNC_WAITDATA, sk);
@@ -229,6 +229,7 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
int copied_from_self = 0;
int copied = 0;
u32 seq;
+ long timeo;
if (unlikely(flags & MSG_ERRQUEUE))
return inet_recv_error(sk, msg, len);
@@ -262,6 +263,8 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
}
}
+ timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
+
msg_bytes_ready:
copied = __sk_msg_recvmsg(sk, psock, msg, len, flags, &copied_from_self);
/* The typical case for EFAULT is the socket was gracefully
@@ -280,7 +283,6 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
}
seq += copied_from_self;
if (!copied) {
- long timeo;
int data;
if (sock_flag(sk, SOCK_DONE))
@@ -299,7 +301,6 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
goto out;
}
- timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
if (!timeo) {
copied = -EAGAIN;
goto out;
@@ -310,13 +311,15 @@ static int tcp_bpf_recvmsg_parser(struct sock *sk,
goto out;
}
- data = tcp_msg_wait_data(sk, psock, timeo);
+ data = tcp_msg_wait_data(sk, psock, &timeo);
if (data < 0) {
copied = data;
goto unlock;
}
if (data && !sk_psock_queue_empty(psock))
goto msg_bytes_ready;
+ if (!data && timeo > 0)
+ goto msg_bytes_ready;
copied = -EAGAIN;
}
out:
@@ -355,6 +358,7 @@ static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
{
struct sk_psock *psock;
int copied, ret;
+ long timeo;
if (unlikely(flags & MSG_ERRQUEUE))
return inet_recv_error(sk, msg, len);
@@ -371,14 +375,59 @@ static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
return tcp_recvmsg(sk, msg, len, flags);
}
lock_sock(sk);
+
+ timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
+
msg_bytes_ready:
copied = sk_msg_recvmsg(sk, psock, msg, len, flags);
if (!copied) {
- long timeo;
int data;
- timeo = sock_rcvtimeo(sk, flags & MSG_DONTWAIT);
- data = tcp_msg_wait_data(sk, psock, timeo);
+ if (sock_flag(sk, SOCK_DONE)) {
+ ret = 0;
+ goto unlock;
+ }
+
+ if (sk->sk_err) {
+ if (!sk_psock_queue_empty(psock))
+ goto msg_bytes_ready;
+ if (!skb_queue_empty(&sk->sk_receive_queue)) {
+ release_sock(sk);
+ sk_psock_put(sk, psock);
+ return tcp_recvmsg(sk, msg, len, flags);
+ }
+ ret = sock_error(sk);
+ goto unlock;
+ }
+
+ if (sk->sk_shutdown & RCV_SHUTDOWN) {
+ if (!sk_psock_queue_empty(psock))
+ goto msg_bytes_ready;
+ if (!skb_queue_empty(&sk->sk_receive_queue)) {
+ release_sock(sk);
+ sk_psock_put(sk, psock);
+ return tcp_recvmsg(sk, msg, len, flags);
+ }
+ ret = 0;
+ goto unlock;
+ }
+
+ if (sk->sk_state == TCP_CLOSE) {
+ ret = -ENOTCONN;
+ goto unlock;
+ }
+
+ if (!timeo) {
+ ret = -EAGAIN;
+ goto unlock;
+ }
+
+ if (signal_pending(current)) {
+ ret = sock_intr_errno(timeo);
+ goto unlock;
+ }
+
+ data = tcp_msg_wait_data(sk, psock, &timeo);
if (data < 0) {
ret = data;
goto unlock;
@@ -390,6 +439,8 @@ static int tcp_bpf_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
sk_psock_put(sk, psock);
return tcp_recvmsg(sk, msg, len, flags);
}
+ if (!data && timeo > 0)
+ goto msg_bytes_ready;
copied = -EAGAIN;
}
ret = copied;
--
2.52.0
^ permalink raw reply related
* [PATCH v5 0/2] bpf, sockmap: handle spurious tcp_msg_wait_data() wakeup
From: Nnamdi Onyeyiri @ 2026-07-17 15:53 UTC (permalink / raw)
To: nnamdio
Cc: bpf, davem, edumazet, horms, jakub, jiayuan.chen, john.fastabend,
kuba, kuniyu, ncardwell, netdev, pabeni, sashiko-reviews,
linux-kernel
Spurious wakeups in tcp_msg_wait_data() isn't being handled by
tcp_bpf_recvmsg() and tcp_bpf_recvmsg_parser(), leading to unexpected
EAGAIN errors returned by recvfrom()/recv(). Adding handling for the
wakeup and a selftest.
This issue was first discovered in an application that adds sockets to
a sockmap as a way to view the received data. No redirects or any
other operations are performed.
Sashiko has noted a few other pre-existing issues in the same area
(https://patch.msgid.link/20260714205118.17DB11F000E9@smtp.kernel.org)
that can lead to EAGAIN in tcp_bpf_recvmsg() and
tcp_bpf_recvmsg_parser(). A local run of Sashiko also identified a
potential issue in tcp_bpf_recvmsg() handling zero-data FIN packets when
the MSG_PEEK flag is set. To prevent this patchset from growing too
large, I intend to submit follow up patches to address these once this
one has been accepted.
Changes in v5:
- Move selftest from net into bpf/prog_tests/sockmap_basic.c
- Link to v4: https://patch.msgid.link/20260715213538.37229-1-nnamdio@gmail.com
Changes in v4:
- Fix potential data loss in tcp_bpf_recvmsg() when a FIN or RST has
been received.
- Check the return code of pthread_create() in the selftest.
- Fix race caused by using EXPECT macros in a thread in selftest.
- Link to v3: https://patch.msgid.link/20260714203927.32289-1-nnamdio@gmail.com
Changes in v3:
- Added the sockmap_recvfrom selftest.
- Link to v2: https://patch.msgid.link/alFRK66z45eDNZA7@localhost.localdomain
Changes in v2:
- In tcp_bpf_recvmsg, handle signals and the socket closing in the loop.
- Fix spurious wakeups when SO_RCVTIMEO has been set on the socket.
- Link to v1: https://patch.msgid.link/ak_rR-Skd8Mvn4mH@localhost.localdomain
Signed-off-by: Nnamdi Onyeyiri <nnamdio@gmail.com>
---
Nnamdi Onyeyiri (2):
bpf, sockmap: handle spurious tcp_msg_wait_data() wakeup
selftest/bpf: added selftest sockmap_basic/sockmap recvfrom eagain
net/ipv4/tcp_bpf.c | 69 +++++++++--
.../selftests/bpf/prog_tests/sockmap_basic.c | 115 ++++++++++++++++++
2 files changed, 175 insertions(+), 9 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH] net: ipv6: fix a potential use-after-free in ip4ip6_err
From: Xin Long @ 2026-07-17 15:53 UTC (permalink / raw)
To: lirongqing
Cc: David Ahern, Ido Schimmel, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260717143315.1942-1-lirongqing@baidu.com>
On Fri, Jul 17, 2026 at 10:33 AM lirongqing <lirongqing@baidu.com> wrote:
>
> From: Li RongQing <lirongqing@baidu.com>
>
> Fix a use-after-free bug in ip4ip6_err() where rt->rt_flags is accessed
> after the route entry object has been released via ip_rt_put(rt).
>
> If ip_rt_put() decrements the reference count to zero and frees the
> rtable structure, reading rt->rt_flags immediately afterward
> results in a use-after-free pointer dereference.
>
> Fix this by caching rt->rt_flags into a local variable before calling
> ip_rt_put().
>
> Fixes: 77552cfa39c4 ("ip6_tunnel: clean up ip4ip6 and ip6ip6's err_handlers")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> net/ipv6/ip6_tunnel.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
> index bf8e40a..984cb0c 100644
> --- a/net/ipv6/ip6_tunnel.c
> +++ b/net/ipv6/ip6_tunnel.c
> @@ -569,6 +569,7 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> {
> __u32 rel_info = ntohl(info);
> const struct iphdr *eiph;
> + unsigned int rt_flags;
> struct sk_buff *skb2;
> int err, rel_msg = 0;
> u8 rel_type = type;
> @@ -627,10 +628,11 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> goto out;
>
> skb2->dev = rt->dst.dev;
> + rt_flags = rt->rt_flags;
> ip_rt_put(rt);
>
> /* route "incoming" packet */
> - if (rt->rt_flags & RTCF_LOCAL) {
> + if (rt_flags & RTCF_LOCAL) {
> rt = ip_route_output_ports(dev_net(skb->dev), &fl4, NULL,
> eiph->daddr, eiph->saddr, 0, 0,
> IPPROTO_IPIP,
> --
> 2.9.4
>
Have you already seen any problem triggered by this?
I don't really think there's a use-after-free issue here.
The entire IPv6 input path, including ICMPv6 error handling, runs under
rcu_read_lock(). Since dst_release() uses call_rcu_hurry() to defer the
actual freeing until after the RCU grace period, accessing rt->rt_flags
after ip_rt_put(rt) is completely safe in this context.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH net-next 0/6] net: add GeoNetworking protocol
From: Simon Dietz @ 2026-07-17 15:40 UTC (permalink / raw)
To: andrew
Cc: andrew+netdev, davem, dietz23838, edumazet, johannes, kuniyu,
linux-wireless, netdev, simon.dietz
In-Reply-To: <9db571aa-4d5c-456a-ab24-796119c9807b@lunn.ch>
> I'm probably doing a deep dive too early, but ...
Thanks for your time and the fast response.
> Nothing new has been added to /proc for a long time. Please consider
> a different interface. I've not yet looked to see what is there, but
> networking now pretty much only uses netlink.
/proc has been used during the development of the gn module for passing
gps data from the user space to the kernel. This behaviour has been
changed to ioctl. Procfs has only been kept for debugging reasons. It
can safely be removed and will be in the next patch version.
> New IOCTL code is also very likely to be rejected. The functionality
> should go through netlink.
I'll take a look into netlink and rewrite the new IOCTL code.
> Generally, inline functions in a .c file are rejected. It is better
> to let the compiler decide. The exception would be if you have a
> benchmark which shows inline actually helps.
Noted. No inline functions (besides proven by benchmarks).
> This seems like debug. At minimum, it should be _dbg(), but maybe it
> should be removed altogether.
I thought to have changed all pr_info to pr_debug, this one slipped
through.
> When does this wrap around? Maybe add it as a comment.
Noted.
> Commented out code is not something we want in the kernel.
Indeed all BUG calls should have been removed with one of the
subsequent patches together with most of the commented out code. I'll
take another look to ensure all comment out code is removed.
> Maybe one of your later patches fixes this. We might want to consider
> squashing them, so the review is done on the final clean code.
That's good advice. I'll adhere to it.
> netdev uses reverse christmas tree, longest lines first, shortest
> last. It should apply to all functions.
Fixed in patch 6/6. And partially included in squashing subsequent
patches so they fully adhere to the coding style from the start.
> Not the sort of thing you normally see in the kernel.
> I've not looked at the code enough to see the big picture, but
> generally, the kernel routing table is static, and fed from a user
> space daemon. Should all this code be in user space?
In GeoNetworking routing decisions can be and are in non broadcast
situations based on the distance to the other vehicle/host. To be more
precise routing is based on if the reciever is in the same area as the
sender. If the sender needs to forward a packet to a reciever outside
its own range, it is forward to the intermediary closest to the
reciever.
That's kind of the core idea/feature of GeoNetworking. I don't see the
possibility to move this part into the userspace. But this does not
mean that there is no option at all.
>> static void debug_loc_te(void) ...
> debugfs? a netlink dump operation?
I'd like to keep this debug function for now. I agree that it should be
removed/changed in the final patch before an actual merge to net-next.
Simon
^ permalink raw reply
* Re: [REGRESSION][BISECTED] stmmac: suspend hangs since 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
From: Andrew Lunn @ 2026-07-17 15:40 UTC (permalink / raw)
To: tresonic; +Cc: netdev, regressions, rmk+kernel, kuba, Maxime Chevallier
In-Reply-To: <72b91ec7-202c-4301-bcd8-b818cf8d72a0@mail.de>
> I tested the changes as you suggested and it seems DMA_CHAN_INTR_ENA_RPS in DMA_CHAN_INTR_ABNORMAL_4_10 broke it.
> With this change on master suspend is working:
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> index 43b036d4e95b..e907142c9ee2 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.h
> @@ -121,7 +121,6 @@ static inline u32 dma_chanx_base_addr(const struct dwmac4_addrs *addrs,
> DMA_CHAN_INTR_ENA_TIE)
>
> #define DMA_CHAN_INTR_ABNORMAL_4_10 (DMA_CHAN_INTR_ENA_AIE_4_10 | \
> - DMA_CHAN_INTR_ENA_RPS | \
> DMA_CHAN_INTR_ENA_RBU | \
> DMA_CHAN_INTR_ENA_FBE)
> /* DMA default interrupt mask for 4.10a */
OK, that narrows it down a bit.
I made the guess it is an interrupt storm during suspend, because
interrupts are not disabled. DMA_CHAN_INTR_ABNORMAL_4_10 is written to
hardware in dwmac410_dma_init_channel(). However, i don't see anywhere
these interrupts are clear? struct stmmac_dma_ops has an init_chan
operation, but there is no opposite operation to reset a channel?
There is however disable_dma_irq. Maybe DMA_CHAN_INTR_ENA_RPS can be
cleared there?
But i'm also having trouble finding where dwmac4_disable_dma_irq() is
actually called. It is called from stmmac_disable_rx_queue() and
stmmac_disable_tx_queue() but they only seem to be used in the XDP
code.
Are the DMAs being stopped during suspend? I don't know this driver
well enough to answer that.
Can you scatter some printk() around and see what actually happens on
suspend. See if you can find somewhere to disable that one interrupt?
Andrew
^ permalink raw reply
* Re: [PATCH v2 2/2] net: sctp: auth: Fix safety issue when skb_clone fails in auth_chunk handling
From: Xin Long @ 2026-07-17 15:22 UTC (permalink / raw)
To: luoqing
Cc: marcelo.leitner, davem, edumazet, kuba, pabeni, horms, linux-sctp,
netdev, linux-kernel, luoqing
In-Reply-To: <CADvbK_fxLnyyx7kuuHr3_Vu9Wp9AenxAZYM7rO5kDwR=eXjd3w@mail.gmail.com>
On Fri, Jul 17, 2026 at 11:01 AM Xin Long <lucien.xin@gmail.com> wrote:
>
> On Thu, Jul 16, 2026 at 6:05 AM luoqing <l1138897701@163.com> wrote:
> >
> > From: luoqing <luoqing@kylinos.cn>
> >
> > When processing AUTH + COOKIE-ECHO packets, if skb_clone fails due to
> > memory pressure, chunk->auth_chunk is set to NULL but chunk->auth is
> > still set to 1. This causes sctp_auth_chunk_verify to skip the AUTH
> > validation (since auth_chunk is NULL), allowing unauthenticated
> > COOKIE-ECHO packets to be accepted.
> >
> > Fix this by only setting chunk->auth = 1 when skb_clone succeeds.
> >
> > Fixes: 59d8d4434f429b ("sctp: delay the authentication for the duplicated cookie-echo chunk")
> >
> > Signed-off-by: luoqing <luoqing@kylinos.cn>
> > ---
> > net/sctp/associola.c | 3 ++-
> > net/sctp/endpointola.c | 3 ++-
> > 2 files changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> > index 62d3cc155809..e54068305396 100644
> > --- a/net/sctp/associola.c
> > +++ b/net/sctp/associola.c
> > @@ -999,7 +999,8 @@ static void sctp_assoc_bh_rcv(struct work_struct *work)
> > if (next_hdr->type == SCTP_CID_COOKIE_ECHO) {
> > chunk->auth_chunk = skb_clone(chunk->skb,
> > GFP_ATOMIC);
> > - chunk->auth = 1;
> > + if (chunk->auth_chunk)
> > + chunk->auth = 1;
> > continue;
> > }
> > }
> > diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> > index dfb1719275db..3419748c66bc 100644
> > --- a/net/sctp/endpointola.c
> > +++ b/net/sctp/endpointola.c
> > @@ -368,7 +368,8 @@ static void sctp_endpoint_bh_rcv(struct work_struct *work)
> > if (next_hdr->type == SCTP_CID_COOKIE_ECHO) {
> > chunk->auth_chunk = skb_clone(chunk->skb,
> > GFP_ATOMIC);
> > - chunk->auth = 1;
> > + if (chunk->auth_chunk)
> > + chunk->auth = 1;
> > continue;
> > }
> > }
> > --
> > 2.25.1
> >
> The patch does not fully address the issues reported by Sashiko in the
> following two cases (I will interpret them below):
>
> 1. [sashiko-gemini]:
>
> When skb_clone() fails, chunk->auth_chunk is set to NULL and chunk->auth
> remains 0. In this case, the chunk will be dropped/skipped in
> sctp_assoc_bh_rcv() by the following check:
>
> if (sctp_auth_recv_cid(subtype.chunk, asoc) && !chunk->auth)
> continue;
>
> This works as expected because the chunk is skipped. However, in
> sctp_endpoint_bh_rcv(), asoc is NULL for new connections, so the above
> condition is always false. As a result, the COOKIE-ECHO chunk can still be
> processed with chunk->auth_chunk == NULL.
>
> 2. [sashiko-claude]:
>
> When the association requires authentication for the COOKIE-ECHO chunk, but
> the packet does not contain an AUTH chunk, skb_clone() is never called and
> chunk->auth_chunk remains NULL. Since the new association is also NULL in
> sctp_endpoint_bh_rcv(), the check above cannot catch this case either. The
> COOKIE-ECHO chunk will still be processed with chunk->auth_chunk == NULL.
>
> A better fix would be:
>
> Add a check in sctp_auth_chunk_verify() at the point where the COOKIE-ECHO
> chunk is actually being processed:
>
>
> if (!chunk->auth_chunk)
> return !sctp_auth_recv_cid(chunk->chunk_hdr->type, asoc);
>
> This ensures that if chunk->auth_chunk is missing while authentication is
> required for the COOKIE-ECHO chunk, the verification fails and the chunk is
> dropped. Otherwise, when authentication is not required, processing can
> continue normally.
>
> Please give it a try.
>
Also, please add a extra Fixes tag in your next post:
Fixes: bbd0d59809f9 ("[SCTP]: Implement the receive and verification
of AUTH chunk")
which introduces chunk->auth_chunk and calls skb_clone() in
sctp_endpoint_bh_rcv().
Thanks.
^ permalink raw reply
* [PATCH net] usbnet: cap max_mtu for drivers without bind callback
From: Laurent Vivier @ 2026-07-17 15:16 UTC (permalink / raw)
To: linux-kernel
Cc: netdev, Jakub Kicinski, linux-usb, Stefano Brivio, Oliver Neukum,
Laurent Vivier, stable
Commit c7159e960f14 ("usbnet: limit max_mtu based on device's hard_mtu")
caps max_mtu inside the if (info->bind) block in usbnet_probe(). Drivers
without a bind callback never enter this block, so max_mtu stays at
ETH_MAX_MTU.
QEMU's usb-net device (0x0525/0xa4a2) is claimed by the cdc_subset
driver which has no bind callback. The guest accepts any MTU from DHCP
(e.g. 65520 from passt), leading to TCP segments that exceed the
device's 2048-byte receive buffer and are silently dropped.
Move the max_mtu capping after the if/else block so it applies to all
usbnet drivers.
Fixes: c7159e960f14 ("usbnet: limit max_mtu based on device's hard_mtu")
Cc: stable@vger.kernel.org
Link: https://gitlab.com/qemu-project/qemu/-/issues/3268
Link: https://bugs.passt.top/show_bug.cgi?id=189
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
---
drivers/net/usb/usbnet.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 25518635b7b7..d87299025552 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -1825,10 +1825,6 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id *prod)
if ((dev->driver_info->flags & FLAG_NOARP) != 0)
net->flags |= IFF_NOARP;
- if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
- net->max_mtu > (dev->hard_mtu - net->hard_header_len))
- net->max_mtu = dev->hard_mtu - net->hard_header_len;
-
if (net->mtu > (dev->hard_mtu - net->hard_header_len))
net->mtu = dev->hard_mtu - net->hard_header_len;
@@ -1851,6 +1847,10 @@ usbnet_probe(struct usb_interface *udev, const struct usb_device_id *prod)
if (status == 0 && !usb_check_bulk_endpoints(udev, ep_addrs))
status = -EINVAL;
}
+ if ((dev->driver_info->flags & FLAG_NOMAXMTU) == 0 &&
+ net->max_mtu > (dev->hard_mtu - net->hard_header_len))
+ net->max_mtu = dev->hard_mtu - net->hard_header_len;
+
if (status >= 0 && dev->status)
status = init_status(dev, udev);
if (status < 0)
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next v2 2/2] net: phy: Add support for the Maxio MAE0621A
From: Andrew Lunn @ 2026-07-17 15:15 UTC (permalink / raw)
To: Liu Changjie
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Luo Jie, Wolfram Sang,
devicetree, linux-kernel
In-Reply-To: <MN0PR19MB609153A4A590C66241B8A3CDACC62@MN0PR19MB6091.namprd19.prod.outlook.com>
On Fri, Jul 17, 2026 at 11:44:03AM +0800, Liu Changjie wrote:
> Add exact PHY ID matching and optional 125 MHz CLKOUT configuration
> for the Maxio MAE0621A Gigabit Ethernet PHY. Preserve the existing
> hardware configuration when the firmware property is absent.
>
> Signed-off-by: Liu Changjie <liucj1228@outlook.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] vhost-scsi: Prevent OOM from invalid protection SGL count
From: Mike Christie @ 2026-07-17 15:13 UTC (permalink / raw)
To: Jia Jia, mst, jasowang, Linfeng Sun
Cc: pbonzini, stefanha, eperezma, virtualization, kvm, netdev,
linux-kernel, stable
In-Reply-To: <20260717142205.103515-1-physicalmtea@gmail.com>
cc'ing Linfeng.
Linfeng also reported this bug and provided a patch that has your check
and an extra check to avoid calling into the function in the first
place. It's been stuck in some other list.
I think it might be best for Linfeng to re-submit their patch now so it
can get merged. For that patch, I think there was one outstanding
question left where Michael had asked if the issue was found with AI so
the proper tag could be added. I don't think that question was responded to.
On 7/17/26 9:22 AM, Jia Jia wrote:
> The protection SGL path passes the result of vhost_scsi_calc_sgls()
> directly to sg_alloc_table_chained(). The helper returns a negative
> errno when the iterator is invalid or the request exceeds the segment
> limit. The negative errno is then treated as a very large unsigned count
> and sends the request into the SGL allocation path with an invalid size.
>
> Repeated malformed T10-PI submissions from a host-side application caused
> memory usage to rise sharply. MemAvailable fell to about 200 MB, and PSI
> full avg10 reached about 1.46. The OOM killer terminated several userspace
> processes before the endpoint cleanup completed. The kernel log included:
>
> [17036.451028] Out of memory: Killed process 2345 (systemd)
> [17036.493325] Out of memory: Killed process 2349 (sd-pam)
> [17078.265127] Out of memory: Killed process 1793 (networkd-dispat)
>
> Return the calculation error before setting up the protection SGL. This
> keeps the protection path consistent with the data SGL path and prevents
> the invalid count from entering the allocation path.
>
> Fixes: bca939d5bcd0 ("vhost-scsi: Dynamically allocate scatterlists")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jia Jia <physicalmtea@gmail.com>
> ---
> drivers/vhost/scsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 9a1253b9d..8486652fd 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -972,6 +972,9 @@ vhost_scsi_mapal(struct vhost_scsi *vs, struct vhost_scsi_cmd *cmd,
> if (prot_bytes) {
> sgl_count = vhost_scsi_calc_sgls(prot_iter, prot_bytes,
> VHOST_SCSI_PREALLOC_PROT_SGLS);
> + if (sgl_count < 0)
> + return sgl_count;
> +
> cmd->prot_table.sgl = cmd->prot_sgl;
> ret = sg_alloc_table_chained(&cmd->prot_table, sgl_count,
> cmd->prot_table.sgl,
> --
> 2.43.0
>
^ permalink raw reply
* Re: [Patch net-next v3] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-17 15:11 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, ming.xu, xiaolin.xu, jianmin.wang, jie.han
In-Reply-To: <20260717054807.1321374-1-kyle.switch@motor-comm.com>
> +/**
> + * ytphy_read_top_ext() - read a PHY's top extended register for YT8824
> + * @phydev: a pointer to a &struct phy_device
> + * @regnum: register number to read
> + *
> + * NOTE:The caller must have taken the MDIO bus lock.
Didn't i request this is done in code, not comments?
> +static int ytphy_read_top_ext(struct phy_device *phydev, u16 regnum)
> +{
> + struct yt8824_shared_priv *shared_priv;
> + unsigned int offset;
> + int ret;
> +
> + shared_priv = phy_package_get_priv(phydev);
> + offset = shared_priv->offset;
> + ret = __phy_package_write(phydev, offset, YTPHY_PAGE_SELECT, regnum);
You look to be using the package wrongly.
https://elixir.bootlin.com/linux/v7.1.3/source/drivers/net/phy/phy_package.c#L192
* The base_addr parameter serves as cookie which has to have the same values
* for all members of one group and as the base PHY address of the PHY package
* for offset calculation to access generic registers of a PHY package.
* Usually, one of the PHY addresses of the different PHYs in the package
* provides access to these global registers.
* The address which is given here, will be used in the __phy_package_read()
* and __phy_package_write() convenience functions as base and added to the
* passed offset in those functions.
Although it is called base, it can be above all the others. So when
you create the package, set the cookie value to your top address. You
can then use __phy_package_write() directly, offset of 0.
> -static struct phy_driver motorcomm_phy_drvs[] = {
> - {
> - PHY_ID_MATCH_EXACT(PHY_ID_YT8511),
> - .name = "YT8511 Gigabit Ethernet",
> - .config_init = yt8511_config_init,
> - .suspend = genphy_suspend,
> - .resume = genphy_resume,
> - .read_page = yt8511_read_page,
> - .write_page = yt8511_write_page,
> - },
I still don't like this. Please stop diff deleting all these and
putting them back later. It makes me thing something changed, maybe
white space?
> +static int yt8824_utp_softreset_paged(struct phy_device *phydev,
> + int reg_space)
> +{
> + int old_page;
> + int ret = 0;
> + int val;
> +
> + old_page = phy_select_page(phydev, reg_space);
> + if (old_page < 0)
> + goto err_restore_page;
> + if (reg_space == YT8824_RSSR_UTP_SPACE) {
> + ret = __phy_read(phydev, MII_BMCR);
> + if (ret < 0)
> + goto err_restore_page;
> + ret |= BMCR_RESET;
> + ret = __phy_write(phydev, MII_BMCR, ret);
So here you are using __phy_write() so it does not take the mdio lock.
> + if (ret < 0)
> + goto err_restore_page;
> + /* wait until softreset done. */
> + ret = phy_read_poll_timeout(phydev, MII_BMCR, val, !(val & BMCR_RESET),
> + 50000, 600000, true);
This uses phy_read(), so does take the lock.
How can this be correct?
Please take some time to think about locking. Please enable all the
locking debug options in the kernel and see if you get splats. And
also really do turn your locking comments into code.
Andrew
^ permalink raw reply
* Re: [PATCH net v3] sctp: socket: remove unused 'err' parameter from sctp_skb_recv_datagram
From: Xin Long @ 2026-07-17 15:10 UTC (permalink / raw)
To: luoqing
Cc: jedrzej.jagielski, davem, edumazet, horms, kuba, linux-kernel,
linux-sctp, luoqing, marcelo.leitner, netdev, pabeni
In-Reply-To: <20260717082048.948262-1-l1138897701@163.com>
On Fri, Jul 17, 2026 at 4:21 AM luoqing <l1138897701@163.com> wrote:
>
> From: luoqing <luoqing@kylinos.cn>
>
> The 'err' parameter in sctp_skb_recv_datagram() is never used by any
> of its callers. Both sctp_recvmsg() and sctp_ulpevent_read_nxtinfo()
> pass the address of a local variable but never check its value after
> the function returns, rendering the parameter completely useless.
>
> Remove the unused parameter to simplify the function signature and
> eliminate dead code.
>
> Signed-off-by: luoqing <luoqing@kylinos.cn>
> ---
> include/net/sctp/sctp.h | 2 +-
> net/sctp/socket.c | 10 +++-------
> net/sctp/ulpevent.c | 3 +--
> 3 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index d50c27812504..b86d50d6b146 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -97,7 +97,7 @@ void sctp_sock_rfree(struct sk_buff *skb);
>
> extern struct percpu_counter sctp_sockets_allocated;
> int sctp_asconf_mgmt(struct sctp_sock *, struct sctp_sockaddr_entry *);
> -struct sk_buff *sctp_skb_recv_datagram(struct sock *, int, int *);
> +struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags);
>
> typedef int (*sctp_callback_t)(struct sctp_endpoint *, struct sctp_transport *, void *);
> void sctp_transport_walk_start(struct rhashtable_iter *iter);
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index c7b9e325ec1c..3804382d78e0 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2123,7 +2123,7 @@ static int sctp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
> goto out;
> }
>
> - skb = sctp_skb_recv_datagram(sk, flags, &err);
> + skb = sctp_skb_recv_datagram(sk, flags);
> if (!skb)
> goto out;
>
> @@ -9082,7 +9082,7 @@ static int sctp_wait_for_packet(struct sock *sk, int *err, long *timeo_p)
> * Note: This is pretty much the same routine as in core/datagram.c
> * with a few changes to make lksctp work.
> */
> -struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags, int *err)
> +struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags)
> {
> int error;
> struct sk_buff *skb;
> @@ -9120,17 +9120,13 @@ struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags, int *err)
> if (sk->sk_shutdown & RCV_SHUTDOWN)
> break;
>
> -
> /* User doesn't want to wait. */
> error = -EAGAIN;
> if (!timeo)
> goto no_packet;
> - } while (sctp_wait_for_packet(sk, err, &timeo) == 0);
> -
> - return NULL;
> + } while (sctp_wait_for_packet(sk, &error, &timeo) == 0);
>
> no_packet:
> - *err = error;
> return NULL;
> }
>
> diff --git a/net/sctp/ulpevent.c b/net/sctp/ulpevent.c
> index 8920ca92a011..8ed51a15c3a4 100644
> --- a/net/sctp/ulpevent.c
> +++ b/net/sctp/ulpevent.c
> @@ -1061,9 +1061,8 @@ void sctp_ulpevent_read_nxtinfo(const struct sctp_ulpevent *event,
> struct sock *sk)
> {
> struct sk_buff *skb;
> - int err;
>
> - skb = sctp_skb_recv_datagram(sk, MSG_PEEK | MSG_DONTWAIT, &err);
> + skb = sctp_skb_recv_datagram(sk, MSG_PEEK | MSG_DONTWAIT);
> if (skb != NULL) {
> __sctp_ulpevent_read_nxtinfo(sctp_skb2event(skb),
> msghdr, skb);
> --
> 2.25.1
>
I think it's used at [1] in sctp_recvmsg():
skb = sctp_skb_recv_datagram(sk, flags, &err);
if (!skb)
goto out;
...
out:
release_sock(sk);
return err; <------ [1]
Thanks.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: sctp: socket: Fix uninitialized error on socket shutdown
From: Xin Long @ 2026-07-17 15:02 UTC (permalink / raw)
To: luoqing
Cc: marcelo.leitner, davem, edumazet, kuba, pabeni, horms, linux-sctp,
netdev, linux-kernel, luoqing
In-Reply-To: <20260716100407.1490724-1-l1138897701@163.com>
On Thu, Jul 16, 2026 at 6:05 AM luoqing <l1138897701@163.com> wrote:
>
> From: luoqing <luoqing@kylinos.cn>
>
> When sctp_skb_recv_datagram() detects sk->sk_shutdown & RCV_SHUTDOWN,
> it breaks out of the loop and returns NULL without setting *err.
> This leaves the error pointer uninitialized or with a stale value,
> which can confuse callers expecting a clean shutdown indication.
>
> Compare with the generic __skb_wait_for_more_packets() in
> net/core/datagram.c which properly handles shutdown by setting *err = 0.
>
> Fix this by setting *err = 0 before breaking when the socket is shut down,
> indicating an orderly shutdown rather than an error condition.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> Signed-off-by: luoqing <luoqing@kylinos.cn>
> ---
> net/sctp/socket.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index c7b9e325ec1c..ea7050b27715 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -9117,8 +9117,10 @@ struct sk_buff *sctp_skb_recv_datagram(struct sock *sk, int flags, int *err)
> if (error)
> goto no_packet;
>
> - if (sk->sk_shutdown & RCV_SHUTDOWN)
> + if (sk->sk_shutdown & RCV_SHUTDOWN) {
> + *err = 0;
> break;
> + }
>
>
> /* User doesn't want to wait. */
> --
> 2.25.1
>
This patch doesn't really fix issues, please drop it.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/2] net: sctp: auth: Fix safety issue when skb_clone fails in auth_chunk handling
From: Xin Long @ 2026-07-17 15:01 UTC (permalink / raw)
To: luoqing
Cc: marcelo.leitner, davem, edumazet, kuba, pabeni, horms, linux-sctp,
netdev, linux-kernel, luoqing
In-Reply-To: <20260716100407.1490724-2-l1138897701@163.com>
On Thu, Jul 16, 2026 at 6:05 AM luoqing <l1138897701@163.com> wrote:
>
> From: luoqing <luoqing@kylinos.cn>
>
> When processing AUTH + COOKIE-ECHO packets, if skb_clone fails due to
> memory pressure, chunk->auth_chunk is set to NULL but chunk->auth is
> still set to 1. This causes sctp_auth_chunk_verify to skip the AUTH
> validation (since auth_chunk is NULL), allowing unauthenticated
> COOKIE-ECHO packets to be accepted.
>
> Fix this by only setting chunk->auth = 1 when skb_clone succeeds.
>
> Fixes: 59d8d4434f429b ("sctp: delay the authentication for the duplicated cookie-echo chunk")
>
> Signed-off-by: luoqing <luoqing@kylinos.cn>
> ---
> net/sctp/associola.c | 3 ++-
> net/sctp/endpointola.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/associola.c b/net/sctp/associola.c
> index 62d3cc155809..e54068305396 100644
> --- a/net/sctp/associola.c
> +++ b/net/sctp/associola.c
> @@ -999,7 +999,8 @@ static void sctp_assoc_bh_rcv(struct work_struct *work)
> if (next_hdr->type == SCTP_CID_COOKIE_ECHO) {
> chunk->auth_chunk = skb_clone(chunk->skb,
> GFP_ATOMIC);
> - chunk->auth = 1;
> + if (chunk->auth_chunk)
> + chunk->auth = 1;
> continue;
> }
> }
> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
> index dfb1719275db..3419748c66bc 100644
> --- a/net/sctp/endpointola.c
> +++ b/net/sctp/endpointola.c
> @@ -368,7 +368,8 @@ static void sctp_endpoint_bh_rcv(struct work_struct *work)
> if (next_hdr->type == SCTP_CID_COOKIE_ECHO) {
> chunk->auth_chunk = skb_clone(chunk->skb,
> GFP_ATOMIC);
> - chunk->auth = 1;
> + if (chunk->auth_chunk)
> + chunk->auth = 1;
> continue;
> }
> }
> --
> 2.25.1
>
The patch does not fully address the issues reported by Sashiko in the
following two cases (I will interpret them below):
1. [sashiko-gemini]:
When skb_clone() fails, chunk->auth_chunk is set to NULL and chunk->auth
remains 0. In this case, the chunk will be dropped/skipped in
sctp_assoc_bh_rcv() by the following check:
if (sctp_auth_recv_cid(subtype.chunk, asoc) && !chunk->auth)
continue;
This works as expected because the chunk is skipped. However, in
sctp_endpoint_bh_rcv(), asoc is NULL for new connections, so the above
condition is always false. As a result, the COOKIE-ECHO chunk can still be
processed with chunk->auth_chunk == NULL.
2. [sashiko-claude]:
When the association requires authentication for the COOKIE-ECHO chunk, but
the packet does not contain an AUTH chunk, skb_clone() is never called and
chunk->auth_chunk remains NULL. Since the new association is also NULL in
sctp_endpoint_bh_rcv(), the check above cannot catch this case either. The
COOKIE-ECHO chunk will still be processed with chunk->auth_chunk == NULL.
A better fix would be:
Add a check in sctp_auth_chunk_verify() at the point where the COOKIE-ECHO
chunk is actually being processed:
if (!chunk->auth_chunk)
return !sctp_auth_recv_cid(chunk->chunk_hdr->type, asoc);
This ensures that if chunk->auth_chunk is missing while authentication is
required for the COOKIE-ECHO chunk, the verification fails and the chunk is
dropped. Otherwise, when authentication is not required, processing can
continue normally.
Please give it a try.
Thanks.
^ permalink raw reply
* Re: [Patch net-next v3] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-17 14:53 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, ming.xu, xiaolin.xu, jianmin.wang, jie.han
In-Reply-To: <20260717054807.1321374-1-kyle.switch@motor-comm.com>
On Fri, Jul 17, 2026 at 01:48:07PM +0800, Kyle Switch wrote:
> Add a driver for motorcomm yt8824 quad 2.5G ethernet phy, supports
> 2.5G/1000M/100M/10M speed.
>
> Signed-off-by: Kyle Switch <kyle.switch@motor-comm.com>
> ---
>
> changes in v3:
> 1. Using common apis defined in phy_package.c to handle shared top
> extend register space.
> 2. Add dts demo in motorcomm,yt8xxx.yaml.
> 3. Fix unnecessary redundant judgments.
> 4. Fix BMCR registers operation using magic number.
> 5. Rename funtion based on its approximate functionality.
>
> changes in v2:
> 1. Remove duplicate code and replace it with existing api.
>
> .../bindings/net/motorcomm,yt8xxx.yaml | 30 +
Please put binding changes in a patch of its own, in the patch
series. You also need to Cc: the DT people.
Andrew
---
pw-bot: cr
^ permalink raw reply
* [PATCH] net: ipv6: fix a potential use-after-free in ip4ip6_err
From: lirongqing @ 2026-07-17 14:33 UTC (permalink / raw)
To: David Ahern, Ido Schimmel, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Xin Long, netdev,
linux-kernel
Cc: Li RongQing
From: Li RongQing <lirongqing@baidu.com>
Fix a use-after-free bug in ip4ip6_err() where rt->rt_flags is accessed
after the route entry object has been released via ip_rt_put(rt).
If ip_rt_put() decrements the reference count to zero and frees the
rtable structure, reading rt->rt_flags immediately afterward
results in a use-after-free pointer dereference.
Fix this by caching rt->rt_flags into a local variable before calling
ip_rt_put().
Fixes: 77552cfa39c4 ("ip6_tunnel: clean up ip4ip6 and ip6ip6's err_handlers")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv6/ip6_tunnel.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index bf8e40a..984cb0c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -569,6 +569,7 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
{
__u32 rel_info = ntohl(info);
const struct iphdr *eiph;
+ unsigned int rt_flags;
struct sk_buff *skb2;
int err, rel_msg = 0;
u8 rel_type = type;
@@ -627,10 +628,11 @@ ip4ip6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
goto out;
skb2->dev = rt->dst.dev;
+ rt_flags = rt->rt_flags;
ip_rt_put(rt);
/* route "incoming" packet */
- if (rt->rt_flags & RTCF_LOCAL) {
+ if (rt_flags & RTCF_LOCAL) {
rt = ip_route_output_ports(dev_net(skb->dev), &fl4, NULL,
eiph->daddr, eiph->saddr, 0, 0,
IPPROTO_IPIP,
--
2.9.4
^ permalink raw reply related
* [PATCH] net: ipv6: fix dif and sdif mismatch in raw6_icmp_error
From: lirongqing @ 2026-07-17 14:32 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, Li RongQing,
Kees Cook, netdev, linux-kernel
From: Li RongQing <lirongqing@baidu.com>
In raw6_icmp_error(), raw_v6_match() is called with inet6_iif(skb) passed
to both the 'dif' and 'sdif' arguments. This is a copy-paste or typo error,
as the last argument should represent the secondary interface index (sdif).
This mismatch breaks ICMPv6 error handling for IPv6 raw sockets in VRF
(Virtual Routing and Forwarding) environments. When a raw socket is bound
to a VRF master device, raw_v6_match() fails to find a match because it is
not given the correct sdif value, causing the socket to miss relevant
ICMPv6 error notifications.
Fix this by properly passing inet6_sdif(skb) as the last argument to
raw_v6_match().
Fixes: 5108ab4bf446fa ("net: ipv6: add second dif to raw socket lookups")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/ipv6/raw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 3cc5869..b88d364 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -349,7 +349,7 @@ void raw6_icmp_error(struct sk_buff *skb, int nexthdr,
const struct ipv6hdr *ip6h = (const struct ipv6hdr *)skb->data;
if (!raw_v6_match(net, sk, nexthdr, &ip6h->saddr, &ip6h->daddr,
- inet6_iif(skb), inet6_iif(skb)))
+ inet6_iif(skb), inet6_sdif(skb)))
continue;
rawv6_err(sk, skb, type, code, inner_offset, info);
}
--
2.9.4
^ permalink raw reply related
* Re: [PATCH] wifi: mwifiex: validate HT/VHT element length before storing beacon IE pointers
From: Francesco Dolcini @ 2026-07-17 14:31 UTC (permalink / raw)
To: Christopher Kleiner
Cc: briannorris, linux-wireless, francesco, netdev, linux-kernel
In-Reply-To: <20260717000017.61415-1-chris@kleiner.pro>
On Thu, Jul 16, 2026 at 08:00:17PM -0400, Christopher Kleiner wrote:
> mwifiex_update_bss_desc_with_ie() stores raw pointers into the beacon
> buffer for the HT Capability, HT Operation, VHT Capability and VHT
> Operation elements without checking that the element is long enough to
> hold the corresponding fixed-size structure. The generic IE loop only
> guarantees that the declared element length fits inside the beacon
> buffer (bytes_left >= total_ie_len); it does not guarantee that
> element_len is large enough for the struct that later consumers copy.
>
> beacon_buf is a tight kmemdup() of the over-the-air IEs. When the
> association command is built, mwifiex_cmd_append_11n_tlv() /
> mwifiex_cmd_append_11ac_tlv() copy a fixed number of bytes from the
> stored pointers (sizeof(struct ieee80211_ht_cap) and friends). A
> malicious AP that emits a beacon or probe response ending in a
> truncated (e.g. zero-length) HT Capability element leaves bcn_ht_cap
> pointing near the end of the slab, and the subsequent copy reads out of
> bounds. The leaked bytes are placed into the association request
> transmitted back to the AP, disclosing adjacent slab memory; on
> CONFIG_KASAN / panic_on_oops kernels it is an out-of-bounds oops.
>
> Commit 685c9b7750bf ("mwifiex: Abort at too short BSS descriptor
> element") added such length checks for the FH/DS/CF/IBSS parameter sets
> and a few other elements, but did not cover the HT/VHT capability and
> operation elements. Validate element_len against the size of the
> structure that will be consumed, mirroring those existing checks.
>
> Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Christopher Kleiner <chris@kleiner.pro>
Duplicate? We already have this in review https://lore.kernel.org/all/20260709100800.7026-1-doruk@0sec.ai/
^ 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