* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-03-31 13:29 UTC (permalink / raw)
To: Keith Busch
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <acvFV8c5QVxnt3Em@kbusch-mbp>
On Tue, Mar 31, 2026 at 07:00:07AM -0600, Keith Busch wrote:
> On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote:
> > On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> > >
> > > You're suggesting that Ziping append the new fields to the end of this
> > > struct? I don't think we can modify the layout of a uapi.
> >
> > He needs to add before flex array. This struct is submitted by the user
> > and kernel can easily calculate the position of that array.
>
> No, you can't just do that. Existing applications would break when they
> compile against the updated kernel header. They don't know about this
> new "tph" supplied flag, but they'll all accidently use the new
> dma_ranges offset.
So we need to always pass TPH flag and treat 0 as do-nothing-field.
Thanks
^ permalink raw reply
* Re: [PATCH v9 net-next 3/5] psp: add a new netdev event for dev unregister
From: Daniel Zahka @ 2026-03-31 13:30 UTC (permalink / raw)
To: Wei Wang, netdev, Jakub Kicinski, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman
Cc: Wei Wang
In-Reply-To: <20260330223143.2394706-4-weibunny.kernel@gmail.com>
On 3/30/26 6:31 PM, Wei Wang wrote:
> +static bool psp_notifier_registered;
> +
> +/**
> + * psp_attach_netdev_notifier() - register netdev notifier on first use
> + *
> + * Register the netdevice notifier when the first device association
> + * is created. In many installations no associations will be created and
> + * the notifier won't be needed.
> + *
> + * Must be called without psd->lock held, due to lock ordering:
> + * rtnl_lock -> psd->lock (the notifier callback runs under rtnl_lock
> + * and takes psd->lock).
> + */
> +void psp_attach_netdev_notifier(void)
> +{
> + if (READ_ONCE(psp_notifier_registered))
> + return;
> +
> + mutex_lock(&psp_devs_lock);
> + if (!psp_notifier_registered) {
> + if (!register_netdevice_notifier(&psp_netdev_notifier))
> + WRITE_ONCE(psp_notifier_registered, true);
> + }
> + mutex_unlock(&psp_devs_lock);
> +}
...
>
> +int psp_device_get_locked_dev_assoc(const struct genl_split_ops *ops,
> + struct sk_buff *skb, struct genl_info *info)
> +{
> + psp_attach_netdev_notifier();
> +
> + return __psp_device_get_locked(ops, skb, info, false);
> +}
From an AI review, but seems plausible to me:
psp_device_get_locked_dev_assoc() will proceed even in the path where
register_netdevice_notifier() and psp_notifier_registered stays false.
^ permalink raw reply
* RE: [EXTERNAL] Re: [PATCH net,v5] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN
From: Srujana Challa @ 2026-03-31 13:29 UTC (permalink / raw)
To: Paolo Abeni, netdev@vger.kernel.org,
virtualization@lists.linux.dev
Cc: mst@redhat.com, jasowang@redhat.com, xuanzhuo@linux.alibaba.com,
eperezma@redhat.com, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, Nithin Kumar Dabilpuram, Shiva Shankar Kommula,
stable@vger.kernel.org
In-Reply-To: <ba027306-e5e0-4d4d-8357-f6080441167d@redhat.com>
> On 3/26/26 3:23 PM, Srujana Challa wrote:
> > rss_max_key_size in the virtio spec is the maximum key size supported
> > by the device, not a mandatory size the driver must use. Also the
> > value 40 is a spec minimum, not a spec maximum.
> >
> > The current code rejects RSS and can fail probe when the device
> > reports a larger rss_max_key_size than the driver buffer limit.
> > Instead, clamp the effective key length to min(device
> > rss_max_key_size, NETDEV_RSS_KEY_LEN) and keep RSS enabled.
> >
> > This keeps probe working on devices that advertise larger maximum key
> > sizes while respecting the netdev RSS key buffer size limit.
> >
> > Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Srujana Challa <schalla@marvell.com>
> > ---
> > v3:
> > - Moved RSS key validation checks to virtnet_validate.
> > - Add fixes: tag and CC -stable
> > v4:
> > - Use NETDEV_RSS_KEY_LEN instead of type_max for the maximum rss key
> size.
> > v5:
> > - Interpret rss_max_key_size as a maximum and clamp it to
> NETDEV_RSS_KEY_LEN.
> > - Do not disable RSS/HASH_REPORT when device rss_max_key_size exceeds
> NETDEV_RSS_KEY_LEN.
> > - Drop the separate patch that replaced the runtime check with
> BUILD_BUG_ON.
> >
> > drivers/net/virtio_net.c | 20 +++++++++-----------
> > 1 file changed, 9 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index
> > 022f60728721..b241c8dbb4e1 100644
> > --- a/drivers/net/virtio_net.c
> > +++ b/drivers/net/virtio_net.c
> > @@ -373,8 +373,6 @@ struct receive_queue {
> > struct xdp_buff **xsk_buffs;
> > };
> >
> > -#define VIRTIO_NET_RSS_MAX_KEY_SIZE 40
> > -
> > /* Control VQ buffers: protected by the rtnl lock */ struct
> > control_buf {
> > struct virtio_net_ctrl_hdr hdr;
> > @@ -478,7 +476,7 @@ struct virtnet_info {
> >
> > /* Must be last as it ends in a flexible-array member. */
> > TRAILING_OVERLAP(struct virtio_net_rss_config_trailer, rss_trailer,
> hash_key_data,
> > - u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
> > + u8 rss_hash_key_data[NETDEV_RSS_KEY_LEN];
> > );
> > };
> > static_assert(offsetof(struct virtnet_info,
> > rss_trailer.hash_key_data) == @@ -6717,6 +6715,7 @@ static int
> virtnet_probe(struct virtio_device *vdev)
> > struct virtnet_info *vi;
> > u16 max_queue_pairs;
> > int mtu = 0;
> > + u16 key_sz;
> >
> > /* Find if host supports multiqueue/rss virtio_net device */
> > max_queue_pairs = 1;
> > @@ -6851,14 +6850,13 @@ static int virtnet_probe(struct virtio_device
> *vdev)
> > }
> >
> > if (vi->has_rss || vi->has_rss_hash_report) {
> > - vi->rss_key_size =
> > - virtio_cread8(vdev, offsetof(struct virtio_net_config,
> rss_max_key_size));
> > - if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
> > - dev_err(&vdev->dev, "rss_max_key_size=%u exceeds
> the limit %u.\n",
> > - vi->rss_key_size,
> VIRTIO_NET_RSS_MAX_KEY_SIZE);
> > - err = -EINVAL;
> > - goto free;
> > - }
> > + key_sz = virtio_cread8(vdev, offsetof(struct virtio_net_config,
> > +rss_max_key_size));
> > +
> > + vi->rss_key_size = min_t(u16, key_sz, NETDEV_RSS_KEY_LEN);
> > + if (key_sz > vi->rss_key_size)
> > + dev_warn(&vdev->dev,
> > + "rss_max_key_size=%u exceeds driver limit
> %u, clamping\n",
> > + key_sz, vi->rss_key_size);
>
> NETDEV_RSS_KEY_LEN is 256 and virtio_cread8() returns a u8. The check is
> not needed, and the warning will never be printed. I think that the
> BUILD_BUG_ON() you used in v4 would be better than the above chunk.
>
Thank you for the feedback. In net-next, NETDEV_RSS_KEY_LEN is 256. This fix is
also intended for stable kernels, where NETDEV_RSS_KEY_LEN is 52, and
I added the message to make clamping visible in that case.
I will remove the check and send the next version.
> /P
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Keith Busch @ 2026-03-31 13:35 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <20260331132942.GC814676@unreal>
On Tue, Mar 31, 2026 at 04:29:42PM +0300, Leon Romanovsky wrote:
> On Tue, Mar 31, 2026 at 07:00:07AM -0600, Keith Busch wrote:
> > On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote:
> > > On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> > > >
> > > > You're suggesting that Ziping append the new fields to the end of this
> > > > struct? I don't think we can modify the layout of a uapi.
> > >
> > > He needs to add before flex array. This struct is submitted by the user
> > > and kernel can easily calculate the position of that array.
> >
> > No, you can't just do that. Existing applications would break when they
> > compile against the updated kernel header. They don't know about this
> > new "tph" supplied flag, but they'll all accidently use the new
> > dma_ranges offset.
>
> So we need to always pass TPH flag and treat 0 as do-nothing-field.
I don't think you're understanding the implications. If Zhiping appends
new fields in front of the flex array dma_ranges, then existing
applications will implicitly use the new offset if they are recompiled
against the new kernel header. But if the binary was compiled against
the older kernel header, then that application would use the previous
offset. Both applications have the TPH flag cleared to 0. How is the
kernel supposed to know which offset the application used?
^ permalink raw reply
* Re: [PATCH net-next v2] net: phy: realtek: support MDI swapping for RTL8226-CG
From: Russell King (Oracle) @ 2026-03-31 13:38 UTC (permalink / raw)
To: Jan Hoffmann
Cc: Andrew Lunn, Heiner Kallweit, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Daniel Golle, Markus Stockhausen,
Damien Dejean, netdev, linux-kernel
In-Reply-To: <20260327202001.413280-1-jan@3e8.eu>
On Fri, Mar 27, 2026 at 08:32:28PM +0100, Jan Hoffmann wrote:
> +static int rtl8226_config_init(struct phy_device *phydev)
> +{
> + int ret;
> +
> + ret = rtl8226_config_mdi_order(phydev);
> + if (ret)
> + return ret;
As I've been pointing out in other patches, putting this "defaulting"
here is not a good idea - this path gets called when the PHY is attached
to the netdev and also when the PHY is being resumed - which will wipe
out the user's configuration just because their system suspended.
I don't think that gives the user a good experience.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] dpll: zl3073x: implement frequency monitoring
From: Petr Oros @ 2026-03-31 13:38 UTC (permalink / raw)
To: Ivan Vecera, netdev
Cc: Vadim Fedorenko, Arkadiusz Kubalewski, Jiri Pirko,
Jonathan Corbet, Shuah Khan, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Donald Hunter,
Prathosh Satish, linux-doc, linux-kernel
In-Reply-To: <20260330105505.715099-4-ivecera@redhat.com>
> Extract common measurement latch logic from zl3073x_ref_ffo_update()
> into a new zl3073x_ref_freq_meas_latch() helper and add
> zl3073x_ref_freq_meas_update() that uses it to latch and read absolute
> input reference frequencies in Hz.
>
> Add meas_freq field to struct zl3073x_ref and the corresponding
> zl3073x_ref_meas_freq_get() accessor. The measured frequencies are
> updated periodically alongside the existing FFO measurements.
>
> Add freq_monitor boolean to struct zl3073x_dpll and implement the
> freq_monitor_set/get device callbacks to enable/disable frequency
> monitoring via the DPLL netlink interface.
>
> Implement measured_freq_get pin callback for input pins that returns the
> measured input frequency in Hz.
>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/dpll/zl3073x/core.c | 88 +++++++++++++++++++++++++++++++------
> drivers/dpll/zl3073x/dpll.c | 88 ++++++++++++++++++++++++++++++++++++-
> drivers/dpll/zl3073x/dpll.h | 2 +
> drivers/dpll/zl3073x/ref.h | 14 ++++++
> 4 files changed, 178 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
> index 6363002d48d46..320c199637efa 100644
> --- a/drivers/dpll/zl3073x/core.c
> +++ b/drivers/dpll/zl3073x/core.c
> @@ -632,22 +632,21 @@ int zl3073x_ref_phase_offsets_update(struct zl3073x_dev *zldev, int channel)
> }
>
> /**
> - * zl3073x_ref_ffo_update - update reference fractional frequency offsets
> + * zl3073x_ref_freq_meas_latch - latch reference frequency measurements
> * @zldev: pointer to zl3073x_dev structure
> + * @type: measurement type (ZL_REF_FREQ_MEAS_CTRL_*)
> *
> - * The function asks device to update fractional frequency offsets latch
> - * registers the latest measured values, reads and stores them into
> + * The function waits for the previous measurement to finish, selects all
> + * references and requests a new measurement of the given type.
> *
> * Return: 0 on success, <0 on error
> */
> static int
> -zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
> +zl3073x_ref_freq_meas_latch(struct zl3073x_dev *zldev, u8 type)
> {
> - int i, rc;
> + int rc;
>
> - /* Per datasheet we have to wait for 'ref_freq_meas_ctrl' to be zero
> - * to ensure that the measured data are coherent.
> - */
> + /* Wait for previous measurement to finish */
> rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
> ZL_REF_FREQ_MEAS_CTRL);
> if (rc)
> @@ -663,15 +662,64 @@ zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
> if (rc)
> return rc;
>
> - /* Request frequency offset measurement */
> - rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
> - ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
> + /* Request measurement */
> + rc = zl3073x_write_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL, type);
> if (rc)
> return rc;
>
> /* Wait for finish */
> - rc = zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
> - ZL_REF_FREQ_MEAS_CTRL);
> + return zl3073x_poll_zero_u8(zldev, ZL_REG_REF_FREQ_MEAS_CTRL,
> + ZL_REF_FREQ_MEAS_CTRL);
> +}
> +
> +/**
> + * zl3073x_ref_freq_meas_update - update measured input reference frequencies
> + * @zldev: pointer to zl3073x_dev structure
> + *
> + * The function asks device to latch measured input reference frequencies
> + * and stores the results in the ref state.
> + *
> + * Return: 0 on success, <0 on error
> + */
> +static int
> +zl3073x_ref_freq_meas_update(struct zl3073x_dev *zldev)
> +{
> + int i, rc;
> +
> + rc = zl3073x_ref_freq_meas_latch(zldev, ZL_REF_FREQ_MEAS_CTRL_REF_FREQ);
> + if (rc)
> + return rc;
> +
> + /* Read measured frequencies in Hz (unsigned 32-bit, LSB = 1 Hz) */
> + for (i = 0; i < ZL3073X_NUM_REFS; i++) {
> + u32 value;
> +
> + rc = zl3073x_read_u32(zldev, ZL_REG_REF_FREQ(i), &value);
> + if (rc)
> + return rc;
> +
> + zldev->ref[i].meas_freq = value;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * zl3073x_ref_ffo_update - update reference fractional frequency offsets
> + * @zldev: pointer to zl3073x_dev structure
> + *
> + * The function asks device to update fractional frequency offsets latch
> + * registers the latest measured values, reads and stores them into
> + *
> + * Return: 0 on success, <0 on error
> + */
> +static int
> +zl3073x_ref_ffo_update(struct zl3073x_dev *zldev)
> +{
> + int i, rc;
> +
> + rc = zl3073x_ref_freq_meas_latch(zldev,
> + ZL_REF_FREQ_MEAS_CTRL_REF_FREQ_OFF);
> if (rc)
> return rc;
>
> @@ -714,6 +762,20 @@ zl3073x_dev_periodic_work(struct kthread_work *work)
> dev_warn(zldev->dev, "Failed to update phase offsets: %pe\n",
> ERR_PTR(rc));
>
> + /* Update measured input reference frequencies if any DPLL has
> + * frequency monitoring enabled.
> + */
> + list_for_each_entry(zldpll, &zldev->dplls, list) {
> + if (zldpll->freq_monitor) {
> + rc = zl3073x_ref_freq_meas_update(zldev);
> + if (rc)
> + dev_warn(zldev->dev,
> + "Failed to update measured frequencies: %pe\n",
> + ERR_PTR(rc));
> + break;
> + }
> + }
> +
> /* Update references' fractional frequency offsets */
> rc = zl3073x_ref_ffo_update(zldev);
> if (rc)
> diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
> index a29f606318f6d..c44bfecf2c265 100644
> --- a/drivers/dpll/zl3073x/dpll.c
> +++ b/drivers/dpll/zl3073x/dpll.c
> @@ -39,6 +39,7 @@
> * @pin_state: last saved pin state
> * @phase_offset: last saved pin phase offset
> * @freq_offset: last saved fractional frequency offset
> + * @measured_freq: last saved measured frequency
> */
> struct zl3073x_dpll_pin {
> struct list_head list;
> @@ -54,6 +55,7 @@ struct zl3073x_dpll_pin {
> enum dpll_pin_state pin_state;
> s64 phase_offset;
> s64 freq_offset;
> + u32 measured_freq;
> };
>
> /*
> @@ -202,6 +204,20 @@ zl3073x_dpll_input_pin_ffo_get(const struct dpll_pin *dpll_pin, void *pin_priv,
> return 0;
> }
>
> +static int
> +zl3073x_dpll_input_pin_measured_freq_get(const struct dpll_pin *dpll_pin,
> + void *pin_priv,
> + const struct dpll_device *dpll,
> + void *dpll_priv, u64 *measured_freq,
> + struct netlink_ext_ack *extack)
> +{
> + struct zl3073x_dpll_pin *pin = pin_priv;
> +
> + *measured_freq = pin->measured_freq;
> +
> + return 0;
> +}
> +
> static int
> zl3073x_dpll_input_pin_frequency_get(const struct dpll_pin *dpll_pin,
> void *pin_priv,
> @@ -1116,6 +1132,35 @@ zl3073x_dpll_phase_offset_monitor_set(const struct dpll_device *dpll,
> return 0;
> }
>
> +static int
> +zl3073x_dpll_freq_monitor_get(const struct dpll_device *dpll,
> + void *dpll_priv,
> + enum dpll_feature_state *state,
> + struct netlink_ext_ack *extack)
> +{
> + struct zl3073x_dpll *zldpll = dpll_priv;
> +
> + if (zldpll->freq_monitor)
> + *state = DPLL_FEATURE_STATE_ENABLE;
> + else
> + *state = DPLL_FEATURE_STATE_DISABLE;
> +
> + return 0;
> +}
> +
> +static int
> +zl3073x_dpll_freq_monitor_set(const struct dpll_device *dpll,
> + void *dpll_priv,
> + enum dpll_feature_state state,
> + struct netlink_ext_ack *extack)
> +{
> + struct zl3073x_dpll *zldpll = dpll_priv;
> +
> + zldpll->freq_monitor = (state == DPLL_FEATURE_STATE_ENABLE);
> +
> + return 0;
> +}
> +
> static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
> .direction_get = zl3073x_dpll_pin_direction_get,
> .esync_get = zl3073x_dpll_input_pin_esync_get,
> @@ -1123,6 +1168,7 @@ static const struct dpll_pin_ops zl3073x_dpll_input_pin_ops = {
> .ffo_get = zl3073x_dpll_input_pin_ffo_get,
> .frequency_get = zl3073x_dpll_input_pin_frequency_get,
> .frequency_set = zl3073x_dpll_input_pin_frequency_set,
> + .measured_freq_get = zl3073x_dpll_input_pin_measured_freq_get,
> .phase_offset_get = zl3073x_dpll_input_pin_phase_offset_get,
> .phase_adjust_get = zl3073x_dpll_input_pin_phase_adjust_get,
> .phase_adjust_set = zl3073x_dpll_input_pin_phase_adjust_set,
> @@ -1151,6 +1197,8 @@ static const struct dpll_device_ops zl3073x_dpll_device_ops = {
> .phase_offset_avg_factor_set = zl3073x_dpll_phase_offset_avg_factor_set,
> .phase_offset_monitor_get = zl3073x_dpll_phase_offset_monitor_get,
> .phase_offset_monitor_set = zl3073x_dpll_phase_offset_monitor_set,
> + .freq_monitor_get = zl3073x_dpll_freq_monitor_get,
> + .freq_monitor_set = zl3073x_dpll_freq_monitor_set,
> .supported_modes_get = zl3073x_dpll_supported_modes_get,
> };
>
> @@ -1593,6 +1641,39 @@ zl3073x_dpll_pin_ffo_check(struct zl3073x_dpll_pin *pin)
> return false;
> }
>
> +/**
> + * zl3073x_dpll_pin_measured_freq_check - check for pin measured frequency change
> + * @pin: pin to check
> + *
> + * Check for the given pin's measured frequency change.
> + *
> + * Return: true on measured frequency change, false otherwise
> + */
> +static bool
> +zl3073x_dpll_pin_measured_freq_check(struct zl3073x_dpll_pin *pin)
> +{
> + struct zl3073x_dpll *zldpll = pin->dpll;
> + struct zl3073x_dev *zldev = zldpll->dev;
> + const struct zl3073x_ref *ref;
> + u8 ref_id;
> +
> + if (!zldpll->freq_monitor)
> + return false;
> +
> + ref_id = zl3073x_input_pin_ref_get(pin->id);
> + ref = zl3073x_ref_state_get(zldev, ref_id);
> +
> + if (pin->measured_freq != ref->meas_freq) {
> + dev_dbg(zldev->dev, "%s measured freq changed: %u -> %u\n",
> + pin->label, pin->measured_freq, ref->meas_freq);
> + pin->measured_freq = ref->meas_freq;
> +
> + return true;
> + }
> +
> + return false;
> +}
> +
> /**
> * zl3073x_dpll_changes_check - check for changes and send notifications
> * @zldpll: pointer to zl3073x_dpll structure
> @@ -1677,13 +1758,18 @@ zl3073x_dpll_changes_check(struct zl3073x_dpll *zldpll)
> pin_changed = true;
> }
>
> - /* Check for phase offset and ffo change once per second */
> + /* Check for phase offset, ffo, and measured freq change
> + * once per second.
> + */
> if (zldpll->check_count % 2 == 0) {
> if (zl3073x_dpll_pin_phase_offset_check(pin))
> pin_changed = true;
>
> if (zl3073x_dpll_pin_ffo_check(pin))
> pin_changed = true;
> +
> + if (zl3073x_dpll_pin_measured_freq_check(pin))
> + pin_changed = true;
> }
>
> if (pin_changed)
> diff --git a/drivers/dpll/zl3073x/dpll.h b/drivers/dpll/zl3073x/dpll.h
> index 115ee4f67e7ab..434c32a7db123 100644
> --- a/drivers/dpll/zl3073x/dpll.h
> +++ b/drivers/dpll/zl3073x/dpll.h
> @@ -15,6 +15,7 @@
> * @id: DPLL index
> * @check_count: periodic check counter
> * @phase_monitor: is phase offset monitor enabled
> + * @freq_monitor: is frequency monitor enabled
> * @ops: DPLL device operations for this instance
> * @dpll_dev: pointer to registered DPLL device
> * @tracker: tracking object for the acquired reference
> @@ -28,6 +29,7 @@ struct zl3073x_dpll {
> u8 id;
> u8 check_count;
> bool phase_monitor;
> + bool freq_monitor;
> struct dpll_device_ops ops;
> struct dpll_device *dpll_dev;
> dpll_tracker tracker;
> diff --git a/drivers/dpll/zl3073x/ref.h b/drivers/dpll/zl3073x/ref.h
> index 06d8d4d97ea26..be16be20dbc7e 100644
> --- a/drivers/dpll/zl3073x/ref.h
> +++ b/drivers/dpll/zl3073x/ref.h
> @@ -23,6 +23,7 @@ struct zl3073x_dev;
> * @sync_ctrl: reference sync control
> * @config: reference config
> * @ffo: current fractional frequency offset
> + * @meas_freq: measured input frequency in Hz
> * @mon_status: reference monitor status
> */
> struct zl3073x_ref {
> @@ -40,6 +41,7 @@ struct zl3073x_ref {
> );
> struct_group(stat, /* Status */
> s64 ffo;
> + u32 meas_freq;
> u8 mon_status;
> );
> };
> @@ -68,6 +70,18 @@ zl3073x_ref_ffo_get(const struct zl3073x_ref *ref)
> return ref->ffo;
> }
>
> +/**
> + * zl3073x_ref_meas_freq_get - get measured input frequency
> + * @ref: pointer to ref state
> + *
> + * Return: measured input frequency in Hz
> + */
> +static inline u32
> +zl3073x_ref_meas_freq_get(const struct zl3073x_ref *ref)
> +{
> + return ref->meas_freq;
> +}
> +
> /**
> * zl3073x_ref_freq_get - get given input reference frequency
> * @ref: pointer to ref state
LGTM
Reviewed-by: Petr Oros <poros@redhat.com>
^ permalink raw reply
* Re: [PATCH net] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Eric Dumazet @ 2026-03-31 13:38 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, horms, pabeni, kuba, davem, dsahern, Yiming Qian
In-Reply-To: <9aaf6dc6-3c21-4cec-9f16-5d76cb40dc80@suse.de>
On Tue, Mar 31, 2026 at 5:50 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> On 3/31/26 2:13 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:00 AM Fernando Fernandez Mancera
> > <fmancera@suse.de> wrote:
> >>
> >> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> >> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> >> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> >> allocation fails for large nexthop groups like 512+ nexthops.
> >>
> >> This results in the following warning splat:
> >>
> >> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#19: rep/9282
> >> [...]
> >> RIP: 0010:rtm_get_nexthop+0x176/0x1c0
> >> [...]
> >> Call Trace:
> >> <TASK>
> >> rtnetlink_rcv_msg+0x168/0x670
> >> netlink_rcv_skb+0x5c/0x110
> >> netlink_unicast+0x203/0x2e0
> >> netlink_sendmsg+0x222/0x460
> >> ____sys_sendmsg+0x35a/0x380
> >> ___sys_sendmsg+0x99/0xe0
> >> __sys_sendmsg+0x8a/0xf0
> >> do_syscall_64+0x12f/0x1590
> >> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >> </TASK>
> >
> > I find these stack traces without symbols not very useful.
>
> Hi Eric,
>
> sure, here is the decoded trace:
>
> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0,
> CPU#20: rep/4608
> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395 (discriminator 2))
> Call Trace:
> <TASK>
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> netlink_unicast (net/netlink/af_netlink.c:1319
> net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> ____sys_sendmsg (net/socket.c:721 (discriminator 16) net/socket.c:736
> (discriminator 16) net/socket.c:2585 (discriminator 16))
> ___sys_sendmsg (net/socket.c:2641)
> __sys_sendmsg (net/socket.c:2671 (discriminator 1))
> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1)
> arch/x86/entry/syscall_64.c:94 (discriminator 1))
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> >
> > Any reason you have not used scripts/decode_stacktrace.sh ?
> >
>
> Not really, in the past I checked other commits with `git log --grep
> "Call Trace"` and found out that most of the traces did not have symbols
> so I decided to attach the raw trace.
>
> I do not really have a personal preference here. If trace with symbols
> is preferred I will do it like that in the future. I could also send a
> V2 of this patch if needed.
Please send a V2 (after the ~24 hours delay) as we prefer this
whenever possible.
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Charles Perry @ 2026-03-31 13:42 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Charles Perry, netdev, Maxime Chevallier, Andrew Lunn,
Heiner Kallweit, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel
In-Reply-To: <acvEpk1grDFAahzd@shell.armlinux.org.uk>
On Tue, Mar 31, 2026 at 01:57:10PM +0100, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 05:38:54AM -0700, Charles Perry wrote:
> > + if (!(bus->phy_ignore_ta_mask & 1 << mii_id) &&
> > + !FIELD_GET(MDIO_READOK_BIT, val)) {
> > + dev_dbg(&bus->dev, "READOK bit cleared\n");
> > + return -EIO;
> > + }
> > +
> > + ret = FIELD_GET(MDIO_RDATA_MASK, val);
> > +
> > + return ret;
>
> You don't need "ret" here, this can simply be:
>
> return FIELD_GET(MDIO_RDATA_MASK, val);
Ok
>
> ...
>
> > + writel(MDIO_TRIGGER_BIT | FIELD_PREP(MDIO_REG_DEV_ADDR_MASK, regnum) |
> > + FIELD_PREP(MDIO_PHY_PRT_ADDR_MASK, mii_id) |
> > + FIELD_PREP(MDIO_OPERATION_MASK, MDIO_OPERATION_WRITE) |
> > + FIELD_PREP(MDIO_START_OF_FRAME_MASK, 1),
> > + priv->regs + MDIO_REG_FRAME_CFG_2);
>
> Shouldn't this wait for the write to complete?
>
As it is, the write transaction has NOT finished when the function returns,
because there's no call to pic64hpsc_mdio_wait_trigger().
It works because there's a pic64hpsc_mdio_wait_trigger() at the beginning
of ->read() and ->write(), so the completion will be waited for on the next
read or write. I've taken this from mdio-mscc-miim.c.
I don't know if there's any value in waiting for write completion here as
write completion doesn't mean that the effects of the write are available
right now. I also didn't run into any issues in my testing. Let me know if
you know of a use case where this wouldn't work.
I can add a wait for transaction completion if that's expected by phylib.
Thanks,
Charles
> Thanks.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH] netfilter: nf_conntrack_helper: pass helper to expect cleanup
From: Phil Sutter @ 2026-03-31 13:40 UTC (permalink / raw)
To: Qi Tang
Cc: Pablo Neira Ayuso, Florian Westphal, netfilter-devel, coreteam,
netdev
In-Reply-To: <20260329165036.240932-1-tpluszz77@gmail.com>
On Mon, Mar 30, 2026 at 12:50:36AM +0800, Qi Tang wrote:
> nf_conntrack_helper_unregister() calls nf_ct_expect_iterate_destroy()
> to remove expectations belonging to the helper being unregistered.
> However, it passes NULL instead of the helper pointer as the data
> argument, so expect_iter_me() never matches any expectation and all
> of them survive the cleanup.
>
> After unregister returns, nfnl_cthelper_del() frees the helper
> object immediately. Subsequent expectation dumps or packet-driven
> init_conntrack() calls then dereference the freed exp->helper,
> causing a use-after-free.
>
> Pass the actual helper pointer so expectations referencing it are
> properly destroyed before the helper object is freed.
>
> BUG: KASAN: slab-use-after-free in string+0x38f/0x430
> Read of size 1 at addr ffff888003b14d20 by task poc/103
> Call Trace:
> string+0x38f/0x430
> vsnprintf+0x3cc/0x1170
> seq_printf+0x17a/0x240
> exp_seq_show+0x2e5/0x560
> seq_read_iter+0x419/0x1280
> proc_reg_read+0x1ac/0x270
> vfs_read+0x179/0x930
> ksys_read+0xef/0x1c0
> Freed by task 103:
> The buggy address is located 32 bytes inside of
> freed 192-byte region [ffff888003b14d00, ffff888003b14dc0)
>
> Fixes: ac7b84839003 ("netfilter: expect: add and use nf_ct_expect_iterate helpers")
> Signed-off-by: Qi Tang <tpluszz77@gmail.com>
Reviewed-by: Phil Sutter <phil@nwl.cc>
Thanks, Phil
^ permalink raw reply
* [PATCH iproute2-next] dpll: add direction and state filtering for pin show
From: Petr Oros @ 2026-03-31 13:59 UTC (permalink / raw)
To: netdev; +Cc: dsahern, stephen, ivecera, Petr Oros
Allow filtering pins by direction (input/output) and state
(connected/disconnected/selectable) in the pin show command.
These filters match against parent-device nested attributes and
can be combined with the parent-device filter to check a specific
parent-device relationship.
Example: dpll pin show parent-device 0 direction input state connected
Signed-off-by: Petr Oros <poros@redhat.com>
---
bash-completion/dpll | 11 ++++++-
dpll/dpll.c | 71 ++++++++++++++++++++++++++++++++++++++++++--
man/man8/dpll.8 | 23 +++++++++++++-
3 files changed, 100 insertions(+), 5 deletions(-)
diff --git a/bash-completion/dpll b/bash-completion/dpll
index 5913c894dda96e..981c3edbf367b0 100644
--- a/bash-completion/dpll
+++ b/bash-completion/dpll
@@ -185,10 +185,19 @@ _dpll_pin()
int-oscillator gnss" -- "$cur" ) )
return 0
;;
+ direction)
+ COMPREPLY=( $( compgen -W "input output" -- "$cur" ) )
+ return 0
+ ;;
+ state)
+ COMPREPLY=( $( compgen -W \
+ "connected disconnected selectable" -- "$cur" ) )
+ return 0
+ ;;
*)
COMPREPLY=( $( compgen -W "id parent-device parent-pin \
module-name clock-id board-label panel-label \
- package-label type" \
+ package-label type direction state" \
-- "$cur" ) )
return 0
;;
diff --git a/dpll/dpll.c b/dpll/dpll.c
index 634b8fd1976ffd..0afc2b4213180d 100644
--- a/dpll/dpll.c
+++ b/dpll/dpll.c
@@ -162,6 +162,17 @@ static int str_to_dpll_pin_state(const char *state_str, __u32 *state)
return 0;
}
+static int str_to_dpll_pin_direction(const char *dir_str, __u32 *direction)
+{
+ int num;
+
+ num = str_map_lookup_str(pin_direction_map, dir_str);
+ if (num < 0)
+ return num;
+ *direction = num;
+ return 0;
+}
+
static int str_to_dpll_pin_type(const char *type_str, __u32 *type)
{
int num;
@@ -921,6 +932,8 @@ static bool dpll_device_dump_filter(struct dpll_device_filter *filter,
#define DPLL_FILTER_PIN_TYPE BIT(5)
#define DPLL_FILTER_PIN_PARENT_DEVICE BIT(6)
#define DPLL_FILTER_PIN_PARENT_PIN BIT(7)
+#define DPLL_FILTER_PIN_DIRECTION BIT(8)
+#define DPLL_FILTER_PIN_STATE BIT(9)
struct dpll_pin_filter {
uint64_t present;
@@ -932,6 +945,8 @@ struct dpll_pin_filter {
__u32 type;
__u32 parent_device_id;
__u32 parent_pin_id;
+ __u32 direction;
+ __u32 state;
};
static bool filter_match_nested_id(const struct nlmsghdr *nlh,
@@ -953,6 +968,39 @@ static bool filter_match_nested_id(const struct nlmsghdr *nlh,
return false;
}
+static bool filter_match_nested_parent_device(const struct nlmsghdr *nlh,
+ struct dpll_pin_filter *filter)
+{
+ const struct nlattr *attr;
+
+ mnl_attr_for_each(attr, nlh, sizeof(struct genlmsghdr)) {
+ struct nlattr *tb_nest[DPLL_A_PIN_MAX + 1] = {};
+
+ if (mnl_attr_get_type(attr) != DPLL_A_PIN_PARENT_DEVICE)
+ continue;
+
+ mnl_attr_parse_nested(attr, attr_pin_cb, tb_nest);
+
+ if ((filter->present & DPLL_FILTER_PIN_PARENT_DEVICE) &&
+ !filter_match_u32(tb_nest[DPLL_A_PIN_PARENT_ID],
+ filter->parent_device_id))
+ continue;
+
+ if ((filter->present & DPLL_FILTER_PIN_DIRECTION) &&
+ !filter_match_u32(tb_nest[DPLL_A_PIN_DIRECTION],
+ filter->direction))
+ continue;
+
+ if ((filter->present & DPLL_FILTER_PIN_STATE) &&
+ !filter_match_u32(tb_nest[DPLL_A_PIN_STATE],
+ filter->state))
+ continue;
+
+ return true;
+ }
+ return false;
+}
+
static bool dpll_pin_dump_filter(struct dpll_pin_filter *filter,
const struct nlmsghdr *nlh,
struct nlattr **tb)
@@ -979,9 +1027,10 @@ static bool dpll_pin_dump_filter(struct dpll_pin_filter *filter,
if ((filter->present & DPLL_FILTER_PIN_TYPE) &&
!filter_match_u32(tb[DPLL_A_PIN_TYPE], filter->type))
return false;
- if ((filter->present & DPLL_FILTER_PIN_PARENT_DEVICE) &&
- !filter_match_nested_id(nlh, DPLL_A_PIN_PARENT_DEVICE,
- filter->parent_device_id))
+ if ((filter->present & (DPLL_FILTER_PIN_PARENT_DEVICE |
+ DPLL_FILTER_PIN_DIRECTION |
+ DPLL_FILTER_PIN_STATE)) &&
+ !filter_match_nested_parent_device(nlh, filter))
return false;
if ((filter->present & DPLL_FILTER_PIN_PARENT_PIN) &&
!filter_match_nested_id(nlh, DPLL_A_PIN_PARENT_PIN,
@@ -1892,6 +1941,22 @@ static int cmd_pin_show(struct dpll *dpll)
str_to_dpll_pin_type,
"mux/ext/synce-eth-port/int-oscillator/gnss"))
return -EINVAL;
+ } else if (dpll_argv_match(dpll, "direction")) {
+ if (dpll_filter_parse_enum(dpll, "direction",
+ &filter.direction,
+ &filter.present,
+ DPLL_FILTER_PIN_DIRECTION,
+ str_to_dpll_pin_direction,
+ "input/output"))
+ return -EINVAL;
+ } else if (dpll_argv_match(dpll, "state")) {
+ if (dpll_filter_parse_enum(dpll, "state",
+ &filter.state,
+ &filter.present,
+ DPLL_FILTER_PIN_STATE,
+ str_to_dpll_pin_state,
+ "connected/disconnected/selectable"))
+ return -EINVAL;
} else {
pr_err("unknown option: %s\n", dpll_argv(dpll));
return -EINVAL;
diff --git a/man/man8/dpll.8 b/man/man8/dpll.8
index 479e5ed9871eeb..4213ae7a494fb8 100644
--- a/man/man8/dpll.8
+++ b/man/man8/dpll.8
@@ -169,7 +169,7 @@ Device type:
.SH PIN COMMANDS
-.SS dpll pin show [ id ID ] [ parent-device DEVICE_ID ] [ parent-pin PIN_ID ] [ module-name NAME ] [ clock-id ID ] [ board-label LABEL ] [ panel-label LABEL ] [ package-label LABEL ] [ type TYPE ]
+.SS dpll pin show [ id ID ] [ parent-device DEVICE_ID ] [ parent-pin PIN_ID ] [ module-name NAME ] [ clock-id ID ] [ board-label LABEL ] [ panel-label LABEL ] [ package-label LABEL ] [ type TYPE ] [ direction DIR ] [ state STATE ]
Display information about DPLL pins. If no arguments are specified,
shows all pins in the system.
@@ -211,6 +211,22 @@ Show only pins with the specified package label.
Show only pins of the specified type:
.BR mux ", " ext ", " synce-eth-port ", " int-oscillator ", " gnss .
+.TP
+.BI direction " DIR"
+Show only pins that have a parent-device relationship with the specified direction:
+.BR input ", " output .
+When combined with
+.BR parent-device ,
+only the specified parent-device relationship is checked.
+
+.TP
+.BI state " STATE"
+Show only pins that have a parent-device relationship with the specified state:
+.BR connected ", " disconnected ", " selectable .
+When combined with
+.BR parent-device ,
+only the specified parent-device relationship is checked.
+
.PP
Output includes:
.RS
@@ -401,6 +417,11 @@ Press Ctrl+C to stop monitoring.
.B dpll -jp pin show id 5
.fi
+.SS Show connected input pins on device 0
+.nf
+.B dpll pin show parent-device 0 direction input state connected
+.fi
+
.SS Set pin frequency to 10 MHz
.nf
.B dpll pin set id 0 frequency 10000000
--
2.52.0
^ permalink raw reply related
* Re: [RFC PATCH net-next 0/3] seg6: SRv6 L2 VPN with End.DT2U and srl2 device
From: Nicolas Dichtel @ 2026-03-31 14:00 UTC (permalink / raw)
To: Stefano Salsano, Andrea Mayer, netdev
Cc: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Paolo Lungaroni, Ahmed Abdelsalam,
Justin Iurman, linux-kernel
In-Reply-To: <56dca998-220c-4c29-bf3d-2a94292d6d32@uniroma2.it>
Le 27/03/2026 à 02:09, Stefano Salsano a écrit :
[snip]
>> What is the gain of having two interfaces?
>> In term of scalability, it is interesting to have only one interface.
>
> among our medium-term design goals we have:
>
> 1) achieving the feature parity with vxlan
> 2) being at least isomorphic with vxlan in terms of exposed CLI mechanisms
>
> in this way we can port the existing vxlan based solution for cloud
> infrastructures and container networking to srv6
>
> on top of this, we can design srv6 specific machinery for higher efficiency
>
> therefore, the bridge+sr6 solution has to be supported to achieve feature
> parity/isomorphism with vxlan
>
> on top of this, we also include a solution that does not need the bridge and
> terminates an L2 tunnel directly into a single sr6 interface characterized by a
> mac address (this is for the decap side)
Make sense, thanks for the details.
>
> for the encap side, we are considering per-mac solutions (see our answer to
> Justin) in a way which is aligned with vxlan design for the reasons mentioned above
Ok.
Regards,
Nicolas
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-03-31 14:03 UTC (permalink / raw)
To: Keith Busch
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <acvNsvS5ShlQlrox@kbusch-mbp>
On Tue, Mar 31, 2026 at 07:35:46AM -0600, Keith Busch wrote:
> On Tue, Mar 31, 2026 at 04:29:42PM +0300, Leon Romanovsky wrote:
> > On Tue, Mar 31, 2026 at 07:00:07AM -0600, Keith Busch wrote:
> > > On Tue, Mar 31, 2026 at 11:37:58AM +0300, Leon Romanovsky wrote:
> > > > On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> > > > >
> > > > > You're suggesting that Ziping append the new fields to the end of this
> > > > > struct? I don't think we can modify the layout of a uapi.
> > > >
> > > > He needs to add before flex array. This struct is submitted by the user
> > > > and kernel can easily calculate the position of that array.
> > >
> > > No, you can't just do that. Existing applications would break when they
> > > compile against the updated kernel header. They don't know about this
> > > new "tph" supplied flag, but they'll all accidently use the new
> > > dma_ranges offset.
> >
> > So we need to always pass TPH flag and treat 0 as do-nothing-field.
>
> I don't think you're understanding the implications. If Zhiping appends
> new fields in front of the flex array dma_ranges, then existing
> applications will implicitly use the new offset if they are recompiled
> against the new kernel header. But if the binary was compiled against
> the older kernel header, then that application would use the previous
> offset. Both applications have the TPH flag cleared to 0. How is the
> kernel supposed to know which offset the application used?
I understand, my proposal is always set TPH flag when new struct is
used. Everything will be much easier if we can add fields after flex
array.
Thanks
^ permalink raw reply
* Re: [PATCH net-next v10 06/10] bng_en: add HW stats infra and structured ethtool ops
From: Paolo Abeni @ 2026-03-31 14:03 UTC (permalink / raw)
To: Bhargava Marreddy, davem, edumazet, kuba, andrew+netdev, horms
Cc: netdev, linux-kernel, michael.chan, pavan.chebbi,
vsrama-krishna.nemani, vikas.gupta
In-Reply-To: <20260327201343.16146-7-bhargava.marreddy@broadcom.com>
On 3/27/26 9:13 PM, Bhargava Marreddy wrote:
> @@ -1024,10 +1208,12 @@ static int bnge_alloc_core(struct bnge_net *bn)
> txr->bnapi = bnapi2;
> }
>
> - rc = bnge_alloc_ring_stats(bn);
> + rc = bnge_alloc_stats(bn);
> if (rc)
> goto err_free_core;
Sashico says:
---
Does tying the statistics memory allocation to bnge_alloc_core() cause
accumulated statistics to be lost when the interface is toggled down?
When the interface is brought down, bnge_free_core() calls
bnge_free_port_stats() which frees sw_stats and clears the
BNGE_FLAG_PORT_STATS flag. Any ethtool queries made while the interface
is down will then silently abort and return empty statistics, and all
historical counters will be permanently erased.
Should the software accumulators be allocated once at probe time so they
can persist across link state changes?
---
Please have a look at the full report, it could include other relevant
things.
https://sashiko.dev/#/patchset/20260327201343.16146-1-bhargava.marreddy%40broadcom.com
/P
^ permalink raw reply
* Re: [PATCH v9 net-next 5/5] selftest/net: psp: Add test for dev-assoc/disassoc
From: Daniel Zahka @ 2026-03-31 14:04 UTC (permalink / raw)
To: Wei Wang, netdev, Jakub Kicinski, Willem de Bruijn, David Wei,
Andrew Lunn, David S . Miller, Eric Dumazet, Simon Horman
Cc: Wei Wang
In-Reply-To: <20260330223143.2394706-6-weibunny.kernel@gmail.com>
On 3/30/26 6:31 PM, Wei Wang wrote:
> +
> +def _dev_assoc_no_nsid(cfg):
> + """ Test dev-assoc and dev-disassoc without nsid attribute """
> + _init_psp_dev(cfg, True)
> + psp_dev_id = cfg.psp_dev_id
> +
> + # Get nk_host's ifindex (in host namespace, same as caller)
> + nk_host_dev = ip(f"link show dev {cfg._nk_host_ifname}", json=True)[0]
> + nk_host_ifindex = nk_host_dev['ifindex']
> +
> + # Associate without nsid - should look up ifindex in caller's netns
> + cfg.pspnl.dev_assoc({'id': psp_dev_id, 'ifindex': nk_host_ifindex})
> +
> + # Verify assoc-list contains the device
> + dev_info = cfg.pspnl.dev_get({'id': psp_dev_id})
> + ksft_true('assoc-list' in dev_info, "No assoc-list after association")
> + found = False
> + for assoc in dev_info['assoc-list']:
> + if assoc['ifindex'] == nk_host_ifindex:
> + found = True
> + break
> + ksft_true(found, "Associated device not found in assoc-list")
> +
> + # Disassociate without nsid - should also use caller's netns
> + cfg.pspnl.dev_disassoc({'id': psp_dev_id, 'ifindex': nk_host_ifindex})
> +
> + # Verify assoc-list no longer contains the device
> + dev_info = cfg.pspnl.dev_get({'id': psp_dev_id})
> + found = False
> + if 'assoc-list' in dev_info:
> + for assoc in dev_info['assoc-list']:
> + if assoc['ifindex'] == nk_host_ifindex:
> + found = True
> + break
> + ksft_true(not found, "Device should not be in assoc-list after disassociation")
> +
> + del cfg.psp_dev_id
> + del cfg.psp_info
> +
...
> +
> +@ksft_variants([
> + KsftNamedVariant(f"v{v}_ip6", v, "6")
> + for v in range(4)
> +])
> +def dev_assoc_no_nsid(cfg, version, ipver):
> + cfg.require_ipver(ipver)
> + _dev_assoc_no_nsid(cfg)
> +
Why do we need ip connectivity for this test? Why are you parameterizing
over PSP version?
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Russell King (Oracle) @ 2026-03-31 14:05 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Maxime Chevallier, Andrew Lunn, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <acvPKuuikqvfXauy@bby-cbu-swbuild03.eng.microchip.com>
On Tue, Mar 31, 2026 at 06:42:02AM -0700, Charles Perry wrote:
> I don't know if there's any value in waiting for write completion here as
> write completion doesn't mean that the effects of the write are available
> right now. I also didn't run into any issues in my testing. Let me know if
> you know of a use case where this wouldn't work.
>
> I can add a wait for transaction completion if that's expected by phylib.
Consider a PHY using a shared interrupt line, and the interrupt being
disabled in at the PHY before being torn down... wouldn't we want the
write to the register which enables interrupts to complete before we
unregister the interrupt handler for the particular PHY?
I do notice that other MDIO drivers don't wait. Some PHY drivers don't
access the PHY after the write to disable interrupts either. So, maybe
phy_free_interrupt() should read-back from the PHY before calling
free_irq() to guarantee that the write has completed?
Andrew?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH iproute2-next] dpll: add direction and state filtering for pin show
From: Ivan Vecera @ 2026-03-31 14:07 UTC (permalink / raw)
To: Petr Oros, netdev; +Cc: dsahern, stephen
In-Reply-To: <20260331135918.49567-1-poros@redhat.com>
On 3/31/26 3:59 PM, Petr Oros wrote:
> Allow filtering pins by direction (input/output) and state
> (connected/disconnected/selectable) in the pin show command.
> These filters match against parent-device nested attributes and
> can be combined with the parent-device filter to check a specific
> parent-device relationship.
>
> Example: dpll pin show parent-device 0 direction input state connected
> Signed-off-by: Petr Oros <poros@redhat.com>
> ---
> bash-completion/dpll | 11 ++++++-
> dpll/dpll.c | 71 ++++++++++++++++++++++++++++++++++++++++++--
> man/man8/dpll.8 | 23 +++++++++++++-
> 3 files changed, 100 insertions(+), 5 deletions(-)
>
> diff --git a/bash-completion/dpll b/bash-completion/dpll
> index 5913c894dda96e..981c3edbf367b0 100644
> --- a/bash-completion/dpll
> +++ b/bash-completion/dpll
> @@ -185,10 +185,19 @@ _dpll_pin()
> int-oscillator gnss" -- "$cur" ) )
> return 0
> ;;
> + direction)
> + COMPREPLY=( $( compgen -W "input output" -- "$cur" ) )
> + return 0
> + ;;
> + state)
> + COMPREPLY=( $( compgen -W \
> + "connected disconnected selectable" -- "$cur" ) )
> + return 0
> + ;;
> *)
> COMPREPLY=( $( compgen -W "id parent-device parent-pin \
> module-name clock-id board-label panel-label \
> - package-label type" \
> + package-label type direction state" \
> -- "$cur" ) )
> return 0
> ;;
> diff --git a/dpll/dpll.c b/dpll/dpll.c
> index 634b8fd1976ffd..0afc2b4213180d 100644
> --- a/dpll/dpll.c
> +++ b/dpll/dpll.c
> @@ -162,6 +162,17 @@ static int str_to_dpll_pin_state(const char *state_str, __u32 *state)
> return 0;
> }
>
> +static int str_to_dpll_pin_direction(const char *dir_str, __u32 *direction)
> +{
> + int num;
> +
> + num = str_map_lookup_str(pin_direction_map, dir_str);
> + if (num < 0)
> + return num;
> + *direction = num;
> + return 0;
> +}
> +
> static int str_to_dpll_pin_type(const char *type_str, __u32 *type)
> {
> int num;
> @@ -921,6 +932,8 @@ static bool dpll_device_dump_filter(struct dpll_device_filter *filter,
> #define DPLL_FILTER_PIN_TYPE BIT(5)
> #define DPLL_FILTER_PIN_PARENT_DEVICE BIT(6)
> #define DPLL_FILTER_PIN_PARENT_PIN BIT(7)
> +#define DPLL_FILTER_PIN_DIRECTION BIT(8)
> +#define DPLL_FILTER_PIN_STATE BIT(9)
>
> struct dpll_pin_filter {
> uint64_t present;
> @@ -932,6 +945,8 @@ struct dpll_pin_filter {
> __u32 type;
> __u32 parent_device_id;
> __u32 parent_pin_id;
> + __u32 direction;
> + __u32 state;
> };
>
> static bool filter_match_nested_id(const struct nlmsghdr *nlh,
> @@ -953,6 +968,39 @@ static bool filter_match_nested_id(const struct nlmsghdr *nlh,
> return false;
> }
>
> +static bool filter_match_nested_parent_device(const struct nlmsghdr *nlh,
> + struct dpll_pin_filter *filter)
> +{
> + const struct nlattr *attr;
> +
> + mnl_attr_for_each(attr, nlh, sizeof(struct genlmsghdr)) {
> + struct nlattr *tb_nest[DPLL_A_PIN_MAX + 1] = {};
> +
> + if (mnl_attr_get_type(attr) != DPLL_A_PIN_PARENT_DEVICE)
> + continue;
> +
> + mnl_attr_parse_nested(attr, attr_pin_cb, tb_nest);
> +
> + if ((filter->present & DPLL_FILTER_PIN_PARENT_DEVICE) &&
> + !filter_match_u32(tb_nest[DPLL_A_PIN_PARENT_ID],
> + filter->parent_device_id))
> + continue;
> +
> + if ((filter->present & DPLL_FILTER_PIN_DIRECTION) &&
> + !filter_match_u32(tb_nest[DPLL_A_PIN_DIRECTION],
> + filter->direction))
> + continue;
> +
> + if ((filter->present & DPLL_FILTER_PIN_STATE) &&
> + !filter_match_u32(tb_nest[DPLL_A_PIN_STATE],
> + filter->state))
> + continue;
> +
> + return true;
> + }
> + return false;
> +}
> +
> static bool dpll_pin_dump_filter(struct dpll_pin_filter *filter,
> const struct nlmsghdr *nlh,
> struct nlattr **tb)
> @@ -979,9 +1027,10 @@ static bool dpll_pin_dump_filter(struct dpll_pin_filter *filter,
> if ((filter->present & DPLL_FILTER_PIN_TYPE) &&
> !filter_match_u32(tb[DPLL_A_PIN_TYPE], filter->type))
> return false;
> - if ((filter->present & DPLL_FILTER_PIN_PARENT_DEVICE) &&
> - !filter_match_nested_id(nlh, DPLL_A_PIN_PARENT_DEVICE,
> - filter->parent_device_id))
> + if ((filter->present & (DPLL_FILTER_PIN_PARENT_DEVICE |
> + DPLL_FILTER_PIN_DIRECTION |
> + DPLL_FILTER_PIN_STATE)) &&
> + !filter_match_nested_parent_device(nlh, filter))
> return false;
> if ((filter->present & DPLL_FILTER_PIN_PARENT_PIN) &&
> !filter_match_nested_id(nlh, DPLL_A_PIN_PARENT_PIN,
> @@ -1892,6 +1941,22 @@ static int cmd_pin_show(struct dpll *dpll)
> str_to_dpll_pin_type,
> "mux/ext/synce-eth-port/int-oscillator/gnss"))
> return -EINVAL;
> + } else if (dpll_argv_match(dpll, "direction")) {
> + if (dpll_filter_parse_enum(dpll, "direction",
> + &filter.direction,
> + &filter.present,
> + DPLL_FILTER_PIN_DIRECTION,
> + str_to_dpll_pin_direction,
> + "input/output"))
> + return -EINVAL;
> + } else if (dpll_argv_match(dpll, "state")) {
> + if (dpll_filter_parse_enum(dpll, "state",
> + &filter.state,
> + &filter.present,
> + DPLL_FILTER_PIN_STATE,
> + str_to_dpll_pin_state,
> + "connected/disconnected/selectable"))
> + return -EINVAL;
> } else {
> pr_err("unknown option: %s\n", dpll_argv(dpll));
> return -EINVAL;
> diff --git a/man/man8/dpll.8 b/man/man8/dpll.8
> index 479e5ed9871eeb..4213ae7a494fb8 100644
> --- a/man/man8/dpll.8
> +++ b/man/man8/dpll.8
> @@ -169,7 +169,7 @@ Device type:
>
> .SH PIN COMMANDS
>
> -.SS dpll pin show [ id ID ] [ parent-device DEVICE_ID ] [ parent-pin PIN_ID ] [ module-name NAME ] [ clock-id ID ] [ board-label LABEL ] [ panel-label LABEL ] [ package-label LABEL ] [ type TYPE ]
> +.SS dpll pin show [ id ID ] [ parent-device DEVICE_ID ] [ parent-pin PIN_ID ] [ module-name NAME ] [ clock-id ID ] [ board-label LABEL ] [ panel-label LABEL ] [ package-label LABEL ] [ type TYPE ] [ direction DIR ] [ state STATE ]
>
> Display information about DPLL pins. If no arguments are specified,
> shows all pins in the system.
> @@ -211,6 +211,22 @@ Show only pins with the specified package label.
> Show only pins of the specified type:
> .BR mux ", " ext ", " synce-eth-port ", " int-oscillator ", " gnss .
>
> +.TP
> +.BI direction " DIR"
> +Show only pins that have a parent-device relationship with the specified direction:
> +.BR input ", " output .
> +When combined with
> +.BR parent-device ,
> +only the specified parent-device relationship is checked.
> +
> +.TP
> +.BI state " STATE"
> +Show only pins that have a parent-device relationship with the specified state:
> +.BR connected ", " disconnected ", " selectable .
> +When combined with
> +.BR parent-device ,
> +only the specified parent-device relationship is checked.
> +
> .PP
> Output includes:
> .RS
> @@ -401,6 +417,11 @@ Press Ctrl+C to stop monitoring.
> .B dpll -jp pin show id 5
> .fi
>
> +.SS Show connected input pins on device 0
> +.nf
> +.B dpll pin show parent-device 0 direction input state connected
> +.fi
> +
> .SS Set pin frequency to 10 MHz
> .nf
> .B dpll pin set id 0 frequency 10000000
Hi Petr,
thanks for this!
Tested-by: Ivan Vecera <ivecera@redhat.com>
^ permalink raw reply
* Re: [PATCH net-next] fbnic: Set Relaxed Ordering PCIe TLP attributes for DMA engines
From: patchwork-bot+netdevbpf @ 2026-03-31 14:10 UTC (permalink / raw)
To: Dimitri Daskalakis
Cc: davem, alexanderduyck, kuba, kernel-team, andrew+netdev, edumazet,
pabeni, horms, jacob.e.keller, mohsin.bashr, lee,
mike.marciniszyn, netdev
In-Reply-To: <20260327204445.3074446-1-dimitri.daskalakis1@gmail.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Mar 2026 13:44:45 -0700 you wrote:
> From: Alexander Duyck <alexanderduyck@fb.com>
>
> Add ATTR CSR bit field definitions for the DMA engine TLP header
> configuration registers:
> AW_CFG: RDE_ATTR[17:15], RQM_ATTR[14:12], TQM_ATTR[11:9]
> AR_CFG: TDE_ATTR[17:15], RQM_ATTR[14:12], TQM_ATTR[11:9]
>
> [...]
Here is the summary with links:
- [net-next] fbnic: Set Relaxed Ordering PCIe TLP attributes for DMA engines
https://git.kernel.org/netdev/net-next/c/9229cb5a941c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Keith Busch @ 2026-03-31 14:13 UTC (permalink / raw)
To: Leon Romanovsky
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <20260331140309.GH814676@unreal>
On Tue, Mar 31, 2026 at 05:03:09PM +0300, Leon Romanovsky wrote:
> I understand, my proposal is always set TPH flag when new struct is
> used.
An existing application recompiled against the new kernel api implicitly
uses the new struct layout without setting the TPH flag, so kernel and
application are out of sync on where dma_ranges exists with your
proposal.
^ permalink raw reply
* Re: [PATCH net-next v2 5/5] selftests: net: bridge: add tests for igmpv3 MRC and QQIC validation
From: Ido Schimmel @ 2026-03-31 14:13 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260330191611.16929-6-royujjal@gmail.com>
On Mon, Mar 30, 2026 at 07:16:11PM +0000, Ujjal Roy wrote:
> Add bridge selftests that configure IGMPv3 parameters and validate the
> resulting Query packet fields for Max Resp Code (MRC) and Querier Query
> Interval Code (QQIC).
>
> This also adds helper binary to encode floating-point exponential fields.
>
> Future extensions may cover corresponding IPv6 cases.
Please cover both IGMPv3 and MLDv2 since the patchset touches both. You
can add the MLDv2 tests in bridge_mld.sh.
Also, I think you can simplify the test by simply matching on the
expected values of MRC and QQIC using tc-u32.
For both IGMPv3 and MLDv2 please test both:
* MRC and QQIC in linear range.
* MRC and QQIC in non-linear range.
And please make sure the new test cases don't add new shellcheck
warnings / errors or it will fail in the CI. You can ignore existing
ones.
^ permalink raw reply
* Re: [PATCH net-next v2 0/5] net: bridge: mcast: add multicast exponential field encoding
From: Ido Schimmel @ 2026-03-31 14:16 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Nikolay Aleksandrov, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260330191611.16929-1-royujjal@gmail.com>
On Mon, Mar 30, 2026 at 07:16:06PM +0000, Ujjal Roy wrote:
> Description:
> This series addresses a mismatch in how multicast query
> intervals and response codes are handled across IPv4 (IGMPv3)
> and IPv6 (MLDv2). While decoding logic currently exists,
> the corresponding encoding logic is missing during query
> packet generation. This leads to incorrect intervals being
> transmitted when values exceed their linear thresholds.
Thanks for the patches. I will take a look, but please read:
https://docs.kernel.org/process/maintainer-netdev.html
In particular:
"The new version of patches should be posted as a separate thread, not
as a reply to the previous posting."
^ permalink raw reply
* Re: [PATCH net v2] bridge: mrp: reject zero test interval to avoid OOM panic
From: patchwork-bot+netdevbpf @ 2026-03-31 14:20 UTC (permalink / raw)
To: Xiang Mei
Cc: netdev, bridge, horms, razor, kuba, idosch, davem, edumazet,
pabeni, bestswngs
In-Reply-To: <20260328063000.1845376-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Mar 2026 23:30:00 -0700 you wrote:
> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> interval value from netlink without validation. When interval is 0,
> usecs_to_jiffies(0) yields 0, causing the delayed work
> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> itself with zero delay. This creates a tight loop on system_percpu_wq
> that allocates and transmits MRP test frames at maximum rate, exhausting
> all system memory and causing a kernel panic via OOM deadlock.
>
> [...]
Here is the summary with links:
- [net,v2] bridge: mrp: reject zero test interval to avoid OOM panic
https://git.kernel.org/netdev/net/c/fa6e24963342
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 2/2] net: mdio: add a driver for PIC64-HPSC/HX MDIO controller
From: Andrew Lunn @ 2026-03-31 14:20 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: Charles Perry, netdev, Maxime Chevallier, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <acvUqDgepCIScs8M@shell.armlinux.org.uk>
On Tue, Mar 31, 2026 at 03:05:28PM +0100, Russell King (Oracle) wrote:
> On Tue, Mar 31, 2026 at 06:42:02AM -0700, Charles Perry wrote:
> > I don't know if there's any value in waiting for write completion here as
> > write completion doesn't mean that the effects of the write are available
> > right now. I also didn't run into any issues in my testing. Let me know if
> > you know of a use case where this wouldn't work.
> >
> > I can add a wait for transaction completion if that's expected by phylib.
>
> Consider a PHY using a shared interrupt line, and the interrupt being
> disabled in at the PHY before being torn down... wouldn't we want the
> write to the register which enables interrupts to complete before we
> unregister the interrupt handler for the particular PHY?
>
> I do notice that other MDIO drivers don't wait. Some PHY drivers don't
> access the PHY after the write to disable interrupts either. So, maybe
> phy_free_interrupt() should read-back from the PHY before calling
> free_irq() to guarantee that the write has completed?
>
> Andrew?
The general pattern is to not wait on write.
Interrupts is not a case i've thought about. Yes, a read to flush the
write would make sense, maybe in phy_disable_interrupts().
Andrew
^ permalink raw reply
* Re: [PATCH net-next] pppoe: update Kconfig URLs
From: Jaco Kroon @ 2026-03-31 14:21 UTC (permalink / raw)
To: Dianne Skoll
Cc: Qingfang Deng, linux-ppp, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev,
linux-kernel, Paul Mackerras, James Carlson
In-Reply-To: <20260331091655.30212333@gato.skoll.ca>
Hi Dianne,
On 2026/03/31 15:16, Dianne Skoll wrote:
> On Tue, 31 Mar 2026 08:21:40 +0200
> Jaco Kroon <jaco@uls.co.za> wrote:
>
>> That same code has recently been dropped from rp-pppoe,
> That is not the case. I still ship all of the plugin code with rp-pppoe.
My bad, my apologies. It was the userspace code you dropped then, which
does NOT require the kernel options? I do recall there was a huge
debate around this though in the one ppp bug.
>> Most people will never need rp-pppoe.
> This is correct because the ppp project *also* ships the plugin code.
Kind regards,
Jaco
^ permalink raw reply
* Re: [PATCH 2/2] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
From: Waiman Long @ 2026-03-31 14:23 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman, David S. Miller, David Ahern, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Frederic Weisbecker, Chen Ridong, Phil Auld,
linux-kernel, netdev, lvs-devel, netfilter-devel, coreteam,
sheviks
In-Reply-To: <6b8f1536-444c-e75a-c4b3-d5cbe7c1786e@ssi.bg>
On 3/26/26 4:32 AM, Julian Anastasov wrote:
> Hello,
>
> On Tue, 24 Mar 2026, Waiman Long wrote:
>
>> The ip_vs_ctl.c file and the associated ip_vs.h file are the only places
>> in the kernel where HK_TYPE_KTHREAD cpumask is being retrieved and used.
>> Now that HK_TYPE_KTHREAD/HK_TYPE_DOMAIN cpumask can be changed at run
>> time. We need to use RCU to guard access to this cpumask to avoid a
>> potential UAF problem as the returned cpumask may be freed before it
>> is being used.
>>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> include/net/ip_vs.h | 20 ++++++++++++++++----
>> net/netfilter/ipvs/ip_vs_ctl.c | 13 ++++++++-----
>> 2 files changed, 24 insertions(+), 9 deletions(-)
>>
>> diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
>> index 29a36709e7f3..17c85a575ef4 100644
>> --- a/include/net/ip_vs.h
>> +++ b/include/net/ip_vs.h
>> @@ -1155,7 +1155,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)
>> return ipvs->sysctl_run_estimation;
>> }
>>
>> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)
>> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)
>> {
>> if (ipvs->est_cpulist_valid)
>> return ipvs->sysctl_est_cpulist;
>> @@ -1273,7 +1273,7 @@ static inline int sysctl_run_estimation(struct netns_ipvs *ipvs)
>> return 1;
>> }
>>
>> -static inline const struct cpumask *sysctl_est_cpulist(struct netns_ipvs *ipvs)
>> +static inline const struct cpumask *__sysctl_est_cpulist(struct netns_ipvs *ipvs)
>> {
>> return housekeeping_cpumask(HK_TYPE_KTHREAD);
>> }
>> @@ -1290,6 +1290,18 @@ static inline int sysctl_est_nice(struct netns_ipvs *ipvs)
>>
>> #endif
>>
> May be there is little fuzz here, due to the recent
> changes in the nf-next tree. If this is a bugfix due to the
> missing RCU protection, may be you should add Fixes line too
> and use the nf tree. Probably, there will be fuzz/collisions with
> the changes in the nf-next tree...
Thanks for the suggestion, I will rebase the patches on top of the
nf-next tree.
>
>> +static inline bool sysctl_est_cpulist_empty(struct netns_ipvs *ipvs)
>> +{
>> + guard(rcu)();
>> + return cpumask_empty(__sysctl_est_cpulist(ipvs));
>> +}
>> +
>> +static inline unsigned int sysctl_est_cpulist_weight(struct netns_ipvs *ipvs)
>> +{
>> + guard(rcu)();
>> + return cpumask_weight(__sysctl_est_cpulist(ipvs));
>> +}
>> +
>> /* IPVS core functions
>> * (from ip_vs_core.c)
>> */
>> @@ -1604,7 +1616,7 @@ static inline void ip_vs_est_stopped_recalc(struct netns_ipvs *ipvs)
>> /* Stop tasks while cpulist is empty or if disabled with flag */
>> ipvs->est_stopped = !sysctl_run_estimation(ipvs) ||
>> (ipvs->est_cpulist_valid &&
>> - cpumask_empty(sysctl_est_cpulist(ipvs)));
>> + sysctl_est_cpulist_empty(ipvs));
>> #endif
>> }
>>
>> @@ -1620,7 +1632,7 @@ static inline bool ip_vs_est_stopped(struct netns_ipvs *ipvs)
>> static inline int ip_vs_est_max_threads(struct netns_ipvs *ipvs)
>> {
>> unsigned int limit = IPVS_EST_CPU_KTHREADS *
>> - cpumask_weight(sysctl_est_cpulist(ipvs));
>> + sysctl_est_cpulist_weight(ipvs);
>>
>> return max(1U, limit);
>> }
>> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
>> index 35642de2a0fe..f38a2e2a9dc5 100644
>> --- a/net/netfilter/ipvs/ip_vs_ctl.c
>> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
>> @@ -1973,11 +1973,14 @@ static int ipvs_proc_est_cpumask_get(const struct ctl_table *table,
>>
>> mutex_lock(&ipvs->est_mutex);
>>
>> - if (ipvs->est_cpulist_valid)
>> - mask = *valp;
>> - else
>> - mask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);
>> - ret = scnprintf(buffer, size, "%*pbl\n", cpumask_pr_args(mask));
>> + /* HK_TYPE_KTHREAD cpumask needs RCU protection */
> Can we switch IPVS to use HK_TYPE_DOMAIN? The initial
> intention was to follow the code in kthread.c. Then you can
> reconsider if HK_TYPE_KTHREAD should be alias to HK_TYPE_DOMAIN,
> may be not if there are no other users...
Yes, I can certainly switch to use HK_TYPE_DOMAIN instead. The reason I
keep HK_TYPE_KTHREAD is that it may not be obvious to others that
kthread is now following the HK_TYPE_DOMAIN cpumask,
keeping HK_TYPE_KTHREAD but making it an alias can make that clear.
>> + scoped_guard(rcu) {
>> + if (ipvs->est_cpulist_valid)
>> + mask = *valp;
>> + else
>> + mask = (struct cpumask *)housekeeping_cpumask(HK_TYPE_KTHREAD);
>> + ret = scnprintf(buffer, size, "%*pbl\n", cpumask_pr_args(mask));
>> + }
>>
>> mutex_unlock(&ipvs->est_mutex);
>>
>> --
>> 2.53.0
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH net-next] pppoe: update Kconfig URLs
From: Dianne Skoll @ 2026-03-31 14:25 UTC (permalink / raw)
To: Jaco Kroon
Cc: Qingfang Deng, linux-ppp, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev,
linux-kernel, Paul Mackerras, James Carlson
In-Reply-To: <1bba860e-a204-4a5b-9b8f-4d55a559d01e@uls.co.za>
Hi, all,
> My bad, my apologies. It was the userspace code you dropped then, which
> does NOT require the kernel options?
I was considering doing that, but I kept the userspace code. The reason is
that on some platforms, such as uclinux on a processor without an MMU,
the dlopen() system call is not implemented, so there's no way to use
a plugin with pppd. One user asked me to keep the userspace code, so I
did.
But you are correct in that 99.99% of Linux users will not need to download
rp-pppoe if all they want to do is connect to the Internet using a PPPoE
client.
Regards,
Dianne.
^ 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