* Re: [PATCH net] vsock/test: fix send_buf()/recv_buf() EINTR handling
From: patchwork-bot+netdevbpf @ 2026-04-07 1:50 UTC (permalink / raw)
To: Stefano Garzarella; +Cc: netdev, davem, avkrasnov, linux-kernel, virtualization
In-Reply-To: <20260403093251.30662-1-sgarzare@redhat.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 11:32:51 +0200 you wrote:
> From: Stefano Garzarella <sgarzare@redhat.com>
>
> When send() or recv() returns -1 with errno == EINTR, the code skips
> the break but still adds the return value to nwritten/nread, making it
> decrease by 1. This leads to wrong buffer offsets and wrong bytes count.
>
> Fix it by explicitly continuing the loop on EINTR, so the return value
> is only added when it is positive.
>
> [...]
Here is the summary with links:
- [net] vsock/test: fix send_buf()/recv_buf() EINTR handling
https://git.kernel.org/netdev/net/c/24ad7ff66889
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v6 net 0/8] xsk: tailroom reservation and MTU validation
From: patchwork-bot+netdevbpf @ 2026-04-07 1:50 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: netdev, bpf, magnus.karlsson, stfomichev, kuba, pabeni, horms,
larysa.zaremba, aleksander.lobakin, bjorn
In-Reply-To: <20260402154958.562179-1-maciej.fijalkowski@intel.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 17:49:50 +0200 you wrote:
> v5->v6:
> - refrain from relying on umem refcnt when disabling zc on error path
> (Sashiko)
> - have a separate __xsk_pool_get_rx_frame_size() which preserves old
> behavior and use it on copy path (Sashiko)
> - drop driver cleanups
>
> [...]
Here is the summary with links:
- [v6,net,1/8] xsk: tighten UMEM headroom validation to account for tailroom and min frame
https://git.kernel.org/netdev/net/c/a315e022a72d
- [v6,net,2/8] xsk: respect tailroom for ZC setups
https://git.kernel.org/netdev/net/c/1ee1605138fc
- [v6,net,3/8] xsk: fix XDP_UMEM_SG_FLAG issues
https://git.kernel.org/netdev/net/c/93e84fe45b75
- [v6,net,4/8] xsk: validate MTU against usable frame size on bind
https://git.kernel.org/netdev/net/c/36ee60b569ba
- [v6,net,5/8] selftests: bpf: introduce a common routine for reading procfs
https://git.kernel.org/netdev/net/c/c5866a6be472
- [v6,net,6/8] selftests: bpf: fix pkt grow tests
https://git.kernel.org/netdev/net/c/3197c51ce2fa
- [v6,net,7/8] selftests: bpf: have a separate variable for drop test
https://git.kernel.org/netdev/net/c/16546954e117
- [v6,net,8/8] selftests: bpf: adjust rx_dropped xskxceiver's test to respect tailroom
https://git.kernel.org/netdev/net/c/62838e363e4f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v2] net: skb: fix cross-cache free of KFENCE-allocated skb head
From: patchwork-bot+netdevbpf @ 2026-04-07 1:50 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, antonius, davem, edumazet, kuba, pabeni, horms,
kerneljasonxing, kuniyu, mhal, almasrymina, ebiggers, toke,
alexanderduyck, soheil, linux-kernel, bpf
In-Reply-To: <20260403014517.142550-1-jiayuan.chen@linux.dev>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 3 Apr 2026 09:45:12 +0800 you wrote:
> SKB_SMALL_HEAD_CACHE_SIZE is intentionally set to a non-power-of-2
> value (e.g. 704 on x86_64) to avoid collisions with generic kmalloc
> bucket sizes. This ensures that skb_kfree_head() can reliably use
> skb_end_offset to distinguish skb heads allocated from
> skb_small_head_cache vs. generic kmalloc caches.
>
> However, when KFENCE is enabled, kfence_ksize() returns the exact
> requested allocation size instead of the slab bucket size. If a caller
> (e.g. bpf_test_init) allocates skb head data via kzalloc() and the
> requested size happens to equal SKB_SMALL_HEAD_CACHE_SIZE, then
> slab_build_skb() -> ksize() returns that exact value. After subtracting
> skb_shared_info overhead, skb_end_offset ends up matching
> SKB_SMALL_HEAD_HEADROOM, causing skb_kfree_head() to incorrectly free
> the object to skb_small_head_cache instead of back to the original
> kmalloc cache, resulting in a slab cross-cache free:
>
> [...]
Here is the summary with links:
- [net,v2] net: skb: fix cross-cache free of KFENCE-allocated skb head
https://git.kernel.org/netdev/net/c/0f42e3f4fe2a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v6 net 3/8] xsk: fix XDP_UMEM_SG_FLAG issues
From: Jakub Kicinski @ 2026-04-07 1:45 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: netdev, bpf, magnus.karlsson, stfomichev, pabeni, horms,
larysa.zaremba, aleksander.lobakin, bjorn
In-Reply-To: <adDjtUbNPSjffLSm@boxer>
On Sat, 4 Apr 2026 12:11:01 +0200 Maciej Fijalkowski wrote:
> > BUILD_BUG_ON(XDP_UMEM_SG_FLAG & XDP_UMEM_FLAGS_VALID)
> >
> > somewhere or use a hack like this ?
> >
> > #define XDP_UMEM_SG_FLAG (XDP_UMEM_FLAGS_VALID + 1)
>
> Good idea i'd lean towards the latter version. I can send v7 after easter
> or if there wouldn't be other issues related to set maybe maintainer could
> adjust it? ;)
Quick edit breaks the build, probably missing an include.
Let's leave it for a follow up 'cause I'm gonna break something :S
^ permalink raw reply
* Re: [PATCH net-next] ipv6: sit: remove redundant ret = 0 assignment
From: Jakub Kicinski @ 2026-04-07 1:43 UTC (permalink / raw)
To: Yue Haibing; +Cc: davem, dsahern, edumazet, pabeni, horms, netdev, linux-kernel
In-Reply-To: <20260403084402.4105936-1-yuehaibing@huawei.com>
On Fri, 3 Apr 2026 16:44:02 +0800 Yue Haibing wrote:
> The variable ret is initialized to 0 when it is defined
> and is not modified before copy_to_user().
Makes more sense to remove the init during definition IMO.
^ permalink raw reply
* Re: [PATCH net-next v2] vsock: avoid timeout for non-blocking accept() with empty backlog
From: patchwork-bot+netdevbpf @ 2026-04-07 1:40 UTC (permalink / raw)
To: Laurence Rowe
Cc: sgarzare, davem, edumazet, kuba, pabeni, horms, virtualization,
netdev, bobbyeshleman
In-Reply-To: <20260402204918.130395-1-laurencerowe@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 13:49:18 -0700 you wrote:
> A common pattern in epoll network servers is to eagerly accept all
> pending connections from the non-blocking listening socket after
> epoll_wait indicates the socket is ready by calling accept in a loop
> until EAGAIN is returned indicating that the backlog is empty.
>
> Scheduling a timeout for a non-blocking accept with an empty backlog
> meant AF_VSOCK sockets used by epoll network servers incurred hundreds
> of microseconds of additional latency per accept loop compared to
> AF_INET or AF_UNIX sockets.
>
> [...]
Here is the summary with links:
- [net-next,v2] vsock: avoid timeout for non-blocking accept() with empty backlog
https://git.kernel.org/netdev/net-next/c/98f28d8d6e5a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 net-next] net: advance skb_defer_disable_key check in napi_consume_skb
From: patchwork-bot+netdevbpf @ 2026-04-07 1:40 UTC (permalink / raw)
To: Jason Xing; +Cc: davem, edumazet, kuba, pabeni, horms, netdev, kernelxing
In-Reply-To: <20260402034114.65766-1-kerneljasonxing@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 11:41:14 +0800 you wrote:
> From: Jason Xing <kernelxing@tencent.com>
>
> When net.core.skb_defer_max is adjusted to zero, napi_consume_skb()
> shouldn't go into that deeper in skb_attempt_defer_free() because it adds
> an additional pair of local_bh_enable/disable() which is evidently not
> needed. Advancing the check of the static key saves more cycles and
> benefits non defer case.
>
> [...]
Here is the summary with links:
- [v4,net-next] net: advance skb_defer_disable_key check in napi_consume_skb
https://git.kernel.org/netdev/net-next/c/8a4e3ab61d49
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: dsa: mxl862xx: add support for bridge offloading
From: patchwork-bot+netdevbpf @ 2026-04-07 1:40 UTC (permalink / raw)
To: Daniel Golle
Cc: andrew, olteanv, davem, edumazet, kuba, pabeni, mmyangfl, horms,
linux, netdev, linux-kernel, frankwu, chad, cezary.wilmanski, lxu,
yweng, jverdu, ajayaraman, john
In-Reply-To: <cover.1775049897.git.daniel@makrotopia.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 1 Apr 2026 14:34:11 +0100 you wrote:
> As a next step to complete the mxl862xx DSA driver, add support for
> offloading forwarding between bridged ports to the switch hardware.
>
> This works pretty much without any big surprises, apart from two
> subtleties:
> * per-port control over flooding behavior has to be implemented by
> (ab)using a 0-rate QoS meters as stopper in lack of any better
> option.
> * STP state transition unconditionally enables learning on a port
> even if it was previously explicitely disabled (a firmware bug)
>
> [...]
Here is the summary with links:
- [net-next,v9,1/4] net: dsa: move dsa_bridge_ports() helper to dsa.h
https://git.kernel.org/netdev/net-next/c/b0a79590d108
- [net-next,v9,2/4] net: dsa: add bridge member iteration macro
https://git.kernel.org/netdev/net-next/c/f259e08494c4
- [net-next,v9,3/4] dsa: tag_mxl862xx: set dsa_default_offload_fwd_mark()
https://git.kernel.org/netdev/net-next/c/4250ff1640ea
- [net-next,v9,4/4] net: dsa: mxl862xx: implement bridge offloading
https://git.kernel.org/netdev/net-next/c/340bdf984613
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v1 17/22] dt-bindings: clock: Add StarFive JHB100 Peripheral-2 clock and reset generator
From: Changhuang Liang @ 2026-04-07 1:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Philipp Zabel, Emil Renner Berthing, Kees Cook,
Gustavo A . R . Silva, Richard Cochran, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-hardening@vger.kernel.org,
netdev@vger.kernel.org, JeeHeng Sia, Hal Feng, Leyfoon Tan
In-Reply-To: <20260404-valiant-auburn-raven-c24be6@quoll>
Hi, Krzysztof
Thanks for the review.
> On Thu, Apr 02, 2026 at 03:55:18AM -0700, Changhuang Liang wrote:
> > + clocks:
> > + items:
> > + - description: Peripheral-2 600MHz
> > + - description: Peripheral-2 400MHz
> > + - description: Peripheral-2 125MHz
> > + - description: Peripheral-2 GMAC2 RGMII RX
> > + - description: Peripheral-2 GMAC2 RMII Reference
> > + - description: Peripheral-2 GMAC3 SGMII TX
> > + - description: Peripheral-2 GMAC3 SGMII RX
> > + - description: Main Oscillator (25 MHz)
> > +
> > + clock-names:
> > + items:
> > + - const: per2_600
>
> Does not have any meaningful name in datasheet / clock hierarchy?
Yes, some clocks are named directly by frequency.
I will try to find if there are other meaningful naming options.
Best Regards,
Changhuang
^ permalink raw reply
* Re: [PATCH bpf-next v3] bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb
From: sun jian @ 2026-04-07 1:34 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: ast, daniel, andrii, eddyz87, song, yonghong.song, john.fastabend,
kpsingh, sdf, haoluo, jolsa, davem, edumazet, kuba, pabeni, horms,
shuah, syzbot+619b9ef527f510a57cfc, bpf, netdev, linux-kernel,
linux-kselftest
In-Reply-To: <202646183934.lJx5.martin.lau@linux.dev>
On Tue, Apr 7, 2026 at 2:58 AM Martin KaFai Lau <martin.lau@linux.dev> wrote:
>
> On Fri, Apr 03, 2026 at 12:01:47AM +0800, Sun Jian wrote:
> > diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c
> > index 178c4738e63b..300e2bfc5a62 100644
> > --- a/net/bpf/test_run.c
> > +++ b/net/bpf/test_run.c
> > @@ -1120,19 +1120,23 @@ int bpf_prog_test_run_skb(struct bpf_prog *prog, const union bpf_attr *kattr,
> >
> > switch (skb->protocol) {
> > case htons(ETH_P_IP):
> > - sk->sk_family = AF_INET;
> > - if (sizeof(struct iphdr) <= skb_headlen(skb)) {
> > - sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
> > - sk->sk_daddr = ip_hdr(skb)->daddr;
> > + if (skb_headlen(skb) < sizeof(struct iphdr)) {
> > + ret = -EINVAL;
> > + goto out;
> > }
> > + sk->sk_family = AF_INET;
> > + sk->sk_rcv_saddr = ip_hdr(skb)->saddr;
> > + sk->sk_daddr = ip_hdr(skb)->daddr;
> > break;
> > #if IS_ENABLED(CONFIG_IPV6)
> > case htons(ETH_P_IPV6):
> > - sk->sk_family = AF_INET6;
> > - if (sizeof(struct ipv6hdr) <= skb_headlen(skb)) {
> > - sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
> > - sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
> > + if (skb_headlen(skb) < sizeof(struct ipv6hdr)) {
> > + ret = -EINVAL;
> > + goto out;
> > }
> > + sk->sk_family = AF_INET6;
> > + sk->sk_v6_rcv_saddr = ipv6_hdr(skb)->saddr;
> > + sk->sk_v6_daddr = ipv6_hdr(skb)->daddr;
> > break;
> > #endif
> > default:
> > diff --git a/tools/testing/selftests/bpf/prog_tests/empty_skb.c b/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> > index 438583e1f2d1..d53567e9cd77 100644
> > --- a/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> > +++ b/tools/testing/selftests/bpf/prog_tests/empty_skb.c
> > @@ -12,6 +12,8 @@ void test_empty_skb(void)
> > struct bpf_program *prog;
> > char eth_hlen_pp[15];
> > char eth_hlen[14];
> > + char ipv4_eth_hlen[14];
> > + char ipv6_eth_hlen[14];
>
> The eth_hlen_pp and eth_hlen needs to memset zero now.
>
> Instead of adding two more ethhdrs, just reuse the current eth_hlen and
> define it as 'struct ethhdr eth_hlen;' instead of a char array.
> Add 'h_proto' to the anonymous 'struct { } tests[]'. Initialize
> the eth_hlen.h_proto based on the tests[i].h_proto.
>
> Also, this test does not actually reproduce the reading uninit memeory.
> It needs a bpf prog to actually trigger it by calling bpf_skb_adjust_room()
> based on the report in the "Closes" link. The test should be able
> to trigger it without the change in test_run.c
>
> The ai-review has flagged again that it is missing a "Fixes" tag. This
> probably started since the bpf_skb_adjust_room helper was introduced.
>
> The selftests should also be in a separate patch 2 following the patch 1
> changes in test_run.c.
>
> pw-bot: cr
Ack. I'll split this into two patches and rework the selftest accordingly.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: use get_random_u{16,32,64}() where appropriate
From: Julian Calaby @ 2026-04-07 1:33 UTC (permalink / raw)
To: David Carlier
Cc: Jakub Kicinski, David S . Miller, Eric Dumazet, Paolo Abeni,
Andrew Lunn, Simon Horman, Ilya Dryomov, Johannes Berg,
Matthieu Baerts, Mat Martineau, Geliang Tang, Aaron Conole,
Ilya Maximets, Marcelo Ricardo Leitner, Xin Long, Jon Maloy,
netdev, ceph-devel, linux-wireless, mptcp, dev, linux-sctp,
tipc-discussion, linux-kernel
In-Reply-To: <20260405154816.4774-1-devnexen@gmail.com>
Hi David,
On Mon, Apr 6, 2026 at 1:50 AM David Carlier <devnexen@gmail.com> wrote:
>
> Use the typed random integer helpers instead of
> get_random_bytes() when filling a single integer variable.
> The helpers return the value directly, require no pointer
> or size argument, and better express intent.
>
> Skipped sites writing into __be16 fields (netdevsim) where
> a direct assignment would trigger sparse endianness warnings.
I don't believe that endian swapping significantly affects the
randomness of the data returned, so either:
1. Do something to silence sparse (casts?)
2. Live with the endian swap overhead if they're not in the hot path.
Other than that,
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH] bpf: add is_locked_tcp_sock guard for sock_ops rtt_min access
From: Martin KaFai Lau @ 2026-04-07 1:25 UTC (permalink / raw)
To: Werner Kasselman
Cc: Jiayuan Chen, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, John Fastabend, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lawrence Brakmo, bpf@vger.kernel.org,
netdev@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <20260406224953.2787289-1-werner@verivus.com>
On Mon, Apr 06, 2026 at 10:49:56PM +0000, Werner Kasselman wrote:
> sock_ops_convert_ctx_access() generates BPF instructions to inline
> context field accesses for BPF_PROG_TYPE_SOCK_OPS programs. For
> tcp_sock-specific fields like snd_cwnd, srtt_us, etc., it uses the
> SOCK_OPS_GET_TCP_SOCK_FIELD() macro which checks is_locked_tcp_sock
> and returns 0 when the socket is not a locked full TCP socket.
>
> However, the rtt_min field bypasses this guard entirely: it emits a raw
> two-instruction load sequence (load sk pointer, then load from
> tcp_sock->rtt_min offset) without checking is_locked_tcp_sock first.
>
> This is a problem because bpf_skops_hdr_opt_len() and
> bpf_skops_write_hdr_opt() in tcp_output.c set sock_ops.sk to a
> tcp_request_sock (cast from request_sock) during SYN-ACK processing,
> with is_fullsock=0 and is_locked_tcp_sock=0. If a SOCK_OPS program
> with BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG reads ctx->rtt_min in this
> callback, the generated code treats the tcp_request_sock pointer as a
> tcp_sock and reads at offsetof(struct tcp_sock, rtt_min) -- which is
> well past the end of the tcp_request_sock allocation, causing an
> out-of-bounds slab read.
This is not limited to hdr related CB flags.
It also happens to earlier CB flags that have a request_sock, such as
BPF_SOCK_OPS_RWND_INIT.
>
> The rtt_min field was introduced in the same commit as the other
> tcp_sock fields but was given hand-rolled access code because it reads
> a sub-field (rtt_min.s[0].v, a minmax_sample) rather than a direct
> struct member, making it incompatible with the SOCK_OPS_GET_FIELD()
> macro. This hand-rolled code omitted the is_fullsock guard that the
> macro provides. The guard was later renamed to is_locked_tcp_sock in
> commit fd93eaffb3f9 ("bpf: Prevent unsafe access to the sock fields in the BPF timestamping callback").
>
> Add the is_locked_tcp_sock guard to the rtt_min case, replicating the
> exact instruction pattern used by SOCK_OPS_GET_FIELD() including
> proper handling of the dst_reg==src_reg case with temp register
> save/restore. Use offsetof(struct minmax_sample, v) for the sub-field
> offset to match the style in bpf_tcp_sock_convert_ctx_access().
>
> Found via AST-based call-graph analysis using sqry.
>
> Fixes: 44f0e43037d3 ("bpf: Add support for reading sk_state and more")
> Cc: stable@vger.kernel.org
> Signed-off-by: Werner Kasselman <werner@verivus.com>
> ---
> net/core/filter.c | 47 ++++++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 78b548158fb0..58f0735b18d9 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -10830,13 +10830,54 @@ static u32 sock_ops_convert_ctx_access(enum bpf_access_type type,
> BUILD_BUG_ON(sizeof(struct minmax) <
> sizeof(struct minmax_sample));
>
> + /* Unlike other tcp_sock fields that use
> + * SOCK_OPS_GET_TCP_SOCK_FIELD(), rtt_min requires a
> + * custom access pattern because it reads a sub-field
> + * (rtt_min.s[0].v) rather than a direct struct member.
> + * We must still guard the access with is_locked_tcp_sock
> + * to prevent an OOB read when sk points to a
> + * tcp_request_sock (e.g., during SYN-ACK processing via
> + * bpf_skops_hdr_opt_len/bpf_skops_write_hdr_opt).
> + */
> + off = offsetof(struct tcp_sock, rtt_min) +
> + offsetof(struct minmax_sample, v);
> + {
> + int fullsock_reg = si->dst_reg, reg = BPF_REG_9, jmp = 2;
> +
> + if (si->dst_reg == reg || si->src_reg == reg)
> + reg--;
> + if (si->dst_reg == reg || si->src_reg == reg)
> + reg--;
> + if (si->dst_reg == si->src_reg) {
> + *insn++ = BPF_STX_MEM(BPF_DW, si->src_reg, reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
> + fullsock_reg = reg;
> + jmp += 2;
> + }
> + *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(
> + struct bpf_sock_ops_kern,
> + is_locked_tcp_sock),
> + fullsock_reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + is_locked_tcp_sock));
> + *insn++ = BPF_JMP_IMM(BPF_JEQ, fullsock_reg, 0, jmp);
> + if (si->dst_reg == si->src_reg)
> + *insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
> *insn++ = BPF_LDX_MEM(BPF_FIELD_SIZEOF(
> struct bpf_sock_ops_kern, sk),
> si->dst_reg, si->src_reg,
> offsetof(struct bpf_sock_ops_kern, sk));
> - *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->dst_reg,
> - offsetof(struct tcp_sock, rtt_min) +
> - sizeof_field(struct minmax_sample, t));
> + *insn++ = BPF_LDX_MEM(BPF_W, si->dst_reg, si->dst_reg, off);
> + if (si->dst_reg == si->src_reg) {
> + *insn++ = BPF_JMP_A(1);
> + *insn++ = BPF_LDX_MEM(BPF_DW, reg, si->src_reg,
> + offsetof(struct bpf_sock_ops_kern,
> + temp));
There is an existing bug in this copy-and-paste codes [1] and now is
repeated here, so please find a way to refactor it to be reusable instead of
duplicating it.
This also needs a test. It should be a subtest of [1],
so [1] need to land first.
[1]: https://lore.kernel.org/bpf/20260406031330.187630-1-jiayuan.chen@linux.dev/
^ permalink raw reply
* Re: [PATCH net-next v3 5/5] selftests: net: bridge: add tests for MRC and QQIC validation
From: Jakub Kicinski @ 2026-04-07 1:25 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Nikolay Aleksandrov, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260403150050.1235-6-royujjal@gmail.com>
On Fri, 3 Apr 2026 15:00:50 +0000 Ujjal Roy wrote:
> --- a/tools/testing/selftests/net/forwarding/.gitignore
> +++ b/tools/testing/selftests/net/forwarding/.gitignore
> @@ -1,3 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
> forwarding.config
> ipmr
> +mc_encode
> +mc_decode
please keep this file sorted
> diff --git a/tools/testing/selftests/net/forwarding/Makefile b/tools/testing/selftests/net/forwarding/Makefile
> index bbaf4d937dd8..a26da846632d 100644
> --- a/tools/testing/selftests/net/forwarding/Makefile
> +++ b/tools/testing/selftests/net/forwarding/Makefile
> @@ -1,5 +1,15 @@
> # SPDX-License-Identifier: GPL-2.0+ OR MIT
>
> +top_srcdir = ../../../../..
> +
> +CFLAGS += -Wall -Wl,--no-as-needed -O2 -g -I$(top_srcdir)/usr/include $(KHDR_INCLUDES)
> +CFLAGS += -I$(top_srcdir)/tools/include
Could you please keep the format more aligned with the ksft
net/Makefile? Also is the -I$(top_srcdir)/tools/include
still necessary? KHDR_INCLUDES don't include $src/usr/include ??
> +TEST_GEN_FILES := \
> + mc_encode \
> + mc_decode \
> +# end of TEST_GEN_FILES
Also needs to be sorted
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] net: mctp: defer creation of dst after source-address check
From: patchwork-bot+netdevbpf @ 2026-04-07 1:20 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: matt, davem, edumazet, kuba, pabeni, horms, netdev
In-Reply-To: <20260403-dev-mctp-dst-defer-v1-1-9c2c55faf9e9@codeconstruct.com.au>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 10:24:51 +0800 you wrote:
> Sashiko reports:
>
> > mctp_dst_from_route() increments the device reference count by calling
> > mctp_dev_hold(). When a valid route is found and dst is NULL, the
> > structure copy is bypassed and rc is set to 0.
>
> Instead of optimistically creating a dst from the final route (then
> releasing it if the saddr is invalid), perform the saddr check first.
>
> [...]
Here is the summary with links:
- [net-next] net: mctp: defer creation of dst after source-address check
https://git.kernel.org/netdev/net-next/c/f32ba0963119
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] psp: add missing device stats to get-stats reply attributes
From: patchwork-bot+netdevbpf @ 2026-04-07 1:20 UTC (permalink / raw)
To: Daniel Zahka
Cc: kuba, willemdebruijn.kernel, davem, edumazet, pabeni, horms,
donald.hunter, netdev, linux-kernel
In-Reply-To: <20260403-psp-yaml-fix-v1-1-dacee0663903@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 03:26:31 -0700 you wrote:
> Commit f05d26198cf2 ("psp: add stats from psp spec to driver facing
> api") added device statistics (rx-packets, rx-bytes, rx-auth-fail,
> rx-error, rx-bad, tx-packets, tx-bytes, tx-error) to the stats
> attribute-set but did not add them to the get-stats operation reply
> attributes. The kernel reports these attributes in the reply, so
> list them in the spec to match.
>
> [...]
Here is the summary with links:
- [net-next] psp: add missing device stats to get-stats reply attributes
https://git.kernel.org/netdev/net-next/c/c8eee00c0fef
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: mctp: tests: use actual address when creating dev with addr
From: patchwork-bot+netdevbpf @ 2026-04-07 1:20 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: matt, davem, edumazet, kuba, pabeni, horms, netdev
In-Reply-To: <20260403-dev-mctp-fix-test-addr-v1-1-b7fa789cdd9b@codeconstruct.com.au>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 03 Apr 2026 10:21:04 +0800 you wrote:
> Sashiko reports:
>
> > This isn't a bug in the core networking code, but the addr parameter
> > appears to be ignored here.
>
> In mctp_test_create_dev_with_addr(), we are ignoring the addr argument
> and just using `8`. Use the passed address instead.
>
> [...]
Here is the summary with links:
- [net-next] net: mctp: tests: use actual address when creating dev with addr
https://git.kernel.org/netdev/net-next/c/70e32aadb5ca
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Jakub Kicinski @ 2026-04-07 1:19 UTC (permalink / raw)
To: Allison Henderson; +Cc: netdev, pabeni, edumazet, rds-devel, horms, linux-rdma
In-Reply-To: <20260405041613.309958-2-achender@kernel.org>
On Sat, 4 Apr 2026 21:16:12 -0700 Allison Henderson wrote:
> From: Håkon Bugge <haakon.bugge@oracle.com>
> Signed-off-by: Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com>
> Signed-off-by: Gerd Rausch <gerd.rausch@oracle.com>
> Signed-off-by: Allison Henderson <achender@kernel.org>
Author's sign-off missing on this patch (I sent out the AI reviews
as well, without looking, take them with a grain of salt).
^ permalink raw reply
* Re: [PATCH net v1 2/2] net/rds: Restrict use of RDS/IB to the initial network namespace
From: Jakub Kicinski @ 2026-04-07 1:19 UTC (permalink / raw)
To: achender
Cc: Jakub Kicinski, rds-devel, edumazet, linux-rdma, horms, pabeni,
netdev
In-Reply-To: <20260405041613.309958-3-achender@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net/rds: Restrict use of RDS/IB to the initial network namespace
Prevent using RDS/IB in network namespaces other than the initial one.
The existing RDS/IB code will not work properly in non-initial network
namespaces, and there are currently no plans to support such use.
Closes: https://syzkaller.appspot.com/bug?extid=da8e060735ae02c8f3d1
> diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
> --- a/net/rds/af_rds.c
> +++ b/net/rds/af_rds.c
[ ... ]
> @@ -373,6 +374,10 @@ static int rds_set_transport(struct net *net, struct rds_sock *rs,
> if (t_type < 0 || t_type >= RDS_TRANS_COUNT)
> return -EINVAL;
>
> + /* Only RDS/TCP supports non-initial network namespaces */
> + if (t_type != RDS_TRANS_TCP && !net_eq(net, &init_net))
> + return -EPROTOTYPE;
> +
[ ... ]
> diff --git a/net/rds/ib.c b/net/rds/ib.c
> --- a/net/rds/ib.c
> +++ b/net/rds/ib.c
> @@ -490,8 +490,13 @@
> static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> __u32 scope_id)
> {
> - struct rds_ib_device *rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> + struct rds_ib_device *rds_ibdev;
>
> + /* RDS/IB is only supported in the initial network namespace */
> + if (!net_eq(net, &init_net))
> + return -EPROTOTYPE;
> +
^^^^
Is the wording "is only supported" in this comment precise? Looking at the
existing codebase, rds_ib_cm_handle_connect() already has a comment that
says "RDS/IB is not currently netns aware, thus init_net" with the phrase
"for now" in rds_ib_laddr_check_cm() suggesting this could change. Before
this patch, it was technically possible to attempt using RDS/IB in
non-init namespaces (though it led to the UAF bug). The comment might be
clearer if it said "RDS/IB does not work correctly in non-initial network
namespaces" or "RDS/IB is restricted to the initial network namespace" to
better distinguish between the technical limitation and the enforcement.
> + rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> if (rds_ibdev) {
> rds_ib_dev_put(rds_ibdev);
>
The commit message states "there are currently no plans to support such
use." While the existing code clearly does not support non-init namespaces
(with hardcoded &init_net references throughout), this statement about
future plans cannot be verified from code. The existing comments in
rds_ib_cm_handle_connect() and rds_ib_laddr_check_cm() use phrases like
"for now" and "not currently" which could suggest plans might exist or
could be placeholders. Is this policy statement necessary in the commit
message, or would it be sufficient to state the technical facts about the
current limitation?
^ permalink raw reply
* Re: [PATCH net v1 1/2] net/rds: Optimize rds_ib_laddr_check
From: Jakub Kicinski @ 2026-04-07 1:19 UTC (permalink / raw)
To: achender
Cc: Jakub Kicinski, rds-devel, edumazet, linux-rdma, horms, pabeni,
netdev
In-Reply-To: <20260405041613.309958-2-achender@kernel.org>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net/rds: Optimize rds_ib_laddr_check
This patch optimizes rds_ib_laddr_check() to avoid excessive
rdma_bind_addr() calls by checking if an address has been used before.
It renames the original function to rds_ib_laddr_check_cm() and
introduces a new wrapper that first checks rds_ib_get_device() before
falling back to the CM-based check.
> diff --git a/net/rds/ib.c b/net/rds/ib.c
> index ac6affa33ce7..73e01984ee9a 100644
> --- a/net/rds/ib.c
> +++ b/net/rds/ib.c
> @@ -401,8 +401,8 @@ static void rds6_ib_ic_info(struct socket *sock, unsigned int len,
> * allowed to influence which paths have priority. We could call userspace
> * asserting this policy "routing".
> */
> -static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> - __u32 scope_id)
> +static int rds_ib_laddr_check_cm(struct net *net, const struct in6_addr *addr,
> + __u32 scope_id)
> {
> int ret;
> struct rdma_cm_id *cm_id;
[ ... ]
> @@ -487,6 +487,20 @@ static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> return ret;
> }
>
> +static int rds_ib_laddr_check(struct net *net, const struct in6_addr *addr,
> + __u32 scope_id)
> +{
> + struct rds_ib_device *rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
> +
> + if (rds_ibdev) {
> + rds_ib_dev_put(rds_ibdev);
> +
> + return 0;
> + }
> +
> + return rds_ib_laddr_check_cm(net, addr, scope_id);
> +}
> +
Can this code handle pure IPv6 addresses correctly? The function extracts
addr->s6_addr32[3] and passes it to rds_ib_get_device(), which looks up
devices by IPv4 address.
For IPv4-mapped IPv6 addresses, addr->s6_addr32[3] contains the IPv4
address. But for pure IPv6 addresses (when CONFIG_IPV6 is enabled),
addr->s6_addr32[3] contains the last 32 bits of the IPv6 address, which
could accidentally match a stored IPv4 address.
When this collision occurs, the function returns 0 (success) without
calling rds_ib_laddr_check_cm(), which performs the full validation
including rdma_bind_addr() and IPv6 link-local scope_id checks. This
means a pure IPv6 address could be incorrectly accepted as valid for IB
transport.
Should this be guarded with an ipv6_addr_v4mapped(addr) check? For
example:
if (ipv6_addr_v4mapped(addr)) {
rds_ibdev = rds_ib_get_device(addr->s6_addr32[3]);
...
}
The existing callers of rds_ib_get_device (rds_ib_get_mr,
rds_ib_update_ipaddr) operate in post-connection contexts where the
address type is already validated, but rds_ib_laddr_check is the
validation gate called during bind/transport-selection for any address
type.
> static void rds_ib_unregister_client(void)
> {
> ib_unregister_client(&rds_ib_client);
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [net-next v8 01/10] net: tso: Introduce tso_dma_map and helpers
From: Jakub Kicinski @ 2026-04-07 1:16 UTC (permalink / raw)
To: Joe Damato
Cc: netdev, David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
andrew+netdev, michael.chan, pavan.chebbi, linux-kernel, leon
In-Reply-To: <20260403003524.2564973-2-joe@dama.to>
On Thu, 2 Apr 2026 17:35:08 -0700 Joe Damato wrote:
> +/**
> + * tso_dma_map_complete - tear down mapping at completion time
> + * @dev: the device that owns the mapping
> + * @cstate: state saved by tso_dma_map_completion_save()
> + *
> + * Returns true if the IOVA path was used and the mapping has been
> + * destroyed. Returns false if the fallback per-region path was used
> + * and the driver must unmap via its normal completion path.
> + */
> +static inline bool
> +tso_dma_map_complete(struct device *dev,
> + struct tso_dma_map_completion_state *cstate)
> +{
> + if (dma_use_iova(&cstate->iova_state)) {
> + dma_iova_destroy(dev, &cstate->iova_state, cstate->total_len,
> + DMA_TO_DEVICE, 0);
> + return true;
> + }
> +
> + return false;
> +}
kdoc says:
Warning: include/net/tso.h:120 No description found for return value of 'tso_dma_map_complete'
missing the crucial : character..
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 0/3] psp: add crypt-offset and spi-threshold attributes
From: Jakub Kicinski @ 2026-04-07 1:14 UTC (permalink / raw)
To: Akhilesh Samineni
Cc: davem, edumazet, pabeni, andrew+netdev, horms, willemb,
daniel.zahka, netdev, linux-kernel, jayakrishnan.udayavarma,
ajit.khaparde, kiran.kella, sachin.suman
In-Reply-To: <20260406222305.4111170-1-akhilesh.samineni@broadcom.com>
On Mon, 6 Apr 2026 15:23:02 -0700 Akhilesh Samineni wrote:
> This series introduces two new configurable per-device attributes to
> the PSP (PSP Security Protocol) subsystem: crypt-offset and spi-threshold.
Please read this document:
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] bnxt_en: fix out-of-bounds write in bnxt_alloc_vf_resources()
From: Jakub Kicinski @ 2026-04-07 1:11 UTC (permalink / raw)
To: Michael Chan
Cc: Junrui Luo, Michael Chan, Pavan Chebbi, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Prashant Sreedharan,
Jeffrey Huang, Eddie Wai, netdev, linux-kernel, Yuhao Jiang,
stable
In-Reply-To: <SYBPR01MB78817B7EE349BB2CF0FC6873AF53A@SYBPR01MB7881.ausprd01.prod.outlook.com>
On Tue, 31 Mar 2026 17:57:10 +0800 Junrui Luo wrote:
> bnxt_alloc_vf_resources() derives the number of DMA pages for VF HWRM
> command buffers from num_vfs and stores them in the fixed-size arrays
> hwrm_cmd_req_addr[4] and hwrm_cmd_req_dma_addr[4]. The vf_event_bmap
> bitmap is similarly fixed at 128 bits.
>
> If num_vfs exceeds 128, the allocation loop writes past the arrays,
> corrupting adjacent fields in bnxt_pf_info.
>
> Add BNXT_MAX_VFS to cap num_vfs at 128, matching the existing array and
> bitmap capacity.
>
> Fixes: c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")
> Reported-by: Yuhao Jiang <danisjiang@gmail.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Quick Google search reveals that BCM957608 is supposed to support
1k VFs so I suspect Broadcom may be scrambling for a real fix here.
I'll drop this from patchwork.
Michael, if my hunch is correct please make sure to credit the reporter.
If you just need more time to validate - please take this in and repost
once ready. patches older than 1 week "fall out" of our patch tracking
:(
^ permalink raw reply
* Re: [PATCH net-next] net: dropreason: add SKB_DROP_REASON_{BROAD,MULTI}CAST_BACKLOG
From: Jakub Kicinski @ 2026-04-07 1:02 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Paolo Abeni, Simon Horman, Kuniyuki Iwashima,
Andrew Lunn, netdev, eric.dumazet
In-Reply-To: <20260403022443.3480770-1-edumazet@google.com>
On Fri, 3 Apr 2026 02:24:43 +0000 Eric Dumazet wrote:
> ipvlan and macvlan use queues to process broadcast or multicast packets
> from a work queue.
>
> Under attack these queues can drop packets.
>
> Add BROADCAST_BACKLOG drop_reason for macvlan broadcast queue.
>
> Add MULTICAST_BACKLOG drop_reason for ipvlan multicast queue.
What distinction are you trying to communicate by using BROADCAST
vs MULTICAST? Funny naming of the functions aside I believe that
in both cases we're basically dealing with multicast traffic.
Reading the code it seems like macvlan has some optimization where
it delivers the frame inline if the multicast group is not very
popular. And if it is popular it schedules a work (and calls that
broadcast). ipvlan doesn't have the inline filter and calls the
deliver via work multicast.
tl;dr I think the drivers do the same thing just call their functions
broadcast vs multicast. Having two drop reasons here is actively
misleading?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2] selftests: net: py: color the basics in the output
From: patchwork-bot+netdevbpf @ 2026-04-07 0:50 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, sdf,
willemb, joe, shuah, petrm, linux-kselftest
In-Reply-To: <20260402215444.1589893-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 2 Apr 2026 14:54:44 -0700 you wrote:
> Sometimes it's hard to spot the ok / not ok lines in the output.
> This is especially true for the GRO tests which retries a lot
> so there's a wall of non-fatal output printed.
>
> Try to color the crucial lines green / red / yellow when running
> in a terminal.
>
> [...]
Here is the summary with links:
- [net-next,v2] selftests: net: py: color the basics in the output
https://git.kernel.org/netdev/net-next/c/3b45559f6c0a
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: macb: Use napi_schedule_irqoff() in IRQ handler
From: Kevin Hao @ 2026-04-07 0:45 UTC (permalink / raw)
To: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt
Cc: netdev, linux-rt-devel, Kevin Hao
For non-PREEMPT_RT kernels, the IRQ handler runs with interrupts
disabled, allowing the use of napi_schedule_irqoff() to save a pair of
local_irq_{save,restore} operations. For PREEMPT_RT kernels,
napi_schedule_irqoff() behaves identically to napi_schedule().
Signed-off-by: Kevin Hao <haokexin@gmail.com>
---
drivers/net/ethernet/cadence/macb_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index 6ec7b110dc7219ca337de4c6f0cbe38bb11558b5..322545b3be23f8d2c4ca2e3da61e057496458eab 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2149,7 +2149,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
*/
queue_writel(queue, IDR, bp->rx_intr_mask);
macb_queue_isr_clear(bp, queue, MACB_BIT(RCOMP));
- napi_schedule(&queue->napi_rx);
+ napi_schedule_irqoff(&queue->napi_rx);
}
if (status & (MACB_BIT(TCOMP) |
@@ -2162,7 +2162,7 @@ static irqreturn_t macb_interrupt(int irq, void *dev_id)
wmb(); // ensure softirq can see update
}
- napi_schedule(&queue->napi_tx);
+ napi_schedule_irqoff(&queue->napi_tx);
}
if (unlikely(status & MACB_INT_MISC_FLAGS))
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260404-macb-napi-irqoff-12b3f4d9799b
Best regards,
--
Kevin Hao <haokexin@gmail.com>
^ 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