* [PATCH 1/1] nfc: llcp: fix use-after-free in llcp_sock_release()
From: Lee Jones @ 2026-04-29 13:22 UTC (permalink / raw)
To: lee, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kees Cook, netdev, linux-kernel
llcp_sock_release() unconditionally unlinks the socket from the local
sockets list. However, if the socket is still in connecting state, it
is on the connecting list.
Fix this by checking the socket state and unlinking from the correct list.
Signed-off-by: Lee Jones <lee@kernel.org>
---
net/nfc/llcp_sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index f1be1e84f6653..feab29fc62f44 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -633,6 +633,8 @@ static int llcp_sock_release(struct socket *sock)
if (sock->type == SOCK_RAW)
nfc_llcp_sock_unlink(&local->raw_sockets, sk);
+ else if (sk->sk_state == LLCP_CONNECTING)
+ nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
else
nfc_llcp_sock_unlink(&local->sockets, sk);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH net-next] net: gianfar: use alloc_ethdev_mqs
From: Andrew Lunn @ 2026-04-29 13:24 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Claudiu Manoil, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, open list
In-Reply-To: <CAKxU2N_uQaGvsT5zri53Bcr9veCFWzV=_VnddJRdOXBYgoqWQw@mail.gmail.com>
> I see what you mean. Will respin this.
This is why the netdev FAQ says:
Netdev discourages patches which perform simple clean-ups, which are
not in the context of other work.
...
This is because it is felt that the churn that such changes produce
comes at a greater cost than the value of such clean-ups.
Does changing alloc_netdev_mq() to alloc_netdev_mqs() bring enough
gain to offset the work needed to find the new bugs added at the same
time?
I know i would prefer looking at patches adding new drivers, new
infrastructure, new features, than broken cleanups for very old
drivers with very few users.
Andrew
^ permalink raw reply
* Re: [PATCH v4 05/15] remoteproc: qcom_q6v5_pas: Switch over to generic PAS TZ APIs
From: Mukesh Ojha @ 2026-04-29 13:25 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-6-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:53PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch qcom_q6v5_pas client driver over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5_pas.c | 51 +++++++++++++++---------------
> 1 file changed, 26 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_pas.c b/drivers/remoteproc/qcom_q6v5_pas.c
> index da27d1d3c9da..847249c28c1b 100644
> --- a/drivers/remoteproc/qcom_q6v5_pas.c
> +++ b/drivers/remoteproc/qcom_q6v5_pas.c
> @@ -20,6 +20,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/firmware/qcom/qcom_scm.h>
Can you check do we really need this header ?
> #include <linux/regulator/consumer.h>
> #include <linux/remoteproc.h>
> @@ -118,8 +119,8 @@ struct qcom_pas {
> struct qcom_rproc_ssr ssr_subdev;
> struct qcom_sysmon *sysmon;
>
> - struct qcom_scm_pas_context *pas_ctx;
> - struct qcom_scm_pas_context *dtb_pas_ctx;
> + struct qcom_pas_context *pas_ctx;
> + struct qcom_pas_context *dtb_pas_ctx;
> };
>
> static void qcom_pas_segment_dump(struct rproc *rproc,
> @@ -196,7 +197,7 @@ static int qcom_pas_shutdown_poll_decrypt(struct qcom_pas *pas)
>
> do {
> msleep(QCOM_PAS_DECRYPT_SHUTDOWN_DELAY_MS);
> - ret = qcom_scm_pas_shutdown(pas->pas_id);
> + ret = qcom_pas_shutdown(pas->pas_id);
> } while (ret == -EINVAL && --retry_num);
>
> return ret;
> @@ -212,9 +213,9 @@ static int qcom_pas_unprepare(struct rproc *rproc)
> * auth_and_reset() was successful, but in other cases clean it up
> * here.
> */
> - qcom_scm_pas_metadata_release(pas->pas_ctx);
> + qcom_pas_metadata_release(pas->pas_ctx);
> if (pas->dtb_pas_id)
> - qcom_scm_pas_metadata_release(pas->dtb_pas_ctx);
> + qcom_pas_metadata_release(pas->dtb_pas_ctx);
>
> return 0;
> }
> @@ -228,9 +229,9 @@ static int qcom_pas_load(struct rproc *rproc, const struct firmware *fw)
> pas->firmware = fw;
>
> if (pas->lite_pas_id)
> - qcom_scm_pas_shutdown(pas->lite_pas_id);
> + qcom_pas_shutdown(pas->lite_pas_id);
> if (pas->lite_dtb_pas_id)
> - qcom_scm_pas_shutdown(pas->lite_dtb_pas_id);
> + qcom_pas_shutdown(pas->lite_dtb_pas_id);
>
> if (pas->dtb_pas_id) {
> ret = request_firmware(&pas->dtb_firmware, pas->dtb_firmware_name, pas->dev);
> @@ -250,7 +251,7 @@ static int qcom_pas_load(struct rproc *rproc, const struct firmware *fw)
> return 0;
>
> release_dtb_metadata:
> - qcom_scm_pas_metadata_release(pas->dtb_pas_ctx);
> + qcom_pas_metadata_release(pas->dtb_pas_ctx);
> release_firmware(pas->dtb_firmware);
>
> return ret;
> @@ -310,7 +311,7 @@ static int qcom_pas_start(struct rproc *rproc)
> if (ret)
> goto disable_px_supply;
>
> - ret = qcom_scm_pas_prepare_and_auth_reset(pas->dtb_pas_ctx);
> + ret = qcom_pas_prepare_and_auth_reset(pas->dtb_pas_ctx);
> if (ret) {
> dev_err(pas->dev,
> "failed to authenticate dtb image and release reset\n");
> @@ -329,7 +330,7 @@ static int qcom_pas_start(struct rproc *rproc)
> if (ret)
> goto release_pas_metadata;
>
> - ret = qcom_scm_pas_prepare_and_auth_reset(pas->pas_ctx);
> + ret = qcom_pas_prepare_and_auth_reset(pas->pas_ctx);
> if (ret) {
> dev_err(pas->dev,
> "failed to authenticate image and release reset\n");
> @@ -339,13 +340,13 @@ static int qcom_pas_start(struct rproc *rproc)
> ret = qcom_q6v5_wait_for_start(&pas->q6v5, msecs_to_jiffies(5000));
> if (ret == -ETIMEDOUT) {
> dev_err(pas->dev, "start timed out\n");
> - qcom_scm_pas_shutdown(pas->pas_id);
> + qcom_pas_shutdown(pas->pas_id);
> goto unmap_carveout;
> }
>
> - qcom_scm_pas_metadata_release(pas->pas_ctx);
> + qcom_pas_metadata_release(pas->pas_ctx);
> if (pas->dtb_pas_id)
> - qcom_scm_pas_metadata_release(pas->dtb_pas_ctx);
> + qcom_pas_metadata_release(pas->dtb_pas_ctx);
>
> /* firmware is used to pass reference from qcom_pas_start(), drop it now */
> pas->firmware = NULL;
> @@ -355,9 +356,9 @@ static int qcom_pas_start(struct rproc *rproc)
> unmap_carveout:
> qcom_pas_unmap_carveout(rproc, pas->mem_phys, pas->mem_size);
> release_pas_metadata:
> - qcom_scm_pas_metadata_release(pas->pas_ctx);
> + qcom_pas_metadata_release(pas->pas_ctx);
> if (pas->dtb_pas_id)
> - qcom_scm_pas_metadata_release(pas->dtb_pas_ctx);
> + qcom_pas_metadata_release(pas->dtb_pas_ctx);
>
> unmap_dtb_carveout:
> if (pas->dtb_pas_id)
> @@ -406,7 +407,7 @@ static int qcom_pas_stop(struct rproc *rproc)
> if (ret == -ETIMEDOUT)
> dev_err(pas->dev, "timed out on wait\n");
>
> - ret = qcom_scm_pas_shutdown(pas->pas_id);
> + ret = qcom_pas_shutdown(pas->pas_id);
> if (ret && pas->decrypt_shutdown)
> ret = qcom_pas_shutdown_poll_decrypt(pas);
>
> @@ -414,7 +415,7 @@ static int qcom_pas_stop(struct rproc *rproc)
> dev_err(pas->dev, "failed to shutdown: %d\n", ret);
>
> if (pas->dtb_pas_id) {
> - ret = qcom_scm_pas_shutdown(pas->dtb_pas_id);
> + ret = qcom_pas_shutdown(pas->dtb_pas_id);
> if (ret)
> dev_err(pas->dev, "failed to shutdown dtb: %d\n", ret);
>
> @@ -484,11 +485,11 @@ static int qcom_pas_parse_firmware(struct rproc *rproc, const struct firmware *f
> *
> * Here, we call rproc_elf_load_rsc_table() to check firmware binary has resources
> * or not and if it is not having then we pass NULL and zero as input resource
> - * table pointer and size respectively to the argument of qcom_scm_pas_get_rsc_table()
> + * table pointer and size respectively to the argument of qcom_pas_get_rsc_table()
> * and this is even true for Qualcomm remote processor who does follow remoteproc
> * framework.
> */
> - output_rt = qcom_scm_pas_get_rsc_table(pas->pas_ctx, table, table_sz, &output_rt_size);
> + output_rt = qcom_pas_get_rsc_table(pas->pas_ctx, table, table_sz, &output_rt_size);
> ret = IS_ERR(output_rt) ? PTR_ERR(output_rt) : 0;
> if (ret) {
> dev_err(pas->dev, "Error in getting resource table: %d\n", ret);
> @@ -746,7 +747,7 @@ static int qcom_pas_probe(struct platform_device *pdev)
> if (!desc)
> return -EINVAL;
>
> - if (!qcom_scm_is_available())
> + if (!qcom_pas_is_available())
> return -EPROBE_DEFER;
>
> fw_name = desc->firmware_name;
> @@ -838,16 +839,16 @@ static int qcom_pas_probe(struct platform_device *pdev)
>
> qcom_add_ssr_subdev(rproc, &pas->ssr_subdev, desc->ssr_name);
>
> - pas->pas_ctx = devm_qcom_scm_pas_context_alloc(pas->dev, pas->pas_id,
> - pas->mem_phys, pas->mem_size);
> + pas->pas_ctx = devm_qcom_pas_context_alloc(pas->dev, pas->pas_id,
> + pas->mem_phys, pas->mem_size);
> if (IS_ERR(pas->pas_ctx)) {
> ret = PTR_ERR(pas->pas_ctx);
> goto remove_ssr_sysmon;
> }
>
> - pas->dtb_pas_ctx = devm_qcom_scm_pas_context_alloc(pas->dev, pas->dtb_pas_id,
> - pas->dtb_mem_phys,
> - pas->dtb_mem_size);
> + pas->dtb_pas_ctx = devm_qcom_pas_context_alloc(pas->dev, pas->dtb_pas_id,
> + pas->dtb_mem_phys,
> + pas->dtb_mem_size);
> if (IS_ERR(pas->dtb_pas_ctx)) {
> ret = PTR_ERR(pas->dtb_pas_ctx);
> goto remove_ssr_sysmon;
> --
> 2.51.0
>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 1/1] nfc: llcp: fix use-after-free in llcp_sock_release()
From: Eric Dumazet @ 2026-04-29 13:26 UTC (permalink / raw)
To: Lee Jones
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kees Cook, netdev, linux-kernel
In-Reply-To: <20260429132218.3548644-1-lee@kernel.org>
On Wed, Apr 29, 2026 at 6:22 AM Lee Jones <lee@kernel.org> wrote:
>
> llcp_sock_release() unconditionally unlinks the socket from the local
> sockets list. However, if the socket is still in connecting state, it
> is on the connecting list.
>
> Fix this by checking the socket state and unlinking from the correct list.
>
> Signed-off-by: Lee Jones <lee@kernel.org>
> ---
> net/nfc/llcp_sock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
> index f1be1e84f6653..feab29fc62f44 100644
> --- a/net/nfc/llcp_sock.c
> +++ b/net/nfc/llcp_sock.c
> @@ -633,6 +633,8 @@ static int llcp_sock_release(struct socket *sock)
>
> if (sock->type == SOCK_RAW)
> nfc_llcp_sock_unlink(&local->raw_sockets, sk);
> + else if (sk->sk_state == LLCP_CONNECTING)
> + nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
> else
> nfc_llcp_sock_unlink(&local->sockets, sk);
>
> --
> 2.54.0.545.g6539524ca2-goog
>
Why are you sending this patch a second time?
You forgot to add a Fixes: tag, as requested for all networking patches.
^ permalink raw reply
* Re: [PATCH 1/2] net: thunderbolt: Call tbnet_stop() upon shutdown
From: Andrew Lunn @ 2026-04-29 13:31 UTC (permalink / raw)
To: Mika Westerberg
Cc: Jakub Kicinski, netdev, YehezkelShB, andrew+netdev, davem,
edumazet, pabeni
In-Reply-To: <20260429053046.GZ557136@black.igk.intel.com>
On Wed, Apr 29, 2026 at 07:30:46AM +0200, Mika Westerberg wrote:
> On Tue, Apr 28, 2026 at 06:12:24PM -0700, Jakub Kicinski wrote:
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > ---
> > net: thunderbolt: Call tbnet_stop() upon shutdown
> >
> > This commit updates the shutdown callback for the Thunderbolt network service
> > driver to call tbnet_stop() if the interface is running. This ensures the
> > service drivers release the rings upon shutdown.
> >
> > > diff --git a/drivers/net/thunderbolt/main.c b/drivers/net/thunderbolt/main.c
> > > index 7aae5d915a1e..631af237998d 100644
> > > --- a/drivers/net/thunderbolt/main.c
> > > +++ b/drivers/net/thunderbolt/main.c
> > > @@ -1417,7 +1417,10 @@ static void tbnet_remove(struct tb_service *svc)
> > >
> > > static void tbnet_shutdown(struct tb_service *svc)
> > > {
> > > - tbnet_tear_down(tb_service_get_drvdata(svc), true);
> > > + struct tbnet *net = tb_service_get_drvdata(svc);
> > > +
> > > + if (netif_running(net->dev))
> > > + tbnet_stop(net->dev);
> >
> > Does calling tbnet_stop() directly bypass the network stack teardown sequence?
>
> This is called when the machine is rebooted or shut down to quiesce the
> device. I don't think the network stack has anything similar?
You mean that network interfaces are left running while the machine
reboots, potentially DMAing receive packets over the bootloader or
freshly loaded kernel? Does that seem reasonable? Don't you think the
core will somehow call the .close function? I cannot point to the code
doing that without a bit if searching, but i think it probably exists.
Andrew
^ permalink raw reply
* Re: [PATCH v4 06/15] remoteproc: qcom_q6v5_mss: Switch to generic PAS TZ APIs
From: Mukesh Ojha @ 2026-04-29 13:31 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-7-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:54PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch qcom_q6v5_mss client driver over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_q6v5_mss.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_q6v5_mss.c b/drivers/remoteproc/qcom_q6v5_mss.c
> index ae78f5c7c1b6..96888007faa8 100644
> --- a/drivers/remoteproc/qcom_q6v5_mss.c
> +++ b/drivers/remoteproc/qcom_q6v5_mss.c
> @@ -34,6 +34,7 @@
> #include "qcom_pil_info.h"
> #include "qcom_q6v5.h"
>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/firmware/qcom/qcom_scm.h>
same here., whether it is needed now ?
>
> #define MPSS_CRASH_REASON_SMEM 421
> @@ -1480,7 +1481,7 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
> }
>
> if (qproc->need_pas_mem_setup) {
> - ret = qcom_scm_pas_mem_setup(MPSS_PAS_ID, qproc->mpss_phys, qproc->mpss_size);
> + ret = qcom_pas_mem_setup(MPSS_PAS_ID, qproc->mpss_phys, qproc->mpss_size);
> if (ret) {
> dev_err(qproc->dev,
> "setting up mpss memory failed: %d\n", ret);
> @@ -2077,7 +2078,7 @@ static int q6v5_probe(struct platform_device *pdev)
> if (!desc)
> return -EINVAL;
>
> - if (desc->need_mem_protection && !qcom_scm_is_available())
> + if (desc->need_mem_protection && !qcom_pas_is_available())
> return -EPROBE_DEFER;
>
> mba_image = desc->hexagon_mba_image;
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH 1/1] nfc: llcp: fix use-after-free in llcp_sock_release()
From: Lee Jones @ 2026-04-29 13:37 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kees Cook, netdev, linux-kernel
In-Reply-To: <CANn89iL_o4dJ-zgjGzA=gGXiVF1P0TTz74LJNuy2zrgbxB5S0Q@mail.gmail.com>
On Wed, 29 Apr 2026, Eric Dumazet wrote:
> On Wed, Apr 29, 2026 at 6:22 AM Lee Jones <lee@kernel.org> wrote:
> >
> > llcp_sock_release() unconditionally unlinks the socket from the local
> > sockets list. However, if the socket is still in connecting state, it
> > is on the connecting list.
> >
> > Fix this by checking the socket state and unlinking from the correct list.
> >
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > net/nfc/llcp_sock.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
> > index f1be1e84f6653..feab29fc62f44 100644
> > --- a/net/nfc/llcp_sock.c
> > +++ b/net/nfc/llcp_sock.c
> > @@ -633,6 +633,8 @@ static int llcp_sock_release(struct socket *sock)
> >
> > if (sock->type == SOCK_RAW)
> > nfc_llcp_sock_unlink(&local->raw_sockets, sk);
> > + else if (sk->sk_state == LLCP_CONNECTING)
> > + nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
> > else
> > nfc_llcp_sock_unlink(&local->sockets, sk);
> >
> > --
> > 2.54.0.545.g6539524ca2-goog
> >
>
> Why are you sending this patch a second time?
Because I am a dunce and forgot to clear out my send cache before
sending a related but different patch.
> You forgot to add a Fixes: tag, as requested for all networking patches.
No problem. Please ignore both of these and I'll follow-up with a
coherent set with `Fixes:` tags applied.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 1/1] nfc: llcp: fix use-after-free in llcp_sock_release()
From: Eric Dumazet @ 2026-04-29 13:39 UTC (permalink / raw)
To: Lee Jones
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kees Cook, netdev, linux-kernel
In-Reply-To: <20260429133742.GE1806155@google.com>
On Wed, Apr 29, 2026 at 6:37 AM Lee Jones <lee@kernel.org> wrote:
>
> No problem. Please ignore both of these and I'll follow-up with a
> coherent set with `Fixes:` tags applied.
Thanks a lot!
^ permalink raw reply
* [PATCH 1/2] nfc: llcp: Fix use-after-free in llcp_sock_release()
From: Lee Jones @ 2026-04-29 13:40 UTC (permalink / raw)
To: lee, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Kees Cook, Junxi Qian,
Ingo Molnar, Samuel Ortiz, netdev, linux-kernel
llcp_sock_release() unconditionally unlinks the socket from the local
sockets list. However, if the socket is still in connecting state, it
is on the connecting list.
Fix this by checking the socket state and unlinking from the correct list.
Fixes: b4011239a08e ("NFC: llcp: Fix non blocking sockets connections")
Signed-off-by: Lee Jones <lee@kernel.org>
---
net/nfc/llcp_sock.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/nfc/llcp_sock.c b/net/nfc/llcp_sock.c
index f1be1e84f6653..feab29fc62f44 100644
--- a/net/nfc/llcp_sock.c
+++ b/net/nfc/llcp_sock.c
@@ -633,6 +633,8 @@ static int llcp_sock_release(struct socket *sock)
if (sock->type == SOCK_RAW)
nfc_llcp_sock_unlink(&local->raw_sockets, sk);
+ else if (sk->sk_state == LLCP_CONNECTING)
+ nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
else
nfc_llcp_sock_unlink(&local->sockets, sk);
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* [PATCH 2/2] nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()
From: Lee Jones @ 2026-04-29 13:40 UTC (permalink / raw)
To: lee, David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Ingo Molnar, Kees Cook,
Junxi Qian, Samuel Ortiz, netdev, linux-kernel
In-Reply-To: <20260429134115.3558604-1-lee@kernel.org>
A race condition exists in the NFC LLCP connection state machine where
the connection acceptance packet (CC) can be processed concurrently with
socket release. This can lead to a use-after-free of the socket object.
When nfc_llcp_recv_cc() moves the socket from the connecting_sockets
list to the sockets list, it does so without holding the socket lock.
If llcp_sock_release() is executing concurrently, it might have already
unlinked the socket and dropped its references, which can result in
nfc_llcp_recv_cc() linking a freed socket into the live list.
Fix this by holding lock_sock() during the state transition and list
movement in nfc_llcp_recv_cc(). After acquiring the lock, check if
the socket is still hashed to ensure it hasn't already been unlinked
and marked for destruction by the release path. This aligns the locking
pattern with recv_hdlc() and recv_disc().
Fixes: a69f32af86e3 ("NFC: Socket linked list")
Signed-off-by: Lee Jones <lee@kernel.org>
---
net/nfc/llcp_core.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index db5bc6a878ddb..dc65c719f35f2 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1218,6 +1218,15 @@ static void nfc_llcp_recv_cc(struct nfc_llcp_local *local,
sk = &llcp_sock->sk;
+ lock_sock(sk);
+
+ /* Check if socket was destroyed whilst waiting for the lock */
+ if (!sk_hashed(sk)) {
+ release_sock(sk);
+ nfc_llcp_sock_put(llcp_sock);
+ return;
+ }
+
/* Unlink from connecting and link to the client array */
nfc_llcp_sock_unlink(&local->connecting_sockets, sk);
nfc_llcp_sock_link(&local->sockets, sk);
@@ -1229,6 +1238,8 @@ static void nfc_llcp_recv_cc(struct nfc_llcp_local *local,
sk->sk_state = LLCP_CONNECTED;
sk->sk_state_change(sk);
+ release_sock(sk);
+
nfc_llcp_sock_put(llcp_sock);
}
--
2.54.0.545.g6539524ca2-goog
^ permalink raw reply related
* Re: [PATCH v4 07/15] soc: qcom: mdtloader: Switch to generic PAS TZ APIs
From: Mukesh Ojha @ 2026-04-29 13:42 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-8-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:55PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch mdtloader client driver over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/soc/qcom/mdt_loader.c | 12 ++++++------
> include/linux/soc/qcom/mdt_loader.h | 6 +++---
> 2 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index c004d444d698..fdde7eda538a 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -13,7 +13,7 @@
> #include <linux/firmware.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/sizes.h>
> #include <linux/slab.h>
> #include <linux/soc/qcom/mdt_loader.h>
> @@ -229,7 +229,7 @@ EXPORT_SYMBOL_GPL(qcom_mdt_read_metadata);
>
> static int __qcom_mdt_pas_init(struct device *dev, const struct firmware *fw,
> const char *fw_name, int pas_id, phys_addr_t mem_phys,
> - struct qcom_scm_pas_context *ctx)
> + struct qcom_pas_context *ctx)
> {
> const struct elf32_phdr *phdrs;
> const struct elf32_phdr *phdr;
> @@ -271,7 +271,7 @@ static int __qcom_mdt_pas_init(struct device *dev, const struct firmware *fw,
> goto out;
> }
>
> - ret = qcom_scm_pas_init_image(pas_id, metadata, metadata_len, ctx);
> + ret = qcom_pas_init_image(pas_id, metadata, metadata_len, ctx);
> kfree(metadata);
> if (ret) {
> /* Invalid firmware metadata */
> @@ -280,7 +280,7 @@ static int __qcom_mdt_pas_init(struct device *dev, const struct firmware *fw,
> }
>
> if (relocate) {
> - ret = qcom_scm_pas_mem_setup(pas_id, mem_phys, max_addr - min_addr);
> + ret = qcom_pas_mem_setup(pas_id, mem_phys, max_addr - min_addr);
> if (ret) {
> /* Unable to set up relocation */
> dev_err(dev, "error %d setting up firmware %s\n", ret, fw_name);
> @@ -472,7 +472,7 @@ EXPORT_SYMBOL_GPL(qcom_mdt_load);
> * firmware segments (e.g., .bXX files). Authentication of the segments done
> * by a separate call.
> *
> - * The PAS context must be initialized using qcom_scm_pas_context_init()
> + * The PAS context must be initialized using qcom_pas_context_init()
Should devm_qcom_pas_context_alloc() now
> * prior to invoking this function.
> *
> * @ctx: Pointer to the PAS (Peripheral Authentication Service) context
> @@ -483,7 +483,7 @@ EXPORT_SYMBOL_GPL(qcom_mdt_load);
> *
> * Return: 0 on success or a negative error code on failure.
> */
> -int qcom_mdt_pas_load(struct qcom_scm_pas_context *ctx, const struct firmware *fw,
> +int qcom_mdt_pas_load(struct qcom_pas_context *ctx, const struct firmware *fw,
> const char *firmware, void *mem_region, phys_addr_t *reloc_base)
> {
> int ret;
> diff --git a/include/linux/soc/qcom/mdt_loader.h b/include/linux/soc/qcom/mdt_loader.h
> index 82372e0db0a1..142409555425 100644
> --- a/include/linux/soc/qcom/mdt_loader.h
> +++ b/include/linux/soc/qcom/mdt_loader.h
> @@ -10,7 +10,7 @@
>
> struct device;
> struct firmware;
> -struct qcom_scm_pas_context;
> +struct qcom_pas_context;
>
> #if IS_ENABLED(CONFIG_QCOM_MDT_LOADER)
>
> @@ -20,7 +20,7 @@ int qcom_mdt_load(struct device *dev, const struct firmware *fw,
> phys_addr_t mem_phys, size_t mem_size,
> phys_addr_t *reloc_base);
>
> -int qcom_mdt_pas_load(struct qcom_scm_pas_context *ctx, const struct firmware *fw,
> +int qcom_mdt_pas_load(struct qcom_pas_context *ctx, const struct firmware *fw,
> const char *firmware, void *mem_region, phys_addr_t *reloc_base);
>
> int qcom_mdt_load_no_init(struct device *dev, const struct firmware *fw,
> @@ -45,7 +45,7 @@ static inline int qcom_mdt_load(struct device *dev, const struct firmware *fw,
> return -ENODEV;
> }
>
> -static inline int qcom_mdt_pas_load(struct qcom_scm_pas_context *ctx,
> +static inline int qcom_mdt_pas_load(struct qcom_pas_context *ctx,
> const struct firmware *fw, const char *firmware,
> void *mem_region, phys_addr_t *reloc_base)
> {
> --
> 2.51.0
>
With above nit
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v4 08/15] remoteproc: qcom_wcnss: Switch to generic PAS TZ APIs
From: Mukesh Ojha @ 2026-04-29 13:43 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-9-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:56PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch qcom_wcnss client driver over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/remoteproc/qcom_wcnss.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index 4add9037dbd5..0dbdd18ab3dd 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -19,7 +19,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_domain.h>
> #include <linux/pm_runtime.h>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/regulator/consumer.h>
> #include <linux/remoteproc.h>
> #include <linux/soc/qcom/mdt_loader.h>
> @@ -257,7 +257,7 @@ static int wcnss_start(struct rproc *rproc)
> wcnss_indicate_nv_download(wcnss);
> wcnss_configure_iris(wcnss);
>
> - ret = qcom_scm_pas_auth_and_reset(WCNSS_PAS_ID);
> + ret = qcom_pas_auth_and_reset(WCNSS_PAS_ID);
> if (ret) {
> dev_err(wcnss->dev,
> "failed to authenticate image and release reset\n");
> @@ -269,7 +269,7 @@ static int wcnss_start(struct rproc *rproc)
> if (wcnss->ready_irq > 0 && ret == 0) {
> /* We have a ready_irq, but it didn't fire in time. */
> dev_err(wcnss->dev, "start timed out\n");
> - qcom_scm_pas_shutdown(WCNSS_PAS_ID);
> + qcom_pas_shutdown(WCNSS_PAS_ID);
> ret = -ETIMEDOUT;
> goto disable_iris;
> }
> @@ -311,7 +311,7 @@ static int wcnss_stop(struct rproc *rproc)
> 0);
> }
>
> - ret = qcom_scm_pas_shutdown(WCNSS_PAS_ID);
> + ret = qcom_pas_shutdown(WCNSS_PAS_ID);
> if (ret)
> dev_err(wcnss->dev, "failed to shutdown: %d\n", ret);
>
> @@ -557,10 +557,10 @@ static int wcnss_probe(struct platform_device *pdev)
>
> data = of_device_get_match_data(&pdev->dev);
>
> - if (!qcom_scm_is_available())
> + if (!qcom_pas_is_available())
> return -EPROBE_DEFER;
>
> - if (!qcom_scm_pas_supported(WCNSS_PAS_ID)) {
> + if (!qcom_pas_supported(WCNSS_PAS_ID)) {
> dev_err(&pdev->dev, "PAS is not available for WCNSS\n");
> return -ENXIO;
> }
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH v4 09/15] remoteproc: qcom: Select QCOM_PAS generic service
From: Mukesh Ojha @ 2026-04-29 13:52 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-10-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:57PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Select PAS generic service driver to enable support for multiple PAS
> backends like OP-TEE in addition to SCM.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/remoteproc/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index ee54436fea5a..da3c5d9562ea 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -230,6 +230,7 @@ config QCOM_Q6V5_PAS
> select QCOM_Q6V5_COMMON
> select QCOM_RPROC_COMMON
> select QCOM_SCM
Check do we really need SCM now ?
Why not the change for WCNSS, MSS ?
> + select QCOM_PAS
> help
> Say y here to support the TrustZone based Peripheral Image Loader for
> the Qualcomm remote processors. This is commonly used to control
> --
> 2.51.0
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH net-next 1/4] net: eth: fbnic: Fix addr validation in pcs write
From: Andrew Lunn @ 2026-04-29 13:54 UTC (permalink / raw)
To: Mike Marciniszyn
Cc: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Heiner Kallweit,
Russell King, Jacob Keller, Mohsin Bashir, netdev, linux-kernel,
stable
In-Reply-To: <afHfFj0CkBUIQxRT@PF5YBGDS.localdomain>
On Wed, Apr 29, 2026 at 06:36:06AM -0400, Mike Marciniszyn wrote:
> On Tue, Apr 28, 2026 at 08:11:30PM +0200, Andrew Lunn wrote:
> > On Tue, Apr 28, 2026 at 01:28:07PM -0400, mike.marciniszyn@gmail.com wrote:
> > > From: "Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>
> > >
> > > This patch contains a fix for addr validation in fbnic_mdio_write_pcs().
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: d0ce9fd7eae0 ("fbnic: Add SW shim for MDIO interface to PMD and PCS")
> > > Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
> >
> > Please don't mix fixed and going development work in one
> > patchset. They should be applied to different trees, etc.
> >
> > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
> >
> > Andrew
> >
>
> So I'm guessing I need to send the bug fix to net instead of net-next
> and reissue the patch series?
Correct.
You also have access to some good mentors within Meta, maybe reach out
to them and do internal reviews before posting to netdev?
> BTW, the review notes that the patch wasn't sent to you
> (https://netdev-ctrl.bots.linux.dev/logs/build/1087030/14544928/cc_maintainers/)
> but that is because there are two addresses for you:
>
> grep Lunn MAINTAINERS
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew+netdev@lunn.ch> <----
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
> M: Andrew Lunn <andrew@lunn.ch>
>
> That seems to foil my scripting. Is MAINTAINERS wrong?
No. The +netdev helps procmail separate traffic between run of the
mill netdev deluge, and email specifically for me, so they go into
different mailboxes.
Andrew
^ permalink raw reply
* Re: [PATCH RFC] net/mlx5: check whether VFs are assigned before disabling SR-IOV
From: Jason Gunthorpe @ 2026-04-29 13:57 UTC (permalink / raw)
To: Boone, Max
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DB8CFC33-0929-40F5-86CA-39D1CD84D415@akamai.com>
On Wed, Apr 29, 2026 at 01:29:57PM +0000, Boone, Max wrote:
> > On Tue, Apr 28, 2026 at 08:04:14PM +0200, Max Boone via B4 Relay wrote:
> >> From: Max Boone <mboone@akamai.com>
> >>
> >> When MLX5 cards are passed through to a VM, disabling SR-IOV by
> >> setting the sriov_numvfs to 0 will render the machine unstable.
> >
> > What? How does that happen?
>
> Unstable is maybe a bit confusing phrasing on my part, “locks up”
> might be a better description?
>
> In short:
> - Enable by setting sriov_numvfs to positive
> - vfio-pci passthrough to QEMU (or other process)
> - Disable by setting sriov_numvfs to zero
> - QEMU processes freeze, shell that was writing to sysfs freezes
> - SIGKILL doesn’t seem to have much effect, shutdown never completes
I'm not surprised, but this is definately a bug in VFIO that should be
researched.
And is it right that pci_vfs_assigned() doesn't fix this anyhow since
only Xen activates it?
> Python script to reproduce without QEMU:
> - https://github.com/akamaxb/repro-vfio-sriov-removal/blob/main/vfio-sriov-bind.py
>
> Does:
> 1. Require sriov_numvfs == 0 on the PF (report any existing users and exit if not)
> 2. Add one SR-IOV VF
> 3. Bind the VF to vfio-pci via driver_override + drivers_probe
> 4. Open VFIO container + group, get device fd
> 5. Create a KVM VM (registers an MMU notifier — required to trigger the race)
> 6. Hold and wait for user input
>
> To trigger the bug while the script is waiting, in another terminal:
> echo 0 > /sys/bus/pci/devices/<pf_device>/sriov_numvfs
>
> On the vfio-pci end of it all, it prints these two lines to dmesg before it hangs:
> - https://elixir.bootlin.com/linux/v7.0.1/source/drivers/vfio/pci/vfio_pci_core.c#L1826
The VFIO protocol requires userspace to implement this event channel
and immediately close the VFIO FD when the driver is removed. The vfio
driver unbind sleeps and waits for this. It should not hang the
userspace vfio user, but you will get an unkillable process writing to
the sriov_numvfs sysfs waiting on this.
The above logging shows your test program doesn't implement the
protocol so I don't expect it to work.
vfio currently does not support a kernel lead isolation of its fds.
> - https://elixir.bootlin.com/linux/v7.0.1/source/drivers/vfio/vfio_main.c#L421
And this is the above driver remove is waiting for the FD to close in
response to the event.
qemu is supposed to implement the event protocol, so I don't have a
guess how you get a qemu to become unkillable - that seems to be the
primary bug here. Would be good to know what system call qemu is stuck
inside.
I'd modify your test to implement the event protocol, setup an event
fd to receive an interrupt on VFIO_PCI_REQ_IRQ_INDEX then trigger the
teardown sequence when the eventfd triggers. That would clean out the
basic flow.
Jason
^ permalink raw reply
* Re: [PATCH v4 10/15] drm/msm: Switch to generic PAS TZ APIs
From: Mukesh Ojha @ 2026-04-29 13:59 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg,
Dmitry Baryshkov
In-Reply-To: <20260427095603.1157963-11-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:25:58PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Switch drm/msm client drivers over to generic PAS TZ APIs. Generic PAS
> TZ service allows to support multiple TZ implementation backends like QTEE
> based SCM PAS service, OP-TEE based PAS service and any further future TZ
> backend service.
>
> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
> drivers/gpu/drm/msm/Kconfig | 1 +
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 11 ++++++-----
> 3 files changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gdrivers/gpu/drm/msm/Kconfigpu/drm/msm/Kconfig
> index 250246f81ea9..09469d56513b 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -21,6 +21,7 @@ config DRM_MSM
> select SHMEM
> select TMPFS
> select QCOM_SCM
do we need this ?
> + select QCOM_PAS
> select QCOM_UBWC_CONFIG
> select WANT_DEV_COREDUMP
> select SND_SOC_HDMI_CODEC if SND_SOC
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 79acae11154a..b556da823897 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -5,7 +5,7 @@
> #include <linux/kernel.h>
> #include <linux/types.h>
> #include <linux/cpumask.h>
> -#include <linux/firmware/qcom/qcom_scm.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/pm_opp.h>
> #include <linux/nvmem-consumer.h>
> #include <linux/slab.h>
> @@ -653,7 +653,7 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
> if (adreno_is_a506(adreno_gpu))
> return 0;
>
> - ret = qcom_scm_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
> + ret = qcom_pas_set_remote_state(SCM_GPU_ZAP_SHADER_RESUME, GPU_PAS_ID);
> if (ret)
> DRM_ERROR("%s: zap-shader resume failed: %d\n",
> gpu->name, ret);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 66f80f2d12f9..6d68edf0578c 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -8,6 +8,7 @@
>
> #include <linux/ascii85.h>
> #include <linux/interconnect.h>
> +#include <linux/firmware/qcom/qcom_pas.h>
> #include <linux/firmware/qcom/qcom_scm.h>
do we need this ?
> #include <linux/kernel.h>
> #include <linux/of_reserved_mem.h>
> @@ -146,10 +147,10 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname,
> goto out;
>
> /* Send the image to the secure world */
> - ret = qcom_scm_pas_auth_and_reset(pasid);
> + ret = qcom_pas_auth_and_reset(pasid);
>
> /*
> - * If the scm call returns -EOPNOTSUPP we assume that this target
> + * If the pas call returns -EOPNOTSUPP we assume that this target
> * doesn't need/support the zap shader so quietly fail
> */
> if (ret == -EOPNOTSUPP)
> @@ -175,9 +176,9 @@ int adreno_zap_shader_load(struct msm_gpu *gpu, u32 pasid)
> if (!zap_available)
> return -ENODEV;
>
> - /* We need SCM to be able to load the firmware */
> - if (!qcom_scm_is_available()) {
> - DRM_DEV_ERROR(&pdev->dev, "SCM is not available\n");
> + /* We need PAS to be able to load the firmware */
> + if (!qcom_pas_is_available()) {
> + DRM_DEV_ERROR(&pdev->dev, "Qcom PAS is not available\n");
> return -EPROBE_DEFER;
> }
>
> --
> 2.51.0
>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* [PATCH RFC net-next v3] hsr: Allow to send a specific port and with HSR header
From: Sebastian Andrzej Siewior @ 2026-04-29 14:01 UTC (permalink / raw)
To: netdev
Cc: Andrew Lunn, Chintan Vankar, Danish Anwar, Daolin Qiu,
David S. Miller, Eric Dumazet, Felix Maurer, Jakub Kicinski,
Neelima Muralidharan, Paolo Abeni, Praneeth Bajjuri,
Pratheesh Gangadhar TK, Richard Cochran, Simon Horman,
Vignesh Raghavendra, Willem de Bruijn, Sebastian Andrzej Siewior
HSR forwards all packets it received on slave port 1 to slave port 2 and
one of the two copies to the user (master) interface.
In terms of PTP this is not good because the latency introduced by
forwarding makes the timestamp in the PTP packet inaccurate.
The PTP packets should not forwarded like regular packets.
In order to work with PTP over HSR the following has been done:
- PTP packets which are received are dropped within the HSR stack. That
means they are not forwarded or injected into the master port. If the
user requires them, then they need to be obtained directly from the
SLAVE interface.
- Sending packets. If the ethernet type of the packet is ETH_P_1588 then
the stack assumes a header of type struct hsr_inline_header. The size
of this header is as ethhdr. As a safeguard, the header contains a
magic field which matches the position of h_source and it needs to
match HSR_INLINE_HDR.
Once this is verified, the header contains the port on which this
packet needs to be sent and if system's HSR header should be added.
This information is used with the HSR stack and also attached to skb
as a skb-extension. The packet is then pulled passed the custom header
so the remaining stack will see the actual data.
The skb-extension is needed so that an ethernet driver, with
HSR-offload capabilities, knows that it must not add HSR-header (unless
requested) and send the packet on both ports.
The originally submitted skb is freed and only the (altered) clone is
submitted to the slave interface for sending. Therefore on cloning, the
socket and tx_flags/ tskey are copied so that the PTP timestamp is
forwarded to the submitting socket.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
I am trying to extend linuxptp to support PTP over a HSR network.
This is the kernel side of the changes. In short PTP over HSR sends its
packets to a multicast address and every node needs to forward the PTP
packet (SYNC and FOLLOW-UP for instance) within the HSR ring.
In order to achieve this, the HSR stack must not duplicate and forward
the PTP packets as it would do with other packets. The delay caused by
the duplication and forwarding adds overhead which in turn makes the
timing information within the PTP packet inaccurate.
My current approach is to open the slave devices (eth0/ eth1) from
userland in order to receive the PTP packets. Sending happens from the
hsr0 device. The actual packet can have an optional inline header
prepended of type struct hsr_inline_header. The size of the header is
equivalent to ethhdr. The header has a type (h_proto) at the same
position as ethhdr and expects it to be ETH_P_1588 as this extra meta
information is only relevant for PTP packets. It makes no sense to send
PTP packets via the HSR interface because it gets duplicated and the
timestamp information is lost so this should not break anything. As an
additional safe guard there is a magic value at h_source position. The
value has '0xaf' at the most significant byte which makes the address a
locally administered multicast address.
The header passes two information from userland: On which slave port
the packet has to be sent and does the HSR stack need to prepend a
header or not.
This information is then added to a skb-extension, the header is skipped
so that the remaining stack sees the actual data and then send it as
requested.
The PRP packets are sent directly via the SLAVE interface. The standard
mandates not add a PRP trailer (PRP, redundancy control trailer) to PTP
packets. There not really a reason to use hsr interface.
HSR hardware offloading is optional. If the skb has a HSR skb-extension
then based on the provided information it decides if it is required to
add a HSR-header or send it as-is.
If the extension is not present and the ethernet type is PTP then it
assumes a PRP network and the packet is sent as-is on the requested
port.
This has been tested in a pure software environment and in an HW-assisted
environment where the HW is able to duplicate and duplicate packets
but does not do it for PTP packets.
It has not been tested within an environment where the HW is able to
forward the PTP packet and correctly update the timing information.
---
v2…v3: https://patch.msgid.link/20260309-hsr_ptp-v2-0-798262aad3a4@linutronix.de
- Remove af_packet changes entirely.
- Add an internal header to pass additional information for HSR-PTP
packets.
- Remove PRP, userland will use slave devices directly.
- Drop all received PTP packets. Userland needs to use the slave device
for RX.
v1…v2: https://patch.msgid.link/20260204-hsr_ptp-v1-0-b421c69a77da@linutronix.de
- Added PRP support
- skb extention is used instead of extending struct skb_shared_info
- in af_packet
- packet_sendmsg_spkt() is no longer extended
- jump labels are used to avoid the overhead if there no socket that
is using this HSR extension.
---
include/linux/if_hsr.h | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/skbuff.h | 3 ++
net/core/skbuff.c | 4 +++
net/hsr/Kconfig | 1 +
net/hsr/hsr_device.c | 51 +++++++++++++++++++++++------
net/hsr/hsr_forward.c | 74 +++++++++++++++++++++++++++++++++++++-----
net/hsr/hsr_framereg.h | 1 +
net/hsr/hsr_slave.c | 33 +++++++++++++++----
8 files changed, 229 insertions(+), 25 deletions(-)
diff --git a/include/linux/if_hsr.h b/include/linux/if_hsr.h
index f4cf2dd36d193..220f6e5d7b24c 100644
--- a/include/linux/if_hsr.h
+++ b/include/linux/if_hsr.h
@@ -3,6 +3,7 @@
#define _LINUX_IF_HSR_H_
#include <linux/types.h>
+#include <linux/skbuff.h>
struct net_device;
@@ -22,6 +23,21 @@ enum hsr_port_type {
HSR_PT_PORTS, /* This must be the last item in the enum */
};
+struct hsr_ptp_ext {
+ u8 port;
+ u8 header;
+};
+
+#define HSR_INLINE_HDR 0xaf485352
+struct hsr_inline_header {
+ uint8_t tx_port;
+ uint8_t hsr_hdr;
+ uint8_t __pad0[4];
+ uint32_t magic;
+ uint8_t __pad1[2];
+ uint16_t eth_type;
+} __packed;
+
/* HSR Tag.
* As defined in IEC-62439-3:2010, the HSR tag is really { ethertype = 0x88FB,
* path, LSDU_size, sequence Nr }. But we let eth_header() create { h_dest,
@@ -45,6 +61,60 @@ struct net_device *hsr_get_port_ndev(struct net_device *ndev,
enum hsr_port_type pt);
int hsr_get_port_type(struct net_device *hsr_dev, struct net_device *dev,
enum hsr_port_type *type);
+
+static inline bool hsr_skb_has_header(struct sk_buff *skb)
+{
+ struct hsr_ptp_ext *ptp_ext;
+
+ ptp_ext = skb_ext_find(skb, SKB_EXT_HSR);
+ if (!ptp_ext)
+ return false;
+ return ptp_ext->header;
+}
+
+static inline unsigned int hsr_skb_has_port(struct sk_buff *skb)
+{
+ struct hsr_ptp_ext *ptp_ext;
+
+ if (!skb)
+ return 0;
+
+ ptp_ext = skb_ext_find(skb, SKB_EXT_HSR);
+ if (!ptp_ext)
+ return 0;
+ return ptp_ext->port;
+}
+
+static inline bool hsr_skb_get_header_port(struct sk_buff *skb, bool *header,
+ enum hsr_port_type *port_type)
+{
+ struct hsr_ptp_ext *ptp_ext;
+
+ *port_type = HSR_PT_NONE;
+ *header = false;
+
+ ptp_ext = skb_ext_find(skb, SKB_EXT_HSR);
+ if (!ptp_ext)
+ return false;
+
+ *port_type = ptp_ext->port;
+ *header = ptp_ext->header;
+ return true;
+}
+
+static inline bool hsr_skb_add_header_port(struct sk_buff *skb, bool header,
+ enum hsr_port_type port)
+{
+ struct hsr_ptp_ext *ptp_ext;
+
+ ptp_ext = skb_ext_add(skb, SKB_EXT_HSR);
+ if (!ptp_ext)
+ return false;
+ ptp_ext->port = port;
+ ptp_ext->header = header;
+ return true;
+}
+
#else
static inline bool is_hsr_master(struct net_device *dev)
{
@@ -68,6 +138,23 @@ static inline int hsr_get_port_type(struct net_device *hsr_dev,
{
return -EINVAL;
}
+
+static inline bool hsr_skb_has_header(struct sk_buff *skb)
+{
+ return false;
+}
+
+static inline unsigned int hsr_skb_has_port(struct sk_buff *skb)
+{
+ return 0;
+}
+
+static inline bool hsr_skb_get_header_port(struct sk_buff *skb, bool *header,
+ enum hsr_port_type *port_type)
+{
+ return false;
+}
+
#endif /* CONFIG_HSR */
#endif /*_LINUX_IF_HSR_H_*/
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2bcf78a4de7b9..17918eecaf6cf 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -5030,6 +5030,9 @@ enum skb_ext_id {
#endif
#if IS_ENABLED(CONFIG_CAN)
SKB_EXT_CAN,
+#endif
+#if IS_ENABLED(CONFIG_HSR)
+ SKB_EXT_HSR,
#endif
SKB_EXT_NUM, /* must be last */
};
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7dad68e3b5186..fa0780c4b7d1b 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -60,6 +60,7 @@
#include <linux/errqueue.h>
#include <linux/prefetch.h>
#include <linux/bitfield.h>
+#include <linux/if_hsr.h>
#include <linux/if_vlan.h>
#include <linux/mpls.h>
#include <linux/kcov.h>
@@ -5116,6 +5117,9 @@ static const u8 skb_ext_type_len[] = {
#if IS_ENABLED(CONFIG_CAN)
[SKB_EXT_CAN] = SKB_EXT_CHUNKSIZEOF(struct can_skb_ext),
#endif
+#if IS_ENABLED(CONFIG_HSR)
+ [SKB_EXT_HSR] = SKB_EXT_CHUNKSIZEOF(struct hsr_ptp_ext),
+#endif
};
static __always_inline __no_profile unsigned int skb_ext_total_length(void)
diff --git a/net/hsr/Kconfig b/net/hsr/Kconfig
index fcacdf4f0ffc3..973f8b03aeb11 100644
--- a/net/hsr/Kconfig
+++ b/net/hsr/Kconfig
@@ -5,6 +5,7 @@
config HSR
tristate "High-availability Seamless Redundancy (HSR & PRP)"
+ select SKB_EXTENSIONS
help
This enables IEC 62439 defined High-availability Seamless
Redundancy (HSR) and Parallel Redundancy Protocol (PRP).
diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
index 5555b71ab19b5..ac39b2347aa0f 100644
--- a/net/hsr/hsr_device.c
+++ b/net/hsr/hsr_device.c
@@ -228,20 +228,51 @@ static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, struct net_device *dev)
rcu_read_lock();
master = hsr_port_get_hsr(hsr, HSR_PT_MASTER);
- if (master) {
- skb->dev = master->dev;
- skb_reset_mac_header(skb);
- skb_reset_mac_len(skb);
- spin_lock_bh(&hsr->seqnr_lock);
- hsr_forward_skb(skb, master);
- spin_unlock_bh(&hsr->seqnr_lock);
- } else {
- dev_core_stats_tx_dropped_inc(dev);
- dev_kfree_skb_any(skb);
+ if (!master)
+ goto drop;
+
+ skb->dev = master->dev;
+ if (skb->len > ETH_HLEN * 2) {
+ struct hsr_inline_header *hsr_opt;
+
+ BUILD_BUG_ON(sizeof(struct hsr_inline_header) != sizeof(struct ethhdr));
+ hsr_opt = (struct hsr_inline_header *)skb_mac_header(skb);
+ if (hsr_opt->eth_type == htons(ETH_P_1588) &&
+ hsr_opt->magic == htonl(HSR_INLINE_HDR)) {
+ enum hsr_port_type tx_port;
+ bool has_header;
+
+ has_header = hsr_opt->hsr_hdr;
+ tx_port = hsr_opt->tx_port;
+ if (tx_port != HSR_PT_SLAVE_A && tx_port != HSR_PT_SLAVE_B)
+ goto drop;
+
+ if (!hsr_skb_add_header_port(skb, has_header, tx_port))
+ goto drop;
+
+ skb_pull(skb, ETH_HLEN);
+ if (has_header)
+ skb_set_network_header(skb, ETH_HLEN + HSR_HLEN);
+ else
+ skb_set_network_header(skb, ETH_HLEN);
+ }
}
+
+ skb_reset_mac_header(skb);
+ skb_reset_mac_len(skb);
+ spin_lock_bh(&hsr->seqnr_lock);
+ hsr_forward_skb(skb, master);
+ spin_unlock_bh(&hsr->seqnr_lock);
+
rcu_read_unlock();
return NETDEV_TX_OK;
+
+drop:
+ dev_core_stats_tx_dropped_inc(dev);
+ dev_kfree_skb_any(skb);
+ rcu_read_unlock();
+ return NETDEV_TX_OK;
}
static const struct header_ops hsr_header_ops = {
diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c
index 0aca859c88cbb..3345eb26cd98e 100644
--- a/net/hsr/hsr_forward.c
+++ b/net/hsr/hsr_forward.c
@@ -12,11 +12,25 @@
#include <linux/skbuff.h>
#include <linux/etherdevice.h>
#include <linux/if_vlan.h>
+#include <net/sock.h>
#include "hsr_main.h"
#include "hsr_framereg.h"
struct hsr_node;
+static void hsr_parse_req_master(struct hsr_frame_info *frame,
+ unsigned int *port,
+ bool *header)
+{
+ *port = HSR_PT_NONE;
+ *header = false;
+
+ if (!frame->skb_std)
+ return;
+
+ hsr_skb_get_header_port(frame->skb_std, header, port);
+}
+
/* The uses I can see for these HSR supervision frames are:
* 1) Use the frames that are sent after node initialization ("HSR_TLV.Type =
* 22") to reset any sequence_nr counters belonging to that node. Useful if
@@ -343,7 +357,10 @@ struct sk_buff *hsr_create_tagged_frame(struct hsr_frame_info *frame,
hsr_set_path_id(frame, hsr_ethhdr, port);
return skb_clone(frame->skb_hsr, GFP_ATOMIC);
} else if (port->dev->features & NETIF_F_HW_HSR_TAG_INS) {
- return skb_clone(frame->skb_std, GFP_ATOMIC);
+ skb = skb_clone(frame->skb_std, GFP_ATOMIC);
+ if (hsr_skb_has_port(skb))
+ skb_set_owner_w(skb, frame->skb_std->sk);
+ return skb;
}
/* Create the new skb with enough headroom to fit the HSR tag */
@@ -365,6 +382,15 @@ struct sk_buff *hsr_create_tagged_frame(struct hsr_frame_info *frame,
memmove(dst, src, movelen);
skb_reset_mac_header(skb);
+ if (hsr_skb_has_port(skb)) {
+ /* Packets are bound to a port and the sender may expect time
+ * information.
+ */
+ skb_shinfo(skb)->tx_flags = skb_shinfo(frame->skb_std)->tx_flags;
+ skb_shinfo(skb)->tskey = skb_shinfo(frame->skb_std)->tskey;
+ skb_set_owner_w(skb, frame->skb_std->sk);
+ }
+
/* skb_put_padto free skb on error and hsr_fill_tag returns NULL in
* that case
*/
@@ -420,7 +446,7 @@ static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
static int hsr_xmit(struct sk_buff *skb, struct hsr_port *port,
struct hsr_frame_info *frame)
{
- if (frame->port_rcv->type == HSR_PT_MASTER) {
+ if (frame->port_rcv->type == HSR_PT_MASTER && !frame->has_foreign_header) {
hsr_addr_subst_dest(frame->node_src, skb, port);
/* Address substitution (IEC62439-3 pp 26, 50): replace mac
@@ -518,12 +544,17 @@ bool hsr_drop_frame(struct hsr_frame_info *frame, struct hsr_port *port)
*/
static void hsr_forward_do(struct hsr_frame_info *frame)
{
+ unsigned int req_tx_port;
+ bool req_tx_keep_header;
struct hsr_port *port;
- struct sk_buff *skb;
bool sent = false;
+ hsr_parse_req_master(frame, &req_tx_port, &req_tx_keep_header);
+
hsr_for_each_port(frame->port_rcv->hsr, port) {
struct hsr_priv *hsr = port->hsr;
+ struct sk_buff *skb = NULL;
+
/* Don't send frame back the way it came */
if (port == frame->port_rcv)
continue;
@@ -542,6 +573,19 @@ static void hsr_forward_do(struct hsr_frame_info *frame)
if ((port->dev->features & NETIF_F_HW_HSR_DUP) && sent)
continue;
+ /* PTP TX packets have an outgoing port specified */
+ if (req_tx_port != HSR_PT_NONE && req_tx_port != port->type)
+ continue;
+ /* PTP TX packets may already have a HSR header which needs to
+ * be preserved
+ */
+ if (req_tx_keep_header) {
+ skb = skb_clone(frame->skb_std, GFP_ATOMIC);
+ if (skb)
+ skb_set_owner_w(skb, frame->skb_std->sk);
+ goto inject_into_stack;
+ }
+
/* Don't send frame over port where it has been sent before.
* Also for SAN, this shouldn't be done.
*/
@@ -569,6 +613,7 @@ static void hsr_forward_do(struct hsr_frame_info *frame)
else
skb = hsr->proto_ops->get_untagged_frame(frame, port);
+inject_into_stack:
if (!skb) {
frame->port_rcv->dev->stats.rx_dropped++;
continue;
@@ -633,6 +678,13 @@ int hsr_fill_frame_info(__be16 proto, struct sk_buff *skb,
struct hsr_port *port = frame->port_rcv;
struct hsr_priv *hsr = port->hsr;
+ if (frame->has_foreign_header) {
+ frame->skb_std = skb;
+
+ WARN_ON_ONCE(port->type != HSR_PT_MASTER);
+ WARN_ON_ONCE(skb->mac_len < sizeof(struct hsr_ethhdr));
+ return 0;
+ }
/* HSRv0 supervisory frames double as a tag so treat them as tagged. */
if ((!hsr->prot_version && proto == htons(ETH_P_PRP)) ||
proto == htons(ETH_P_HSR)) {
@@ -697,10 +749,15 @@ static int fill_frame_info(struct hsr_frame_info *frame,
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 */
+ if (hsr_skb_has_header(skb))
+ frame->has_foreign_header = true;
+
+ if (!frame->has_foreign_header) {
+ 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 */
+ }
ethhdr = (struct ethhdr *)skb_mac_header(skb);
frame->is_vlan = false;
@@ -739,7 +796,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.has_foreign_header)
+ 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.h b/net/hsr/hsr_framereg.h
index c65ecb9257348..fc0341b158f67 100644
--- a/net/hsr/hsr_framereg.h
+++ b/net/hsr/hsr_framereg.h
@@ -27,6 +27,7 @@ struct hsr_frame_info {
bool is_local_dest;
bool is_local_exclusive;
bool is_from_san;
+ bool has_foreign_header;
};
void hsr_del_self_node(struct hsr_priv *hsr);
diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c
index d9af9e65f72f0..00aa8d848e2a9 100644
--- a/net/hsr/hsr_slave.c
+++ b/net/hsr/hsr_slave.c
@@ -44,8 +44,7 @@ static rx_handler_result_t hsr_handle_frame(struct sk_buff **pskb)
if (hsr_addr_is_self(port->hsr, eth_hdr(skb)->h_source)) {
/* Directly kill frames sent by ourselves */
- kfree_skb(skb);
- goto finish_consume;
+ goto finish_free_consume;
}
/* For HSR, only tagged frames are expected (unless the device offloads
@@ -64,10 +63,8 @@ static rx_handler_result_t hsr_handle_frame(struct sk_buff **pskb)
skb_reset_mac_header(skb);
if ((!hsr->prot_version && protocol == htons(ETH_P_PRP)) ||
protocol == htons(ETH_P_HSR)) {
- if (!pskb_may_pull(skb, ETH_HLEN + HSR_HLEN)) {
- kfree_skb(skb);
- goto finish_consume;
- }
+ if (!pskb_may_pull(skb, ETH_HLEN + HSR_HLEN))
+ goto finish_free_consume;
skb_set_network_header(skb, ETH_HLEN + HSR_HLEN);
}
@@ -81,10 +78,32 @@ static rx_handler_result_t hsr_handle_frame(struct sk_buff **pskb)
hsr_forward_skb(skb, port);
spin_unlock_bh(&hsr->seqnr_lock);
} else {
+ struct hsr_ethhdr *hsr_ethhdr;
+
+ /* PTP packets are not supposed to be forwarded via HSR as-is.
+ * The latency introduced by forwarding renders the time
+ * information useless. Userland needs to capture the packet on
+ * the original interface instead of hsr.
+ */
+ if ((!hsr->prot_version && protocol == htons(ETH_P_PRP)) ||
+ protocol == htons(ETH_P_HSR)) {
+ /* HSR */
+ hsr_ethhdr = (struct hsr_ethhdr *)skb_mac_header(skb);
+ if (hsr_ethhdr->hsr_tag.encap_proto == htons(ETH_P_1588))
+ goto finish_free_consume;
+ } else {
+ /* PRP */
+ if (protocol == htons(ETH_P_1588))
+ goto finish_free_consume;
+ }
+
hsr_forward_skb(skb, port);
}
-finish_consume:
+ return RX_HANDLER_CONSUMED;
+
+finish_free_consume:
+ kfree_skb(skb);
return RX_HANDLER_CONSUMED;
finish_pass:
---
base-commit: 5e9b7d093f3f77cb0af4409559e3d139babfb443
change-id: 20260204-hsr_ptp-1f6380f1d35f
Best regards,
--
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
^ permalink raw reply related
* Re: [PATCH v4 14/15] firmware: qcom_scm: Remove SCM PAS wrappers
From: Mukesh Ojha @ 2026-04-29 14:04 UTC (permalink / raw)
To: Sumit Garg
Cc: andersson, konradybcio, linux-arm-msm, devicetree, dri-devel,
freedreno, linux-media, netdev, linux-wireless, ath12k,
linux-remoteproc, robh, krzk+dt, conor+dt, robin.clark, sean,
akhilpo, lumag, abhinav.kumar, jesszhan0024, marijn.suijten,
airlied, simona, vikash.garodia, dikshita.agarwal, bod, mchehab,
elder, andrew+netdev, davem, edumazet, kuba, pabeni, jjohnson,
mathieu.poirier, trilokkumar.soni, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg
In-Reply-To: <20260427095603.1157963-15-sumit.garg@kernel.org>
On Mon, Apr 27, 2026 at 03:26:02PM +0530, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
>
> Now since all the Qcom SCM client drivers have been migrated over to
> generic PAS TZ service, let's drop the exported SCM PAS wrappers.
>
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [RFC Patch net-next v2 1/8] r8169: add some register definitions
From: Vadim Fedorenko @ 2026-04-29 14:06 UTC (permalink / raw)
To: javen, hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms
Cc: netdev, linux-kernel
In-Reply-To: <20260429070750.1477-2-javen_xu@realsil.com.cn>
On 29/04/2026 08:07, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> To support rss, this patch adds some macro definitions and register
> definitions.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> ---
> changes in v2:
> - modify the name, avoid using camel names
> - change the name more reasonable, global
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 58 +++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 791277e750ba..4f56f8b420fe 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -77,6 +77,21 @@
> #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
> #define R8169_TX_STOP_THRS (MAX_SKB_FRAGS + 1)
> #define R8169_TX_START_THRS (2 * R8169_TX_STOP_THRS)
> +#define R8169_MAX_RX_QUEUES 8
> +#define R8169_MAX_MSIX_VEC 32
> +#define R8127_MAX_RX_QUEUES 8
> +#define R8127_MAX_IRQ 32
> +#define R8127_MIN_IRQ 30
> +#define RTL_RSS_KEY_SIZE 40
> +#define RSS_CPU_NUM_OFFSET 16
> +#define RSS_MASK_BITS_OFFSET 8
> +#define RTL_MAX_INDIRECTION_TABLE_ENTRIES 128
> +#define RXS_RSS_UDP BIT(27)
> +#define RXS_RSS_IPV4 BIT(28)
> +#define RXS_RSS_IPV6 BIT(29)
> +#define RXS_RSS_TCP BIT(30)
> +#define RXS_RSS_L3_TYPE_MASK (RXS_RSS_IPV4 | RXS_RSS_IPV6)
> +#define RXS_RSS_L4_TYPE_MASK (RXS_RSS_TCP | RXS_RSS_UDP)
You introduce these defines without actual user in patch, all users are
in subsequent patches. It's a bit harder to review, easier way would be
to introduce defines together with users.
^ permalink raw reply
* Re: [RFC Patch net-next v2 2/8] r8169: add support for multi irqs
From: Vadim Fedorenko @ 2026-04-29 14:13 UTC (permalink / raw)
To: javen, hkallweit1, nic_swsd, andrew+netdev, davem, edumazet, kuba,
pabeni, horms
Cc: netdev, linux-kernel
In-Reply-To: <20260429070750.1477-3-javen_xu@realsil.com.cn>
[...]
> static int rtl_alloc_irq(struct rtl8169_private *tp)
> {
> + struct pci_dev *pdev = tp->pci_dev;
> unsigned int flags;
> + int nvecs = 1;
nit: unneeded initialization
>
> switch (tp->mac_version) {
> case RTL_GIGA_MAC_VER_02 ... RTL_GIGA_MAC_VER_06:
> @@ -5402,7 +5519,15 @@ static int rtl_alloc_irq(struct rtl8169_private *tp)
> break;
> }
>
> - return pci_alloc_irq_vectors(tp->pci_dev, 1, 1, flags);
> + nvecs = pci_alloc_irq_vectors(pdev, tp->min_irq_nvecs, tp->max_irq_nvecs, flags);
for RTL8127 you try to allocate 30 to 32 IRQ vectors here...
> +
> + if (nvecs < 0)
> + nvecs = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> +
> + tp->irq = pdev->irq;
> + tp->irq_nvecs = 1;
.. but completely ignores the result here. why?
> +
> + return nvecs;
> }
>
> static void rtl_read_mac_address(struct rtl8169_private *tp,
> @@ -5597,6 +5722,18 @@ static void rtl_hw_initialize(struct rtl8169_private *tp)
> }
> }
>
> +static int rtl8169_set_real_num_queue(struct rtl8169_private *tp)
> +{
> + int retval;
> +
> + retval = netif_set_real_num_tx_queues(tp->dev, 1);
> + if (retval < 0)
> + return retval;
> +
> + retval = netif_set_real_num_rx_queues(tp->dev, tp->num_rx_rings);
> + return retval;
simply
return netif_set_real_num_rx_queues(tp->dev, tp->num_rx_rings);
> +}
> +
> static int rtl_jumbo_max(struct rtl8169_private *tp)
> {
> /* Non-GBit versions don't support jumbo frames */
> @@ -5657,6 +5794,19 @@ static bool rtl_aspm_is_safe(struct rtl8169_private *tp)
> return false;
> }
>
> +static void r8169_init_napi(struct rtl8169_private *tp)
> +{
> + for (int i = 0; i < tp->irq_nvecs; i++) {
> + struct rtl8169_napi *r8169napi = &tp->r8169napi[i];
> + int (*poll)(struct napi_struct *napi, int budget);
> +
> + poll = rtl8169_poll;
> + netif_napi_add(tp->dev, &r8169napi->napi, poll);
> + r8169napi->priv = tp;
> + r8169napi->index = i;
> + }
> +}
> +
> static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> {
> const struct rtl_chip_info *chip;
> @@ -5761,11 +5911,12 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> rtl_hw_reset(tp);
>
> + rtl_software_parameter_initialize(tp);
> +
> rc = rtl_alloc_irq(tp);
> if (rc < 0)
> return dev_err_probe(&pdev->dev, rc, "Can't allocate interrupt\n");
positive rc value (which is the allocated irq vectors) is lost here.
>
> - tp->irq = pci_irq_vector(pdev, 0);
>
> INIT_WORK(&tp->wk.work, rtl_task);
> disable_work(&tp->wk.work);
> @@ -5774,7 +5925,13 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>
> dev->ethtool_ops = &rtl8169_ethtool_ops;
>
> - netif_napi_add(dev, &tp->napi, rtl8169_poll);
> + if (!tp->rss_support) {
> + netif_napi_add(dev, &tp->r8169napi[0].napi, rtl8169_poll);
> + tp->r8169napi[0].priv = tp;
> + tp->r8169napi[0].index = 0;
> + } else {
> + r8169_init_napi(tp);
> + }
>
> dev->hw_features = NETIF_F_IP_CSUM | NETIF_F_RXCSUM |
> NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX;
> @@ -5836,6 +5993,10 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
> if (jumbo_max)
> dev->max_mtu = jumbo_max;
>
> + rc = rtl8169_set_real_num_queue(tp);
> + if (rc < 0)
> + return dev_err_probe(&pdev->dev, rc, "set tx/rx num failure\n");
> +
> rtl_set_irq_mask(tp);
>
> tp->counters = dmam_alloc_coherent (&pdev->dev, sizeof(*tp->counters),
^ permalink raw reply
* Re: [PATCH RFC] net/mlx5: check whether VFs are assigned before disabling SR-IOV
From: Boone, Max @ 2026-04-29 13:29 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260429123833.GM849557@ziepe.ca>
[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]
> On Apr 29, 2026, at 2:38 PM, Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> !-------------------------------------------------------------------|
> This Message Is From an External Sender
> This message came from outside your organization.
> |-------------------------------------------------------------------!
>
> On Tue, Apr 28, 2026 at 08:04:14PM +0200, Max Boone via B4 Relay wrote:
>> From: Max Boone <mboone@akamai.com>
>>
>> When MLX5 cards are passed through to a VM, disabling SR-IOV by
>> setting the sriov_numvfs to 0 will render the machine unstable.
>
> What? How does that happen?
Unstable is maybe a bit confusing phrasing on my part, “locks up”
might be a better description?
In short:
- Enable by setting sriov_numvfs to positive
- vfio-pci passthrough to QEMU (or other process)
- Disable by setting sriov_numvfs to zero
- QEMU processes freeze, shell that was writing to sysfs freezes
- SIGKILL doesn’t seem to have much effect, shutdown never completes
Python script to reproduce without QEMU:
- https://github.com/akamaxb/repro-vfio-sriov-removal/blob/main/vfio-sriov-bind.py
Does:
1. Require sriov_numvfs == 0 on the PF (report any existing users and exit if not)
2. Add one SR-IOV VF
3. Bind the VF to vfio-pci via driver_override + drivers_probe
4. Open VFIO container + group, get device fd
5. Create a KVM VM (registers an MMU notifier — required to trigger the race)
6. Hold and wait for user input
To trigger the bug while the script is waiting, in another terminal:
echo 0 > /sys/bus/pci/devices/<pf_device>/sriov_numvfs
On the vfio-pci end of it all, it prints these two lines to dmesg before it hangs:
- https://elixir.bootlin.com/linux/v7.0.1/source/drivers/vfio/pci/vfio_pci_core.c#L1826
- https://elixir.bootlin.com/linux/v7.0.1/source/drivers/vfio/vfio_main.c#L421
>> -void mlx5_sriov_disable(struct pci_dev *pdev, bool num_vf_change)
>> +int mlx5_sriov_disable(struct pci_dev *pdev, bool num_vf_change)
>> {
>> struct mlx5_core_dev *dev = pci_get_drvdata(pdev);
>> struct devlink *devlink = priv_to_devlink(dev);
>> int num_vfs = pci_num_vf(dev->pdev);
>>
>> + if (pci_vfs_assigned(dev->pdev)) {
>> + mlx5_core_warn(dev, "can't disable sriov, VFs are assigned\n");
>> + return -EPERM;
>> + }
>
> *barf* WTF did this come from?
Hahaha, take your pick:
- https://elixir.bootlin.com/linux/v7.0.1/C/ident/pci_vfs_assigned
I followed the sysfs sriov_numvfs op for a couple drivers and saw
that ixgbe (and others) had it plumbed in, so presumed (sorry)
that this would fix it / was an obvious omission if the rest is doing
it. My bad for cargo culting an artifact from Xen.
> Grep says only Xen makes this true, so this is all working around some
> Xen brokenness in their "assignment" ?
Yeap, I see, looks like it.
> If people care about Xen pci_is_dev_assigned() should be be purged and
> pciback should be fixed to not "make the machine unstable" when it is
> removed during a VF teardown.
>
> Or at the very least this nasty Xen intrustion should be placed in the
> PCI core code and removed from the drivers.
>
> Also, no, you can't fail mlx5_sriov_disable() it is called during
> driver remove and cannot fail in that flow.
Check. I can do some further digging and build a kernel with lockdep
to try and find what it is hanging on specifically. Unless something pops
to mind?
>
> Jason
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3061 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] selftests/net: packetdrill: add tcp_syncookies_ip6_9k
From: Neal Cardwell @ 2026-04-29 14:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, netdev, eric.dumazet
In-Reply-To: <20260429080036.1528533-1-edumazet@google.com>
On Wed, Apr 29, 2026 at 4:00 AM Eric Dumazet <edumazet@google.com> wrote:
>
> This test checks syncookie mode is able to reconstruct some
> client options when TCP TS are used:
>
> - wscale option.
> - sackOK.
> - MSS (in a limited way).
> - ECN (not tested, because of limited value).
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> .../net/packetdrill/tcp_syncookies_ip6_9k.pkt | 30 +++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 tools/testing/selftests/net/packetdrill/tcp_syncookies_ip6_9k.pkt
>
> diff --git a/tools/testing/selftests/net/packetdrill/tcp_syncookies_ip6_9k.pkt b/tools/testing/selftests/net/packetdrill/tcp_syncookies_ip6_9k.pkt
> new file mode 100644
> index 0000000000000000000000000000000000000000..15d03992a99140ecc4241edae58693dc5098fece
> --- /dev/null
> +++ b/tools/testing/selftests/net/packetdrill/tcp_syncookies_ip6_9k.pkt
> @@ -0,0 +1,30 @@
> +// SPDX-License-Identifier: GPL-2.0
> +//
> +// Check syncookies.
> +//
> +// Check we are able to rebuild client sack, wscale and mss options.
> +// IPv6 msstab[4] = { 1280 - 60, 1480 - 60, 1500 - 60, 9000 - 60 }
> +
> +--ip_version=ipv6
> +
> +`./defaults.sh
> +sysctl -q net.ipv4.tcp_syncookies=2
> +ip link set dev tun0 mtu 9000
> +`
> +
> + 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
> + +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> + +0 bind(3, ..., ...) = 0
> + +0 listen(3, 10) = 0
> +
> + +0 < S 0:0(0) win 32792 <mss 8940,sackOK,TS val 100 ecr 0,nop,wscale 10>
> + +0 > S. 0:0(0) ack 1 <mss 8940,sackOK,TS val 4000 ecr 100,nop,wscale 8>
> + +.01 < . 1:1(0) ack 1 win 1024 <nop,nop,TS val 110 ecr 4000>
> +
> + +0 accept(3, ..., ...) = 4
> +
> +// Check we properly infer from the final packet the other peer wanted 8940 mss, wscale 10 and sackOK
> + +0 %{ assert tcpi_snd_mss == 8928, tcpi_snd_mss }%
> + +0 %{ assert tcpi_snd_wscale = 10, tcpi_snd_wscale }%
> + +0 %{ assert (tcpi_options & TCPI_OPT_WSCALE) != 0, tcpi_options }%
The comment mentions checking sackOK but the script does not seem to
do that? Probably want to check the TCPI_OPT_SACK bit as well? Maybe
TCPI_OPT_TIMESTAMPS as well, for completeness?
Thanks for the test!
neal
^ permalink raw reply
* [PATCH nf-next] netfilter: flowtable_offload: propagate CT mark to hardware offload path
From: Lorenzo Bianconi @ 2026-04-29 14:24 UTC (permalink / raw)
To: Pablo Neira Ayuso, Florian Westphal, Phil Sutter, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman
Cc: netfilter-devel, coreteam, netdev, Lorenzo Bianconi
When a user-space process sets the Connection Tracking (CT) mark on a
flow via nft_ct or xt_CONNMARK, that mark should be visible to the
hardware offload path when the flow is accelerated through the flowtable
infrastructure.
Extend the flowtable offload attribute set to include the ct mark field
when it has been explicitly set on the conntrack entry. This info can be
used to fill QoS hw rules for the offloaded traffic.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
net/netfilter/nf_flow_table_offload.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/net/netfilter/nf_flow_table_offload.c b/net/netfilter/nf_flow_table_offload.c
index 002ec15d988b..d5fe35b1a647 100644
--- a/net/netfilter/nf_flow_table_offload.c
+++ b/net/netfilter/nf_flow_table_offload.c
@@ -679,6 +679,22 @@ static int flow_offload_decap_tunnel(const struct flow_offload *flow,
return 0;
}
+static void nf_flow_rule_ct_meta_mark(const struct flow_offload *flow,
+ struct nf_flow_rule *flow_rule)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK_MARK)
+ u32 mark = flow->ct ? READ_ONCE(flow->ct->mark) : 0;
+
+ if (mark) {
+ struct flow_action_entry *entry;
+
+ entry = flow_action_entry_next(flow_rule);
+ entry->id = FLOW_ACTION_CT_METADATA;
+ entry->ct_metadata.mark = mark;
+ }
+#endif /* IS_ENABLED(CONFIG_NF_CONNTRACK_MARK) */
+}
+
static int
nf_flow_rule_route_common(struct net *net, const struct flow_offload *flow,
enum flow_offload_tuple_dir dir,
@@ -747,6 +763,8 @@ int nf_flow_rule_route_ipv4(struct net *net, struct flow_offload *flow,
if (nf_flow_rule_route_common(net, flow, dir, flow_rule) < 0)
return -1;
+ nf_flow_rule_ct_meta_mark(flow, flow_rule);
+
if (test_bit(NF_FLOW_SNAT, &flow->flags)) {
if (flow_offload_ipv4_snat(net, flow, dir, flow_rule) < 0 ||
flow_offload_port_snat(net, flow, dir, flow_rule) < 0)
@@ -776,6 +794,8 @@ int nf_flow_rule_route_ipv6(struct net *net, struct flow_offload *flow,
if (nf_flow_rule_route_common(net, flow, dir, flow_rule) < 0)
return -1;
+ nf_flow_rule_ct_meta_mark(flow, flow_rule);
+
if (test_bit(NF_FLOW_SNAT, &flow->flags)) {
if (flow_offload_ipv6_snat(net, flow, dir, flow_rule) < 0 ||
flow_offload_port_snat(net, flow, dir, flow_rule) < 0)
---
base-commit: 09942ddedcb960f9e78fd817ec33f501d1040c5b
change-id: 20260420-nft-flowtable-priority-6eef902d255a
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH net] net: add net_iov_init() and use it to initialize ->page_type
From: Pavel Begunkov @ 2026-04-29 14:31 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, axboe,
almasrymina, sdf, hawk, akpm, rppt, vbabka, io-uring
In-Reply-To: <20260428025320.853452-1-kuba@kernel.org>
On 4/28/26 03:53, Jakub Kicinski wrote:
> Commit db359fccf212 ("mm: introduce a new page type for page pool in
> page type") added a page_type field to struct net_iov at the same
> offset as struct page::page_type, so that page_pool_set_pp_info() can
> call __SetPageNetpp() uniformly on both pages and net_iovs.
>
> The page-type API requires the field to hold the UINT_MAX "no type"
> sentinel before a type can be set; for real struct page that invariant
> is established by the page allocator on free. struct net_iov is not
> allocated through the page allocator, so the field is left as zero
> (io_uring zcrx, which uses __GFP_ZERO) or as slab garbage (devmem,
> which uses kvmalloc_objs() without zeroing). When the page pool then
> calls page_pool_set_pp_info() on a freshly-bound niov,
> __SetPageNetpp()'s VM_BUG_ON_PAGE(page->page_type != UINT_MAX) fires
> and the kernel BUGs. Triggered in selftests by io_uring zcrx setup
> through the fbnic queue restart path:
Looks good to me,
Acked-by: Pavel Begunkov <asml.silence@gmail.com>
--
Pavel Begunkov
^ permalink raw reply
* Re: [PATCH 5/5] arm64: defconfig: Enable Qualcomm Shikra SoC Global clock controller
From: Krzysztof Kozlowski @ 2026-04-29 14:32 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Richard Cochran
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel, netdev
In-Reply-To: <20260429-shikra-gcc-rpmcc-clks-v1-5-c3cd77558b7a@oss.qualcomm.com>
On 29/04/2026 12:51, Imran Shaik wrote:
> Enable the Global clock controller driver on Qualcomm Shikra EVK board.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> arch/arm64/configs/defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index dd1ac01ee29bf631d517c38486f6896ffd82dcc9..13e04080b37160129ccd47b0148a64277b8e0e4c 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1461,6 +1461,7 @@ CONFIG_CLK_IMX8QXP=y
> CONFIG_CLK_IMX8ULP=y
> CONFIG_CLK_IMX93=y
> CONFIG_CLK_IMX95_BLK_CTL=y
> +CONFIG_CLK_SHIKRA_GCC=y
Beside some really odd order, this patch should not be needed.
Best regards,
Krzysztof
^ 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