* Re: Please backport bridge multicast exponential field encoding fix series to stable kernels
From: Ujjal Roy @ 2026-07-09 12:38 UTC (permalink / raw)
To: Greg KH
Cc: Sasha Levin, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Nikolay Aleksandrov, Ido Schimmel,
David Ahern, Shuah Khan, Andy Roulin, Yong Wang, Petr Machata,
stable, Ujjal Roy, bridge, Kernel, Kernel, linux-kselftest
In-Reply-To: <2026063019-crummy-mosaic-d9bb@gregkh>
On Wed, Jul 1, 2026 at 2:00 AM Greg KH <greg@kroah.com> wrote:
>
> On Wed, Jul 01, 2026 at 01:33:07AM +0530, Ujjal Roy wrote:
> > On Thu, Jun 25, 2026 at 8:20 PM Ujjal Roy <royujjal@gmail.com> wrote:
> > >
> > > On Thu, Jun 25, 2026 at 4:12 PM Sasha Levin <sashal@kernel.org> wrote:
> > > >
> > > > > Please backport the 5-patch bridge multicast exponential field
> > > > > encoding series (726fa7da2d8c, 12cfb4ecc471, 95bfd196f0dc,
> > > > > e51560f4220a, 529dbe762de0) to the stable kernels.
> > > >
> > > > I tried, but it doesn't apply to 7.1. Could you provide a backport please?
> > > >
> > > > --
> > > > Thanks,
> > > > Sasha
> > >
> > > I will create patches on top of 7.1. But tell me what about all other
> > > stable releases? I have to create patches to all stables and how to
> > > share the patches to you? Via this email or any other process? I am a
> > > fresh on backporting my changes to all stables.
> >
> > I have prepared the patches for stable releases mentioned in kernel.org.
> >
> > And I am waiting for your response so that I can send you the patchset.
>
> Please just send the patches :)
I just sent another email with the subject "Please backport bridge
multicast exponential field encoding fix series to
6.1.y/6.6.y/6.12.y/6.18.y/7.0.y", please accept that for direct
cherry-picking. Infact 5.15.y also cherry-picked cleanly, except for
the selftest commit which is not needed here, will send another email
regarding this.
I will send a separate patchset after resolving conflicts on 5.10.y and 7.1.y
^ permalink raw reply
* Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y
From: Ujjal Roy @ 2026-07-09 12:42 UTC (permalink / raw)
To: Greg KH
Cc: Linux Stable, David S . Miller, Eric Dumazet, Jakub Kicinski,
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: <2026070925-delay-gauntlet-bc7c@gregkh>
On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > Hi Greg,
> >
> > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> >
> > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
>
> Why is any of this needed in older kernels?
>
> And 7.0.y is long end-of-life.
>
> And why, if this does fix issues, was it not tagged for stable to start
> with?
>
> thanks,
>
> greg k-h
I already explained this in the email thread, "Please backport bridge
multicast exponential field encoding fix series to stable kernels".
^ permalink raw reply
* [PATCH net] geneve: fix hint header definition wrt endianness
From: Antoine Tenart @ 2026-07-09 12:48 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet; +Cc: Antoine Tenart, netdev, Sashiko
Bitfields are packed differently depending on the endianness, take it into
account in the GRO hint header definition.
Fixes: e0a12cbf262b ("geneve: add GRO hint output path")
Cc: Paolo Abeni <pabeni@redhat.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260529144713.780938-1-atenart%40kernel.org
Signed-off-by: Antoine Tenart <atenart@kernel.org>
---
drivers/net/geneve.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index 9afff7bcaa0b..b25b0c4de4d1 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -43,8 +43,17 @@ MODULE_PARM_DESC(log_ecn_error, "Log packets received with corrupted ECN");
#define GENEVE_OPT_GRO_HINT_LEN 1
struct geneve_opt_gro_hint {
+#if defined(__LITTLE_ENDIAN_BITFIELD)
u8 inner_proto_id:2,
- nested_is_v6:1;
+ nested_is_v6:1,
+ rsvd:5;
+#elif defined(__BIG_ENDIAN_BITFIELD)
+ u8 rsvd:5,
+ nested_is_v6:1,
+ inner_proto_id:2;
+#else
+#error "Please fix <asm/byteorder.h>"
+#endif
u8 nested_nh_offset;
u8 nested_tp_offset;
u8 nested_hdr_len;
--
2.55.0
^ permalink raw reply related
* Re: [PATCH] net: hip04: quiesce tx coalesce timer before teardown
From: Simon Horman @ 2026-07-09 12:43 UTC (permalink / raw)
To: fanwu01
Cc: Simon Horman, netdev, shenjian15, salil.mehta, andrew+netdev,
davem, edumazet, kuba, pabeni, linux-kernel, stable
In-Reply-To: <20260703050133.2445155-1-fanwu01@zju.edu.cn>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
Full review at: https://sashiko.dev
---
net: hip04: quiesce tx coalesce timer before teardown
This patch fixes race conditions with the tx_coalesce_timer by properly
canceling it during device stop and remove. It also serializes device
restarts in the tx timeout handler using rtnl_lock().
> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
> index 18376bcc718a2..cb9b01c79ee6e 100644
> --- a/drivers/net/ethernet/hisilicon/hip04_eth.c
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
[ ... ]
> @@ -761,6 +762,13 @@ static int hip04_mac_stop(struct net_device *ndev)
>
> napi_disable(&priv->napi);
> netif_stop_queue(ndev);
[Severity: High]
This is a pre-existing issue, but does netif_stop_queue() adequately protect
against concurrent transmission here?
Since netif_stop_queue() only changes the queue state flag without waiting for
an active ndo_start_xmit callback to finish (unlike netif_tx_disable()), could
this allow the subsequent hip04_tx_reclaim() call to corrupt the TX ring or
cause invalid DMA mappings if a transmission is actively running?
> +
> + /* Cancel the TX-coalesce timer after the arming paths (xmit via the
> + * queue, rx poll via NAPI) are disabled, so a pending tx_done()
> + * (which dereferences priv) is drained before the device is freed.
> + */
> + hrtimer_cancel(&priv->tx_coalesce_timer);
[Severity: High]
This is a pre-existing issue, but is it possible for the softirq to re-arm
the timer after hrtimer_cancel() is called?
In hip04_rx_poll(), the NAPI ownership is released via napi_complete_done()
before the timer is armed:
hip04_rx_poll() {
...
napi_complete_done(napi, rx);
done:
if (rx < budget && tx_remaining)
hip04_start_tx_timer(priv);
}
If the teardown thread cancels the timer and frees the private structure
while the softirq is preempted just after napi_complete_done(), could this
result in a use-after-free when hip04_start_tx_timer() is eventually executed?
> +
> hip04_mac_disable(ndev);
> hip04_tx_reclaim(ndev, true);
[Severity: High]
This is a pre-existing issue, but is there missing hardware synchronization
between disabling the MAC and reclaiming the TX ring?
hip04_mac_disable() disables the MAC using a relaxed MMIO write without
polling for an idle state.
Since the very next call is hip04_tx_reclaim() which unmaps buffers and
modifies descriptor memory, could this cause silent data corruption or IOMMU
page faults if the MAC is still actively processing packets in the background?
[ ... ]
> @@ -791,8 +799,15 @@ static void hip04_tx_timeout_task(struct work_struct *work)
> struct hip04_priv *priv;
>
> priv = container_of(work, struct hip04_priv, tx_timeout_task);
> +
> + rtnl_lock();
> + if (!netif_running(priv->ndev))
> + goto out;
> +
> hip04_mac_stop(priv->ndev);
> hip04_mac_open(priv->ndev);
[Severity: High]
This is a pre-existing issue, but what happens if hip04_mac_open() fails
during this restart?
If dma_map_single() fails inside hip04_mac_open(), it returns -EIO without
enabling NAPI. Because this return value is ignored here, the device remains
broken and NAPI is left disabled (with the SCHED bit set).
Will this cause a hard lockup later when hip04_mac_stop() spins forever in
napi_disable() waiting for the SCHED bit to clear?
> +out:
> + rtnl_unlock();
> }
>
[ ... ]
> @@ -1029,10 +1044,15 @@ static void hip04_remove(struct platform_device *pdev)
> if (priv->phy)
> phy_disconnect(priv->phy);
>
> - hip04_free_ring(ndev, d);
> unregister_netdev(ndev);
[Severity: High]
This is a pre-existing issue, but does calling phy_disconnect() before
unregister_netdev() cause a use-after-free and WARN?
phy_disconnect() halts and detaches the PHY, dropping its reference count.
The subsequent call to unregister_netdev() invokes hip04_mac_stop(), which
unconditionally calls phy_stop().
Could calling phy_stop() on a detached and potentially freed PHY device
pointer cause a crash?
> - of_node_put(priv->phy_node);
> cancel_work_sync(&priv->tx_timeout_task);
> + hrtimer_cancel(&priv->tx_coalesce_timer);
> + /* Free the rings only after the interface is stopped (.ndo_stop via
> + * unregister_netdev) and the work/timer are drained; the TX/NAPI
> + * paths touch them while the device is up.
> + */
> + hip04_free_ring(ndev, d);
[Severity: High]
This is a pre-existing issue, but does hip04_free_ring() safely handle
allocation failures?
During probe, if allocating the TX descriptor ring fails, priv->tx_desc
remains NULL, and the error path calls hip04_free_ring().
Since hip04_free_ring() unconditionally calls dma_free_coherent() on
priv->tx_desc, could this cause a kernel panic on architectures that trap
virtual-to-physical translations on NULL?
> + of_node_put(priv->phy_node);
> free_netdev(ndev);
[Severity: High]
This is a pre-existing issue, but does explicitly freeing the netdev here
create a use-after-free race with the interrupt handler?
The driver requests its interrupt in hip04_mac_probe() using
devm_request_irq(), meaning the IRQ is only freed during devres cleanup after
hip04_remove() completely finishes.
If an interrupt fires between free_netdev() and the devres cleanup,
hip04_mac_interrupt() will cast dev_id to the freed ndev pointer, which seems
like it would lead to a use-after-free crash.
> }
>
[ ... ]
Regarding the RX polling path in hip04_rx_poll():
[Severity: High]
This is a pre-existing issue, but does a failure in build_skb() cause a memory
and DMA mapping leak?
Looking at hip04_rx_poll():
if (unlikely(!skb)) {
net_dbg_ratelimited("build_skb failed\n");
goto refill;
}
...
refill:
...
priv->rx_buf[priv->rx_head] = buf;
priv->rx_phys[priv->rx_head] = phys;
If build_skb() fails, the code jumps directly to the refill label, completely
bypassing the dma_unmap_single() call for the original buffer. It then
allocates and maps a new buffer, overwriting the array entries.
Could this permanently leak the original buffer and its DMA mapping,
eventually leading to an OOM crash under memory pressure?
^ permalink raw reply
* [PATCH net] geneve: ensure the skb is writable before fixing its headers
From: Antoine Tenart @ 2026-07-09 12:50 UTC (permalink / raw)
To: davem, kuba, pabeni, edumazet; +Cc: Antoine Tenart, netdev, Sashiko
Make sure the IPv4/6 and UDP headers are writable before fixing them up in
geneve_post_decap_hint. As skb_ensure_writable can reallocate the skb linear
area, reload the GRO hint header pointer and only set the IPv4/6 header ones
after the call.
Fixes: fd0dd796576e ("geneve: use GRO hint option in the RX path")
Cc: Paolo Abeni <pabeni@redhat.com>
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260529144713.780938-1-atenart%40kernel.org
Signed-off-by: Antoine Tenart <atenart@kernel.org>
---
drivers/net/geneve.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c
index b25b0c4de4d1..0b0f1e300b68 100644
--- a/drivers/net/geneve.c
+++ b/drivers/net/geneve.c
@@ -586,6 +586,7 @@ static int geneve_post_decap_hint(const struct sock *sk, struct sk_buff *skb,
struct iphdr *iph;
struct udphdr *uh;
__be16 p;
+ int err;
hint_off = geneve_sk_gro_hint_off(sk, *geneveh, &p, &len);
if (!hint_off)
@@ -610,12 +611,20 @@ static int geneve_post_decap_hint(const struct sock *sk, struct sk_buff *skb,
!geneve_opt_gro_hint_validate(skb->data, gro_hint)))
return -EINVAL;
- ipv6h = (void *)skb->data + gro_hint->nested_nh_offset;
- iph = (struct iphdr *)ipv6h;
total_len = skb->len - gro_hint->nested_nh_offset;
if (total_len >= GRO_LEGACY_MAX_SIZE)
return -E2BIG;
+ err = skb_ensure_writable(skb, gro_hint->nested_tp_offset + sizeof(*uh));
+ if (unlikely(err))
+ return err;
+
+ *geneveh = geneve_hdr(skb);
+ gro_hint = geneve_opt_gro_hint(*geneveh, hint_off);
+
+ ipv6h = (void *)skb->data + gro_hint->nested_nh_offset;
+ iph = (struct iphdr *)ipv6h;
+
/*
* After stripping the outer encap, the packet still carries a
* tunnel encapsulation: the nested one.
--
2.55.0
^ permalink raw reply related
* Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y
From: Greg KH @ 2026-07-09 12:53 UTC (permalink / raw)
To: Ujjal Roy
Cc: Linux Stable, David S . Miller, Eric Dumazet, Jakub Kicinski,
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: <CAE2MWk=mm8_bkd54Gv1mdox6rfvx85Dd3AjOCxPz0fPAfyuWYA@mail.gmail.com>
On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > Hi Greg,
> > >
> > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > >
> > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> >
> > Why is any of this needed in older kernels?
> >
> > And 7.0.y is long end-of-life.
> >
> > And why, if this does fix issues, was it not tagged for stable to start
> > with?
> >
> > thanks,
> >
> > greg k-h
>
> I already explained this in the email thread, "Please backport bridge
> multicast exponential field encoding fix series to stable kernels".
Sorry, but that's not here (remember, some of us get 1000+ emails a
day.)
Please explain why patches need to be backported when asking for them to
be backported.
thanks,
greg k-h
^ permalink raw reply
* [PATCH 6.6.y] net: Drop the lock in skb_may_tx_timestamp()
From: Philo Lu @ 2026-07-09 12:58 UTC (permalink / raw)
To: stable
Cc: bigeasy, willemb, kerneljasonxing, edumazet, pabeni, lulie, davem,
kuba, netdev, linux-kernel, dust.li, heiko.stuebner
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
commit 983512f3a87fd8dc4c94dfa6b596b6e57df5aad7 upstream.
skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must
not be taken in IRQ context, only softirq is okay. A few drivers receive
the timestamp via a dedicated interrupt and complete the TX timestamp
from that handler. This will lead to a deadlock if the lock is already
write-locked on the same CPU.
Taking the lock can be avoided. The socket (pointed by the skb) will
remain valid until the skb is released. The ->sk_socket and ->file
member will be set to NULL once the user closes the socket which may
happen before the timestamp arrives.
If we happen to observe the pointer while the socket is closing but
before the pointer is set to NULL then we may use it because both
pointer (and the file's cred member) are RCU freed.
Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a
matching WRITE_ONCE() where the pointer are cleared.
Link: https://lore.kernel.org/all/20260205145104.iWinkXHv@linutronix.de
Fixes: b245be1f4db1a ("net-timestamp: no-payload only sysctl")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Jason Xing <kerneljasonxing@gmail.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/20260220183858.N4ERjFW6@linutronix.de
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
[ adapted sk_set_socket() in include/net/sock.h to fix the conflict from
not having commit 5d6b58c932ec ("net: lockless sock_i_ino()") and the
additional previous changes required by it.
It comes down to just now having the lines of
if (sock) {
WRITE_ONCE(sk->sk_uid, SOCK_INODE(sock)->i_uid);
WRITE_ONCE(sk->sk_ino, SOCK_INODE(sock)->i_ino);
}
below the changed line. ]
Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
---
This patch is same as that in 6.12 (c770217044d9), and it can be also applied
to 6.1/5.15/5.10 except for line number differences. I'll send patches for the
other versions if this one looks good.
---
include/net/sock.h | 2 +-
net/core/skbuff.c | 23 ++++++++++++++++++-----
net/socket.c | 2 +-
3 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index a6944844553af..c1f129a532b20 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -2155,7 +2155,7 @@ static inline int sk_rx_queue_get(const struct sock *sk)
static inline void sk_set_socket(struct sock *sk, struct socket *sock)
{
- sk->sk_socket = sock;
+ WRITE_ONCE(sk->sk_socket, sock);
}
static inline wait_queue_head_t *sk_sleep(struct sock *sk)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index c5e2ae6d0406b..732204d99822a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5258,15 +5258,28 @@ static void __skb_complete_tx_timestamp(struct sk_buff *skb,
static bool skb_may_tx_timestamp(struct sock *sk, bool tsonly)
{
- bool ret;
+ struct socket *sock;
+ struct file *file;
+ bool ret = false;
if (likely(READ_ONCE(sysctl_tstamp_allow_data) || tsonly))
return true;
- read_lock_bh(&sk->sk_callback_lock);
- ret = sk->sk_socket && sk->sk_socket->file &&
- file_ns_capable(sk->sk_socket->file, &init_user_ns, CAP_NET_RAW);
- read_unlock_bh(&sk->sk_callback_lock);
+ /* The sk pointer remains valid as long as the skb is. The sk_socket and
+ * file pointer may become NULL if the socket is closed. Both structures
+ * (including file->cred) are RCU freed which means they can be accessed
+ * within a RCU read section.
+ */
+ rcu_read_lock();
+ sock = READ_ONCE(sk->sk_socket);
+ if (!sock)
+ goto out;
+ file = READ_ONCE(sock->file);
+ if (!file)
+ goto out;
+ ret = file_ns_capable(file, &init_user_ns, CAP_NET_RAW);
+out:
+ rcu_read_unlock();
return ret;
}
diff --git a/net/socket.c b/net/socket.c
index fa242d7e51c79..ae31c54664632 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -671,7 +671,7 @@ static void __sock_release(struct socket *sock, struct inode *inode)
iput(SOCK_INODE(sock));
return;
}
- sock->file = NULL;
+ WRITE_ONCE(sock->file, NULL);
}
/**
--
2.47.3
^ permalink raw reply related
* [PATCH net v2] netfilter: nf_nat: recalculate TCP TS offset when snat change sport
From: xietangxin @ 2026-07-09 13:12 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Phil Sutter, Simon Horman, netfilter-devel, coreteam, netdev,
linux-kernel, Victor Nogueira, gaoxingwang, huyizhen, xietangxin
Problem observed in Kubernetes environments where MASQUERADE target with
--random-fully is configured by default. after commit
165573e41f2f ("tcp: secure_seq: add back ports to TS offset") TCP short
connection QPS dropped from ~20000 to ~10000. This added source and
destination ports into TS offset calculation.
However, with MASQUERADE --random-fully, when multiple internal connections
(e.g sport 10000,20000) are mapped to the same external port (e.g 30000),
their TS offsets are calculated as ts_offset(10000) and ts_offset(20000).
If the server reuses the TIME_WAIT slot from the first connection, there is
a chance that ts_offset(20000) < ts_offset(10000), breaking TSval
monotonicity for the same 4-tuple and causing RST packets:
Client -> Server 24870 -> 80 [SYN] TSval=2294041168
Server -> Client 80 -> 24870 [ACK] TSecr=2846236456
Client -> Server 24870 -> 80 [RST] Seq=855605690
After nf_nat_inet_fn() successfully assigns a new randomized
source port, recalculate the TS offset using the new port and
update the SYN packet's TSval accordingly.
Test results on 4U4G VM with
`./wrk -t8 -c200 -H "Connection: close" -d10s --latency http://5.5.5.5:80`
Before:
random:10712 req/s, random-fully:10986 req/s
After:
random:20530 req/s, random-fully:19511 req/s
Fixes: 165573e41f2f ("tcp: secure_seq: add back ports to TS offset")
Cc: stable@vger.kernel.org
Closes:https://lore.kernel.org/all/92935c00-e0be-4591-ac44-5978c7804d57@yeah.net/
Signed-off-by: xietangxin <xietangxin@h-partners.com>
---
v2:
- Move the new helper in the IP_CT_NEW case of nf_nat_inet_fn().
- Fix a compilation failure when CONFIG_IPV6 is disabled.
v1: https://lore.kernel.org/all/20260629093408.3927103-1-xietangxin@h-partners.com/
---
net/netfilter/nf_nat_core.c | 103 +++++++++++++++++++++++++++++++++++-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index 63ff6b4d5d21..9d0b316fa3c7 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -16,6 +16,8 @@
#include <linux/siphash.h>
#include <linux/rtnetlink.h>
+#include <net/tcp.h>
+#include <net/secure_seq.h>
#include <net/netfilter/nf_conntrack_bpf.h>
#include <net/netfilter/nf_conntrack_core.h>
#include <net/netfilter/nf_conntrack_helper.h>
@@ -894,6 +896,99 @@ static bool in_vrf_postrouting(const struct nf_hook_state *state)
return false;
}
+static __be32 *nf_nat_tcp_ts_option_ptr(const struct sk_buff *skb)
+{
+ struct tcphdr *th;
+ unsigned char *ptr;
+ unsigned char opcode;
+ unsigned char opsize;
+ unsigned int optlen, offset;
+
+ offset = 0;
+ th = tcp_hdr(skb);
+ optlen = (th->doff - 5) * 4;
+ ptr = (unsigned char *)(th + 1);
+
+ while (offset < optlen) {
+ opcode = ptr[offset];
+ if (opcode == TCPOPT_EOL)
+ break;
+
+ if (opcode == TCPOPT_NOP) {
+ offset++;
+ continue;
+ }
+
+ if (offset + 1 >= optlen)
+ break;
+
+ opsize = ptr[offset + 1];
+ if (opsize < 2 || offset + opsize > optlen)
+ break;
+
+ if (opcode == TCPOPT_TIMESTAMP && opsize == TCPOLEN_TIMESTAMP)
+ return (__be32 *)(ptr + offset + 2);
+
+ offset += opsize;
+ }
+
+ return NULL;
+}
+
+static void nf_nat_update_tcp_ts_offset(struct nf_conn *ct, struct sk_buff *skb)
+{
+ __be32 *tsptr;
+ struct net *net;
+ struct tcphdr *th;
+ struct tcp_sock *tp;
+ union tcp_seq_and_ts_off st;
+ struct nf_conntrack_tuple *orig_tuple;
+ struct nf_conntrack_tuple *reply_tuple;
+
+ orig_tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
+ reply_tuple = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
+ if (orig_tuple->src.u.tcp.port == reply_tuple->dst.u.tcp.port)
+ return;
+
+ th = tcp_hdr(skb);
+ if (!th || !th->syn || th->ack)
+ return;
+
+ net = nf_ct_net(ct);
+ if (READ_ONCE(net->ipv4.sysctl_tcp_timestamps) != 1)
+ return;
+
+ if (!skb->sk)
+ return;
+
+ tsptr = nf_nat_tcp_ts_option_ptr(skb);
+ if (!tsptr)
+ return;
+
+ switch (nf_ct_l3num(ct)) {
+ case NFPROTO_IPV4:
+ st = secure_tcp_seq_and_ts_off(net, reply_tuple->dst.u3.ip,
+ reply_tuple->src.u3.ip,
+ reply_tuple->dst.u.tcp.port,
+ reply_tuple->src.u.tcp.port);
+ break;
+#if IS_ENABLED(CONFIG_IPV6)
+ case NFPROTO_IPV6:
+ st = secure_tcpv6_seq_and_ts_off(net, reply_tuple->dst.u3.ip6,
+ reply_tuple->src.u3.ip6,
+ reply_tuple->dst.u.tcp.port,
+ reply_tuple->src.u.tcp.port);
+ break;
+#endif
+ default:
+ return;
+ }
+
+ tp = tcp_sk(skb->sk);
+ *tsptr = htonl(tcp_skb_timestamp_ts(tp->tcp_usec_ts, skb) + st.ts_off);
+ WRITE_ONCE(tp->tsoffset, st.ts_off);
+}
+
unsigned int
nf_nat_inet_fn(void *priv, struct sk_buff *skb,
const struct nf_hook_state *state)
@@ -937,8 +1032,14 @@ nf_nat_inet_fn(void *priv, struct sk_buff *skb,
state);
if (ret != NF_ACCEPT)
return ret;
- if (nf_nat_initialized(ct, maniptype))
+ if (nf_nat_initialized(ct, maniptype)) {
+ if (state->hook == NF_INET_POST_ROUTING &&
+ nf_ct_protonum(ct) == IPPROTO_TCP &&
+ (ct->status & IPS_SRC_NAT)) {
+ nf_nat_update_tcp_ts_offset(ct, skb);
+ }
goto do_nat;
+ }
}
null_bind:
ret = nf_nat_alloc_null_binding(ct, state->hook);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH rdma-next 08/13] RDMA/cgroup: Scope rdma cgroup device visibility to the net namespace
From: Michal Koutný @ 2026-07-09 13:04 UTC (permalink / raw)
To: Jiri Pirko
Cc: linux-rdma, cgroups, netdev, linux-s390, linux-kselftest, jgg,
leon, parav, mbloch, cmeiohas, roman.gushchin, bvanassche,
zyjzyj2000, shuah, tj, hannes, alibuda, dust.li, sidraya, wenjia
In-Reply-To: <20260709095532.855647-9-jiri@resnulli.us>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
Hi.
On Thu, Jul 09, 2026 at 11:55:27AM +0200, Jiri Pirko <jiri@resnulli.us> wrote:
> index 993446ab66d0..4523c1884d67 100644
> --- a/Documentation/admin-guide/cgroup-v2.rst
> +++ b/Documentation/admin-guide/cgroup-v2.rst
> @@ -2752,6 +2752,13 @@ RDMA
> The "rdma" controller regulates the distribution and accounting of
> RDMA resources.
>
> +When RDMA devices are isolated per network namespace (exclusive mode),
> +device names are unique only within a network namespace. The device lines
> +below are therefore scoped to the reading or writing process's network
> +namespace: only devices accessible from that namespace are listed, and a
> +limit is applied to the device of that name in that namespace. Configure
> +limits from the same network namespace as the workloads.
OK.
> --- a/include/linux/cgroup_rdma.h
> +++ b/include/linux/cgroup_rdma.h
> @@ -7,6 +7,7 @@
> #define _CGROUP_RDMA_H
>
> #include <linux/cgroup.h>
> +#include <net/net_namespace.h>
>
> enum rdmacg_resource_type {
> RDMACG_RESOURCE_HCA_HANDLE,
> @@ -34,6 +35,15 @@ struct rdmacg_device {
> struct list_head dev_node;
> struct list_head rpools;
> char *name;
> + /*
> + * Net namespace the device belongs to. @netns_shared mirrors
> + * ib_devices_shared_netns: when true the device is visible from every
> + * net namespace (shared mode); otherwise @net is the only namespace
> + * that may see and configure it. @netns_shared is updated when the
> + * sharing mode changes, so use {READ,WRITE}_ONCE() to access it.
> + */
> + possible_net_t net;
> + bool netns_shared;
Any reason to store the netns_shared split per device? (IIUC, it's a
global parameter.)
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* Re: Please backport bridge multicast exponential field encoding fix series to 6.1.y/6.6.y/6.12.y/6.18.y/7.0.y
From: Ujjal Roy @ 2026-07-09 13:05 UTC (permalink / raw)
To: Greg KH
Cc: Linux Stable, David S . Miller, Eric Dumazet, Jakub Kicinski,
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: <2026070954-activist-left-8303@gregkh>
On Thu, Jul 9, 2026 at 6:23 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, Jul 09, 2026 at 06:12:40PM +0530, Ujjal Roy wrote:
> > On Thu, Jul 9, 2026 at 4:34 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, Jul 09, 2026 at 10:13:27AM +0000, Ujjal Roy wrote:
> > > > Hi Greg,
> > > >
> > > > Please consider backporting the following bridge multicast fix series to 6.1.y, 6.6.y, 6.12.y, 6.18.y and 7.0.y.
> > > >
> > > > 726fa7da2d8c ("ipv4: igmp: get rid of IGMPV3_{QQIC,MRC} and simplify calculation")
> > > > 12cfb4ecc471 ("ipv6: mld: rename mldv2_mrc() and add mldv2_qqi()")
> > > > 95bfd196f0dc ("ipv4: igmp: encode multicast exponential fields")
> > > > e51560f4220a ("ipv6: mld: encode multicast exponential fields")
> > > > 529dbe762de0 ("selftests: net: bridge: add MRC and QQIC field encoding tests")
> > >
> > > Why is any of this needed in older kernels?
> > >
> > > And 7.0.y is long end-of-life.
> > >
> > > And why, if this does fix issues, was it not tagged for stable to start
> > > with?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I already explained this in the email thread, "Please backport bridge
> > multicast exponential field encoding fix series to stable kernels".
>
> Sorry, but that's not here (remember, some of us get 1000+ emails a
> day.)
>
> Please explain why patches need to be backported when asking for them to
> be backported.
>
> thanks,
>
> greg k-h
Sorry for breaking the thread. I understand your point, I will
maintain this in the future.
How should I send the patchset that addresses the conflicts on 5.10.y
and 7.1.y? Shall I send the conflicts patchset as a series via a
different thread or how? I've never done this before, so I'm asking.
Here is the explanation for why the patches need to be backported:
History: The multicast stack currently supports decoding of IGMPv3 and
MLDv2 exponential timer field encodings, but lacks the corresponding
encoding logic when generating multicast query packets. As a result,
query intervals and response codes exceeding the linear encoding range
can be transmitted incorrectly. This can cause multicast queriers and
listeners to interpret different timing values, resulting in protocol
interoperability issues, membership timeouts, and premature multicast
group expiration.
Testing: The series adds the missing encoding support for both IGMPv3
and MLDv2 and includes selftests that validate the behavior.
I backported the series to v6.6.123.2 and verified the accompanying
selftests. The selftests fail on the unpatched kernel and pass after
applying the series, demonstrating both the bug and the effectiveness
of the fix.
Given that this is a protocol correctness issue affecting multicast
query generation, please consider backporting the complete series to
all applicable stable kernels.
^ permalink raw reply
* Re: [PATCH nf] ipvs: make destination flags atomic
From: Julian Anastasov @ 2026-07-09 13:06 UTC (permalink / raw)
To: Florian Westphal
Cc: Yizhou Zhao, Simon Horman, David Ahern, Ido Schimmel,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Pablo Neira Ayuso, Phil Sutter, Alexander Frolkin, netdev,
lvs-devel, linux-kernel, netfilter-devel, coreteam, stable,
Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li, Ke Xu
In-Reply-To: <ak-KErd1a0NHGN-D@strlen.de>
Hello,
On Thu, 9 Jul 2026, Florian Westphal wrote:
> Julian Anastasov <ja@ssi.bg> wrote:
> > After looking again at the code, I think we can
> > do it in different way:
> >
> > - IP_VS_DEST_F_AVAILABLE and IP_VS_DEST_F_OVERLOAD are defined
> > in include/uapi/linux/ip_vs.h but we never export them to user
> > space. So, we are free to change them. We can move them to
> > include/net/ip_vs.h, see below...
> >
> > - IP_VS_DEST_F_AVAILABLE is changed only under service_mutex,
> > so we can keep its usage
> >
> > - IP_VS_DEST_F_OVERLOAD needs different access methods.
> > We can add 'unsigned long flags2;', may be after l_threshold.
> > And to switch to such usage (F_OVERLOAD -> FL_OVERLOAD):
> >
> > - test_bit(IP_VS_DEST_FL_OVERLOAD, &dest->flags2)
> > - set_bit(IP_VS_DEST_FL_OVERLOAD, &dest->flags2)
> >
> > Sometimes if (test_bit()) clear_bit() can avoid
> > full memory barrier in ip_vs_dest_update_overload()
> >
> > - clear_bit(IP_VS_DEST_FL_OVERLOAD, &dest->flags2)
> > test_bit() guard can help here too
> >
> > As there are other races involved, something like
> > this can be a starting point for such change. It tries harder
> > to update the overload flag on dest edit/add but it does not
> > include the proposed bitops:
> >
> > diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
> > index 49297fec448a..b34631270e24 100644
>
> Who is supposed to do what?
>
> I.e., are you going to submit this officially as replacement
> for the v2 of this patch or do you expect the sumbitters of
> this patch to rework their v2 along these lines?
I can sumbit the ip_vs_dest_update_overload()
part as separate patch which can be followed by patch(es)
that convert the overload flag to bitops.
I'll wait for comments from Yizhou Zhao, he should
tell me if he is willing to convert the overload flag as
additional patch.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net v2] nfc: llcp: bound the connect_sn TLV walk to the skb
From: Doruk Tan Ozturk @ 2026-07-09 13:12 UTC (permalink / raw)
To: david, oe-linux-nfc
Cc: horms, david.laight.linux, netdev, linux-kernel, stable,
Doruk Tan Ozturk
Commit 27256cdb290e ("nfc: llcp: bound SNL TLV parsing to the skb and
add length checks") fixed the unbounded TLV walk in nfc_llcp_recv_snl(),
and commit d8bd2dedbde5 ("nfc: llcp: fix OOB read and u8 offset wrap in
TLV parsers") subsequently bounded nfc_llcp_parse_gb_tlv() and
nfc_llcp_parse_connection_tlv(). One sibling parser sharing the same
pattern remains unbounded: nfc_llcp_connect_sn().
nfc_llcp_connect_sn() walks a TLV list, reading a two-byte header
(type, length) followed by length bytes of value, without checking that
the two header bytes or the declared length stay within the buffer. It
returns a pointer to a service name of up to 255 bytes that may point
past the end of the skb; it is subsequently consumed by memcmp() in
nfc_llcp_sock_from_sn(). In addition tlv_array_len was computed as
"skb->len - LLCP_HEADER_SIZE" in size_t, so a CONNECT/CC frame shorter
than the LLCP header underflows to a huge length and the walk runs far
past the buffer.
nfc_llcp_connect_sn() is reachable from nfc_llcp_recv_connect() and
nfc_llcp_recv_cc(), i.e. from received CONNECT and CC PDUs. A nearby
NFC device can reach this without authentication; LLCP link activation
happens automatically after NFC-DEP, and the nfc_llcp_rx_skb()
dispatcher applies no minimum-length guard.
Walk the TLV list by pointer, bounded by skb_tail_pointer(skb), and
validate each declared length before use, matching the approach already
used for nfc_llcp_recv_snl(). Starting the walk at
&skb->data[LLCP_HEADER_SIZE] against the tail pointer also removes the
size_t underflow for short frames.
Found by 0sec automated security-research tooling (https://0sec.ai).
Fixes: d646960f7986 ("NFC: Initial LLCP support")
Cc: stable@vger.kernel.org
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
v2: drop the nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv()
hunks - fixed independently by d8bd2dedbde5. This resend covers only
the still-unbounded nfc_llcp_connect_sn().
v1: https://lore.kernel.org/netdev/20260705113505 net/nfc/llcp_core.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index aed5fe1afef0..0de20279e046 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -849,13 +849,16 @@ static struct nfc_llcp_sock *nfc_llcp_sock_get_sn(struct nfc_llcp_local *local,
static const u8 *nfc_llcp_connect_sn(const struct sk_buff *skb, size_t *sn_len)
{
u8 type, length;
- const u8 *tlv = &skb->data[2];
- size_t tlv_array_len = skb->len - LLCP_HEADER_SIZE, offset = 0;
+ const u8 *tlv = &skb->data[LLCP_HEADER_SIZE];
+ const u8 *tlv_end = skb_tail_pointer(skb);
- while (offset < tlv_array_len) {
+ while (tlv + 2 < tlv_end) {
type = tlv[0];
length = tlv[1];
+ if (tlv + 2 + length > tlv_end)
+ break;
+
pr_debug("type 0x%x length %d\n", type, length);
if (type == LLCP_TLV_SN) {
@@ -863,7 +866,6 @@ static const u8 *nfc_llcp_connect_sn(const struct sk_buff *skb, size_t *sn_len)
return &tlv[2];
}
- offset += length + 2;
tlv += length + 2;
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] mptcp: only set DATA_FIN when a mapping is present
From: Michael Bommarito @ 2026-07-09 13:12 UTC (permalink / raw)
To: Matthieu Baerts
Cc: gang.yan, Geliang Tang, Paolo Abeni, Eric Dumazet, Jakub Kicinski,
mptcp, netdev, linux-kernel, Mat Martineau
In-Reply-To: <8d735844-dccb-4a65-b7fc-468d144ebc02@kernel.org>
On Thu, Jul 9, 2026 at 8:27 AM Matthieu Baerts <matttbe@kernel.org> wrote:
> By chance, do you have a reproducer? Maybe using Packetdrill with MPTCP
> support? [1]
> If not, how did you discover this issue?
Yup, I'll send to you offlist. It's a custom Python/TUN/qemu setup,
not Packetdrill, but I'm guessing it could be ported or extended for
testing/fuzzing.
I discovered it with my homegrown agentic stack, which is a Rube
Goldberg machine full of various tools (like cocci, semgrep) and
knowledge graphs (built with libclang). The agent logs suggest that
it came from a family of rules that surfaces suspicious struct init
candidates, which I can share too.
> If I may add, please also send new version in a separate thread, not as
> a reply, not to confuse various tools, as mentioned in the same doc.
Sure, thanks to both you and Gang for the feedback. I'll send a v3
based on your suggestions later today.
Thanks,
Mike
^ permalink raw reply
* [PATCH net] mac802154: llsec: reject frames shorter than the authentication tag
From: Doruk Tan Ozturk @ 2026-07-09 13:12 UTC (permalink / raw)
To: alex.aring, stefan, miquel.raynal
Cc: davem, edumazet, kuba, pabeni, horms, phoebe.buckheister,
linux-wpan, netdev, linux-kernel, stable, Doruk Tan Ozturk
llsec_do_decrypt_auth() computes the associated-data length for the
AEAD request as
assoclen += datalen - authlen;
where datalen is the number of bytes after the MAC header and authlen
(4, 8 or 16) is the length of the authentication tag. Nothing verifies
that the frame actually carries at least authlen payload bytes. A
secured frame whose payload is shorter than the tag makes
datalen - authlen negative; assoclen is then passed to
aead_request_set_ad() as an unsigned value close to 4 GiB, so
crypto_aead_decrypt() walks far off the end of the scatterlist that
only spans the real frame.
The frame is fully attacker-controlled and reaches this path from any
IEEE 802.15.4 peer in radio range. Reject frames whose payload is
shorter than the authentication tag before the subtraction.
Dynamically reproduced on a KASAN kernel as a general-protection-fault
in the AEAD scatterwalk, and the fix confirmed.
Fixes: 4c14a2fb5d14 ("mac802154: add llsec decryption method")
Cc: stable@vger.kernel.org
Reported-by: Doruk Tan Ozturk <doruk@0sec.ai>
Assisted-by: 0sec:claude-opus-4-8
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
net/mac802154/llsec.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index 5e7cc11fab3a..364a1ac1d771 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -893,6 +893,11 @@ llsec_do_decrypt_auth(struct sk_buff *skb, const struct mac802154_llsec *sec,
sg_init_one(&sg, skb_mac_header(skb), assoclen + datalen);
+ if (datalen < authlen) {
+ kfree_sensitive(req);
+ return -EBADMSG;
+ }
+
if (!(hdr->sec.level & IEEE802154_SCF_SECLEVEL_ENC)) {
assoclen += datalen - authlen;
datalen = authlen;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] net: xscale: ixp4xx: add missing MODULE_DEVICE_TABLE()
From: Linus Walleij @ 2026-07-09 13:14 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Imre Kaloz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <20260705001931.74149-1-pengpeng@iscas.ac.cn>
On Sun, Jul 5, 2026 at 2:19 AM Pengpeng Hou <pengpeng@iscas.ac.cn> wrote:
> The driver has a match table for the of bus wired into its driver
> structure, but the table is not exported with MODULE_DEVICE_TABLE().
>
> Add the missing MODULE_DEVICE_TABLE() entry so module alias information
> is generated for automatic module loading.
>
> This is a source-level fix. It does not claim dynamic hardware
> reproduction; the evidence is the driver-owned match table, its use by
> the driver registration structure, and the missing module alias
> publication.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH net v2] netfilter: nf_nat: recalculate TCP TS offset when snat change sport
From: Florian Westphal @ 2026-07-09 13:30 UTC (permalink / raw)
To: xietangxin
Cc: Pablo Neira Ayuso, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Phil Sutter, Simon Horman, netfilter-devel, coreteam,
netdev, linux-kernel, Victor Nogueira, gaoxingwang, huyizhen
In-Reply-To: <20260709131216.2189210-1-xietangxin@h-partners.com>
xietangxin <xietangxin@h-partners.com> wrote:
> v1: https://lore.kernel.org/all/20260629093408.3927103-1-xietangxin@h-partners.com/
> ---
> net/netfilter/nf_nat_core.c | 103 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 102 insertions(+), 1 deletion(-)
>
> diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
> index 63ff6b4d5d21..9d0b316fa3c7 100644
> --- a/net/netfilter/nf_nat_core.c
> +++ b/net/netfilter/nf_nat_core.c
> @@ -16,6 +16,8 @@
> #include <linux/siphash.h>
> #include <linux/rtnetlink.h>
>
> +#include <net/tcp.h>
> +#include <net/secure_seq.h>
> #include <net/netfilter/nf_conntrack_bpf.h>
> #include <net/netfilter/nf_conntrack_core.h>
> #include <net/netfilter/nf_conntrack_helper.h>
> @@ -894,6 +896,99 @@ static bool in_vrf_postrouting(const struct nf_hook_state *state)
> return false;
> }
>
> +static __be32 *nf_nat_tcp_ts_option_ptr(const struct sk_buff *skb)
> +{
> + struct tcphdr *th;
> + unsigned char *ptr;
> + unsigned char opcode;
> + unsigned char opsize;
> + unsigned int optlen, offset;
> +
> + offset = 0;
> + th = tcp_hdr(skb);
> + optlen = (th->doff - 5) * 4;
> + ptr = (unsigned char *)(th + 1);
Hmm, I don't think we should assume its in linear
area. In future someone might re-use this for forwarded
packets too.
Given you munge the packet, I think you could just call
skb_ensure_writable() early to assert entire tcp header
including options is in linear area.
> + while (offset < optlen) {
> + opcode = ptr[offset];
> + if (opcode == TCPOPT_EOL)
> + break;
> +
> + if (opcode == TCPOPT_NOP) {
> + offset++;
> + continue;
> + }
> +
> + if (offset + 1 >= optlen)
> + break;
> +
> + opsize = ptr[offset + 1];
> + if (opsize < 2 || offset + opsize > optlen)
> + break;
> + if (opcode == TCPOPT_TIMESTAMP && opsize == TCPOLEN_TIMESTAMP)
> + return (__be32 *)(ptr + offset + 2);
Maybe add a comment here that says that this is only for locally
generated packets and that linux tcp will always align the tsval.
Else, write needs put_unaligned_be32() instead of direct assign.
> +static void nf_nat_update_tcp_ts_offset(struct nf_conn *ct, struct sk_buff *skb)
> +{
> + __be32 *tsptr;
> + struct net *net;
> + struct tcphdr *th;
> + struct tcp_sock *tp;
> + union tcp_seq_and_ts_off st;
> + struct nf_conntrack_tuple *orig_tuple;
> + struct nf_conntrack_tuple *reply_tuple;
Could reorder this for reverse x-mas tree (i.e. invert
the above order...).
> + orig_tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple;
> + reply_tuple = &ct->tuplehash[IP_CT_DIR_REPLY].tuple;
> + if (orig_tuple->src.u.tcp.port == reply_tuple->dst.u.tcp.port)
> + return;
Maybe add a comment like /* no port rewrite? No need to update anything */
> + th = tcp_hdr(skb);
> + if (!th || !th->syn || th->ack)
> + return;
> +
> + net = nf_ct_net(ct);
> + if (READ_ONCE(net->ipv4.sysctl_tcp_timestamps) != 1)
> + return;
> +
Maybe add a comment that above check avoid bogus tsoff update for
non-randomized tcp timestamps?
> + if (!skb->sk)
> + return;
> +
I suggest to do this first, so that its obvious this function
is only for locally generated packets.
> + tsptr = nf_nat_tcp_ts_option_ptr(skb);
> + if (!tsptr)
> + return;
> +
> + switch (nf_ct_l3num(ct)) {
> + case NFPROTO_IPV4:
> + st = secure_tcp_seq_and_ts_off(net, reply_tuple->dst.u3.ip,
> + reply_tuple->src.u3.ip,
> + reply_tuple->dst.u.tcp.port,
> + reply_tuple->src.u.tcp.port);
> + break;
> +#if IS_ENABLED(CONFIG_IPV6)
> + case NFPROTO_IPV6:
> + st = secure_tcpv6_seq_and_ts_off(net, reply_tuple->dst.u3.ip6,
> + reply_tuple->src.u3.ip6,
> + reply_tuple->dst.u.tcp.port,
> + reply_tuple->src.u.tcp.port);
> + break;
> +#endif
> + default:
> + return;
> + }
> +
> + tp = tcp_sk(skb->sk);
> + *tsptr = htonl(tcp_skb_timestamp_ts(tp->tcp_usec_ts, skb) + st.ts_off);
>
> unsigned int
> nf_nat_inet_fn(void *priv, struct sk_buff *skb,
> const struct nf_hook_state *state)
> @@ -937,8 +1032,14 @@ nf_nat_inet_fn(void *priv, struct sk_buff *skb,
> state);
> if (ret != NF_ACCEPT)
> return ret;
> - if (nf_nat_initialized(ct, maniptype))
> + if (nf_nat_initialized(ct, maniptype)) {
> + if (state->hook == NF_INET_POST_ROUTING &&
I wonder if this should be LOCAL_OUT. I do understand that many
people use SNAT/MASQUERADE from postrouting to deal with both local and
forwarded traffic at the same time, so more of a open question.
^ permalink raw reply
* Re: [PATCH net-next v20 05/12] virtio_net: Query and set flow filter caps
From: Shahar Shitrit @ 2026-07-09 13:37 UTC (permalink / raw)
To: Michael S. Tsirkin, Daniel Jurgens
Cc: netdev, jasowang, pabeni, virtualization, parav, yohadt, xuanzhuo,
eperezma, jgg, kevin.tian, kuba, andrew+netdev, edumazet
In-Reply-To: <20260208063807-mutt-send-email-mst@kernel.org>
On 08/02/2026 13:51, Michael S. Tsirkin wrote:
> On Thu, Feb 05, 2026 at 04:47:00PM -0600, Daniel Jurgens wrote:
>> When probing a virtnet device, attempt to read the flow filter
>> capabilities. In order to use the feature the caps must also
>> be set. For now setting what was read is sufficient.
>>
>> This patch adds uapi definitions virtio_net flow filters define in
>> version 1.4 of the VirtIO spec.
>>
>> Signed-off-by: Daniel Jurgens <danielj@nvidia.com>
>> Reviewed-by: Parav Pandit <parav@nvidia.com>
>> Reviewed-by: Shahar Shitrit <shshitrit@nvidia.com>
>>
>> ---
>> v4:
>> - Validate the length in the selector caps
>> - Removed __free usage.
>> - Removed for(int.
>> v5:
>> - Remove unneed () after MAX_SEL_LEN macro (test bot)
>> v6:
>> - Fix sparse warning "array of flexible structures" Jakub K/Simon H
>> - Use new variable and validate ff_mask_size before set_cap. MST
>> v7:
>> - Set ff->ff_{caps, mask, actions} NULL in error path. Paolo Abeni
>> - Return errors from virtnet_ff_init, -ENOTSUPP is not fatal. Xuan
>>
>> v8:
>> - Use real_ff_mask_size when setting the selector caps. Jason Wang
>>
>> v9:
>> - Set err after failed memory allocations. Simon Horman
>>
>> v10:
>> - Return -EOPNOTSUPP in virnet_ff_init before allocing any memory.
>> Jason/Paolo.
>>
>> v11:
>> - Return -EINVAL if any resource limit is 0. Simon Horman
>> - Ensure we don't overrun alloced space of ff->ff_mask by moving the
>> real_ff_mask_size > ff_mask_size check into the loop. Simon Horman
>>
>> v12:
>> - Move uapi includes to virtio_net.c vs header file. MST
>> - Remove kernel.h header in virtio_net_ff uapi. MST
>> - WARN_ON_ONCE in error paths validating selectors. MST
>> - Move includes from .h to .c files. MST
>> - Add WARN_ON_ONCE if obj_destroy fails. MST
>> - Comment cleanup in virito_net_ff.h uapi. MST
>> - Add 2 byte pad to the end of virtio_net_ff_cap_data.
>> https://lore.kernel.org/virtio-comment/20251119044029-mutt-send-email-mst@kernel.org/T/#m930988a5d3db316c68546d8b61f4b94f6ebda030
>> - Cleanup and reinit in the freeze/restore path. MST
>>
>> v13:
>> - Added /* private: */ comment before reserved field. Jakub
>> - Change ff_mask validation to break at unkonwn selector type. This
>> will allow compatability with newer controllers if the types of
>> selectors is expanded. MST
>>
>> v14:
>> - Handle err from virtnet_ff_init in virtnet_restore_up. MST
>>
>> v15:
>> - In virtnet_restore_up only call virtnet_close in err path if
>> netif_runnig. AI
>>
>> v16:
>> - Return 0 from virtnet_restore_up if virtnet_init_ff return not
>> supported. AI
>>
>> v17:
>> - During restore freeze_down on error during ff_init. AI
>>
>> v18:
>> - Changed selector cap validation to verify size for each type
>> instead of just checking they weren't bigger than max size. AI
>> - Added __count_by attribute to flexible members in uapi. Paolo A
>>
>> v19:
>> - Fixed ;; and incorrect plural in comment. AI
>>
>> v20:
>> - include uapi/linux/stddef.h for __counted_by. AI
>
> AI has led you astray, sadly (
will fix in v21
>
>
>
>
>> ---
>> drivers/net/virtio_net.c | 231 ++++++++++++++++++++++++++++-
>> include/uapi/linux/virtio_net_ff.h | 91 ++++++++++++
>> 2 files changed, 321 insertions(+), 1 deletion(-)
>> create mode 100644 include/uapi/linux/virtio_net_ff.h
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index db88dcaefb20..2cfa37e2f83f 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -26,6 +26,11 @@
>> #include <net/netdev_rx_queue.h>
>> #include <net/netdev_queues.h>
>> #include <net/xdp_sock_drv.h>
>> +#include <linux/virtio_admin.h>
>> +#include <net/ipv6.h>
>> +#include <net/ip.h>
>> +#include <uapi/linux/virtio_pci.h>
>> +#include <uapi/linux/virtio_net_ff.h>
>>
>> static int napi_weight = NAPI_POLL_WEIGHT;
>> module_param(napi_weight, int, 0444);
>> @@ -281,6 +286,14 @@ static const struct virtnet_stat_desc virtnet_stats_tx_speed_desc_qstat[] = {
>> VIRTNET_STATS_DESC_TX_QSTAT(speed, ratelimit_packets, hw_drop_ratelimits),
>> };
>>
>> +struct virtnet_ff {
>> + struct virtio_device *vdev;
>> + bool ff_supported;
>> + struct virtio_net_ff_cap_data *ff_caps;
>> + struct virtio_net_ff_cap_mask_data *ff_mask;
>> + struct virtio_net_ff_actions *ff_actions;
>> +};
>> +
>> #define VIRTNET_Q_TYPE_RX 0
>> #define VIRTNET_Q_TYPE_TX 1
>> #define VIRTNET_Q_TYPE_CQ 2
>> @@ -488,6 +501,7 @@ struct virtnet_info {
>> TRAILING_OVERLAP(struct virtio_net_rss_config_trailer, rss_trailer, hash_key_data,
>> u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
>> );
>> + struct virtnet_ff ff;
>> };
>> static_assert(offsetof(struct virtnet_info, rss_trailer.hash_key_data) ==
>> offsetof(struct virtnet_info, rss_hash_key_data));
>> @@ -526,6 +540,7 @@ static struct sk_buff *virtnet_skb_append_frag(struct sk_buff *head_skb,
>> struct page *page, void *buf,
>> int len, int truesize);
>> static void virtnet_xsk_completed(struct send_queue *sq, int num);
>> +static void remove_vq_common(struct virtnet_info *vi);
>>
>> enum virtnet_xmit_type {
>> VIRTNET_XMIT_TYPE_SKB,
>> @@ -5684,6 +5699,192 @@ static const struct netdev_stat_ops virtnet_stat_ops = {
>> .get_base_stats = virtnet_get_base_stats,
>> };
>>
>> +static size_t get_mask_size(u16 type)
>> +{
>> + switch (type) {
>> + case VIRTIO_NET_FF_MASK_TYPE_ETH:
>> + return sizeof(struct ethhdr);
>> + case VIRTIO_NET_FF_MASK_TYPE_IPV4:
>> + return sizeof(struct iphdr);
>> + case VIRTIO_NET_FF_MASK_TYPE_IPV6:
>> + return sizeof(struct ipv6hdr);
>> + case VIRTIO_NET_FF_MASK_TYPE_TCP:
>> + return sizeof(struct tcphdr);
>> + case VIRTIO_NET_FF_MASK_TYPE_UDP:
>> + return sizeof(struct udphdr);
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int virtnet_ff_init(struct virtnet_ff *ff, struct virtio_device *vdev)
>> +{
>> + size_t ff_mask_size = sizeof(struct virtio_net_ff_cap_mask_data) +
>> + sizeof(struct virtio_net_ff_selector) *
>> + VIRTIO_NET_FF_MASK_TYPE_MAX;
>> + struct virtio_admin_cmd_query_cap_id_result *cap_id_list;
>> + struct virtio_net_ff_selector *sel;
>> + unsigned long sel_types = 0;
>> + size_t real_ff_mask_size;
>> + int err;
>> + int i;
>> +
>> + if (!vdev->config->admin_cmd_exec)
>> + return -EOPNOTSUPP;
>> +
>> + cap_id_list = kzalloc(sizeof(*cap_id_list), GFP_KERNEL);
>> + if (!cap_id_list)
>> + return -ENOMEM;
>> +
>> + err = virtio_admin_cap_id_list_query(vdev, cap_id_list);
>> + if (err)
>> + goto err_cap_list;
>> +
>> + if (!(VIRTIO_CAP_IN_LIST(cap_id_list,
>> + VIRTIO_NET_FF_RESOURCE_CAP) &&
>> + VIRTIO_CAP_IN_LIST(cap_id_list,
>> + VIRTIO_NET_FF_SELECTOR_CAP) &&
>> + VIRTIO_CAP_IN_LIST(cap_id_list,
>> + VIRTIO_NET_FF_ACTION_CAP))) {
>> + err = -EOPNOTSUPP;
>> + goto err_cap_list;
>> + }
>> +
>> + ff->ff_caps = kzalloc(sizeof(*ff->ff_caps), GFP_KERNEL);
>> + if (!ff->ff_caps) {
>> + err = -ENOMEM;
>> + goto err_cap_list;
>> + }
>> +
>> + err = virtio_admin_cap_get(vdev,
>> + VIRTIO_NET_FF_RESOURCE_CAP,
>> + ff->ff_caps,
>> + sizeof(*ff->ff_caps));
>> +
>> + if (err)
>> + goto err_ff;
>> +
>> + if (!ff->ff_caps->groups_limit ||
>> + !ff->ff_caps->classifiers_limit ||
>> + !ff->ff_caps->rules_limit ||
>> + !ff->ff_caps->rules_per_group_limit) {
>> + err = -EINVAL;
>> + goto err_ff;
>> + }
>> +
>> + /* VIRTIO_NET_FF_MASK_TYPE start at 1 */
>> + for (i = 1; i <= VIRTIO_NET_FF_MASK_TYPE_MAX; i++)
>> + ff_mask_size += get_mask_size(i);
>> +
>> + ff->ff_mask = kzalloc(ff_mask_size, GFP_KERNEL);
>> + if (!ff->ff_mask) {
>> + err = -ENOMEM;
>> + goto err_ff;
>> + }
>> +
>> + err = virtio_admin_cap_get(vdev,
>> + VIRTIO_NET_FF_SELECTOR_CAP,
>> + ff->ff_mask,
>> + ff_mask_size);
>
> So ff_actions is from device and ff_actions->count does not seem to be checked.
>
> If device somehow gains a larger mask down the road, can it not then overflow?
> or malicious?
see below
>
>
>> +
>> + if (err)
>> + goto err_ff_mask;
>> +
>> + ff->ff_actions = kzalloc(sizeof(*ff->ff_actions) +
>> + VIRTIO_NET_FF_ACTION_MAX,
>> + GFP_KERNEL);
>> + if (!ff->ff_actions) {
>> + err = -ENOMEM;
>> + goto err_ff_mask;
>> + }
>> +
>> + err = virtio_admin_cap_get(vdev,
>> + VIRTIO_NET_FF_ACTION_CAP,
>> + ff->ff_actions,
>> + sizeof(*ff->ff_actions) + VIRTIO_NET_FF_ACTION_MAX);
>
> So ff_actions is from device and ff_actions->count is not checked.
>
> If device gains a ton of actions down the road, can it not then overflow?
> or malicious?
it can't overflow, as it can write up to sizeof(*ff->ff_actions) +
VIRTIO_NET_FF_ACTION_MAX bytes. But it is a valid concern in case of
someone in the future iterates on count. Better to handle it now so it
won't be forgotten. Checking that ff_actions->count doesn't exceed
VIRTIO_NET_FF_ACTION_MAX can break backward compatibility. If this max
value is extended in a new spec/controller then this driver would fail
to load. Instead, I will assign ff->ff_actions->count with the minimum
of what we got and the max.
>
>> +
>> + if (err)
>> + goto err_ff_action;
>> +
>> + err = virtio_admin_cap_set(vdev,
>> + VIRTIO_NET_FF_RESOURCE_CAP,
>> + ff->ff_caps,
>> + sizeof(*ff->ff_caps));
>> + if (err)
>> + goto err_ff_action;
>> +
>> + real_ff_mask_size = sizeof(struct virtio_net_ff_cap_mask_data);
>> + sel = (void *)&ff->ff_mask->selectors;
>> +
>> + for (i = 0; i < ff->ff_mask->count; i++) {
>> + /* If the selector type is unknown it may indicate the spec
>> + * has been revised to include new types of selectors
>> + */
>> + if (sel->type > VIRTIO_NET_FF_MASK_TYPE_MAX)
>
> do you want to check sel->type 0 too?
yes, will add in v21.
>
>> + break;
>
> but count remains unchanged? should we not to reduce count here
> so device knows what driver can drive?
we should. will add it in v21.
>
>
>> +
>> + if (sel->length != get_mask_size(sel->type) ||
>> + test_and_set_bit(sel->type, &sel_types)) {
>> + WARN_ON_ONCE(true);
>> + err = -EINVAL;
>> + goto err_ff_action;
>> + }
>> + real_ff_mask_size += sizeof(struct virtio_net_ff_selector) + sel->length;
>> + if (real_ff_mask_size > ff_mask_size) {
>> + WARN_ON_ONCE(true);
>> + err = -EINVAL;
>> + goto err_ff_action;
>> + }
>> + sel = (void *)sel + sizeof(*sel) + sel->length;
>> + }
>> +
>> + err = virtio_admin_cap_set(vdev,
>> + VIRTIO_NET_FF_SELECTOR_CAP,
>> + ff->ff_mask,
>> + real_ff_mask_size);
>> + if (err)
>> + goto err_ff_action;
>> +
>> + err = virtio_admin_cap_set(vdev,
>> + VIRTIO_NET_FF_ACTION_CAP,
>> + ff->ff_actions,
>> + sizeof(*ff->ff_actions) + VIRTIO_NET_FF_ACTION_MAX);
>> + if (err)
>> + goto err_ff_action;
>> +
>> + ff->vdev = vdev;
>> + ff->ff_supported = true;
>> +
>> + kfree(cap_id_list);
>> +
>> + return 0;
>> +
>> +err_ff_action:
>> + kfree(ff->ff_actions);
>> + ff->ff_actions = NULL;
>> +err_ff_mask:
>> + kfree(ff->ff_mask);
>> + ff->ff_mask = NULL;
>> +err_ff:
>> + kfree(ff->ff_caps);
>> + ff->ff_caps = NULL;
>> +err_cap_list:
>> + kfree(cap_id_list);
>> +
>> + return err;
>> +}
>> +
>> +static void virtnet_ff_cleanup(struct virtnet_ff *ff)
>> +{
>> + if (!ff->ff_supported)
>> + return;
>> +
>> + kfree(ff->ff_actions);
>> + kfree(ff->ff_mask);
>> + kfree(ff->ff_caps);
>> + ff->ff_supported = false;
>> +}
>> +
>> static void virtnet_freeze_down(struct virtio_device *vdev)
>> {
>> struct virtnet_info *vi = vdev->priv;
>> @@ -5702,6 +5903,10 @@ static void virtnet_freeze_down(struct virtio_device *vdev)
>> netif_tx_lock_bh(vi->dev);
>> netif_device_detach(vi->dev);
>> netif_tx_unlock_bh(vi->dev);
>> +
>> + rtnl_lock();
>> + virtnet_ff_cleanup(&vi->ff);
>> + rtnl_unlock();
>> }
>>
>> static int init_vqs(struct virtnet_info *vi);
>> @@ -5727,10 +5932,23 @@ static int virtnet_restore_up(struct virtio_device *vdev)
>> return err;
>> }
>>
>> + /* Initialize flow filters. Not supported is an acceptable and common
>> + * return code
>> + */
>> + rtnl_lock();
>> + err = virtnet_ff_init(&vi->ff, vi->vdev);
>> + if (err && err != -EOPNOTSUPP) {
>> + rtnl_unlock();
>> + virtnet_freeze_down(vi->vdev);
>> + remove_vq_common(vi);
>> + return err;
>> + }
>> + rtnl_unlock();
>> +
>> netif_tx_lock_bh(vi->dev);
>> netif_device_attach(vi->dev);
>> netif_tx_unlock_bh(vi->dev);
>> - return err;
>> + return 0;
>> }
>>
>> static int virtnet_set_guest_offloads(struct virtnet_info *vi, u64 offloads)
>> @@ -7058,6 +7276,15 @@ static int virtnet_probe(struct virtio_device *vdev)
>> }
>> vi->guest_offloads_capable = vi->guest_offloads;
>>
>> + /* Initialize flow filters. Not supported is an acceptable and common
>> + * return code
>> + */
>> + err = virtnet_ff_init(&vi->ff, vi->vdev);
>> + if (err && err != -EOPNOTSUPP) {
>> + rtnl_unlock();
>> + goto free_unregister_netdev;
>> + }
>> +
>> rtnl_unlock();
>>
>> err = virtnet_cpu_notif_add(vi);
>> @@ -7073,6 +7300,7 @@ static int virtnet_probe(struct virtio_device *vdev)
>>
>> free_unregister_netdev:
>> unregister_netdev(dev);
>> + virtnet_ff_cleanup(&vi->ff);
>> free_failover:
>> net_failover_destroy(vi->failover);
>> free_vqs:
>> @@ -7121,6 +7349,7 @@ static void virtnet_remove(struct virtio_device *vdev)
>> virtnet_free_irq_moder(vi);
>>
>> unregister_netdev(vi->dev);
>> + virtnet_ff_cleanup(&vi->ff);
>>
>> net_failover_destroy(vi->failover);
>>
>> diff --git a/include/uapi/linux/virtio_net_ff.h b/include/uapi/linux/virtio_net_ff.h
>> new file mode 100644
>> index 000000000000..552a6b3a8a91
>> --- /dev/null
>> +++ b/include/uapi/linux/virtio_net_ff.h
>> @@ -0,0 +1,91 @@
>> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
>> + *
>> + * Header file for virtio_net flow filters
>> + */
>> +#ifndef _LINUX_VIRTIO_NET_FF_H
>> +#define _LINUX_VIRTIO_NET_FF_H
>> +
>> +#include <linux/types.h>
>> +#include <uapi/linux/stddef.h>
>> +
>> +#define VIRTIO_NET_FF_RESOURCE_CAP 0x800
>> +#define VIRTIO_NET_FF_SELECTOR_CAP 0x801
>> +#define VIRTIO_NET_FF_ACTION_CAP 0x802
>> +
>> +/**
>> + * struct virtio_net_ff_cap_data - Flow filter resource capability limits
>> + * @groups_limit: maximum number of flow filter groups supported by the device
>> + * @classifiers_limit: maximum number of classifiers supported by the device
>> + * @rules_limit: maximum number of rules supported device-wide across all groups
>> + * @rules_per_group_limit: maximum number of rules allowed in a single group
>> + * @last_rule_priority: priority value associated with the lowest-priority rule
>> + * @selectors_per_classifier_limit: maximum selectors allowed in one classifier
>> + */
>> +struct virtio_net_ff_cap_data {
>> + __le32 groups_limit;
>> + __le32 classifiers_limit;
>> + __le32 rules_limit;
>> + __le32 rules_per_group_limit;
>> + __u8 last_rule_priority;
>> + __u8 selectors_per_classifier_limit;
>> + /* private: */
>> + __u8 reserved[2];
>> +};
>> +
>> +/**
>> + * struct virtio_net_ff_selector - Selector mask descriptor
>> + * @type: selector type, one of VIRTIO_NET_FF_MASK_TYPE_* constants
>> + * @flags: selector flags, see VIRTIO_NET_FF_MASK_F_* constants
>> + * @reserved: must be set to 0 by the driver and ignored by the device
>> + * @length: size in bytes of @mask
>> + * @reserved1: must be set to 0 by the driver and ignored by the device
>> + * @mask: variable-length mask payload for @type, length given by @length
>> + *
>> + * A selector describes a header mask that a classifier can apply. The format
>> + * of @mask depends on @type.
>> + */
>> +struct virtio_net_ff_selector {
>> + __u8 type;
>> + __u8 flags;
>> + __u8 reserved[2];
>> + __u8 length;
>> + __u8 reserved1[3];
>> + __u8 mask[] __counted_by(length);
>> +};
>> +
>> +#define VIRTIO_NET_FF_MASK_TYPE_ETH 1
>> +#define VIRTIO_NET_FF_MASK_TYPE_IPV4 2
>> +#define VIRTIO_NET_FF_MASK_TYPE_IPV6 3
>> +#define VIRTIO_NET_FF_MASK_TYPE_TCP 4
>> +#define VIRTIO_NET_FF_MASK_TYPE_UDP 5
>> +#define VIRTIO_NET_FF_MASK_TYPE_MAX VIRTIO_NET_FF_MASK_TYPE_UDP
>> +
>> +/**
>> + * struct virtio_net_ff_cap_mask_data - Supported selector mask formats
>> + * @count: number of entries in @selectors
>> + * @reserved: must be set to 0 by the driver and ignored by the device
>> + * @selectors: packed array of struct virtio_net_ff_selector.
>> + */
>> +struct virtio_net_ff_cap_mask_data {
>> + __u8 count;
>> + __u8 reserved[7];
>> + __u8 selectors[] __counted_by(count);
>
> This looks wrong to me. count is # of selectors (packed entries) not
> bytes.
right, will remove it.
> >
>
>
>> +};
>> +
>> +#define VIRTIO_NET_FF_MASK_F_PARTIAL_MASK (1 << 0)
>> +
>> +#define VIRTIO_NET_FF_ACTION_DROP 1
>> +#define VIRTIO_NET_FF_ACTION_RX_VQ 2
>> +#define VIRTIO_NET_FF_ACTION_MAX VIRTIO_NET_FF_ACTION_RX_VQ
>> +/**
>> + * struct virtio_net_ff_actions - Supported flow actions
>> + * @count: number of supported actions in @actions
>> + * @reserved: must be set to 0 by the driver and ignored by the device
>> + * @actions: array of action identifiers (VIRTIO_NET_FF_ACTION_*)
>> + */
>> +struct virtio_net_ff_actions {
>> + __u8 count;
>> + __u8 reserved[7];
>> + __u8 actions[] __counted_by(count);
>
>
> this too.
count directly represents the number of __u8 elements in actions[], so
the size of the flexible array is count * sizeof(__u8). Therefore, here
it is correct.
>
>> +};
>> +#endif
>> --
>> 2.50.1
>
>
^ permalink raw reply
* Re: [GIT PULL] wireless-2026-07-09
From: Paolo Abeni @ 2026-07-09 13:40 UTC (permalink / raw)
To: Johannes Berg, netdev; +Cc: linux-wireless
In-Reply-To: <20260709115038.243870-3-johannes@sipsolutions.net>
On 7/9/26 1:49 PM, Johannes Berg wrote:
> Sorry, I meant to send this yesterday, hoping it'd get
> in/out before netdevconf and all that, because it's
> actually really big. Mostly I've now collected many
> random LLM-induced robustness fixes (I can't really
> call most of them security fixes, though there likely
> are a few).
>
> Please pull and let us know if there's any problem.
I'm sorry I was already finalizing the rc3 net PR (which is already
quite big). I think it's not bad if this one lands in afterwards.
/P
^ permalink raw reply
* [PATCH v2 00/18] MT8189: Add support for system and base clock controllers
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud, Irving-CH Lin
This series is a continuation by AngeloGioacchino Del Regno and I of a
previous series ([1]), that adds the clock controller support for
the Mediatek MT8189 SoC and its variants (MT8371, MT8391).
The first major changes is the split of the series in two:
- one for all basic clock controllers including system ones (this
series)
- one for the multimedia and graphics related clock controllers (to be
send in the future)
We chose to separate the multimedia clock drivers from the base system
ones, as there is currently an unsolvable inter-dependency between the
power domains and multimedia clocks; the power domains need a
dual-stage bring-up, where only a part of the multimedia clocks are
accessible in the first power domain powerup stage, and the rest when
the second stage (SRAM enablement) is done.
The current workarounds for this issue, such as removing the is_enabled
operation from the impacted clock controllers clk_ops table or
let the multimedia power domain always on, were quickly discarded
for upstream.
The second major change is the dt-bindings patch that got heavily
reworked, not only because of the split choice. We took the opportunity
to regroup in the MT8186 clock and system clock dt-bindings the
description of several other Mediatek SoC (MT8188, MT8192 and MT8195)
and add in them the MT8189 new ones.
The rationale is to ease maintainability and have common files for
several currently supported SoC or new future ones, that have the same
kind of clock controller design.
Finally the pending remarks from peer reviews on the v6 revision of [1]
were also taken into account and new fixes and cleanups were also
added.
A more detailed changelog between [1] and this series:
- Removed multimedia and graphics related clock controllers code and
definitions from series
- Added new dt-bindings patches to factorise existing MT8188, MT8192
and MT8195 in MT8186 clock dt-bindings
- Heavily modified the MT8189 dt-bindings to add new compatibles
in MT8186 clock dt-bindings
- Created a new dt-bindings include for the MT8189 reset controller
definitions (include/dt-bindings/reset/mediatek,mt8189-resets.h)
- Removed unnecessary `syscon` compatible fallback from MT8189 base
clock controllers
- Added missing 'mediatek,mt8189-fhctl' compatible declaration in
dt-bindings
- Modified Kconfig to COMMON_CLK_MT8189 be tristate (and not bool) to
allow all MT8189 clock controller drivers to be built as modules (it
was partial)
- Fix pll unregisters in clk_mt8189_apmixed_probe error case
- Reparent several clocks to correct 26M references in clk-mt8189-bus.c,
clk-mt8189-topckgen.c and clk-mt8189-vlpckgen.c
- Removed CLK_SET_RATE_NO_REPARENT flag from mfg_sel_mfgpll
- Rename TOPCKGEN_fmipi_csi_up26m clock to fmipi_csi_up26m to remove caps usage
- Implemented reset controllers in clk-mt8189-ufs.c
- Updated all file headers to update copyrights and add all authors
- Added all co-developed-by trailers
The series is based on linux-next tree (tag: next-20260630) and has
been tested on Mediatek Genio 520-EVK (MT8371) and 720-EVK (MT8391) boards
with board hardware enablement patch series ([3]).
[1]: https://lore.kernel.org/linux-mediatek/20260309120512.3624804-1-irving-ch.lin@mediatek.com/
[2]: https://lore.kernel.org/linux-mediatek/20260309120512.3624804-2-irving-ch.lin@mediatek.com/
[3]: https://lore.kernel.org/linux-mediatek/20260701-add-mediatek-genio-520-720-evk-v2-0-19d5da4ef984@collabora.com/
---
Changes in v2:
- Rebased on next-20260708 tag
- Added patch 1,2 and 3 to make the #clock-cells a required property in
MT8186, MT8192 and MT8195 clock controller dt-bindings
- Patch 5:
- Removed conditional blocks to check clock-cells property presence
for MT8188 clock controller compatible
- Reworded commit message to remove the note (no more applicable)
- Fixed incorrect property value in else block for #reset-cells
property check.
_ Removed from patch 9 conditional blocks to check clock-cells property
presence for MT8189 clock controller compatible
- Fixed missing MODULE_DEVICE_TABLE in patches 10, 11 and 12.
- Added devicetree series link in cover letter
- Link to v1: https://lore.kernel.org/r/20260701-mt8189-clocks-system-base-v1-0-2b048feea50a@collabora.com
---
Louis-Alexis Eyraud (18):
dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8186
dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8192
dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8195
dt-bindings: clock: mediatek: reorder MT8186 compatibles
dt-bindings: clock: mediatek: regroup MT8188 dt-bindings into MT8186
dt-bindings: clock: mediatek: regroup MT8192 dt-bindings into MT8186
dt-bindings: clock: mediatek: regroup MT8195 dt-bindings into MT8186
dt-bindings: clock: mediatek: Add MT8189 clocks
clk: mediatek: Add MT8189 apmixedsys clock support
clk: mediatek: Add MT8189 topckgen clock support
clk: mediatek: Add MT8189 vlpckgen clock support
clk: mediatek: Add MT8189 vlpcfg clock support
clk: mediatek: Add MT8189 bus clock support
clk: mediatek: Add MT8189 dbgao clock support
clk: mediatek: Add MT8189 dvfsrc clock support
clk: mediatek: Add MT8189 i2c clock support
clk: mediatek: Add MT8189 scp clock support
clk: mediatek: Add MT8189 ufs clock support
.../bindings/clock/mediatek,mt8186-clock.yaml | 128 ++-
.../bindings/clock/mediatek,mt8186-fhctl.yaml | 1 +
.../bindings/clock/mediatek,mt8186-sys-clock.yaml | 24 +-
.../bindings/clock/mediatek,mt8188-clock.yaml | 93 --
.../bindings/clock/mediatek,mt8188-sys-clock.yaml | 58 --
.../bindings/clock/mediatek,mt8192-clock.yaml | 191 ----
.../bindings/clock/mediatek,mt8192-sys-clock.yaml | 68 --
.../bindings/clock/mediatek,mt8195-clock.yaml | 238 -----
.../bindings/clock/mediatek,mt8195-sys-clock.yaml | 76 --
drivers/clk/mediatek/Kconfig | 79 ++
drivers/clk/mediatek/Makefile | 8 +
drivers/clk/mediatek/clk-mt8189-apmixedsys.c | 196 ++++
drivers/clk/mediatek/clk-mt8189-bus.c | 200 ++++
drivers/clk/mediatek/clk-mt8189-dbgao.c | 98 ++
drivers/clk/mediatek/clk-mt8189-dvfsrc.c | 58 ++
drivers/clk/mediatek/clk-mt8189-iic.c | 122 +++
drivers/clk/mediatek/clk-mt8189-scp.c | 77 ++
drivers/clk/mediatek/clk-mt8189-topckgen.c | 1025 ++++++++++++++++++++
drivers/clk/mediatek/clk-mt8189-ufs.c | 133 +++
drivers/clk/mediatek/clk-mt8189-vlpcfg.c | 116 +++
drivers/clk/mediatek/clk-mt8189-vlpckgen.c | 285 ++++++
include/dt-bindings/clock/mediatek,mt8189-clk.h | 433 +++++++++
include/dt-bindings/reset/mediatek,mt8189-resets.h | 17 +
23 files changed, 2988 insertions(+), 736 deletions(-)
---
base-commit: 451b00e20bcd5526c6def9ee76f9bdb322ae9b46
change-id: 20260630-mt8189-clocks-system-base-70714e4ff2aa
Best regards,
--
Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
^ permalink raw reply
* [PATCH v2 01/18] dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8186
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
Both MT8186 clock controllers dt-bindings (clock and sys-clock)
document the '#clock-cells' property but do not enforce it as required
property.
As clock provider nodes should define this property in devicetrees, add
it to the required property list in both its dt-bindings files.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml | 1 +
Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
index f4e58bfa504f..539149c945d0 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
@@ -44,6 +44,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
index 1c446fbc5108..f8acc02cafee 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
@@ -45,6 +45,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
--
2.55.0
^ permalink raw reply related
* [PATCH v2 02/18] dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8192
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
Both MT8192 clock controllers dt-bindings (clock and sys-clock)
document the '#clock-cells' property but do not enforce it as required
property.
As clock provider nodes should define this property in devicetrees, add
it to the required property list in both its dt-bindings files.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml | 1 +
Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
index b8d690e28bdc..65e4c2fddf5b 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
@@ -46,6 +46,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
index bf8c9aacdf1e..0ebd0d60e2f6 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
@@ -35,6 +35,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
--
2.55.0
^ permalink raw reply related
* [PATCH v2 03/18] dt-bindings: clock: mediatek: Make '#clock-cells' required for MT8195
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
Both MT8195 clock controllers dt-bindings (clock and sys-clock)
document the '#clock-cells' property but do not enforce it as required
property.
As clock provider nodes should define this property in devicetrees, add
it to the required property list in both its dt-bindings files.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml | 1 +
Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml
index fcc963aff087..94dd29c2396c 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8195-clock.yaml
@@ -58,6 +58,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml
index 69f096eb168d..ba1b36fa0169 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8195-sys-clock.yaml
@@ -43,6 +43,7 @@ properties:
required:
- compatible
- reg
+ - '#clock-cells'
additionalProperties: false
--
2.55.0
^ permalink raw reply related
* [PATCH v2 04/18] dt-bindings: clock: mediatek: reorder MT8186 compatibles
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
In order to prepare regrouping several Mediatek SoC clock controller
dt-bindings files into the MT8186 ones, reorder the MT8186 clock
controller compatibles so they are sorted alphanumerically.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../bindings/clock/mediatek,mt8186-clock.yaml | 17 +++++++++--------
.../bindings/clock/mediatek,mt8186-sys-clock.yaml | 4 ++--
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
index 539149c945d0..756b937bb7c4 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
@@ -23,18 +23,19 @@ properties:
compatible:
items:
- enum:
- - mediatek,mt8186-imp_iic_wrap
- - mediatek,mt8186-mfgsys
- - mediatek,mt8186-wpesys
- - mediatek,mt8186-imgsys1
- - mediatek,mt8186-imgsys2
- - mediatek,mt8186-vdecsys
- - mediatek,mt8186-vencsys
- mediatek,mt8186-camsys
- mediatek,mt8186-camsys_rawa
- mediatek,mt8186-camsys_rawb
- - mediatek,mt8186-mdpsys
+ - mediatek,mt8186-imgsys1
+ - mediatek,mt8186-imgsys2
+ - mediatek,mt8186-imp_iic_wrap
- mediatek,mt8186-ipesys
+ - mediatek,mt8186-mdpsys
+ - mediatek,mt8186-mfgsys
+ - mediatek,mt8186-vdecsys
+ - mediatek,mt8186-vencsys
+ - mediatek,mt8186-wpesys
+
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
index f8acc02cafee..6733dafbde16 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
@@ -27,10 +27,10 @@ properties:
compatible:
items:
- enum:
+ - mediatek,mt8186-apmixedsys
+ - mediatek,mt8186-infracfg_ao
- mediatek,mt8186-mcusys
- mediatek,mt8186-topckgen
- - mediatek,mt8186-infracfg_ao
- - mediatek,mt8186-apmixedsys
- const: syscon
reg:
--
2.55.0
^ permalink raw reply related
* [PATCH v2 05/18] dt-bindings: clock: mediatek: regroup MT8188 dt-bindings into MT8186
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
Regroup the MT8188 clock and system clock dt-bindings into MT8186 ones
to ease maintainability and have common files for several currently
supported SoC or new future ones, that have the same kind of clock
controller design.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../bindings/clock/mediatek,mt8186-clock.yaml | 50 +++++++++++-
.../bindings/clock/mediatek,mt8186-sys-clock.yaml | 6 +-
.../bindings/clock/mediatek,mt8188-clock.yaml | 93 ----------------------
.../bindings/clock/mediatek,mt8188-sys-clock.yaml | 58 --------------
4 files changed, 54 insertions(+), 153 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
index 756b937bb7c4..0bc2da60a601 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/mediatek,mt8186-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek Functional Clock Controller for MT8186
+title: MediaTek Functional Clock Controller for Mediatek SoCs
maintainers:
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
@@ -35,6 +35,29 @@ properties:
- mediatek,mt8186-vdecsys
- mediatek,mt8186-vencsys
- mediatek,mt8186-wpesys
+ - mediatek,mt8188-adsp-audio26m
+ - mediatek,mt8188-camsys
+ - mediatek,mt8188-camsys-rawa
+ - mediatek,mt8188-camsys-rawb
+ - mediatek,mt8188-camsys-yuva
+ - mediatek,mt8188-camsys-yuvb
+ - mediatek,mt8188-ccusys
+ - mediatek,mt8188-imgsys
+ - mediatek,mt8188-imgsys-wpe1
+ - mediatek,mt8188-imgsys-wpe2
+ - mediatek,mt8188-imgsys-wpe3
+ - mediatek,mt8188-imgsys1-dip-nr
+ - mediatek,mt8188-imgsys1-dip-top
+ - mediatek,mt8188-imp-iic-wrap-c
+ - mediatek,mt8188-imp-iic-wrap-en
+ - mediatek,mt8188-imp-iic-wrap-w
+ - mediatek,mt8188-ipesys
+ - mediatek,mt8188-mfgcfg
+ - mediatek,mt8188-vdecsys
+ - mediatek,mt8188-vdecsys-soc
+ - mediatek,mt8188-vencsys
+ - mediatek,mt8188-wpesys
+ - mediatek,mt8188-wpesys-vpp0
reg:
maxItems: 1
@@ -42,11 +65,36 @@ properties:
'#clock-cells':
const: 1
+ '#reset-cells':
+ const: 1
+
required:
- compatible
- reg
- '#clock-cells'
+allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - mediatek,mt8188-camsys-rawa
+ - mediatek,mt8188-camsys-rawb
+ - mediatek,mt8188-camsys-yuva
+ - mediatek,mt8188-camsys-yuvb
+ - mediatek,mt8188-imgsys-wpe1
+ - mediatek,mt8188-imgsys-wpe2
+ - mediatek,mt8188-imgsys-wpe3
+ - mediatek,mt8188-imgsys1-dip-nr
+ - mediatek,mt8188-imgsys1-dip-top
+ - mediatek,mt8188-ipesys
+ then:
+ required:
+ - '#reset-cells'
+ else:
+ properties:
+ '#reset-cells': false
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
index 6733dafbde16..199eac2034f2 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/mediatek,mt8186-sys-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: MediaTek System Clock Controller for MT8186
+title: MediaTek System Clock Controller for Mediatek SoCs
maintainers:
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
@@ -31,6 +31,10 @@ properties:
- mediatek,mt8186-infracfg_ao
- mediatek,mt8186-mcusys
- mediatek,mt8186-topckgen
+ - mediatek,mt8188-apmixedsys
+ - mediatek,mt8188-infracfg-ao
+ - mediatek,mt8188-pericfg-ao
+ - mediatek,mt8188-topckgen
- const: syscon
reg:
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml
deleted file mode 100644
index 5403242545ab..000000000000
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8188-clock.yaml
+++ /dev/null
@@ -1,93 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/mediatek,mt8188-clock.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek Functional Clock Controller for MT8188
-
-maintainers:
- - Garmin Chang <garmin.chang@mediatek.com>
-
-description: |
- The clock architecture in MediaTek like below
- PLLs -->
- dividers -->
- muxes
- -->
- clock gate
-
- The devices provide clock gate control in different IP blocks.
-
-properties:
- compatible:
- enum:
- - mediatek,mt8188-adsp-audio26m
- - mediatek,mt8188-camsys
- - mediatek,mt8188-camsys-rawa
- - mediatek,mt8188-camsys-rawb
- - mediatek,mt8188-camsys-yuva
- - mediatek,mt8188-camsys-yuvb
- - mediatek,mt8188-ccusys
- - mediatek,mt8188-imgsys
- - mediatek,mt8188-imgsys-wpe1
- - mediatek,mt8188-imgsys-wpe2
- - mediatek,mt8188-imgsys-wpe3
- - mediatek,mt8188-imgsys1-dip-nr
- - mediatek,mt8188-imgsys1-dip-top
- - mediatek,mt8188-imp-iic-wrap-c
- - mediatek,mt8188-imp-iic-wrap-en
- - mediatek,mt8188-imp-iic-wrap-w
- - mediatek,mt8188-ipesys
- - mediatek,mt8188-mfgcfg
- - mediatek,mt8188-vdecsys
- - mediatek,mt8188-vdecsys-soc
- - mediatek,mt8188-vencsys
- - mediatek,mt8188-wpesys
- - mediatek,mt8188-wpesys-vpp0
-
- reg:
- maxItems: 1
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
-required:
- - compatible
- - reg
- - '#clock-cells'
-
-allOf:
- - if:
- properties:
- compatible:
- contains:
- enum:
- - mediatek,mt8188-camsys-rawa
- - mediatek,mt8188-camsys-rawb
- - mediatek,mt8188-camsys-yuva
- - mediatek,mt8188-camsys-yuvb
- - mediatek,mt8188-imgsys-wpe1
- - mediatek,mt8188-imgsys-wpe2
- - mediatek,mt8188-imgsys-wpe3
- - mediatek,mt8188-imgsys1-dip-nr
- - mediatek,mt8188-imgsys1-dip-top
- - mediatek,mt8188-ipesys
-
- then:
- required:
- - '#reset-cells'
-
-additionalProperties: false
-
-examples:
- - |
- clock-controller@11283000 {
- compatible = "mediatek,mt8188-imp-iic-wrap-c";
- reg = <0x11283000 0x1000>;
- #clock-cells = <1>;
- };
-
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml
deleted file mode 100644
index db13d51a4903..000000000000
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8188-sys-clock.yaml
+++ /dev/null
@@ -1,58 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/mediatek,mt8188-sys-clock.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek System Clock Controller for MT8188
-
-maintainers:
- - Garmin Chang <garmin.chang@mediatek.com>
-
-description: |
- The clock architecture in MediaTek like below
- PLLs -->
- dividers -->
- muxes
- -->
- clock gate
-
- The apmixedsys provides most of PLLs which generated from SoC 26m.
- The topckgen provides dividers and muxes which provide the clock source to other IP blocks.
- The infracfg_ao provides clock gate in peripheral and infrastructure IP blocks.
- The mcusys provides mux control to select the clock source in AP MCU.
- The device nodes also provide the system control capacity for configuration.
-
-properties:
- compatible:
- items:
- - enum:
- - mediatek,mt8188-apmixedsys
- - mediatek,mt8188-infracfg-ao
- - mediatek,mt8188-pericfg-ao
- - mediatek,mt8188-topckgen
- - const: syscon
-
- reg:
- maxItems: 1
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
-required:
- - compatible
- - reg
- - '#clock-cells'
-
-additionalProperties: false
-
-examples:
- - |
- clock-controller@10000000 {
- compatible = "mediatek,mt8188-topckgen", "syscon";
- reg = <0x10000000 0x1000>;
- #clock-cells = <1>;
- };
--
2.55.0
^ permalink raw reply related
* [PATCH v2 06/18] dt-bindings: clock: mediatek: regroup MT8192 dt-bindings into MT8186
From: Louis-Alexis Eyraud @ 2026-07-09 13:42 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Chun-Jie Chen, Philipp Zabel,
Edward-JW Yang, Richard Cochran
Cc: kernel, linux-clk, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, netdev, Louis-Alexis Eyraud
In-Reply-To: <20260709-mt8189-clocks-system-base-v2-0-2926da3db6cf@collabora.com>
Regroup the MT8192 clock and system clock dt-bindings into MT8186 ones
to ease maintainability and have common files for several currently
supported SoC or new future ones, that have the same kind of clock
controller design.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
---
.../bindings/clock/mediatek,mt8186-clock.yaml | 20 +++
.../bindings/clock/mediatek,mt8186-sys-clock.yaml | 4 +
.../bindings/clock/mediatek,mt8192-clock.yaml | 192 ---------------------
.../bindings/clock/mediatek,mt8192-sys-clock.yaml | 69 --------
4 files changed, 24 insertions(+), 261 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
index 0bc2da60a601..b5988d122e4d 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-clock.yaml
@@ -58,6 +58,26 @@ properties:
- mediatek,mt8188-vencsys
- mediatek,mt8188-wpesys
- mediatek,mt8188-wpesys-vpp0
+ - mediatek,mt8192-camsys
+ - mediatek,mt8192-camsys_rawa
+ - mediatek,mt8192-camsys_rawb
+ - mediatek,mt8192-camsys_rawc
+ - mediatek,mt8192-imgsys
+ - mediatek,mt8192-imgsys2
+ - mediatek,mt8192-imp_iic_wrap_c
+ - mediatek,mt8192-imp_iic_wrap_e
+ - mediatek,mt8192-imp_iic_wrap_s
+ - mediatek,mt8192-imp_iic_wrap_ws
+ - mediatek,mt8192-imp_iic_wrap_w
+ - mediatek,mt8192-imp_iic_wrap_n
+ - mediatek,mt8192-ipesys
+ - mediatek,mt8192-mdpsys
+ - mediatek,mt8192-mfgcfg
+ - mediatek,mt8192-msdc_top
+ - mediatek,mt8192-scp_adsp
+ - mediatek,mt8192-vdecsys_soc
+ - mediatek,mt8192-vdecsys
+ - mediatek,mt8192-vencsys
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
index 199eac2034f2..41b8c61132e2 100644
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8186-sys-clock.yaml
@@ -35,6 +35,10 @@ properties:
- mediatek,mt8188-infracfg-ao
- mediatek,mt8188-pericfg-ao
- mediatek,mt8188-topckgen
+ - mediatek,mt8192-apmixedsys
+ - mediatek,mt8192-infracfg
+ - mediatek,mt8192-pericfg
+ - mediatek,mt8192-topckgen
- const: syscon
reg:
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
deleted file mode 100644
index 65e4c2fddf5b..000000000000
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8192-clock.yaml
+++ /dev/null
@@ -1,192 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/mediatek,mt8192-clock.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek Functional Clock Controller for MT8192
-
-maintainers:
- - Chun-Jie Chen <chun-jie.chen@mediatek.com>
-
-description:
- The Mediatek functional clock controller provides various clocks on MT8192.
-
-properties:
- compatible:
- items:
- - enum:
- - mediatek,mt8192-scp_adsp
- - mediatek,mt8192-imp_iic_wrap_c
- - mediatek,mt8192-imp_iic_wrap_e
- - mediatek,mt8192-imp_iic_wrap_s
- - mediatek,mt8192-imp_iic_wrap_ws
- - mediatek,mt8192-imp_iic_wrap_w
- - mediatek,mt8192-imp_iic_wrap_n
- - mediatek,mt8192-msdc_top
- - mediatek,mt8192-mfgcfg
- - mediatek,mt8192-imgsys
- - mediatek,mt8192-imgsys2
- - mediatek,mt8192-vdecsys_soc
- - mediatek,mt8192-vdecsys
- - mediatek,mt8192-vencsys
- - mediatek,mt8192-camsys
- - mediatek,mt8192-camsys_rawa
- - mediatek,mt8192-camsys_rawb
- - mediatek,mt8192-camsys_rawc
- - mediatek,mt8192-ipesys
- - mediatek,mt8192-mdpsys
-
- reg:
- maxItems: 1
-
- '#clock-cells':
- const: 1
-
-required:
- - compatible
- - reg
- - '#clock-cells'
-
-additionalProperties: false
-
-examples:
- - |
- scp_adsp: clock-controller@10720000 {
- compatible = "mediatek,mt8192-scp_adsp";
- reg = <0x10720000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_c: clock-controller@11007000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_c";
- reg = <0x11007000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_e: clock-controller@11cb1000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_e";
- reg = <0x11cb1000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_s: clock-controller@11d03000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_s";
- reg = <0x11d03000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_ws: clock-controller@11d23000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_ws";
- reg = <0x11d23000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_w: clock-controller@11e01000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_w";
- reg = <0x11e01000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imp_iic_wrap_n: clock-controller@11f02000 {
- compatible = "mediatek,mt8192-imp_iic_wrap_n";
- reg = <0x11f02000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- msdc_top: clock-controller@11f10000 {
- compatible = "mediatek,mt8192-msdc_top";
- reg = <0x11f10000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- mfgcfg: clock-controller@13fbf000 {
- compatible = "mediatek,mt8192-mfgcfg";
- reg = <0x13fbf000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imgsys: clock-controller@15020000 {
- compatible = "mediatek,mt8192-imgsys";
- reg = <0x15020000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- imgsys2: clock-controller@15820000 {
- compatible = "mediatek,mt8192-imgsys2";
- reg = <0x15820000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- vdecsys_soc: clock-controller@1600f000 {
- compatible = "mediatek,mt8192-vdecsys_soc";
- reg = <0x1600f000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- vdecsys: clock-controller@1602f000 {
- compatible = "mediatek,mt8192-vdecsys";
- reg = <0x1602f000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- vencsys: clock-controller@17000000 {
- compatible = "mediatek,mt8192-vencsys";
- reg = <0x17000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- camsys: clock-controller@1a000000 {
- compatible = "mediatek,mt8192-camsys";
- reg = <0x1a000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- camsys_rawa: clock-controller@1a04f000 {
- compatible = "mediatek,mt8192-camsys_rawa";
- reg = <0x1a04f000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- camsys_rawb: clock-controller@1a06f000 {
- compatible = "mediatek,mt8192-camsys_rawb";
- reg = <0x1a06f000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- camsys_rawc: clock-controller@1a08f000 {
- compatible = "mediatek,mt8192-camsys_rawc";
- reg = <0x1a08f000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- ipesys: clock-controller@1b000000 {
- compatible = "mediatek,mt8192-ipesys";
- reg = <0x1b000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- mdpsys: clock-controller@1f000000 {
- compatible = "mediatek,mt8192-mdpsys";
- reg = <0x1f000000 0x1000>;
- #clock-cells = <1>;
- };
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
deleted file mode 100644
index 0ebd0d60e2f6..000000000000
--- a/Documentation/devicetree/bindings/clock/mediatek,mt8192-sys-clock.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
-# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
-%YAML 1.2
----
-$id: http://devicetree.org/schemas/clock/mediatek,mt8192-sys-clock.yaml#
-$schema: http://devicetree.org/meta-schemas/core.yaml#
-
-title: MediaTek System Clock Controller for MT8192
-
-maintainers:
- - Chun-Jie Chen <chun-jie.chen@mediatek.com>
-
-description:
- The Mediatek system clock controller provides various clocks and system configuration
- like reset and bus protection on MT8192.
-
-properties:
- compatible:
- items:
- - enum:
- - mediatek,mt8192-topckgen
- - mediatek,mt8192-infracfg
- - mediatek,mt8192-pericfg
- - mediatek,mt8192-apmixedsys
- - const: syscon
-
- reg:
- maxItems: 1
-
- '#clock-cells':
- const: 1
-
- '#reset-cells':
- const: 1
-
-required:
- - compatible
- - reg
- - '#clock-cells'
-
-additionalProperties: false
-
-examples:
- - |
- topckgen: syscon@10000000 {
- compatible = "mediatek,mt8192-topckgen", "syscon";
- reg = <0x10000000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- infracfg: syscon@10001000 {
- compatible = "mediatek,mt8192-infracfg", "syscon";
- reg = <0x10001000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- pericfg: syscon@10003000 {
- compatible = "mediatek,mt8192-pericfg", "syscon";
- reg = <0x10003000 0x1000>;
- #clock-cells = <1>;
- };
-
- - |
- apmixedsys: syscon@1000c000 {
- compatible = "mediatek,mt8192-apmixedsys", "syscon";
- reg = <0x1000c000 0x1000>;
- #clock-cells = <1>;
- };
--
2.55.0
^ 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