* Re: [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices
From: Sabrina Dubroca @ 2026-04-08 11:01 UTC (permalink / raw)
To: Cosmin Ratiu
Cc: andrew+netdev@lunn.ch, davem@davemloft.net,
linux-kselftest@vger.kernel.org, Dragos Tatulea, sdf@fomichev.me,
shuah@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, edumazet@google.com, netdev@vger.kernel.org
In-Reply-To: <3aab1732c62fa8241ea91f2e26720ba47d646a3a.camel@nvidia.com>
2026-04-08, 10:24:28 +0000, Cosmin Ratiu wrote:
> On Wed, 2026-04-08 at 10:25 +0200, Sabrina Dubroca wrote:
> > 2026-04-07, 15:07:47 +0000, Cosmin Ratiu wrote:
> > > On Thu, 2026-04-02 at 16:48 +0200, Sabrina Dubroca wrote:
> > > > If this happens on a real device, the VLAN filters will be
> > > > broken.
> > > > I'm
> > > > not sure what the right behavior would be:
> > > >
> > > > 1. reject the request to enable offload
> > > > 2. switch to promiscuous mode
> > >
> > > I implemented and tested option 1. In the unlikely scenario adding
> > > VLAN
> > > filters prevents offloading
> >
> > How unlikely is it? Resource allocation, talking to HW, device
> > limits,
> > anything else that could fail?
> >
> > > , it's better for the driver to be explicit
> > > and let the user turn on promisc mode themselves. Keeping track of
> > > whether VLAN filters failed and promisc was used as a fallback adds
> > > some extra complexity.
> >
> > If it's indeed (very) unlikely, sure. There's still a bit of a
> > regression/change of behavior for users compared to before the
> > IFF_UNICAST_FLT patch, but I think we can wait until someone
> > complains, and then add the tracking if that happens.
> >
> > > What would be the point of IFF_UNICAST_FLT then?
> >
> > The point is that this would just be a fallback.
> >
> > > Please let me know if you agree with this approach, so I can send
> > > v8
> > > with it.
> >
> > If you can confirm it's on the "very unlikely" side, yes, this
> > approach sounds ok. Thanks.
>
> There are many, many drivers which implement .ndo_vlan_rx_add_vid, I
> can't really browse them all and determine overall likelihood of
Sorry, I wasn't requesting that much work, more of a "feeling" based
on your understanding. Anyway for macsec offload we don't have to care
about the vast majority of drivers.
> failure. But presumably there are some memory allocations involved and
> some FW communication to add the new filter.
I guess if FW communication fails we're in trouble anyway [*], and memory
allocation failure is an acceptable reason to reject offloading
anyway.
[*] rolling back the mdo_add_secy could be a problem if we had
difficulties talking to the HW?
> An AI prompt of "Explore implementations of .ndo_vlan_rx_add_vid in
> drivers and classify potential failure sources and their likelihood of
> failure." resulted in (edited for compactness):
> """
> Analyzed 24+ implementations across major drivers. Here's the
> breakdown:
> Category Likelihood Drivers Typical Error
> HW/FW cmds Low mlx4, nfp, hinic, qeth, vmxnet3 Device-specific
> Mem alloc Very Low bnx2x, qede, virtio_net -ENOMEM
> Filter add Low-Medium mlx5, mlx4, ice, qede, ocelot -ENOSPC, -EEXIST
> Locking Very Low be2net, mlx4, nfp, hinic -EBUSY
> Res limit Medium qede (quota check) Promisc fallback
>
> Three Driver Archetypes
>
> 1. Simple bitfield drivers (never fail): e1000, e1000e, ixgbe, igb —
> just set a VFTA bit in hardware registers, always return 0.
>
> 2. Complex offload drivers (can fail): mlx5 (flow steering rules), mlx4
> (FW VLAN registration), ice (switch rules + promisc management), qede
> (quota-aware with promisc fallback), nfp (mailbox commands), hinic (FW
> commands with rollback).
>
> 3. Delegation/passthrough drivers (inherit failures): bonding, team,
> hsr, dsa, macvlan, ipvlan, macsec — propagate vlan_vid_add() to lower
> devices with unwind-on-failure patterns.
> """
>
> So I guess we go with option 1 for now.
ACK
--
Sabrina
^ permalink raw reply
* Re: [net,PATCH] net: ks8851: Reinstate disabling of BHs around IRQ handler
From: Nicolai Buchwitz @ 2026-04-08 10:54 UTC (permalink / raw)
To: Marek Vasut
Cc: netdev, stable, David S. Miller, Andrew Lunn, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Ronald Wahl, Yicong Hui,
linux-kernel
In-Reply-To: <20260407212344.80265-1-marex@nabladev.com>
On 7.4.2026 23:23, Marek Vasut wrote:
> [...]
>
> diff --git a/drivers/net/ethernet/micrel/ks8851_common.c
> b/drivers/net/ethernet/micrel/ks8851_common.c
> index 8048770958d60..dadedea016fac 100644
> --- a/drivers/net/ethernet/micrel/ks8851_common.c
> +++ b/drivers/net/ethernet/micrel/ks8851_common.c
> @@ -316,6 +316,7 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
> unsigned int status;
> struct sk_buff *skb;
>
> + local_bh_disable();
> ks8851_lock(ks, &flags);
This breaks the SPI variant on non-RT. The SPI path sleeps in
spi_sync() -> wait_for_completion_timeout(), which can't be
done with BH disabled. Confirmed on hardware (KS8851 SPI on
CM4S, PREEMPT non-RT):
BUG: scheduling while atomic: irq/38-eth2/708/0x00000201
...
spi_transfer_one_message+0x518/0x770
__spi_pump_transfer_message+0x1dc/0x5f0
__spi_sync+0x2b4/0x460
spi_sync+0x38/0x68
ks8851_rdfifo_spi+0x60/0xc0
ks8851_irq+0x310/0x3c8
The fix needs to be PAR-specific since the SPI variant doesn't
have the deadlock problem anyway (ks8851_start_xmit_spi doesn't
take the lock).
>
> status = ks8851_rdreg16(ks, KS_ISR);
> @@ -381,6 +382,7 @@ static irqreturn_t ks8851_irq(int irq, void *_ks)
> if (status & IRQ_RXI)
> while ((skb = __skb_dequeue(&rxq)))
> netif_rx(skb);
> + local_bh_enable();
>
> return IRQ_HANDLED;
> }
In order to make this work I would propose something like this (which
works in my SPI setup):
--- a/drivers/net/ethernet/micrel/ks8851_par.c
+++ b/drivers/net/ethernet/micrel/ks8851_par.c
@@ -60,12 +60,14 @@ static void ks8851_lock_par(struct ks8851_net *ks,
unsigned long *flags)
{
struct ks8851_net_par *ksp = to_ks8851_par(ks);
+ local_bh_disable();
spin_lock_irqsave(&ksp->lock, *flags);
}
static void ks8851_unlock_par(struct ks8851_net *ks, unsigned long
*flags)
{
struct ks8851_net_par *ksp = to_ks8851_par(ks);
spin_unlock_irqrestore(&ksp->lock, *flags);
+ local_bh_enable();
}
Tested-by: Nicolai Buchwitz <nb@tipi-net.de> # KS8851 SPI, non-RT
(regression + proposed fix)
^ permalink raw reply
* Re: [PATCH net v4 15/15] rxrpc: fix reference count leak in rxrpc_server_keyring()
From: David Howells @ 2026-04-08 10:53 UTC (permalink / raw)
To: Anderson Nascimento
Cc: dhowells, netdev, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-afs, linux-kernel, Luxiao Xu,
Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu, Ren Wei, Ren Wei,
Simon Horman, stable
In-Reply-To: <2234233.1775645449@warthog.procyon.org.uk>
David Howells <dhowells@redhat.com> wrote:
> Anderson Nascimento <anderson@allelesecurity.com> wrote:
>
> > Isn't this the same issue addressed by my patch "[PATCH net v4 08/15]
> > rxrpc: Fix keyring reference count leak in rxrpc_setsockopt()"? Just
> > asking to make sure this is intended.
>
> Actually, I think it's probably better to use Luxiao Xu's patch rather than
> yours as it puts the check down into the function that actually makes the
> change.
I also then need to remove the rx->key check.
David
^ permalink raw reply
* Re: [PATCH net v4 15/15] rxrpc: fix reference count leak in rxrpc_server_keyring()
From: David Howells @ 2026-04-08 10:50 UTC (permalink / raw)
To: Anderson Nascimento
Cc: dhowells, netdev, Marc Dionne, Jakub Kicinski, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-afs, linux-kernel, Luxiao Xu,
Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu, Ren Wei, Ren Wei,
Simon Horman, stable
In-Reply-To: <aa7aeb86-2430-4c67-9d5d-bb27ad037865@allelesecurity.com>
Anderson Nascimento <anderson@allelesecurity.com> wrote:
> Isn't this the same issue addressed by my patch "[PATCH net v4 08/15] rxrpc:
> Fix keyring reference count leak in rxrpc_setsockopt()"? Just asking to make
> sure this is intended.
Actually, I think it's probably better to use Luxiao Xu's patch rather than
yours as it puts the check down into the function that actually makes the
change.
David
^ permalink raw reply
* Re: [PATCH net v4 15/15] rxrpc: fix reference count leak in rxrpc_server_keyring()
From: David Howells @ 2026-04-08 10:49 UTC (permalink / raw)
To: Jakub Kicinski
Cc: dhowells, Anderson Nascimento, netdev, Marc Dionne,
David S. Miller, Eric Dumazet, Paolo Abeni, linux-afs,
linux-kernel, Luxiao Xu, Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu,
Ren Wei, Ren Wei, Simon Horman, stable
In-Reply-To: <20260401192244.6ad86fc9@kernel.org>
Jakub Kicinski <kuba@kernel.org> wrote:
> And in return maybe you can scan the AI output and tell me
> if any of it is legit? ;)
>
> https://sashiko.dev/#/patchset/20260401105614.1696001-10-dhowells@redhat.com
PATCH 2
-------
The complaint it makes about overflows in relation to patch 2:
net/rxrpc/key.c:rxrpc_preparse_xdr_yfs_rxgk() {
...
keylen = ntohl(key[-1]);
_debug("keylen: %x", keylen);
keylen = round_up(keylen, 4);
...
tktlen = ntohl(ticket[-1]);
_debug("tktlen: %x", tktlen);
tktlen = round_up(tktlen, 4);
...
}
is actually addressed by:
[PATCH net v4 05/15] rxrpc: Fix RxGK token loading to check bounds
I guess it doesn't look forward through the patches?
PATCH 8
-------
In regards to patch 8, it asks:
Does this change introduce an asymmetric behavior between configuring
RXRPC_SECURITY_KEY and RXRPC_SECURITY_KEYRING?
Yes, but it's then correct. An AF_RXRPC server socket can also make client
calls - and, indeed, the kernel AFS client requires this. The kernel AFS
client makes filesystem access/manipulation client calls but also listens for,
amongst other things, change notifications from the server.
With regards to its complaint about patch 12, I should really switch to using
lib/crypto/ to avoid using any memory allocation, but, yes, it has a point and
that crypto_skcipher_decrypt() (and encrypt) can fail too.
"sp->len < 8" is checked for at the beginning of the functions
rxkad_verify_packet_2(), so it must be at least one block in size. rxkad uses
pcbc to wrap fcrypt which should take care of the non-block alignment.
I'll add a patch to add error handling.
PATCH 13
--------
For patch 13, it says:
Are there integer overflows in rxgk_verify_response() when handling
token_len?
Yeah - I do the round up before the check. I'll add a patch to check that the
raw token_len <= len too (len must be < 65536 as the response must fit in a
single UDP packet).
It also says:
Does rxgk_verify_response() leak the rxgk_context structure (gk)?
Yep. Another patch for that.
And:
Does rxgk_do_verify_authenticator() still perform an out-of-bounds
read if the authenticator is smaller than 24 bytes?
Unfortunately, yes. Add one for that.
Further, it says:
Can modifying conn->channels[i].call_counter here cause a data race?
It shouldn't, since the value is only used to allocate the number for a call
that is set in callNumber in the Rx header for that call (well, the number may
also be copied inside the encrypted payload) but it's only *interpreted* by
the peer.
The way Rx works is that there's a separate callNumber space on each channel
on each connection. Only one call can be in progress on a given channel (the
channel number is in the bottom two bits of the connection ID field), and
calls on a channel are numbered consecutively. Seeing a new incoming call
with the next higher callNumber implicitly completes and ACKs the previous
call on that channel (potentially rendering explicit ACK packets unnecessary
on a busy channel).
If, however, a connection becomes idle, the server can just discard its record
of it. Should the client resume activity on that connection, the RESPONSE
packet conveys the client's call counter for each channel, from which the
server reinitialises the counters.
rxrpc_expose_client_call() cranks the counter for the client side;
rxgk_do_verify_authenticator() sets the counter for the server side. This
sets the expectation in a secure environment of what callNumbers should be
next on a connection to help prevent replay attacks.
If the server sees the call ID revert more than 1 (to allow for duplicate
packets from the previous call), it should abort the connection.
So I think nothing needs to be fixed here, as a secure connection isn't
allowed to proceed until the RESPONSE packet is fully parsed and the transport
security set up.
PATCH 14
--------
For patch 14, it says:
While this fixes the panic for auth_len, can a maliciously large
token_len (e.g., 0xFFFFFFFF) cause an integer overflow in the same
function that leads to the exact same BUG_ON() panic?
but this is the same as the first thing it says against patch 13. I've added
a patch to check token_len.
Ditto for:
Does this function also unconditionally leak the rxgk_context
allocated for the transport key?
It then says:
Are there memory leaks and data races if duplicate RESPONSE packets
are processed concurrently?
That can't happen as there's a single work item, conn->processor, that
processes all connection-level events, including CHALLENGE and RESPONSE
issuing and parsing for that connection. Each connection has its own totally
independent security context, so there shouldn't be interference between two
connections.
And finally, it says:
If rxrpc_process_event() does not verify if the connection is already
secured before invoking the verify_response() callback, duplicate
packets would cause rxgk_verify_response() to unconditionally
overwrite conn->key with the new key, leaking the previous key's
reference.
Additionally, if rxgk_init_connection_security() unconditionally
overwrites conn->rxgk.keys[] without putting the old key or holding
conn->security_use_lock, could this cause another rxgk_context leak
and race against concurrent read accesses in rxgk_get_key()?
These are both addressed by a patch I've been sent that I'll add.
PATCH 15
--------
Regarding patch 15, which provides an alternative fix to patch 8, I previously
asked you to drop patch 15 - but I'm thinking now it's probably better to keep
patch 15 and drop patch 8 (and change patch 15 to return -EINVAL).
David
^ permalink raw reply
* Re: [PATCH v10 net-next 3/6] devlink: Implement devlink param multi attribute nested data values
From: Ratheesh Kannoth @ 2026-04-08 10:41 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, linux-kernel, linux-rdma, sgoutham, andrew+netdev, davem,
edumazet, kuba, donald.hunter, horms, jiri, chuck.lever, matttbe,
cjubran, saeedm, leon, tariqt, mbloch, dtatulea
In-Reply-To: <c14a0783-a69f-448d-a464-2d802e6d0ec7@redhat.com>
On 2026-04-07 at 15:28:09, Paolo Abeni (pabeni@redhat.com) wrote:
> On 4/3/26 4:55 AM, Ratheesh Kannoth wrote:
> > From: Saeed Mahameed <saeedm@nvidia.com>
> >
> > Devlink param value attribute is not defined since devlink is handling
> > the value validating and parsing internally, this allows us to implement
> > multi attribute values without breaking any policies.
> >
> > Devlink param multi-attribute values are considered to be dynamically
> > sized arrays of u64 values, by introducing a new devlink param type
> > DEVLINK_PARAM_TYPE_U64_ARRAY, driver and user space can set a variable
> > count of u32 values into the DEVLINK_ATTR_PARAM_VALUE_DATA attribute.
> >
> > Implement get/set parsing and add to the internal value structure passed
> > to drivers.
> >
> > This is useful for devices that need to configure a list of values for
> > a specific configuration.
> >
> > example:
> > $ devlink dev param show pci/... name multi-value-param
> > name multi-value-param type driver-specific
> > values:
> > cmode permanent value: 0,1,2,3,4,5,6,7
> >
> > $ devlink dev param set pci/... name multi-value-param \
> > value 4,5,6,7,0,1,2,3 cmode permanent
> >
> > Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
> > Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
> > ---
> > Documentation/netlink/specs/devlink.yaml | 4 ++
> > include/net/devlink.h | 8 +++
> > include/uapi/linux/devlink.h | 1 +
> > net/devlink/netlink_gen.c | 2 +
> > net/devlink/param.c | 91 +++++++++++++++++++-----
> > 5 files changed, 89 insertions(+), 17 deletions(-)
> >
> > diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netlink/specs/devlink.yaml
> > index b495d56b9137..b619de4fe08a 100644
> > --- a/Documentation/netlink/specs/devlink.yaml
> > +++ b/Documentation/netlink/specs/devlink.yaml
> > @@ -226,6 +226,10 @@ definitions:
> > value: 10
> > -
> > name: binary
> > + -
> > + name: u64-array
> > + value: 129
> > +
> > -
> > name: rate-tc-index-max
> > type: const
> > diff --git a/include/net/devlink.h b/include/net/devlink.h
> > index 3038af6ec017..3a355fea8189 100644
> > --- a/include/net/devlink.h
> > +++ b/include/net/devlink.h
> > @@ -432,6 +432,13 @@ enum devlink_param_type {
> > DEVLINK_PARAM_TYPE_U64 = DEVLINK_VAR_ATTR_TYPE_U64,
> > DEVLINK_PARAM_TYPE_STRING = DEVLINK_VAR_ATTR_TYPE_STRING,
> > DEVLINK_PARAM_TYPE_BOOL = DEVLINK_VAR_ATTR_TYPE_FLAG,
> > + DEVLINK_PARAM_TYPE_U64_ARRAY = DEVLINK_VAR_ATTR_TYPE_U64_ARRAY,
> > +};
> > +
> > +#define __DEVLINK_PARAM_MAX_ARRAY_SIZE 32
> > +struct devlink_param_u64_array {
> > + u64 size;
> > + u64 val[__DEVLINK_PARAM_MAX_ARRAY_SIZE];
> > };
> >
> > union devlink_param_value {
> > @@ -441,6 +448,7 @@ union devlink_param_value {
> > u64 vu64;
> > char vstr[__DEVLINK_PARAM_MAX_STRING_VALUE];
> > bool vbool;
> > + struct devlink_param_u64_array u64arr;
>
> Sashiko as a couple of relevant remarks here, specifically:
>
> ---
> Does this increase the size of union devlink_param_value from 32 bytes
> to over 264 bytes?
> Looking at existing functions like devlink_nl_param_value_fill_one() and
> devlink_nl_param_value_put(), they take multiple copies of this union by
> value. Passing two of these unions by value consumes over 528 bytes of
> stack space, and combined in a call chain this pushes nearly 800 bytes
> of arguments onto the stack.
> Could this create a risk of hitting CONFIG_FRAME_WARN limits deep in
> driver notification contexts? Should the signatures of the internal
> functions and exported APIs be updated to pass the unions by pointer
> instead?
ACK. will make as seperate patch.
> ---
>
> > };
> >
> > struct devlink_param_gset_ctx {
> > diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
> > index 7de2d8cc862f..5332223dd6d0 100644
> > --- a/include/uapi/linux/devlink.h
> > +++ b/include/uapi/linux/devlink.h
> > @@ -406,6 +406,7 @@ enum devlink_var_attr_type {
> > DEVLINK_VAR_ATTR_TYPE_BINARY,
> > __DEVLINK_VAR_ATTR_TYPE_CUSTOM_BASE = 0x80,
> > /* Any possible custom types, unrelated to NLA_* values go below */
> > + DEVLINK_VAR_ATTR_TYPE_U64_ARRAY,
> > };
> >
> > enum devlink_attr {
> > diff --git a/net/devlink/netlink_gen.c b/net/devlink/netlink_gen.c
> > index eb35e80e01d1..7aaf462f27ee 100644
> > --- a/net/devlink/netlink_gen.c
> > +++ b/net/devlink/netlink_gen.c
> > @@ -37,6 +37,8 @@ devlink_attr_param_type_validate(const struct nlattr *attr,
> > case DEVLINK_VAR_ATTR_TYPE_NUL_STRING:
> > fallthrough;
> > case DEVLINK_VAR_ATTR_TYPE_BINARY:
> > + fallthrough;
> > + case DEVLINK_VAR_ATTR_TYPE_U64_ARRAY:
> > return 0;
> > }
> > NL_SET_ERR_MSG_ATTR(extack, attr, "invalid enum value");
> > diff --git a/net/devlink/param.c b/net/devlink/param.c
> > index cf95268da5b0..2ec85dffd8ac 100644
> > --- a/net/devlink/param.c
> > +++ b/net/devlink/param.c
> > @@ -252,6 +252,14 @@ devlink_nl_param_value_put(struct sk_buff *msg, enum devlink_param_type type,
> > return -EMSGSIZE;
> > }
> > break;
> > + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> > + if (val.u64arr.size > __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> > + return -EMSGSIZE;
> > +
> > + for (int i = 0; i < val.u64arr.size; i++)
> > + if (nla_put_uint(msg, nla_type, val.u64arr.val[i]))
> > + return -EMSGSIZE;
> > + break;
> > }
> > return 0;
> > }
> > @@ -304,56 +312,78 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> > u32 portid, u32 seq, int flags,
> > struct netlink_ext_ack *extack)
> > {
> > - union devlink_param_value default_value[DEVLINK_PARAM_CMODE_MAX + 1];
> > - union devlink_param_value param_value[DEVLINK_PARAM_CMODE_MAX + 1];
> > bool default_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> > bool param_value_set[DEVLINK_PARAM_CMODE_MAX + 1] = {};
> > const struct devlink_param *param = param_item->param;
> > - struct devlink_param_gset_ctx ctx;
> > + union devlink_param_value *default_value;
> > + union devlink_param_value *param_value;
> > + struct devlink_param_gset_ctx *ctx;
> > struct nlattr *param_values_list;
> > struct nlattr *param_attr;
> > void *hdr;
> > int err;
> > int i;
> >
> > + default_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> > + sizeof(*default_value), GFP_KERNEL);
> > + if (!default_value)
> > + return -ENOMEM;
> > +
> > + param_value = kcalloc(DEVLINK_PARAM_CMODE_MAX + 1,
> > + sizeof(*param_value), GFP_KERNEL);
> > + if (!param_value) {
> > + kfree(default_value);
> > + return -ENOMEM;
> > + }
> > +
> > + ctx = kmalloc_obj(*ctx);
> > + if (!ctx) {
> > + kfree(param_value);
> > + kfree(default_value);
> > + return -ENOMEM;
> > + }
> > +
> > /* Get value from driver part to driverinit configuration mode */
> > for (i = 0; i <= DEVLINK_PARAM_CMODE_MAX; i++) {
> > if (!devlink_param_cmode_is_supported(param, i))
> > continue;
> > if (i == DEVLINK_PARAM_CMODE_DRIVERINIT) {
> > - if (param_item->driverinit_value_new_valid)
> > + if (param_item->driverinit_value_new_valid) {
> > param_value[i] = param_item->driverinit_value_new;
> > - else if (param_item->driverinit_value_valid)
> > + } else if (param_item->driverinit_value_valid) {
> > param_value[i] = param_item->driverinit_value;
> > - else
> > - return -EOPNOTSUPP;
> > + } else {
> > + err = -EOPNOTSUPP;
> > + goto get_put_fail;
> > + }
> >
> > if (param_item->driverinit_value_valid) {
> > default_value[i] = param_item->driverinit_default;
> > default_value_set[i] = true;
> > }
> > } else {
> > - ctx.cmode = i;
> > - err = devlink_param_get(devlink, param, &ctx, extack);
> > + ctx->cmode = i;
> > + err = devlink_param_get(devlink, param, ctx, extack);
> > if (err)
> > - return err;
> > - param_value[i] = ctx.val;
> > + goto get_put_fail;
> > + param_value[i] = ctx->val;
> >
> > - err = devlink_param_get_default(devlink, param, &ctx,
> > + err = devlink_param_get_default(devlink, param, ctx,
> > extack);
> > if (!err) {
> > - default_value[i] = ctx.val;
> > + default_value[i] = ctx->val;
> > default_value_set[i] = true;
> > } else if (err != -EOPNOTSUPP) {
> > - return err;
> > + goto get_put_fail;
> > }
> > }
> > param_value_set[i] = true;
> > }
> >
> > + err = -EMSGSIZE;
> > hdr = genlmsg_put(msg, portid, seq, &devlink_nl_family, flags, cmd);
> > if (!hdr)
> > - return -EMSGSIZE;
> > + goto get_put_fail;
> >
> > if (devlink_nl_put_handle(msg, devlink))
> > goto genlmsg_cancel;
> > @@ -393,6 +423,9 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> > nla_nest_end(msg, param_values_list);
> > nla_nest_end(msg, param_attr);
> > genlmsg_end(msg, hdr);
> > + kfree(default_value);
> > + kfree(param_value);
> > + kfree(ctx);
> > return 0;
> >
> > values_list_nest_cancel:
> > @@ -401,7 +434,11 @@ static int devlink_nl_param_fill(struct sk_buff *msg, struct devlink *devlink,
> > nla_nest_cancel(msg, param_attr);
> > genlmsg_cancel:
> > genlmsg_cancel(msg, hdr);
> > - return -EMSGSIZE;
> > +get_put_fail:
> > + kfree(default_value);
> > + kfree(param_value);
> > + kfree(ctx);
> > + return err;
> > }
> >
> > static void devlink_param_notify(struct devlink *devlink,
> > @@ -507,7 +544,7 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> > union devlink_param_value *value)
> > {
> > struct nlattr *param_data;
> > - int len;
> > + int len, cnt, rem;
> >
> > param_data = info->attrs[DEVLINK_ATTR_PARAM_VALUE_DATA];
> >
> > @@ -547,6 +584,26 @@ devlink_param_value_get_from_info(const struct devlink_param *param,
> > return -EINVAL;
> > value->vbool = nla_get_flag(param_data);
> > break;
> > +
> > + case DEVLINK_PARAM_TYPE_U64_ARRAY:
> > + cnt = 0;
> > + nla_for_each_attr_type(param_data,
> > + DEVLINK_ATTR_PARAM_VALUE_DATA,
> > + genlmsg_data(info->genlhdr),
> > + genlmsg_len(info->genlhdr), rem) {
> > + if (cnt >= __DEVLINK_PARAM_MAX_ARRAY_SIZE)
> > + return -EMSGSIZE;
> > +
> > + if ((nla_len(param_data) != sizeof(u64)) &&
> > + (nla_len(param_data) != sizeof(u32)))
> > + return -EINVAL;
> > +
> > + value->u64arr.val[cnt] = (u64)nla_get_uint(param_data);
> > + cnt++;
> > + }
> > +
> > + value->u64arr.size = cnt;
> > + break;
>
> Sashiko says:
>
> ---
> Does this make it impossible to set an empty array to clear a
> multi-value parameter?
> If userspace provides 0 elements, param_data will be NULL. Earlier in
> devlink_param_value_get_from_info(), there is a check:
> param_data = info->attrs[DEVLINK_ATTR_PARAM_VALUE_DATA];
> if (param->type != DEVLINK_PARAM_TYPE_BOOL && !param_data)
> return -EINVAL;
> If the parameter is a U64_ARRAY and no data is provided, this check will
> immediately return -EINVAL.
> The kernel can successfully emit an empty array on a GET request if the
> size is 0. Should the SET path similarly support receiving 0 elements to
> allow userspace to clear a multi-value parameter?
multi-value parameter is to set values. if some one wants to set to zero
they can set all values as zero and pass a "size" array. we can ignore this comment, right ?
> ---
>
> There are several others NIC-specific remarks, which IMHO are mostly
> pre-existing issues, but please have a look:
>
> https://sashiko.dev/#/patchset/20260403025533.6250-1-rkannoth%40marvell.com
>
> /P
>
A. Patch 1: [PATCH v10 net-next 1/6] octeontx2-af: npc: cn20k: debugfs enhancements
1.
"Is it safe to use a global static array here?
Concurrent reads of the dstats debugfs file could race to read and write to
this array, leading to torn updates. Additionally, on systems with multiple
RVU devices, wouldn't they share the same array and cross-contaminate their
statistics?"
The purpose of using "dstats" is to identify which rules current traffic is hitting.
We are not particularly concerned with overall packet statistics, as those can
be obtained through rule's stats register. Each rule hit will display the corresponding
rule during 'cating', so this comment can be disregarded.
2.
"Are the hardware parameters read into npc_priv->bank_depth and
npc_priv->num_banks guaranteed to fit within the static bounds of dstats?
If the hardware reports a bank_depth that makes mcam_idx exceed the
pre-allocated array dimensions, could this result in an out-of-bounds
memory access here?"
static u64 dstats[MAX_NUM_BANKS][MAX_SUBBANK_DEPTH * MAX_NUM_SUB_BANKS] = {};
MAX_SUBBANK_DEPTH and MAX_NUM_SUB_BANKS are maximum possible. So above case
wont happen
3.
"Could this cause data loss if the output exceeds the initial seq_file
buffer size?
DEFINE_SHOW_ATTRIBUTE() uses single_open(), which will discard the buffer,
double its size, and re-invoke this show callback from the beginning if it
overflows.
Since dstats[bank][idx] is updated during the first execution, a
re-invocation would see stats == dstats[bank][idx] and silently drop all
previously processed entries."
The purpose of "dstats" entry to find live traffic hitting rules. It may be showing "wrong"
value for the first time, but second time onwards, it will be okay. Usually user runs 'cat'ing mutliple
times to find "htting" rule.
5.
"Similar to the dstats array, does this code overflow en_map?
If the index provided here can exceed the compile-time bounds of
MAX_NUM_BANKS * MAX_NUM_SUB_BANKS * MAX_SUBBANK_DEPTH due to dynamically
read hardware sizes, it could corrupt memory.
Additionally, is en_map explicitly cleared during device initialization
or teardown?
Since npc_priv is global, if the driver is unbound and rebound without
unloading the module, could en_map retain stale state from the previous
session?"
MAX_NUM_BANKS * MAX_NUM_SUB_BANKS * MAX_SUBBANK_DEPTH is big enough to hold
for all SoC variants.
B. Patch 2: [PATCH v10 net-next 2/6] net/mlx5e: heap-allocate devlink param values
1.
"Does returning -ENOMEM here trigger a redundant WARN_ON() in the caller?
Looking at mlx5e_pcie_cong_event_init(), it checks the return value like this:
drivers/net/ethernet/mellanox/mlx5/core/en/pcie_cong_event.c:mlx5e_pcie_cong_event_init() {
...
err = mlx5e_pcie_cong_get_thresh_config(mdev, &thresh_config);
if (WARN_ON(err))
return err;
...
}
Since kcalloc() already prints a warning and stack trace on allocation failure
(unless __GFP_NOWARN is used), wrapping the -ENOMEM return in WARN_ON() will
result in a double stack trace in the kernel log.
Is it possible to drop the WARN_ON() in the caller to avoid this redundant
splat?"
Existing code issue. i believe, i dont have to fix this. correct me pls.
C. Patch 3: [PATCH v10 net-next 3/6] devlink: Implement devlink param multi attribute nested data values
Replied above as part of your comments.
D. Patch 4: [PATCH v10 net-next 4/6] octeontx2-af: npc: cn20k: add subbank search order control
1.
"If xa_store() fails and we jump to fail_used, doesn't this leave the device
in an unrecoverable state?
The code previously erased all subbank entries from npc_priv.xa_sb_used and
npc_priv.xa_sb_free. By aborting without restoring the remaining subbanks,
the erased subbanks appear to be permanently leaked, which would permanently
break subsequent hardware MCAM allocations. Global state is also modified
before the insertion loop, leaving the driver's internal state inconsistent.
Could this be avoided by pre-allocating the required XArray slots with
xa_reserve() or by building new XArrays and swapping them upon success?"
We are doing this operation underlocks and there wont be repetitions of slots in
the array. This above condiition is very unlikely, if there is some issue, we
flag the error thru print. This means that there is some other deep issue which
caused this error. So we can ignore this.
2.
" + if (bitmap_weight(&w, sz) != sz) {
> + dev_err(rvu->dev,
> + "Duplicate or out-of-range subbank index. %lu\n",
> + find_first_zero_bit(&w, sz));
> + return -EINVAL;
> + }
Does this error message print the missing index instead of the duplicate
one?
Since find_first_zero_bit() finds the first unset bit, it will return the
index that the user failed to provide, not the one they duplicated or
provided out of range. Could this lead to a confusing error message for
users?"
I will change print error message to "Duplicate or missing or out-of-range subbank index. %lu\n","
E. Patch 5: [PATCH v10 net-next 5/6] octeontx2-af: npc: cn20k: dynamically allocate and free default MCAM entries
1.
> u64 cfg, hw_prio;
> u8 kw_type;
>
> + if (index < 0 || index >= mcam->total_entries) {
> + WARN(1, "Wrong mcam index %d\n", index);
> + return;
> + }
Could this cause kernel log spam due to unchecked negative MCAM indices?
In npc_enadis_default_entries() and npc_enadis_default_mce_entry(), the code
queries the MCAM index using npc_get_nixlf_mcam_index(), which correctly
returns a negative error code if the entry is not allocated.
This unchecked negative index is then passed directly to
npc_cn20k_enable_mcam_entry(), which checks if (index < 0) and triggers a
stack trace via WARN(1, ...). This means that a routine NIX LF teardown of
an uninitialized interface (or a VF without multicast support querying the
PF's missing BCAST entry) will repeatedly trigger stack traces.
We have checks in npc_enadis_default_entries() to check for default entries and bailout.
/* only CGX or LBK interfaces have default entries */
if (is_cn20k(rvu->pdev) &&
!npc_is_cgx_or_lbk(rvu, pcifunc & ~RVU_PFVF_FUNC_MASK))
return;
will add the same for npc_enadis_default_mce_entry() as well.
2.
> @@ -4024,6 +4041,13 @@ int npc_cn20k_dft_rules_idx_get(struct rvu *rvu, u16 pcifunc, u16 *bcast,
> void *val;
> int i, j;
>
> + for (int i = 0; i < ARRAY_SIZE(ptr); i++) {
> + if (!ptr[i])
> + continue;
There is variable shadowing here. The variable 'i' is declared at the
function scope, but the loop re-declares 'i', shadowing the outer scope
variable. This triggers -Wshadow compiler warnings.
ACK.
3.
Does this code use virtual MCAM indices as physical indices, potentially
causing massive out-of-bounds memory corruption?
In npc_cn20k_dft_rules_alloc(), default MCAM entries are allocated via the
mailbox handler (rvu_mbox_handler_npc_mcam_alloc_entry), which returns
virtual indices (vidx) in rsp.entry_list for CN20K hardware. These vidx
values are inserted directly into the xa_pf2dfl_rmap xarray.
Later, this code in npc_cn20k_dft_rules_free() retrieves these vidx values
and passes them directly to physical index APIs: npc_mcam_clear_bit() and
mcam->entry2pfvf_map[]. Because vidx indices are structurally shifted
(starting at npc_priv.bank_depth * 2), they are guaranteed to be larger
than mcam->bmap_entries.
This causes rentry = mcam->bmap_entries - index - 1 in npc_mcam_clear_bit()
to underflow, leading __clear_bit() to perform out-of-bounds writes on
kernel heap memory. The vidx values should probably be mapped back to
physical indices using npc_cn20k_vidx2idx() before accessing software state
arrays.
virt field in npc_mcam_alloc_entry_req structure is not set for while calling for
default mcam index allocation using rvu_mbox_handler_npc_mcam_alloc_entry(). So
this comment can be ignored.
4.
Is there a race condition here that could lead to MCAM index corruption due
to premature lock release?
The mcam->lock is held while calling npc_mcam_clear_bit(), which
immediately marks the MCAM index as free in the software bitmap
(mcam->bmap). The code then explicitly unlocks mcam->lock before calling
npc_cn20k_idx_free() to release the index in the firmware/hardware.
Releasing the lock creates a critical race window: another thread can
concurrently allocate this exact MCAM index (since it appears free in the
bitmap), assign it to a new interface, and configure it.
When the original thread resumes and calls npc_cn20k_idx_free(), it
instructs the hardware to free the index, silently destroying the newly
allocated flow rules of the concurrent thread. Should the hardware cleanup
be performed before the software bitmap is marked free, or should the lock
remain held?
These alloc free request are thru mbox messages and are processed one by one (serially)
So ignore this case.
5.
int npc_cn20k_dft_rules_alloc(struct rvu *rvu, u16 pcifunc)
Is there a software bitmap leak and multi-free bug in the error path of
npc_cn20k_dft_rules_alloc()?
If xa_insert() fails, the code jumps to the err label to free the allocated
entries. The error path executes:
for (i = 0; i < cnt; i++)
npc_idx_free(rvu, mcam_idx, cnt, false);
Since npc_idx_free() takes an array and a count to free 'cnt' entries,
looping over it causes the exact same array of indices to be freed 'cnt'
times.
Furthermore, the error path fails to clear the software bits in the core
hardware bitmap (mcam->bmap) via npc_mcam_clear_bit() and does not
invalidate mcam->entry2pfvf_map. Since the allocation handler successfully
marked these entries as used, omitting these steps permanently leaks the
software state for these MCAM indices.
dft rules fail means a critical issue as this will affect system operation. Theere is
no point in recovering cleanly from it. But anyway, i dont find a clear 1:1 with code, am
i missing anything here.
6.
Does this early return skip the cleanup of user-defined flow rules for
non-CGX/LBK interfaces?
While the intent seems to be skipping the disablement of default entries
for interfaces that don't have them (like SDP or CPT), this function is
also responsible for disabling ALL user-defined MCAM flow rules associated
with the pcifunc by iterating over mcam->mcam_rules.
By returning early here, all user-defined rules are left fully active in
the hardware parser, pointing to a NIX LF that is being torn down and freed.
This could lead to hardware DMA faults and context errors when traffic
matches these orphaned rules. Should this check be exclusively inside
rvu_npc_disable_default_entries() instead?
ACK.
7.
Can this cause a permanent resource leak of default MCAM entries on PF driver
teardown?
otx2_free_hw_resources() unconditionally sets the NIX_LF_DONT_FREE_DFT_IDXS
flag during NIX LF free. While intended for cases like suspend/resume, this
function is called across all driver unbind/remove paths.
Consequently, when the otx2_pf driver is unloaded, the AF driver skips
freeing the default MCAM rules, leaving them permanently orphaned in the
AF's xa_pf2dfl_rmap and hardware allocation bitmap. They can never be
recovered or reused by other physical or virtual functions, causing a
severe leak of globally shared MCAM resources on every module detach.
These default mcam indexes are freed during rvu_detach_rsrcs mbox call.
rvu_detach_rsrcs() ->npc_cn20k_dft_rules_free().
F: Patch 6: [PATCH v10 net-next 6/6] octeontx2-af: npc: Support for custom KPU profile from filesystem
1.
Can this corrupt global state? In npc_prepare_default_kpu(), adapter->kpu
is initialized to the global static array npc_kpu_profiles. By assigning
kpu->cam2 and kpu->action2 here, this modifies the shared static array with
device-managed memory (devm_kcalloc).
If the device is unbound, the memory will be freed, leaving dangling pointers
in the global array which could lead to a use-after-free for subsequent device
instances.
This memory is part of "AF" and is initlaized during boot. AF memory will be freed when
device is shutdown. There wont be any case of af getting freed and come again on a live system.
2.
> +
> + action = (struct npc_kpu_profile_action *)(fw->data + offset);
> +
> + if (rvu->kpu_fwdata_sz < hdr_sz + sizeof(ikpu_action_entries))
> + return -ENOMEM;
Is -ENOMEM the correct return value here? A malformed or truncated firmware
file would cause this condition, so -EINVAL might be more appropriate than
indicating a memory allocation failure.
ACK.
3.
Could this cause firmware compatibility issues in the future?
ikpu_action_entries is an internal kernel array. If new entries are added
to it in future kernel versions, sizeof(ikpu_action_entries) will grow. This
would cause older firmware files to fail the size check above, or miscalculate
the offset for subsequent entries.
There could be a chance, but there is not field in "struct npc_kpu_profile_fwdata"
to indicate sizeof ikpu_action_entries. Adding a new field will break backward compatability etc.
Anyway In future if more entries are planned, we need to come up with a new design to address
this issue.
4.
+
> + for (kpu = 0; kpu < fw->kpus; kpu++) {
Does this loop have a bounds checking issue? Unlike the firmware database
path which checks if fw->kpus is greater than profile->kpus, this path only
checked if fw->kpus is greater than rvu->hw->npc_kpus earlier.
If the hardware limit exceeds the size of the statically allocated
profile->kpu array, this could overflow profile->kpu.
ACK.
5.
+ "profile size mismatch on kpu%i parsing\n",
> + kpu + 1);
> + return -EINVAL;
> + }
> +
> + fw_kpu = (struct npc_kpu_fwdata *)(fw->data + offset);
> + entries = min(fw_kpu->entries, rvu->hw->npc_kpu_entries);
Can this result in an out-of-bounds read? The size check above only ensures
that the start of fw_kpu is within the firmware data boundaries. It does not
verify that the entire fw_kpu structure fits within the remaining space before
dereferencing fw_kpu->entries.
> + dev_info(rvu->dev,
> + "Loading %u entries on KPU%d\n", entries, kpu);
> +
ACK.
^ permalink raw reply
* Re: [PATCH net v2 1/1] net: hsr: avoid learning unknown senders for local delivery
From: Felix Maurer @ 2026-04-08 10:40 UTC (permalink / raw)
To: Ao Zhou
Cc: netdev, Sebastian Andrzej Siewior, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Murali Karicheri,
Shaurya Rane, Ingo Molnar, Kees Cook, Yifan Wu, Juefei Pu,
Yuan Tan, Xin Liu, Yuqi Xu, Haoze Xie
In-Reply-To: <b053e938014c9bac22f7f687ecc2970f23a2b74a.1775281843.git.royenheart@gmail.com>
On Sat, Apr 04, 2026 at 07:30:47PM +0800, Ao Zhou wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> Traffic that is directly addressed to the local HSR/PRP master can be
> delivered locally without creating a persistent node entry. Learning one
> node per previously unseen source MAC lets forged sender floods grow
> node_db until the prune timer catches up.
>
> Determine whether a frame is locally exclusive before node lookup and
> skip learning for unknown senders in that case. When no node state
> exists, also skip duplicate discard checks that depend on it.
>
> This keeps locally-destined traffic reachable while avoiding node table
> growth from source-MAC floods in both the PRP SAN path and the HSR/PRP
> tagged sender paths.
I see the problem you are trying to solve here, but I don't think this
patch provides a significant improvement over the current situation.
Yes, this will disable learning of new nodes from regular traffic (and
thereby completely prevent the duplicate discard algorithm from
working). New nodes would only be learned from supervision frames. But
nothing prevents a malicious host in the network from spoofing tons of
supervision frames.
HSR and PRP are supposed to be used in pretty restricted network
environments, so the whole protocol design doesn't really expect
malicious actors in the network and doesn't provide good options to
safeguard against misuse.
IMHO, the only real way to prevent excessive resource use on our side is
to put a limit on these resources. In this case, limit the size of the
node table (bonus: make that limit configurable as Paolo suggested).
Thanks,
Felix
> Fixes: f421436a591d ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
> Fixes: 451d8123f897 ("net: prp: add packet handling support")
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Tested-by: Yuqi Xu <xuyuqiabc@gmail.com>
> Signed-off-by: Haoze Xie <royenheart@gmail.com>
> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> ---
> changes in v2:
> - generalize the fix beyond PRP SAN traffic and cover HSR/PRP tagged sender floods
> - decide whether learning is needed from local-exclusive delivery instead of protocol-specific SAN checks
> - use the normal NULL return semantics from hsr_get_node() instead of ERR_PTR-based error plumbing
> - skip duplicate-discard state checks when no node state exists
>
> net/hsr/hsr_forward.c | 23 +++++++++++++----------
> net/hsr/hsr_framereg.c | 5 ++++-
> net/hsr/hsr_framereg.h | 2 +-
> 3 files changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
> index aefc9b6936ba..15bd17b4ee17 100644
> --- a/net/hsr/hsr_forward.c
> +++ b/net/hsr/hsr_forward.c
> @@ -403,7 +403,8 @@ static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
> int res, recv_len;
>
> was_multicast_frame = (skb->pkt_type == PACKET_MULTICAST);
> - hsr_addr_subst_source(node_src, skb);
> + if (node_src)
> + hsr_addr_subst_source(node_src, skb);
> skb_pull(skb, ETH_HLEN);
> recv_len = skb->len;
> res = netif_rx(skb);
> @@ -545,7 +546,7 @@ static void hsr_forward_do(struct hsr_frame_info *frame)
> /* Don't send frame over port where it has been sent before.
> * Also for SAN, this shouldn't be done.
> */
> - if (!frame->is_from_san &&
> + if (frame->node_src && !frame->is_from_san &&
> hsr->proto_ops->register_frame_out &&
> hsr->proto_ops->register_frame_out(port, frame))
> continue;
> @@ -688,21 +689,25 @@ static int fill_frame_info(struct hsr_frame_info *frame,
> return -EINVAL;
>
> memset(frame, 0, sizeof(*frame));
> + frame->port_rcv = port;
> frame->is_supervision = is_supervision_frame(port->hsr, skb);
> if (frame->is_supervision && hsr->redbox)
> frame->is_proxy_supervision =
> is_proxy_supervision_frame(port->hsr, skb);
>
> + ethhdr = (struct ethhdr *)skb_mac_header(skb);
> + check_local_dest(port->hsr, skb, frame);
> +
> n_db = &hsr->node_db;
> if (port->type == HSR_PT_INTERLINK)
> n_db = &hsr->proxy_node_db;
>
> frame->node_src = hsr_get_node(port, n_db, skb,
> - frame->is_supervision, port->type);
> - if (!frame->node_src)
> - return -1; /* Unknown node and !is_supervision, or no mem */
> + frame->is_supervision, port->type,
> + !frame->is_local_exclusive);
> + if (!frame->node_src && !frame->is_local_exclusive)
> + return -1;
>
> - ethhdr = (struct ethhdr *)skb_mac_header(skb);
> frame->is_vlan = false;
> proto = ethhdr->h_proto;
>
> @@ -720,13 +725,10 @@ static int fill_frame_info(struct hsr_frame_info *frame,
> }
>
> frame->is_from_san = false;
> - frame->port_rcv = port;
> ret = hsr->proto_ops->fill_frame_info(proto, skb, frame);
> if (ret)
> return ret;
>
> - check_local_dest(port->hsr, skb, frame);
> -
> return 0;
> }
>
> @@ -739,7 +741,8 @@ void hsr_forward_skb(struct sk_buff *skb, struct hsr_port *port)
> if (fill_frame_info(&frame, skb, port) < 0)
> goto out_drop;
>
> - hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> + if (frame.node_src)
> + hsr_register_frame_in(frame.node_src, port, frame.sequence_nr);
> hsr_forward_do(&frame);
> rcu_read_unlock();
> /* Gets called for ingress frames as well as egress from master port.
> diff --git a/net/hsr/hsr_framereg.c b/net/hsr/hsr_framereg.c
> index 50996f4de7f9..2bc6f8f154c2 100644
> --- a/net/hsr/hsr_framereg.c
> +++ b/net/hsr/hsr_framereg.c
> @@ -221,7 +221,7 @@ void prp_update_san_info(struct hsr_node *node, bool is_sup)
> */
> struct hsr_node *hsr_get_node(struct hsr_port *port, struct list_head *node_db,
> struct sk_buff *skb, bool is_sup,
> - enum hsr_port_type rx_port)
> + enum hsr_port_type rx_port, bool learn)
> {
> struct hsr_priv *hsr = port->hsr;
> struct hsr_node *node;
> @@ -270,6 +270,9 @@ struct hsr_node *hsr_get_node(struct hsr_port *port, struct list_head *node_db,
> san = true;
> }
>
> + if (!learn)
> + return NULL;
> +
> return hsr_add_node(hsr, node_db, ethhdr->h_source, san, rx_port);
> }
>
> diff --git a/net/hsr/hsr_framereg.h b/net/hsr/hsr_framereg.h
> index c65ecb925734..3d9c88e83090 100644
> --- a/net/hsr/hsr_framereg.h
> +++ b/net/hsr/hsr_framereg.h
> @@ -33,7 +33,7 @@ void hsr_del_self_node(struct hsr_priv *hsr);
> void hsr_del_nodes(struct list_head *node_db);
> struct hsr_node *hsr_get_node(struct hsr_port *port, struct list_head *node_db,
> struct sk_buff *skb, bool is_sup,
> - enum hsr_port_type rx_port);
> + enum hsr_port_type rx_port, bool learn);
> void hsr_handle_sup_frame(struct hsr_frame_info *frame);
> bool hsr_addr_is_self(struct hsr_priv *hsr, unsigned char *addr);
> bool hsr_addr_is_redbox(struct hsr_priv *hsr, unsigned char *addr);
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH net-next v3 4/4] can: raw: convert to getsockopt_iter
From: Breno Leitao @ 2026-04-08 10:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev
Cc: io-uring, bpf, netdev, Linus Torvalds, linux-kernel, kernel-team,
Breno Leitao
In-Reply-To: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org>
Convert CAN raw socket's getsockopt implementation to use the new
getsockopt_iter callback with sockopt_t.
Key changes:
- Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
- Use opt->optlen for buffer length (input) and returned size (output)
- Use copy_to_iter() instead of copy_to_user()
- For CAN_RAW_FILTER and CAN_RAW_XL_VCID_OPTS: on -ERANGE, set
opt->optlen to the required buffer size. The wrapper writes this
back to userspace even on error, preserving the existing API that
lets userspace discover the needed allocation size.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/can/raw.c | 28 +++++++++++++---------------
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/net/can/raw.c b/net/can/raw.c
index eee244ffc31ec..6f9ef867a13f2 100644
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -760,7 +760,7 @@ static int raw_setsockopt(struct socket *sock, int level, int optname,
}
static int raw_getsockopt(struct socket *sock, int level, int optname,
- char __user *optval, int __user *optlen)
+ sockopt_t *opt)
{
struct sock *sk = sock->sk;
struct raw_sock *ro = raw_sk(sk);
@@ -770,8 +770,7 @@ static int raw_getsockopt(struct socket *sock, int level, int optname,
if (level != SOL_CAN_RAW)
return -EINVAL;
- if (get_user(len, optlen))
- return -EFAULT;
+ len = opt->optlen;
if (len < 0)
return -EINVAL;
@@ -787,12 +786,12 @@ static int raw_getsockopt(struct socket *sock, int level, int optname,
if (len < fsize) {
/* return -ERANGE and needed space in optlen */
err = -ERANGE;
- if (put_user(fsize, optlen))
- err = -EFAULT;
+ opt->optlen = fsize;
} else {
if (len > fsize)
len = fsize;
- if (copy_to_user(optval, ro->filter, len))
+ if (copy_to_iter(ro->filter, len,
+ &opt->iter_out) != len)
err = -EFAULT;
}
} else {
@@ -801,7 +800,7 @@ static int raw_getsockopt(struct socket *sock, int level, int optname,
release_sock(sk);
if (!err)
- err = put_user(len, optlen);
+ opt->optlen = len;
return err;
}
case CAN_RAW_ERR_FILTER:
@@ -845,16 +844,16 @@ static int raw_getsockopt(struct socket *sock, int level, int optname,
if (len < sizeof(ro->raw_vcid_opts)) {
/* return -ERANGE and needed space in optlen */
err = -ERANGE;
- if (put_user(sizeof(ro->raw_vcid_opts), optlen))
- err = -EFAULT;
+ opt->optlen = sizeof(ro->raw_vcid_opts);
} else {
if (len > sizeof(ro->raw_vcid_opts))
len = sizeof(ro->raw_vcid_opts);
- if (copy_to_user(optval, &ro->raw_vcid_opts, len))
+ if (copy_to_iter(&ro->raw_vcid_opts, len,
+ &opt->iter_out) != len)
err = -EFAULT;
}
if (!err)
- err = put_user(len, optlen);
+ opt->optlen = len;
return err;
}
case CAN_RAW_JOIN_FILTERS:
@@ -868,9 +867,8 @@ static int raw_getsockopt(struct socket *sock, int level, int optname,
return -ENOPROTOOPT;
}
- if (put_user(len, optlen))
- return -EFAULT;
- if (copy_to_user(optval, val, len))
+ opt->optlen = len;
+ if (copy_to_iter(val, len, &opt->iter_out) != len)
return -EFAULT;
return 0;
}
@@ -1077,7 +1075,7 @@ static const struct proto_ops raw_ops = {
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
.setsockopt = raw_setsockopt,
- .getsockopt = raw_getsockopt,
+ .getsockopt_iter = raw_getsockopt,
.sendmsg = raw_sendmsg,
.recvmsg = raw_recvmsg,
.mmap = sock_no_mmap,
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 2/4] net: call getsockopt_iter if available
From: Breno Leitao @ 2026-04-08 10:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev
Cc: io-uring, bpf, netdev, Linus Torvalds, linux-kernel, kernel-team,
Breno Leitao
In-Reply-To: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org>
Update do_sock_getsockopt() to use the new getsockopt_iter callback
when available. Add do_sock_getsockopt_iter() helper that:
1. Reads optlen from user/kernel space
2. Initializes a sockopt_t with the appropriate iov_iter (kvec for
kernel, ubuf for user buffers) and sets opt.optlen
3. Calls the protocol's getsockopt_iter callback
4. Writes opt.optlen back to user/kernel space
The optlen is always written back, even on failure. Some protocols
(e.g. CAN raw) return -ERANGE and set optlen to the required buffer
size so userspace knows how much to allocate.
The callback is responsible for setting opt.optlen to indicate the
returned data size.
Important to say that iov_out does not need to be copied back in
do_sock_getsockopt().
When optval is not kernel (the userspace path), sockptr_to_sockopt()
sets up opt->iter_out as a ITER_DEST ubuf iterator pointing directly at
the userspace buffer (optval.user). So when getsockopt_iter
implementations call copy_to_iter(..., &opt->iter_out), the data is
written directly to userspace — no intermediate kernel buffer is
involved.
When optval.is_kernel is true (the in-kernel path, e.g. from io_uring),
the kvec points at the already-provided kernel buffer (optval.kernel),
so the data lands in the caller's buffer directly via the kvec-backed
iterator.
In both cases the iterator writes to the final destination in-place at
protocol callback. There's nothing to copy back — only optlen needs to
be written back.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/socket.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 51 insertions(+), 3 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index ade2ff5845a0c..a25e513cf0f47 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -77,6 +77,7 @@
#include <linux/mount.h>
#include <linux/pseudo_fs.h>
#include <linux/security.h>
+#include <linux/uio.h>
#include <linux/syscalls.h>
#include <linux/compat.h>
#include <linux/kmod.h>
@@ -2349,11 +2350,45 @@ SYSCALL_DEFINE5(setsockopt, int, fd, int, level, int, optname,
INDIRECT_CALLABLE_DECLARE(bool tcp_bpf_bypass_getsockopt(int level,
int optname));
+/*
+ * Initialize a sockopt_t from sockptr optval/optlen, setting up iov_iter
+ * for both input and output directions.
+ * It is important to remember that both iov points to the same data, but,
+ * .iter_in is read-only and .iter_out is write-only by the protocol callbacks
+ */
+static int sockptr_to_sockopt(sockopt_t *opt, sockptr_t optval,
+ sockptr_t optlen, struct kvec *kvec)
+{
+ int koptlen;
+
+ if (copy_from_sockptr(&koptlen, optlen, sizeof(int)))
+ return -EFAULT;
+
+ if (koptlen < 0)
+ return -EINVAL;
+
+ if (optval.is_kernel) {
+ kvec->iov_base = optval.kernel;
+ kvec->iov_len = koptlen;
+ iov_iter_kvec(&opt->iter_out, ITER_DEST, kvec, 1, koptlen);
+ iov_iter_kvec(&opt->iter_in, ITER_SOURCE, kvec, 1, koptlen);
+ } else {
+ iov_iter_ubuf(&opt->iter_out, ITER_DEST, optval.user, koptlen);
+ iov_iter_ubuf(&opt->iter_in, ITER_SOURCE, optval.user,
+ koptlen);
+ }
+ opt->optlen = koptlen;
+
+ return 0;
+}
+
int do_sock_getsockopt(struct socket *sock, bool compat, int level,
int optname, sockptr_t optval, sockptr_t optlen)
{
int max_optlen __maybe_unused = 0;
const struct proto_ops *ops;
+ struct kvec kvec;
+ sockopt_t opt;
int err;
err = security_socket_getsockopt(sock, level, optname);
@@ -2366,15 +2401,28 @@ int do_sock_getsockopt(struct socket *sock, bool compat, int level,
ops = READ_ONCE(sock->ops);
if (level == SOL_SOCKET) {
err = sk_getsockopt(sock->sk, level, optname, optval, optlen);
- } else if (unlikely(!ops->getsockopt)) {
- err = -EOPNOTSUPP;
- } else {
+ } else if (ops->getsockopt_iter) {
+ err = sockptr_to_sockopt(&opt, optval, optlen, &kvec);
+ if (err)
+ return err;
+
+ err = ops->getsockopt_iter(sock, level, optname, &opt);
+
+ /* Always write back optlen, even on failure. Some protocols
+ * (e.g. CAN raw) return -ERANGE and set optlen to the
+ * required buffer size so userspace can discover it.
+ */
+ if (copy_to_sockptr(optlen, &opt.optlen, sizeof(int)))
+ return -EFAULT;
+ } else if (ops->getsockopt) {
if (WARN_ONCE(optval.is_kernel || optlen.is_kernel,
"Invalid argument type"))
return -EOPNOTSUPP;
err = ops->getsockopt(sock, level, optname, optval.user,
optlen.user);
+ } else {
+ err = -EOPNOTSUPP;
}
if (!compat)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 3/4] af_packet: convert to getsockopt_iter
From: Breno Leitao @ 2026-04-08 10:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev
Cc: io-uring, bpf, netdev, Linus Torvalds, linux-kernel, kernel-team,
Breno Leitao
In-Reply-To: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org>
Convert AF_PACKET's getsockopt implementation to use the new
getsockopt_iter callback with sockopt_t.
Key changes:
- Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
- Use opt->optlen for buffer length (input) and returned size (output)
- Use copy_to_iter() instead of put_user()/copy_to_user()
- For PACKET_HDRLEN which reads from optval: use opt->iter_in with
copy_from_iter() for the input read, then the common opt->iter_out
copy_to_iter() epilogue handles the output
Signed-off-by: Breno Leitao <leitao@debian.org>
---
net/packet/af_packet.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index bb2d88205e5a6..1da78b6ad3d5f 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -49,6 +49,7 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
#include <linux/ethtool.h>
+#include <linux/uio.h>
#include <linux/filter.h>
#include <linux/types.h>
#include <linux/mm.h>
@@ -4051,7 +4052,7 @@ packet_setsockopt(struct socket *sock, int level, int optname, sockptr_t optval,
}
static int packet_getsockopt(struct socket *sock, int level, int optname,
- char __user *optval, int __user *optlen)
+ sockopt_t *opt)
{
int len;
int val, lv = sizeof(val);
@@ -4065,8 +4066,7 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
if (level != SOL_PACKET)
return -ENOPROTOOPT;
- if (get_user(len, optlen))
- return -EFAULT;
+ len = opt->optlen;
if (len < 0)
return -EINVAL;
@@ -4115,7 +4115,7 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
len = sizeof(int);
if (len < sizeof(int))
return -EINVAL;
- if (copy_from_user(&val, optval, len))
+ if (copy_from_iter(&val, len, &opt->iter_in) != len)
return -EFAULT;
switch (val) {
case TPACKET_V1:
@@ -4171,9 +4171,8 @@ static int packet_getsockopt(struct socket *sock, int level, int optname,
if (len > lv)
len = lv;
- if (put_user(len, optlen))
- return -EFAULT;
- if (copy_to_user(optval, data, len))
+ opt->optlen = len;
+ if (copy_to_iter(data, len, &opt->iter_out) != len)
return -EFAULT;
return 0;
}
@@ -4672,7 +4671,7 @@ static const struct proto_ops packet_ops = {
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
.setsockopt = packet_setsockopt,
- .getsockopt = packet_getsockopt,
+ .getsockopt_iter = packet_getsockopt,
.sendmsg = packet_sendmsg,
.recvmsg = packet_recvmsg,
.mmap = packet_mmap,
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers
From: Breno Leitao @ 2026-04-08 10:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev
Cc: io-uring, bpf, netdev, Linus Torvalds, linux-kernel, kernel-team,
Breno Leitao
Currently, the .getsockopt callback requires __user pointers:
int (*getsockopt)(struct socket *sock, int level,
int optname, char __user *optval, int __user *optlen);
This prevents kernel callers (io_uring, BPF) from using getsockopt on
levels other than SOL_SOCKET, since they pass kernel pointers.
Following Linus' suggestion [0], this series introduces sockopt_t, a
type-safe wrapper around iov_iter, and a getsockopt_iter callback that
works with both user and kernel buffers. AF_PACKET and CAN raw are
converted as initial users, with selftests covering the trickiest
conversion patterns.
[0] https://lore.kernel.org/all/CAHk-=whmzrO-BMU=uSVXbuoLi-3tJsO=0kHj1BCPBE3F2kVhTA@mail.gmail.com/
Updates from v2 to v3:
* Use two iov in sockopt_t instead of a single one:
a) .iter_in that is populated by the caller and will be read-only in
the protocols callback.
b) .iter_out will be populated by the protocol and it will be sent
back to the caller.
- This will avoid changing the protocol reset and changing the data
source at the callback, making the driver callback implementation
and converstion saner.
* created sockptr_to_sockopt() to convert sockptr to sockopt, making the
call to getsockopt_iter straight-forward
Link: https://lore.kernel.org/all/CAHk-=whmzrO-BMU=uSVXbuoLi-3tJsO=0kHj1BCPBE3F2kVhTA@mail.gmail.com/ [0]
---
Changes in v3:
- Create Two iov in sockopt_t instead of a single one (Stanislav Fomichev)
- Implement the sockptr_to_sockopt() helper (Stanislav Fomichev)
- Link to v2: https://patch.msgid.link/20260401-getsockopt-v2-0-611df6771aff@debian.org
Changes in v2:
- Restore optlen even on error path (getsockopt_iter fails)
- Move af_packet.c and can instead of netlink (given these are the most
complicate ones).
- Link to v1: https://patch.msgid.link/20260130-getsockopt-v1-0-9154fcff6f95@debian.org
---
Breno Leitao (4):
net: add getsockopt_iter callback to proto_ops
net: call getsockopt_iter if available
af_packet: convert to getsockopt_iter
can: raw: convert to getsockopt_iter
include/linux/net.h | 23 +++++++++++++++++++++
net/can/raw.c | 28 ++++++++++++--------------
net/packet/af_packet.c | 15 +++++++-------
net/socket.c | 54 +++++++++++++++++++++++++++++++++++++++++++++++---
4 files changed, 94 insertions(+), 26 deletions(-)
---
base-commit: 9c14d60a50c4b726a3613a02e8b74778e9964891
change-id: 20260130-getsockopt-9f36625eedcb
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply
* [PATCH net-next v3 1/4] net: add getsockopt_iter callback to proto_ops
From: Breno Leitao @ 2026-04-08 10:30 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, metze, axboe,
Stanislav Fomichev
Cc: io-uring, bpf, netdev, Linus Torvalds, linux-kernel, kernel-team,
Breno Leitao
In-Reply-To: <20260408-getsockopt-v3-0-061bb9cb355d@debian.org>
Add a new getsockopt_iter callback to struct proto_ops that uses
sockopt_t, a type-safe wrapper around iov_iter. This provides a clean
interface for socket option operations that works with both user and
kernel buffers.
The sockopt_t type encapsulates an iov_iter and an optlen field.
The optlen field, although not suggested by Linus, serves as both input
(buffer size) and output (returned data size), allowing callbacks to
return random values independent of the bytes written via
copy_to_iter(), so, keep it separated from iov_iter.count.
This is preparatory work for removing the SOL_SOCKET level restriction
from io_uring getsockopt operations.
Keep in mind that both iter_out and iter_in always point to the same
data at all times, and we just have two of them to make the callback
implementation sane.
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Breno Leitao <leitao@debian.org>
---
include/linux/net.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/include/linux/net.h b/include/linux/net.h
index a8e818de95b33..fdd48d5c94441 100644
--- a/include/linux/net.h
+++ b/include/linux/net.h
@@ -23,9 +23,30 @@
#include <linux/fs.h>
#include <linux/mm.h>
#include <linux/sockptr.h>
+#include <linux/uio.h>
#include <uapi/linux/net.h>
+/**
+ * struct sockopt - socket option value container
+ * @iter_in: iov_iter for reading optval with the content from the caller.
+ * Use copy_from_iter() given this iov direction is ITER_SOURCE
+ * @iter_out: iov_iter for protocols to update optval data to userspace
+ * Use _copy_to_iter() given iov direction is ITER_DEST
+ * @optlen: serves as both input (buffer size) and output (returned data size).
+ *
+ * Type-safe wrapper for socket option data that works with both
+ * user and kernel buffers.
+ *
+ * The optlen field allows callbacks to return a specific length value
+ * independent of the bytes written via copy_to_iter().
+ */
+typedef struct sockopt {
+ struct iov_iter iter_in;
+ struct iov_iter iter_out;
+ int optlen;
+} sockopt_t;
+
struct poll_table_struct;
struct pipe_inode_info;
struct inode;
@@ -192,6 +213,8 @@ struct proto_ops {
unsigned int optlen);
int (*getsockopt)(struct socket *sock, int level,
int optname, char __user *optval, int __user *optlen);
+ int (*getsockopt_iter)(struct socket *sock, int level,
+ int optname, sockopt_t *opt);
void (*show_fdinfo)(struct seq_file *m, struct socket *sock);
int (*sendmsg) (struct socket *sock, struct msghdr *m,
size_t total_len);
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 5/5] dpll: zl3073x: add ref-sync pair support
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260408102716.443099-1-ivecera@redhat.com>
Add support for ref-sync pair registration using the 'ref-sync-sources'
phandle property from device tree. A ref-sync pair consists of a clock
reference and a low-frequency sync signal where the DPLL locks to the
clock reference but phase-aligns to the sync reference.
The implementation:
- Stores fwnode handle in zl3073x_dpll_pin during pin registration
- Adds ref_sync_get/set callbacks to read and write the sync control
mode and pair registers
- Validates ref-sync frequency constraints: sync signal must be 8 kHz
or less, clock reference must be 1 kHz or more and higher than sync
- Excludes sync source from automatic reference selection by setting
its priority to NONE on connect; on disconnect the priority is left
as NONE and the user must explicitly make the pin selectable again
- Iterates ref-sync-sources phandles to register declared pairings
via dpll_pin_ref_sync_pair_add()
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 207 +++++++++++++++++++++++++++++++++++-
1 file changed, 206 insertions(+), 1 deletion(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index dc649cf103cb4..c95e93ef3ab04 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/netlink.h>
#include <linux/platform_device.h>
+#include <linux/property.h>
#include <linux/slab.h>
#include <linux/sprintf.h>
@@ -30,6 +31,7 @@
* @dpll: DPLL the pin is registered to
* @dpll_pin: pointer to registered dpll_pin
* @tracker: tracking object for the acquired reference
+ * @fwnode: firmware node handle
* @label: package label
* @dir: pin direction
* @id: pin id
@@ -46,6 +48,7 @@ struct zl3073x_dpll_pin {
struct zl3073x_dpll *dpll;
struct dpll_pin *dpll_pin;
dpll_tracker tracker;
+ struct fwnode_handle *fwnode;
char label[8];
enum dpll_pin_direction dir;
u8 id;
@@ -186,6 +189,109 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
return zl3073x_ref_state_set(zldev, ref_id, &ref);
}
+static int
+zl3073x_dpll_input_pin_ref_sync_get(const struct dpll_pin *dpll_pin,
+ void *pin_priv,
+ const struct dpll_pin *ref_sync_pin,
+ void *ref_sync_pin_priv,
+ enum dpll_pin_state *state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll_pin *sync_pin = ref_sync_pin_priv;
+ struct zl3073x_dpll_pin *pin = pin_priv;
+ struct zl3073x_dpll *zldpll = pin->dpll;
+ struct zl3073x_dev *zldev = zldpll->dev;
+ const struct zl3073x_ref *ref;
+ u8 ref_id, mode, pair;
+
+ ref_id = zl3073x_input_pin_ref_get(pin->id);
+ ref = zl3073x_ref_state_get(zldev, ref_id);
+ mode = zl3073x_ref_sync_mode_get(ref);
+ pair = zl3073x_ref_sync_pair_get(ref);
+
+ if (mode == ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR &&
+ pair == zl3073x_input_pin_ref_get(sync_pin->id))
+ *state = DPLL_PIN_STATE_CONNECTED;
+ else
+ *state = DPLL_PIN_STATE_DISCONNECTED;
+
+ return 0;
+}
+
+static int
+zl3073x_dpll_input_pin_ref_sync_set(const struct dpll_pin *dpll_pin,
+ void *pin_priv,
+ const struct dpll_pin *ref_sync_pin,
+ void *ref_sync_pin_priv,
+ const enum dpll_pin_state state,
+ struct netlink_ext_ack *extack)
+{
+ struct zl3073x_dpll_pin *sync_pin = ref_sync_pin_priv;
+ struct zl3073x_dpll_pin *pin = pin_priv;
+ struct zl3073x_dpll *zldpll = pin->dpll;
+ struct zl3073x_dev *zldev = zldpll->dev;
+ u8 mode, ref_id, sync_ref_id;
+ struct zl3073x_chan chan;
+ struct zl3073x_ref ref;
+ int rc;
+
+ ref_id = zl3073x_input_pin_ref_get(pin->id);
+ sync_ref_id = zl3073x_input_pin_ref_get(sync_pin->id);
+ ref = *zl3073x_ref_state_get(zldev, ref_id);
+
+ if (state == DPLL_PIN_STATE_CONNECTED) {
+ const struct zl3073x_ref *sync_ref;
+ u32 ref_freq, sync_freq;
+
+ sync_ref = zl3073x_ref_state_get(zldev, sync_ref_id);
+ ref_freq = zl3073x_ref_freq_get(&ref);
+ sync_freq = zl3073x_ref_freq_get(sync_ref);
+
+ /* Sync signal must be 8 kHz or less and clock reference
+ * must be 1 kHz or more and higher than the sync signal.
+ */
+ if (sync_freq > 8000) {
+ NL_SET_ERR_MSG(extack,
+ "sync frequency must be 8 kHz or less");
+ return -EINVAL;
+ }
+ if (ref_freq < 1000) {
+ NL_SET_ERR_MSG(extack,
+ "clock frequency must be 1 kHz or more");
+ return -EINVAL;
+ }
+ if (ref_freq <= sync_freq) {
+ NL_SET_ERR_MSG(extack,
+ "clock frequency must be higher than sync frequency");
+ return -EINVAL;
+ }
+
+ zl3073x_ref_sync_pair_set(&ref, sync_ref_id);
+ mode = ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR;
+ } else {
+ mode = ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF;
+ }
+
+ zl3073x_ref_sync_mode_set(&ref, mode);
+
+ rc = zl3073x_ref_state_set(zldev, ref_id, &ref);
+ if (rc)
+ return rc;
+
+ /* Exclude sync source from automatic reference selection by setting
+ * its priority to NONE. On disconnect the priority is left as NONE
+ * and the user must explicitly make the pin selectable again.
+ */
+ if (state == DPLL_PIN_STATE_CONNECTED) {
+ chan = *zl3073x_chan_state_get(zldev, zldpll->id);
+ zl3073x_chan_ref_prio_set(&chan, sync_ref_id,
+ ZL_DPLL_REF_PRIO_NONE);
+ return zl3073x_chan_state_set(zldev, zldpll->id, &chan);
+ }
+
+ return 0;
+}
+
static int
zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
const struct dpll_device *dpll, void *dpll_priv,
@@ -1147,6 +1253,8 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
.phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
.prio_get = zl3073x_dpll_input_pin_prio_get,
.prio_set = zl3073x_dpll_input_pin_prio_set,
+ .ref_sync_get = zl3073x_dpll_input_pin_ref_sync_get,
+ .ref_sync_set = zl3073x_dpll_input_pin_ref_sync_set,
.state_on_dpll_get = zl3073x_dpll_input_pin_state_on_dpll_get,
.state_on_dpll_set = zl3073x_dpll_input_pin_state_on_dpll_set,
};
@@ -1239,8 +1347,11 @@ zl3073x_dpll_pin_register(struct zl3073x_dpll_pin *pin, u32 index)
if (IS_ERR(props))
return PTR_ERR(props);
- /* Save package label, esync capability and phase adjust granularity */
+ /* Save package label, fwnode, esync capability and phase adjust
+ * granularity.
+ */
strscpy(pin->label, props->package_label);
+ pin->fwnode = fwnode_handle_get(props->fwnode);
pin->esync_control = props->esync_control;
pin->phase_gran = props->dpll_props.phase_gran;
@@ -1285,6 +1396,8 @@ zl3073x_dpll_pin_register(struct zl3073x_dpll_pin *pin, u32 index)
dpll_pin_put(pin->dpll_pin, &pin->tracker);
pin->dpll_pin = NULL;
err_pin_get:
+ fwnode_handle_put(pin->fwnode);
+ pin->fwnode = NULL;
zl3073x_pin_props_put(props);
return rc;
@@ -1314,6 +1427,9 @@ zl3073x_dpll_pin_unregister(struct zl3073x_dpll_pin *pin)
dpll_pin_put(pin->dpll_pin, &pin->tracker);
pin->dpll_pin = NULL;
+
+ fwnode_handle_put(pin->fwnode);
+ pin->fwnode = NULL;
}
/**
@@ -1827,6 +1943,88 @@ zl3073x_dpll_free(struct zl3073x_dpll *zldpll)
kfree(zldpll);
}
+/**
+ * zl3073x_dpll_ref_sync_pair_register - register ref_sync pairs for a pin
+ * @pin: pointer to zl3073x_dpll_pin structure
+ *
+ * Iterates 'ref-sync-sources' phandles in the pin's firmware node and
+ * registers each declared pairing.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_dpll_ref_sync_pair_register(struct zl3073x_dpll_pin *pin)
+{
+ struct zl3073x_dev *zldev = pin->dpll->dev;
+ struct fwnode_handle *fwnode;
+ struct dpll_pin *sync_pin;
+ dpll_tracker tracker;
+ int n, rc;
+
+ for (n = 0; ; n++) {
+ /* Get n'th ref-sync source */
+ fwnode = fwnode_find_reference(pin->fwnode, "ref-sync-sources",
+ n);
+ if (IS_ERR(fwnode)) {
+ rc = PTR_ERR(fwnode);
+ break;
+ }
+
+ /* Find associated dpll pin */
+ sync_pin = fwnode_dpll_pin_find(fwnode, &tracker);
+ fwnode_handle_put(fwnode);
+ if (!sync_pin) {
+ dev_warn(zldev->dev, "%s: ref-sync source %d not found",
+ pin->label, n);
+ continue;
+ }
+
+ /* Register new ref-sync pair */
+ rc = dpll_pin_ref_sync_pair_add(pin->dpll_pin, sync_pin);
+ dpll_pin_put(sync_pin, &tracker);
+
+ /* -EBUSY means pairing already exists from another DPLL's
+ * registration.
+ */
+ if (rc && rc != -EBUSY) {
+ dev_err(zldev->dev,
+ "%s: failed to add ref-sync source %d: %pe",
+ pin->label, n, ERR_PTR(rc));
+ break;
+ }
+ }
+
+ return rc != -ENOENT ? rc : 0;
+}
+
+/**
+ * zl3073x_dpll_ref_sync_pairs_register - register ref_sync pairs for a DPLL
+ * @zldpll: pointer to zl3073x_dpll structure
+ *
+ * Iterates all registered input pins of the given DPLL and establishes
+ * ref_sync pairings declared by 'ref-sync-sources' phandles in the
+ * device tree.
+ *
+ * Return: 0 on success, <0 on error
+ */
+static int
+zl3073x_dpll_ref_sync_pairs_register(struct zl3073x_dpll *zldpll)
+{
+ struct zl3073x_dpll_pin *pin;
+ int rc;
+
+ list_for_each_entry(pin, &zldpll->pins, list) {
+ if (!zl3073x_dpll_is_input_pin(pin) || !pin->fwnode)
+ continue;
+
+ rc = zl3073x_dpll_ref_sync_pair_register(pin);
+ if (rc)
+ return rc;
+ }
+
+ return 0;
+}
+
/**
* zl3073x_dpll_register - register DPLL device and all its pins
* @zldpll: pointer to zl3073x_dpll structure
@@ -1850,6 +2048,13 @@ zl3073x_dpll_register(struct zl3073x_dpll *zldpll)
return rc;
}
+ rc = zl3073x_dpll_ref_sync_pairs_register(zldpll);
+ if (rc) {
+ zl3073x_dpll_pins_unregister(zldpll);
+ zl3073x_dpll_device_unregister(zldpll);
+ return rc;
+ }
+
return 0;
}
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 4/5] dt-bindings: dpll: add ref-sync-sources property
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Rob Herring (Arm),
Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt, Simon Horman,
Vadim Fedorenko, linux-kernel, Conor Dooley, Krzysztof Kozlowski,
devicetree, Pasi Vaananen
In-Reply-To: <20260408102716.443099-1-ivecera@redhat.com>
Add ref-sync-sources phandle-array property to the dpll-pin schema
allowing board designers to declare which input pins can serve as
sync sources in a Reference-Sync pair. A Ref-Sync pair consists of
a clock reference and a low-frequency sync signal where the DPLL locks
to the clock but phase-aligns to the sync reference.
Update both examples in the Microchip ZL3073x binding to demonstrate
the new property with a 1 PPS sync source paired to a clock source.
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
.../devicetree/bindings/dpll/dpll-pin.yaml | 13 ++++++++
.../bindings/dpll/microchip,zl30731.yaml | 30 ++++++++++++++-----
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
index 51db93b77306f..1287a472f08fa 100644
--- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
+++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
@@ -36,6 +36,19 @@ properties:
description: String exposed as the pin board label
$ref: /schemas/types.yaml#/definitions/string
+ ref-sync-sources:
+ description: |
+ List of phandles to input pins that can serve as the sync source
+ in a Reference-Sync pair with this pin acting as the clock source.
+ A Ref-Sync pair consists of a clock reference and a low-frequency
+ sync signal. The DPLL locks to the clock reference but
+ phase-aligns to the sync reference.
+ Only valid for input pins. Each referenced pin must be a
+ different input pin on the same device.
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ items:
+ maxItems: 1
+
supported-frequencies-hz:
description: List of supported frequencies for this pin, expressed in Hz.
diff --git a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
index 17747f754b845..fa5a8f8e390cd 100644
--- a/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
+++ b/Documentation/devicetree/bindings/dpll/microchip,zl30731.yaml
@@ -52,11 +52,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync0: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ label = "SMA1";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source, can pair with sync0 */
+ reg = <1>;
+ connection-type = "ext";
+ label = "SMA2";
+ supported-frequencies-hz = /bits/ 64 <10000 10000000>;
+ ref-sync-sources = <&sync0>;
};
};
@@ -90,11 +98,19 @@ examples:
#address-cells = <1>;
#size-cells = <0>;
- pin@0 { /* REF0P */
+ sync1: pin@0 { /* REF0P - 1 PPS sync source */
reg = <0>;
- connection-type = "ext";
- label = "Input 0";
- supported-frequencies-hz = /bits/ 64 <1 1000>;
+ connection-type = "gnss";
+ label = "GNSS_1PPS_IN";
+ supported-frequencies-hz = /bits/ 64 <1>;
+ };
+
+ pin@1 { /* REF0N - clock source */
+ reg = <1>;
+ connection-type = "gnss";
+ label = "GNSS_10M_IN";
+ supported-frequencies-hz = /bits/ 64 <10000000>;
+ ref-sync-sources = <&sync1>;
};
};
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 3/5] dpll: zl3073x: add ref sync and output clock type helpers
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260408102716.443099-1-ivecera@redhat.com>
Add ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR and ZL_REF_SYNC_CTRL_PAIR
register definitions.
Add inline helpers to get and set the sync control mode and sync pair
fields of the reference sync control register:
zl3073x_ref_sync_mode_get/set() - ZL_REF_SYNC_CTRL_MODE field
zl3073x_ref_sync_pair_get/set() - ZL_REF_SYNC_CTRL_PAIR field
Add inline helpers to get and set the clock type field of the output
mode register:
zl3073x_out_clock_type_get/set() - ZL_OUTPUT_MODE_CLOCK_TYPE field
Convert existing esync callbacks to use the new helpers.
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 24 ++++++++-----------
drivers/dpll/zl3073x/out.h | 22 ++++++++++++++++++
drivers/dpll/zl3073x/ref.h | 46 +++++++++++++++++++++++++++++++++++++
drivers/dpll/zl3073x/regs.h | 2 ++
4 files changed, 80 insertions(+), 14 deletions(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index 445f4bccb9aab..dc649cf103cb4 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -139,7 +139,7 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
+ switch (zl3073x_ref_sync_mode_get(ref)) {
case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
esync->pulse = 25;
@@ -175,8 +175,7 @@ zl3073x_dpll_input_pin_esync_set(const struct dpll_pin *dpll_pin,
else
sync_mode = ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75;
- ref.sync_ctrl &= ~ZL_REF_SYNC_CTRL_MODE;
- ref.sync_ctrl |= FIELD_PREP(ZL_REF_SYNC_CTRL_MODE, sync_mode);
+ zl3073x_ref_sync_mode_set(&ref, sync_mode);
if (freq) {
/* 1 Hz is only supported frequency now */
@@ -595,7 +594,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
const struct zl3073x_synth *synth;
const struct zl3073x_out *out;
u32 synth_freq, out_freq;
- u8 clock_type, out_id;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = zl3073x_out_state_get(zldev, out_id);
@@ -618,8 +617,7 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->range = esync_freq_ranges;
esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
- if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
+ if (zl3073x_out_clock_type_get(out) != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
/* No need to read esync data if it is not enabled */
esync->freq = 0;
esync->pulse = 0;
@@ -652,8 +650,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
struct zl3073x_out out;
- u8 clock_type, out_id;
u32 synth_freq;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = *zl3073x_out_state_get(zldev, out_id);
@@ -665,15 +663,13 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
if (zl3073x_out_is_ndiv(&out))
return -EOPNOTSUPP;
- /* Select clock type */
+ /* Update clock type in output mode */
if (freq)
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC;
+ zl3073x_out_clock_type_set(&out,
+ ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC);
else
- clock_type = ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL;
-
- /* Update clock type in output mode */
- out.mode &= ~ZL_OUTPUT_MODE_CLOCK_TYPE;
- out.mode |= FIELD_PREP(ZL_OUTPUT_MODE_CLOCK_TYPE, clock_type);
+ zl3073x_out_clock_type_set(&out,
+ ZL_OUTPUT_MODE_CLOCK_TYPE_NORMAL);
/* If esync is being disabled just write mailbox and finish */
if (!freq)
diff --git a/drivers/dpll/zl3073x/out.h b/drivers/dpll/zl3073x/out.h
index edf40432bba5f..660889c57bffa 100644
--- a/drivers/dpll/zl3073x/out.h
+++ b/drivers/dpll/zl3073x/out.h
@@ -42,6 +42,28 @@ const struct zl3073x_out *zl3073x_out_state_get(struct zl3073x_dev *zldev,
int zl3073x_out_state_set(struct zl3073x_dev *zldev, u8 index,
const struct zl3073x_out *out);
+/**
+ * zl3073x_out_clock_type_get - get output clock type
+ * @out: pointer to out state
+ *
+ * Return: clock type of given output (ZL_OUTPUT_MODE_CLOCK_TYPE_*)
+ */
+static inline u8 zl3073x_out_clock_type_get(const struct zl3073x_out *out)
+{
+ return FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
+}
+
+/**
+ * zl3073x_out_clock_type_set - set output clock type
+ * @out: pointer to out state
+ * @type: clock type (ZL_OUTPUT_MODE_CLOCK_TYPE_*)
+ */
+static inline void
+zl3073x_out_clock_type_set(struct zl3073x_out *out, u8 type)
+{
+ FIELD_MODIFY(ZL_OUTPUT_MODE_CLOCK_TYPE, &out->mode, type);
+}
+
/**
* zl3073x_out_signal_format_get - get output signal format
* @out: pointer to out state
diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
index be16be20dbc7e..55e80e4f08734 100644
--- a/drivers/dpll/zl3073x/ref.h
+++ b/drivers/dpll/zl3073x/ref.h
@@ -120,6 +120,52 @@ zl3073x_ref_freq_set(struct zl3073x_ref *ref, u32 freq)
return 0;
}
+/**
+ * zl3073x_ref_sync_mode_get - get sync control mode
+ * @ref: pointer to ref state
+ *
+ * Return: sync control mode (ZL_REF_SYNC_CTRL_MODE_*)
+ */
+static inline u8
+zl3073x_ref_sync_mode_get(const struct zl3073x_ref *ref)
+{
+ return FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl);
+}
+
+/**
+ * zl3073x_ref_sync_mode_set - set sync control mode
+ * @ref: pointer to ref state
+ * @mode: sync control mode (ZL_REF_SYNC_CTRL_MODE_*)
+ */
+static inline void
+zl3073x_ref_sync_mode_set(struct zl3073x_ref *ref, u8 mode)
+{
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_MODE, &ref->sync_ctrl, mode);
+}
+
+/**
+ * zl3073x_ref_sync_pair_get - get sync pair reference index
+ * @ref: pointer to ref state
+ *
+ * Return: paired reference index
+ */
+static inline u8
+zl3073x_ref_sync_pair_get(const struct zl3073x_ref *ref)
+{
+ return FIELD_GET(ZL_REF_SYNC_CTRL_PAIR, ref->sync_ctrl);
+}
+
+/**
+ * zl3073x_ref_sync_pair_set - set sync pair reference index
+ * @ref: pointer to ref state
+ * @pair: paired reference index
+ */
+static inline void
+zl3073x_ref_sync_pair_set(struct zl3073x_ref *ref, u8 pair)
+{
+ FIELD_MODIFY(ZL_REF_SYNC_CTRL_PAIR, &ref->sync_ctrl, pair);
+}
+
/**
* zl3073x_ref_is_diff - check if the given input reference is differential
* @ref: pointer to ref state
diff --git a/drivers/dpll/zl3073x/regs.h b/drivers/dpll/zl3073x/regs.h
index 5ae50cb761a97..d425dc67250fe 100644
--- a/drivers/dpll/zl3073x/regs.h
+++ b/drivers/dpll/zl3073x/regs.h
@@ -213,7 +213,9 @@
#define ZL_REG_REF_SYNC_CTRL ZL_REG(10, 0x2e, 1)
#define ZL_REF_SYNC_CTRL_MODE GENMASK(2, 0)
#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR_OFF 0
+#define ZL_REF_SYNC_CTRL_MODE_REFSYNC_PAIR 1
#define ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75 2
+#define ZL_REF_SYNC_CTRL_PAIR GENMASK(7, 4)
#define ZL_REG_REF_ESYNC_DIV ZL_REG(10, 0x30, 4)
#define ZL_REF_ESYNC_DIV_1HZ 0
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260408102716.443099-1-ivecera@redhat.com>
Replace open-coded clear-and-set bitfield operations with
FIELD_MODIFY().
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.h | 17 ++++++-----------
drivers/dpll/zl3073x/core.c | 3 +--
drivers/dpll/zl3073x/flash.c | 3 +--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
index e0f02d3432086..481da2133202b 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -66,8 +66,7 @@ static inline u8 zl3073x_chan_ref_get(const struct zl3073x_chan *chan)
*/
static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
{
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_MODE;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_MODE, mode);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_MODE, &chan->mode_refsel, mode);
}
/**
@@ -77,8 +76,7 @@ static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
*/
static inline void zl3073x_chan_ref_set(struct zl3073x_chan *chan, u8 ref)
{
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_REF;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_REF, ref);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_REF, &chan->mode_refsel, ref);
}
/**
@@ -110,13 +108,10 @@ zl3073x_chan_ref_prio_set(struct zl3073x_chan *chan, u8 ref, u8 prio)
{
u8 *val = &chan->ref_prio[ref / 2];
- if (!(ref & 1)) {
- *val &= ~ZL_DPLL_REF_PRIO_REF_P;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_P, prio);
- } else {
- *val &= ~ZL_DPLL_REF_PRIO_REF_N;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_N, prio);
- }
+ if (!(ref & 1))
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_P, val, prio);
+ else
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_N, val, prio);
}
/**
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index cb47a5db061aa..5f1e70f3e40a0 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -805,8 +805,7 @@ int zl3073x_dev_phase_avg_factor_set(struct zl3073x_dev *zldev, u8 factor)
value = (factor + 1) & 0x0f;
/* Update phase measurement control register */
- dpll_meas_ctrl &= ~ZL_DPLL_MEAS_CTRL_AVG_FACTOR;
- dpll_meas_ctrl |= FIELD_PREP(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, value);
+ FIELD_MODIFY(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, &dpll_meas_ctrl, value);
rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, dpll_meas_ctrl);
if (rc)
return rc;
diff --git a/drivers/dpll/zl3073x/flash.c b/drivers/dpll/zl3073x/flash.c
index 83452a77e3e98..f85535c8ad246 100644
--- a/drivers/dpll/zl3073x/flash.c
+++ b/drivers/dpll/zl3073x/flash.c
@@ -194,8 +194,7 @@ zl3073x_flash_cmd_wait(struct zl3073x_dev *zldev, u32 operation,
if (rc)
return rc;
- value &= ~ZL_WRITE_FLASH_OP;
- value |= FIELD_PREP(ZL_WRITE_FLASH_OP, operation);
+ FIELD_MODIFY(ZL_WRITE_FLASH_OP, &value, operation);
rc = zl3073x_write_u8(zldev, ZL_REG_WRITE_FLASH, value);
if (rc)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 1/5] dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260408102716.443099-1-ivecera@redhat.com>
Return -EOPNOTSUPP early in esync_get callbacks when esync is not
supported instead of conditionally populating the range at the end.
This simplifies the control flow by removing the finish label/goto
in the output variant and the conditional range assignment in both
input and output variants.
Replace open-coded N-div signal format switch statements with
zl3073x_out_is_ndiv() helper in esync_get, esync_set and
frequency_set callbacks.
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 64 ++++++++++++-------------------------
1 file changed, 20 insertions(+), 44 deletions(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index d788ca45a17e5..445f4bccb9aab 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -133,6 +133,12 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
ref_id = zl3073x_input_pin_ref_get(pin->id);
ref = zl3073x_ref_state_get(zldev, ref_id);
+ if (!pin->esync_control || zl3073x_ref_freq_get(ref) <= 1)
+ return -EOPNOTSUPP;
+
+ esync->range = esync_freq_ranges;
+ esync->range_num = ARRAY_SIZE(esync_freq_ranges);
+
switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
@@ -144,17 +150,6 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
break;
}
- /* If the pin supports esync control expose its range but only
- * if the current reference frequency is > 1 Hz.
- */
- if (pin->esync_control && zl3073x_ref_freq_get(ref) > 1) {
- esync->range = esync_freq_ranges;
- esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- } else {
- esync->range = NULL;
- esync->range_num = 0;
- }
-
return 0;
}
@@ -599,8 +594,8 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
const struct zl3073x_out *out;
+ u32 synth_freq, out_freq;
u8 clock_type, out_id;
- u32 synth_freq;
out_id = zl3073x_output_pin_out_get(pin->id);
out = zl3073x_out_state_get(zldev, out_id);
@@ -609,17 +604,19 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
* for N-division is also used for the esync divider so both cannot
* be used.
*/
- switch (zl3073x_out_signal_format_get(out)) {
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
+ if (zl3073x_out_is_ndiv(out))
return -EOPNOTSUPP;
- default:
- break;
- }
/* Get attached synth frequency */
synth = zl3073x_synth_state_get(zldev, zl3073x_out_synth_get(out));
synth_freq = zl3073x_synth_freq_get(synth);
+ out_freq = synth_freq / out->div;
+
+ if (!pin->esync_control || out_freq <= 1)
+ return -EOPNOTSUPP;
+
+ esync->range = esync_freq_ranges;
+ esync->range_num = ARRAY_SIZE(esync_freq_ranges);
clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
@@ -627,11 +624,11 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->freq = 0;
esync->pulse = 0;
- goto finish;
+ return 0;
}
/* Compute esync frequency */
- esync->freq = synth_freq / out->div / out->esync_n_period;
+ esync->freq = out_freq / out->esync_n_period;
/* By comparing the esync_pulse_width to the half of the pulse width
* the esync pulse percentage can be determined.
@@ -640,18 +637,6 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
*/
esync->pulse = (50 * out->esync_n_width) / out->div;
-finish:
- /* Set supported esync ranges if the pin supports esync control and
- * if the output frequency is > 1 Hz.
- */
- if (pin->esync_control && (synth_freq / out->div) > 1) {
- esync->range = esync_freq_ranges;
- esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- } else {
- esync->range = NULL;
- esync->range_num = 0;
- }
-
return 0;
}
@@ -677,13 +662,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
* for N-division is also used for the esync divider so both cannot
* be used.
*/
- switch (zl3073x_out_signal_format_get(&out)) {
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
+ if (zl3073x_out_is_ndiv(&out))
return -EOPNOTSUPP;
- default:
- break;
- }
/* Select clock type */
if (freq)
@@ -745,9 +725,9 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
struct zl3073x_dev *zldev = zldpll->dev;
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
- u8 out_id, signal_format;
u32 new_div, synth_freq;
struct zl3073x_out out;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = *zl3073x_out_state_get(zldev, out_id);
@@ -757,12 +737,8 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
synth_freq = zl3073x_synth_freq_get(synth);
new_div = synth_freq / (u32)frequency;
- /* Get used signal format for the given output */
- signal_format = zl3073x_out_signal_format_get(&out);
-
/* Check signal format */
- if (signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV &&
- signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV) {
+ if (!zl3073x_out_is_ndiv(&out)) {
/* For non N-divided signal formats the frequency is computed
* as division of synth frequency and output divisor.
*/
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v3 0/5] dpll: zl3073x: add ref-sync pair support
From: Ivan Vecera @ 2026-04-08 10:27 UTC (permalink / raw)
To: netdev
Cc: Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt, Petr Oros,
Prathosh Satish, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
This series adds Reference-Sync pair support to the ZL3073x DPLL driver.
A Ref-Sync pair consists of a clock reference and a low-frequency sync
signal (e.g. 1 PPS) where the DPLL locks to the clock reference but
phase-aligns to the sync reference.
Patches 1-3 are preparatory cleanups and helper additions:
- Clean up esync get/set callbacks with early returns and use the
zl3073x_out_is_ndiv() helper
- Convert open-coded clear-and-set bitfield patterns to FIELD_MODIFY()
- Add ref sync control and output clock type accessor helpers
Patch 4 adds the 'ref-sync-sources' phandle-array property to the
dpll-pin device tree binding schema and updates the ZL3073x binding
examples.
Patch 5 implements the driver support:
- ref_sync_get/set callbacks with frequency validation
- Automatic sync source exclusion from reference selection
- Device tree based ref-sync pair registration
Tested and verified on Microchip EDS2 (pcb8385) development board.
Changes:
v3 - fix ref-sync-sources schema: add items/maxItems constraint for
phandle list without arg cells (Rob Herring)
v2 - added proper reviewed-by tags (requested by Kuba)
Ivan Vecera (5):
dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
dpll: zl3073x: add ref sync and output clock type helpers
dt-bindings: dpll: add ref-sync-sources property
dpll: zl3073x: add ref-sync pair support
.../devicetree/bindings/dpll/dpll-pin.yaml | 13 +
.../bindings/dpll/microchip,zl30731.yaml | 30 +-
drivers/dpll/zl3073x/chan.h | 17 +-
drivers/dpll/zl3073x/core.c | 3 +-
drivers/dpll/zl3073x/dpll.c | 295 ++++++++++++++----
drivers/dpll/zl3073x/flash.c | 3 +-
drivers/dpll/zl3073x/out.h | 22 ++
drivers/dpll/zl3073x/ref.h | 46 +++
drivers/dpll/zl3073x/regs.h | 2 +
9 files changed, 350 insertions(+), 81 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [RFC PATCH v4 00/19] Support socket access-control
From: Mickaël Salaün @ 2026-04-08 10:26 UTC (permalink / raw)
To: Mikhail Ivanov
Cc: gnoack, willemdebruijn.kernel, matthieu, linux-security-module,
netdev, netfilter-devel, yusongping, artem.kuzin,
konstantin.meskhidze
In-Reply-To: <20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com>
Hi Mikhail,
On Tue, Nov 18, 2025 at 09:46:20PM +0800, Mikhail Ivanov wrote:
> Hello! This is v4 RFC patch dedicated to socket protocols restriction.
>
> It is based on the landlock's mic-next branch on top of Linux 6.16-rc2
> kernel version.
>
> Objective
> =========
> Extend Landlock with a mechanism to restrict any set of protocols in
> a sandboxed process.
>
> Closes: https://github.com/landlock-lsm/linux/issues/6
>
> Motivation
> ==========
> Landlock implements the `LANDLOCK_RULE_NET_PORT` rule type, which provides
> fine-grained control of actions for a specific protocol. Any action or
> protocol that is not supported by this rule can not be controlled. As a
> result, protocols for which fine-grained control is not supported can be
> used in a sandboxed system and lead to vulnerabilities or unexpected
> behavior.
>
> Controlling the protocols used will allow to use only those that are
> necessary for the system and/or which have fine-grained Landlock control
> through others types of rules (e.g. TCP bind/connect control with
> `LANDLOCK_RULE_NET_PORT`, UNIX bind control with
> `LANDLOCK_RULE_PATH_BENEATH`).
>
> Consider following examples:
> * Server may want to use only TCP sockets for which there is fine-grained
> control of bind(2) and connect(2) actions [1].
> * System that does not need a network or that may want to disable network
> for security reasons (e.g. [2]) can achieve this by restricting the use
> of all possible protocols.
>
> [1] https://lore.kernel.org/all/ZJvy2SViorgc+cZI@google.com/
> [2] https://cr.yp.to/unix/disablenetwork.html
>
> Implementation
> ==============
> This patchset adds control over the protocols used by implementing a
> restriction of socket creation. This is possible thanks to the new type
> of rule - `LANDLOCK_RULE_SOCKET`, that allows to restrict actions on
> sockets, and a new access right - `LANDLOCK_ACCESS_SOCKET_CREATE`, that
> corresponds to user space sockets creation. The key in this rule
> corresponds to communication protocol signature from socket(2) syscall.
FYI, I sent a new patch series that adds a handled_perm field to
rulesets:
https://lore.kernel.org/all/20260312100444.2609563-6-mic@digikod.net/
See also the rationale:
https://lore.kernel.org/all/20260312100444.2609563-12-mic@digikod.net/
I think that would work well with the socket creation permission. WDYT?
Do you think you'll be able to continue this work or would you like me
or Günther to complete the remaining last bits (while of course keeping
you as the main author)?
>
> The right to create a socket is checked in the LSM hook which is called
> in the __sock_create method. The following user space operations are
> subject to this check: socket(2), socketpair(2), io_uring(7).
>
> `LANDLOCK_ACCESS_SOCKET_CREATE` does not restrict socket creation
> performed by accept(2), because created socket is used for messaging
> between already existing endpoints.
>
> Design discussion
> ===================
> 1. Should `SCTP_SOCKOPT_PEELOFF` and socketpair(2) be restricted?
>
> SCTP socket can be connected to a multiple endpoints (one-to-many
> relation). Calling setsockopt(2) on such socket with option
> `SCTP_SOCKOPT_PEELOFF` detaches one of existing connections to a separate
> UDP socket. This detach is currently restrictable.
>
> Same applies for the socketpair(2) syscall. It was noted that denying
> usage of socketpair(2) in sandboxed environment may be not meaninful [1].
>
> Currently both operations use general socket interface to create sockets.
> Therefore it's not possible to distinguish between socket(2) and those
> operations inside security_socket_create LSM hook which is currently
> used for protocols restriction. Providing such separation may require
> changes in socket layer (eg. in __sock_create) interface which may not be
> acceptable.
>
> [1] https://lore.kernel.org/all/ZurZ7nuRRl0Zf2iM@google.com/
>
> Code coverage
> =============
> Code coverage(gcov) report with the launch of all the landlock selftests:
> * security/landlock:
> lines......: 94.0% (1200 of 1276 lines)
> functions..: 95.0% (134 of 141 functions)
>
> * security/landlock/socket.c:
> lines......: 100.0% (56 of 56 lines)
> functions..: 100.0% (5 of 5 functions)
>
> Currently landlock-test-tools fails on mini.kernel_socket test due to lack
> of SMC protocol support.
>
> General changes v3->v4
> ======================
> * Implementation
> * Adds protocol field to landlock_socket_attr.
> * Adds protocol masks support via wildcards values in
> landlock_socket_attr.
> * Changes LSM hook used from socket_post_create to socket_create.
> * Changes protocol ranges acceptable by socket rules.
> * Adds audit support.
> * Changes ABI version to 8.
> * Tests
> * Adds 5 new tests:
> * mini.rule_with_wildcard, protocol_wildcard.access,
> mini.ruleset_with_wildcards_overlap:
> verify rulesets containing rules with wildcard values.
> * tcp_protocol.alias_restriction: verify that Landlock doesn't
> perform protocol mappings.
> * audit.socket_create: tests audit denial logging.
> * Squashes tests corresponding to Landlock rule adding to a single commit.
> * Documentation
> * Refactors Documentation/userspace-api/landlock.rst.
> * Commits
> * Rebases on mic-next.
> * Refactors commits.
>
> Previous versions
> =================
> v3: https://lore.kernel.org/all/20240904104824.1844082-1-ivanov.mikhail1@huawei-partners.com/
> v2: https://lore.kernel.org/all/20240524093015.2402952-1-ivanov.mikhail1@huawei-partners.com/
> v1: https://lore.kernel.org/all/20240408093927.1759381-1-ivanov.mikhail1@huawei-partners.com/
>
> Mikhail Ivanov (19):
> landlock: Support socket access-control
> selftests/landlock: Test creating a ruleset with unknown access
> selftests/landlock: Test adding a socket rule
> selftests/landlock: Testing adding rule with wildcard value
> selftests/landlock: Test acceptable ranges of socket rule key
> landlock: Add hook on socket creation
> selftests/landlock: Test basic socket restriction
> selftests/landlock: Test network stack error code consistency
> selftests/landlock: Test overlapped rulesets with rules of protocol
> ranges
> selftests/landlock: Test that kernel space sockets are not restricted
> selftests/landlock: Test protocol mappings
> selftests/landlock: Test socketpair(2) restriction
> selftests/landlock: Test SCTP peeloff restriction
> selftests/landlock: Test that accept(2) is not restricted
> lsm: Support logging socket common data
> landlock: Log socket creation denials
> selftests/landlock: Test socket creation denial log for audit
> samples/landlock: Support socket protocol restrictions
> landlock: Document socket rule type support
>
> Documentation/userspace-api/landlock.rst | 48 +-
> include/linux/lsm_audit.h | 8 +
> include/uapi/linux/landlock.h | 60 +-
> samples/landlock/sandboxer.c | 118 +-
> security/landlock/Makefile | 2 +-
> security/landlock/access.h | 3 +
> security/landlock/audit.c | 12 +
> security/landlock/audit.h | 1 +
> security/landlock/limits.h | 4 +
> security/landlock/ruleset.c | 37 +-
> security/landlock/ruleset.h | 46 +-
> security/landlock/setup.c | 2 +
> security/landlock/socket.c | 198 +++
> security/landlock/socket.h | 20 +
> security/landlock/syscalls.c | 61 +-
> security/lsm_audit.c | 4 +
> tools/testing/selftests/landlock/base_test.c | 2 +-
> tools/testing/selftests/landlock/common.h | 14 +
> tools/testing/selftests/landlock/config | 47 +
> tools/testing/selftests/landlock/net_test.c | 11 -
> .../selftests/landlock/protocols_define.h | 169 +++
> .../testing/selftests/landlock/socket_test.c | 1169 +++++++++++++++++
> 22 files changed, 1990 insertions(+), 46 deletions(-)
> create mode 100644 security/landlock/socket.c
> create mode 100644 security/landlock/socket.h
> create mode 100644 tools/testing/selftests/landlock/protocols_define.h
> create mode 100644 tools/testing/selftests/landlock/socket_test.c
>
>
> base-commit: 6dde339a3df80a57ac3d780d8cfc14d9262e2acd
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH net v6 4/4] macsec: Support VLAN-filtering lower devices
From: Cosmin Ratiu @ 2026-04-08 10:24 UTC (permalink / raw)
To: sd@queasysnail.net
Cc: andrew+netdev@lunn.ch, davem@davemloft.net,
linux-kselftest@vger.kernel.org, Dragos Tatulea, sdf@fomichev.me,
shuah@kernel.org, kuba@kernel.org, pabeni@redhat.com,
horms@kernel.org, edumazet@google.com, netdev@vger.kernel.org
In-Reply-To: <adYQ3OMfEEWFTd7X@krikkit>
On Wed, 2026-04-08 at 10:25 +0200, Sabrina Dubroca wrote:
> 2026-04-07, 15:07:47 +0000, Cosmin Ratiu wrote:
> > On Thu, 2026-04-02 at 16:48 +0200, Sabrina Dubroca wrote:
> > > If this happens on a real device, the VLAN filters will be
> > > broken.
> > > I'm
> > > not sure what the right behavior would be:
> > >
> > > 1. reject the request to enable offload
> > > 2. switch to promiscuous mode
> >
> > I implemented and tested option 1. In the unlikely scenario adding
> > VLAN
> > filters prevents offloading
>
> How unlikely is it? Resource allocation, talking to HW, device
> limits,
> anything else that could fail?
>
> > , it's better for the driver to be explicit
> > and let the user turn on promisc mode themselves. Keeping track of
> > whether VLAN filters failed and promisc was used as a fallback adds
> > some extra complexity.
>
> If it's indeed (very) unlikely, sure. There's still a bit of a
> regression/change of behavior for users compared to before the
> IFF_UNICAST_FLT patch, but I think we can wait until someone
> complains, and then add the tracking if that happens.
>
> > What would be the point of IFF_UNICAST_FLT then?
>
> The point is that this would just be a fallback.
>
> > Please let me know if you agree with this approach, so I can send
> > v8
> > with it.
>
> If you can confirm it's on the "very unlikely" side, yes, this
> approach sounds ok. Thanks.
There are many, many drivers which implement .ndo_vlan_rx_add_vid, I
can't really browse them all and determine overall likelihood of
failure. But presumably there are some memory allocations involved and
some FW communication to add the new filter.
An AI prompt of "Explore implementations of .ndo_vlan_rx_add_vid in
drivers and classify potential failure sources and their likelihood of
failure." resulted in (edited for compactness):
"""
Analyzed 24+ implementations across major drivers. Here's the
breakdown:
Category Likelihood Drivers Typical Error
HW/FW cmds Low mlx4, nfp, hinic, qeth, vmxnet3 Device-specific
Mem alloc Very Low bnx2x, qede, virtio_net -ENOMEM
Filter add Low-Medium mlx5, mlx4, ice, qede, ocelot -ENOSPC, -EEXIST
Locking Very Low be2net, mlx4, nfp, hinic -EBUSY
Res limit Medium qede (quota check) Promisc fallback
Three Driver Archetypes
1. Simple bitfield drivers (never fail): e1000, e1000e, ixgbe, igb —
just set a VFTA bit in hardware registers, always return 0.
2. Complex offload drivers (can fail): mlx5 (flow steering rules), mlx4
(FW VLAN registration), ice (switch rules + promisc management), qede
(quota-aware with promisc fallback), nfp (mailbox commands), hinic (FW
commands with rollback).
3. Delegation/passthrough drivers (inherit failures): bonding, team,
hsr, dsa, macvlan, ipvlan, macsec — propagate vlan_vid_add() to lower
devices with unwind-on-failure patterns.
"""
So I guess we go with option 1 for now.
>
> > > OTOH maybe we don't need to care, since __netdev_update_features
> > > also
> > > (kind of) ignores those errors:
> > >
> [...]
> >
> > Well, in this case we have the chance to do something nicer (even
> > proper error message back to the user via extack) for a small
>
> (That reminds me I have a branch of "macsec: add extack to X" patches
> I still need to polish and submit. I don't think I'll get to it
> before
> the merge window opens, I'll rebase on top of your changes.)
>
> > complexity cost. Perhaps the VLAN filter handling could be improved
> > separately.
>
> I'm not sure if this would be an "improvement to VLAN filter
> handling"
> or a "(breaking) change of user-visible behavior". Probably
> improvement. Or maybe it's "unlikely enough" that nobody has ever
> cared.
>
^ permalink raw reply
* [PATCH net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
From: Lorenzo Bianconi @ 2026-04-08 10:20 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Xuegang Lu,
Lorenzo Bianconi
airoha_fe_set routine is used to set specified bits to 1 in the selected
register. In the FE_PSE_BUF_SET case this can due to a overestimation of
the required buffers for I/O queues since we can miss to set some bits
of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw
routine instead.
Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()")
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 91cb63a32d99..c365d693cf40 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -293,16 +293,18 @@ static void airoha_fe_pse_ports_init(struct airoha_eth *eth)
[FE_PSE_PORT_GDM4] = 2,
[FE_PSE_PORT_CDM5] = 2,
};
- u32 all_rsv;
int q;
- all_rsv = airoha_fe_get_pse_all_rsv(eth);
if (airoha_ppe_is_enabled(eth, 1)) {
+ u32 all_rsv;
+
/* hw misses PPE2 oq rsv */
+ all_rsv = airoha_fe_get_pse_all_rsv(eth);
all_rsv += PSE_RSV_PAGES *
pse_port_num_queues[FE_PSE_PORT_PPE2];
+ airoha_fe_rmw(eth, REG_FE_PSE_BUF_SET, PSE_ALLRSV_MASK,
+ FIELD_PREP(PSE_ALLRSV_MASK, all_rsv));
}
- airoha_fe_set(eth, REG_FE_PSE_BUF_SET, all_rsv);
/* CMD1 */
for (q = 0; q < pse_port_num_queues[FE_PSE_PORT_CDM1]; q++)
---
base-commit: f821664dde29302e8450aa0597bf1e4c7c5b0a22
change-id: 20260408-airoha-reg_fe_pse_buf_set-39a75edb52ca
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH net v2 3/3] vsock/test: add MSG_PEEK after partial recv test
From: Stefano Garzarella @ 2026-04-08 10:18 UTC (permalink / raw)
To: Luigi Leonardi
Cc: Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Arseniy Krasnov, kvm, virtualization,
netdev, linux-kernel
In-Reply-To: <20260407-fix_peek-v2-3-2e2581dc8b7c@redhat.com>
On Tue, Apr 07, 2026 at 11:13:57AM +0200, Luigi Leonardi wrote:
>Add a test that verifies MSG_PEEK works correctly after a partial
>recv().
>
>This is to test a bug that was present in the
>`virtio_transport_stream_do_peek()` when computing the number of bytes to
>copy: After a partial read, the peek function didn't take into
>consideration the number of bytes that were already read. So peeking the
>whole buffer would cause a out-of-bounds read, that resulted in a -EFAULT.
>
>This test does exactly this: do a partial recv on a buffer, then try to
>peek the whole buffer content.
>
>Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>---
> tools/testing/vsock/vsock_test.c | 43 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
>diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
>index bdb0754965df..d38a90a86f34 100644
>--- a/tools/testing/vsock/vsock_test.c
>+++ b/tools/testing/vsock/vsock_test.c
>@@ -346,6 +346,44 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
> return test_msg_peek_server(opts, false);
> }
>
>+static void test_stream_peek_after_recv_client(const struct test_opts *opts)
>+{
>+ unsigned char buf[MSG_PEEK_BUF_LEN];
What about:
unsigned char buf[MSG_PEEK_BUF_LEN] = { 0 };
so we can remove the memset() call?
>+ int fd;
>+
>+ fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
>+ if (fd < 0) {
>+ perror("connect");
>+ exit(EXIT_FAILURE);
>+ }
>+
>+ memset(buf, 0, sizeof(buf));
>+
>+ send_buf(fd, buf, sizeof(buf), 0, sizeof(buf));
>+
>+ close(fd);
>+}
>+
>+static void test_stream_peek_after_recv_server(const struct test_opts *opts)
>+{
>+ unsigned char buf[MSG_PEEK_BUF_LEN];
>+ int fd;
>+
>+ fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
>+ if (fd < 0) {
>+ perror("accept");
>+ exit(EXIT_FAILURE);
>+ }
>+
>+ /* Partial recv to advance offset within the skb */
>+ recv_buf(fd, buf, 1, 0, 1);
>+
>+ /* Ask more bytes than available */
>+ recv_buf(fd, buf, sizeof(buf), MSG_PEEK, sizeof(buf) - 1);
What about checking also what we read like we do in
test_msg_peek_server() ?
Not a strong opinion, but if we go in that direction, maybe we can just
reuse test_stream_msg_peek_client() also for this test case.
Thanks,
Stefano
>+
>+ close(fd);
>+}
>+
> #define SOCK_BUF_SIZE (2 * 1024 * 1024)
> #define SOCK_BUF_SIZE_SMALL (64 * 1024)
> #define MAX_MSG_PAGES 4
>@@ -2509,6 +2547,11 @@ static struct test_case test_cases[] = {
> .run_client = test_stream_tx_credit_bounds_client,
> .run_server = test_stream_tx_credit_bounds_server,
> },
>+ {
>+ .name = "SOCK_STREAM MSG_PEEK after partial recv",
>+ .run_client = test_stream_peek_after_recv_client,
>+ .run_server = test_stream_peek_after_recv_server,
>+ },
> {},
> };
>
>
>--
>2.53.0
>
^ permalink raw reply
* Re: [PATCH net-next 0/4] net: mana: Fix probe/remove error path bugs
From: Erni Sri Satya Vennela @ 2026-04-08 10:17 UTC (permalink / raw)
To: Mohsin Bashir
Cc: kys, haiyangz, wei.liu, decui, longli, andrew+netdev, davem,
edumazet, kuba, pabeni, ssengar, dipayanroy, gargaditya,
shirazsaleem, kees, kotaranov, leon, shacharr, stephen,
linux-hyperv, netdev, linux-kernel
In-Reply-To: <62c3fcc1-6758-47c4-984e-f6940139de0c@gmail.com>
On Fri, Apr 03, 2026 at 11:28:34PM -0700, Mohsin Bashir wrote:
>
>
> On 4/3/26 12:09 AM, Erni Sri Satya Vennela wrote:
> > Fix four pre-existing bugs in mana_probe()/mana_remove() error handling
> > that can cause warnings on uninitialized work structs, masked errors,
> > and resource leaks when early probe steps fail.
> >
> > Patches 1-2 move work struct initialization (link_change_work and
> > gf_stats_work) to before any error path that could trigger
> > mana_remove(), preventing WARN_ON in __flush_work() or debug object
> > warnings when sync cancellation runs on uninitialized work structs.
> >
> > Patch 3 prevents add_adev() from overwriting a port probe error,
> > which could leave the driver in a broken state with NULL ports while
> > reporting success.
> >
> > Patch 4 changes 'goto out' to 'break' in mana_remove()'s port loop
> > so that mana_destroy_eq() is always reached, preventing EQ leaks when
> > a NULL port is encountered.
> >
> > Erni Sri Satya Vennela (4):
> > net: mana: Init link_change_work before potential error paths in probe
> > net: mana: Init gf_stats_work before potential error paths in probe
> > net: mana: Don't overwrite port probe error with add_adev result
> > net: mana: Fix EQ leak in mana_remove on NULL port
> >
> > drivers/net/ethernet/microsoft/mana/mana_en.c | 28 +++++++++----------
> > 1 file changed, 14 insertions(+), 14 deletions(-)
> >
> I believe mana is already in the mainline so fixes go to the net tree?
Thanks for the correction Mohsin.
I'll make this chaneg in the next version.
- Vennela
^ permalink raw reply
* Re: [PATCH] ppp: require CAP_NET_ADMIN in target netns for unattached ioctls
From: Matteo Croce @ 2026-04-08 10:04 UTC (permalink / raw)
To: Qingfang Deng
Cc: Taegu Ha, netdev, linux-ppp, gnault, jaco, richardbgobert,
ericwouds, Cyrill Gorcunov
In-Reply-To: <59d11588-0af2-42e6-a030-83240a0a5512@linux.dev>
On Wed, Apr 8, 2026 at 8:28 AM Qingfang Deng <qingfang.deng@linux.dev> wrote:
>
> >
> Hi,
>
> Added Cc: Cyrill, and Matteo
>
> On 2026/4/8 12:23, Taegu Ha wrote:
> > /dev/ppp open is currently authorized against file->f_cred->user_ns,
> > while unattached administrative ioctls operate on current->nsproxy->net_ns.
> >
> > As a result, a local unprivileged user can create a new user namespace
> > with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace,
> > and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against
> > an inherited network namespace.
> >
> > Require CAP_NET_ADMIN in the user namespace that owns the target network
> > namespace before handling these unattached PPP administrative ioctls.
> >
> > This preserves normal pppd operation in the network namespace it is
> > actually privileged in, while rejecting the userns-only inherited-netns
> > case.
> >
> > Fixes: 273ec51dd7ce ("net: ppp_generic - introduce net-namespace functionality v2")
>
> For fixes, you should set the target tree to "net" in the patch subject,
> using:
>
LGTM as long as it's still possible to start a pppd from within a user
an network namespace.
Regards,
--
Matteo Croce
^ permalink raw reply
* Re: [PATCH net v2 2/3] vsock/test: handle MSG_PEEK in `recv_buf`
From: Stefano Garzarella @ 2026-04-08 10:03 UTC (permalink / raw)
To: Luigi Leonardi
Cc: Stefan Hajnoczi, Michael S. Tsirkin, Jason Wang, Xuan Zhuo,
Eugenio Pérez, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Arseniy Krasnov, kvm, virtualization,
netdev, linux-kernel
In-Reply-To: <20260407-fix_peek-v2-2-2e2581dc8b7c@redhat.com>
On Tue, Apr 07, 2026 at 11:13:56AM +0200, Luigi Leonardi wrote:
>`recv_buf` does not handle the MSG_PEEK flag correctly: it keeps calling
>`recv` until all requested bytes are available or an error occurs.
>
>The problem is how it calculates the amount of bytes read: MSG_PEEK
>doesn't consume any bytes, will re-read the same bytes from the buffer
>head, so, summing the return value every time is wrong.
>
>Moreover, MSG_PEEK doesn't consume the bytes in the buffer, so if the
>requested amount is more than the bytes available, the loop will never
>terminate, because `recv` will never return EOF. For this reason we need
>to compare the amount of read bytes with the number of bytes expected.
>
>Add a check, and if the MSG_PEEK flag is present, update the counter of
>read bytes differently, and break if we read the expected amount.
>
>This allows us to simplify the `test_stream_credit_update_test`, by
>reusing `recv_buf`.
>
>Suggested-by: Stefano Garzarella <sgarzare@redhat.com>
>Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
>---
> tools/testing/vsock/util.c | 8 ++++++++
> tools/testing/vsock/vsock_test.c | 13 +------------
> 2 files changed, 9 insertions(+), 12 deletions(-)
>
>diff --git a/tools/testing/vsock/util.c b/tools/testing/vsock/util.c
>index 9430ef5b8bc3..f12425ca99ed 100644
>--- a/tools/testing/vsock/util.c
>+++ b/tools/testing/vsock/util.c
>@@ -399,6 +399,14 @@ void recv_buf(int fd, void *buf, size_t len, int flags, ssize_t expected_ret)
> if (ret == 0 || (ret < 0 && errno != EINTR))
> break;
>
We should add a comment here or even better in the documentation on top
of the function to explain better this behaviour for future reference.
>+ if (flags & MSG_PEEK) {
>+ if (ret == expected_ret) {
>+ nread = ret;
>+ break;
>+ }
Not that I expect this to happen often, but I wonder if it would be
better to add a `timeout_usleep()` here to avoid using up too many CPU
cycles.
>+ continue;
>+ }
>+
> nread += ret;
> } while (nread < len);
> timeout_end();
>diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
>index 5bd20ccd9335..bdb0754965df 100644
>--- a/tools/testing/vsock/vsock_test.c
>+++ b/tools/testing/vsock/vsock_test.c
>@@ -1500,18 +1500,7 @@ static void test_stream_credit_update_test(const struct test_opts *opts,
> }
>
> /* Wait until there will be 128KB of data in rx queue. */
>- while (1) {
>- ssize_t res;
>-
>- res = recv(fd, buf, buf_size, MSG_PEEK);
>- if (res == buf_size)
>- break;
>-
>- if (res <= 0) {
>- fprintf(stderr, "unexpected 'recv()' return: %zi\n", res);
>- exit(EXIT_FAILURE);
>- }
>- }
>+ recv_buf(fd, buf, buf_size, MSG_PEEK, buf_size);
Not sure about this change in this patch, but since they are just tests
it could be fine.
mmm, on a second thought, we already used recv_buf() with MSG_PEEK in
several other tests, so yep, better to add this change, but I'd make
more clear in the commit title/description that this is at the end a fix
for other tests using MSG_PEEK with recv_buf(), I mean something like
this:
vsock/test: fix MSG_PEEK handling in recv_buf()
And also pointing out that other tests already used MSG_PEEK with
recv_buf(), but it can be broken in some cases.
Thanks,
Stefano
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox