* Re: [PATCH v2 3/4] media: rkisp1: use fwnode_graph_for_each_endpoint_scoped() to simplify code
From: Laurent Pinchart @ 2026-06-24 19:16 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li
In-Reply-To: <20260624-fw_scoped-v2-3-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:11PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Use fwnode_graph_for_each_endpoint_scoped() to simplify code.
>
> No functional changes.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Andy: Keep original code because too much break. and I am working on more
> generally solution, so the whole function can be replaced.
> ---
> drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 1791c02a40ae1..f90e01301943c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -187,7 +187,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
> {
> struct v4l2_async_notifier *ntf = &rkisp1->notifier;
> struct fwnode_handle *fwnode = dev_fwnode(rkisp1->dev);
> - struct fwnode_handle *ep;
> unsigned int index = 0;
> int ret = 0;
>
> @@ -195,7 +194,7 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
>
> ntf->ops = &rkisp1_subdev_notifier_ops;
>
> - fwnode_graph_for_each_endpoint(fwnode, ep) {
> + fwnode_graph_for_each_endpoint_scoped(fwnode, ep) {
> struct fwnode_handle *port;
> struct v4l2_fwnode_endpoint vep = { };
> struct rkisp1_sensor_async *rk_asd;
> @@ -286,7 +285,6 @@ static int rkisp1_subdev_notifier_register(struct rkisp1_device *rkisp1)
> }
>
> if (ret) {
> - fwnode_handle_put(ep);
> v4l2_async_nf_cleanup(ntf);
> return ret;
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 1/3] replay: refactor enum replay_mode into a bool
From: Toon Claes @ 2026-06-24 19:15 UTC (permalink / raw)
To: Junio C Hamano, Patrick Steinhardt; +Cc: git, Elijah Newren
In-Reply-To: <xmqq7bnq37jm.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Patrick Steinhardt <ps@pks.im> writes:
>
>> That's fair, and the result is easier to write. But is it really easier
>> to read?
You're bringing up a very valid point there, and not directly in what
you're saying, but how it makes me reconsider.
So we're comparing:
pick_regular_commit(revs->repo, commit, replayed_commits,
mode == REPLAY_MODE_REVERT ? last_commit : onto,
&merge_opt, &result, mode, opts->empty);
with:
pick_regular_commit(revs->repo, commit, replayed_commits,
reverse ? last_commit : onto,
&merge_opt, &result, reverse, opts->empty);
You can argue which of both is easier to read, but the problem isn't
really whether it's a bool or an enum, but the ternary operator in this
lengthy function call is. That is the problem I was trying to solve, and
converting enum to bool isn't really the solution.
>> And what if we ever have to create a third mode going forward?
Personally I find this weak argument. As far as I know we most of the
time do not write code in a way so "it will be ready to add X in the
future". In my personal experience, I'm always wrong in predicting what
might be added in the future. Although I must say this case is
different, because we're not adding something new, no this commit was
dumbing down something existing. So I'll revisit this commit in the next
iteration.
>> I'm generally no fan of booleans as parameters as they basically give
>> you no information at all at the callsite, except if you're lucky and
>> you already have an aptly-named variable available that you can pass.
>> Which seems to be the case here, but I'm still not sure whether this
>> change really improves the code.
That's also a very valid argument, which I didn't take in mind.
> I tend to agree with you on both counts. The "what happens when
> somebody else wants a third choice?" is a quesiton I would ask the
> first thing as the maintainer of a project.
>
> Even if the boolean parameter is so obviously named, the callsite
> can only say "true" or "false", unlike some other popular languages
> that lets you say
>
> my_function(use_revert_mode=true, verbose=false);
>
> and you cannot tell what effect the author wanted out of that "true"
> if all you can write were
>
> my_function(true, false);
>
> Of course, we could go ultra verbose, like
>
> my_function(true, /* use_revert_mode */
> false, /* verbose */);
>
> but then we are often better off writing:
>
> my_function(REPLAY_MODE_REVERT, REPLAY_QUIET);
Thanks for bringing in this illustrative example. Point made, I'll
revisit.
--
Cheers,
Toon
^ permalink raw reply
* Re: [PATCH v2 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: Laurent Pinchart @ 2026-06-24 19:14 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-2-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:10PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
> code.
>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@ EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags)
> {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint) {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
--
Regards,
Laurent Pinchart
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH] misc: fastrpc: ignore unsent and duplicate invoke replies
From: Yousef Alhouseen @ 2026-06-24 19:14 UTC (permalink / raw)
To: Srinivas Kandagatla, Amol Maheshwari
Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-arm-msm, dri-devel,
linux-kernel, Yousef Alhouseen
fastrpc_rpmsg_callback() drops the invoke reference taken before sending
the request. The callback can currently consume a reference for a guessed
context ID before the request has been sent, and duplicate replies can
schedule multiple puts for the same send reference.
Track whether an invoke has been sent and whether a reply has already
been accepted while holding the channel IDR lock. Reject unsent and
duplicate replies so only the first valid response consumes the send
reference.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/misc/fastrpc.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index c91d5da42..4eaecee1b 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -250,6 +250,8 @@ struct fastrpc_invoke_ctx {
uintptr_t *buf_pv;
struct fastrpc_buf_overlap *olaps;
struct fastrpc_channel_ctx *cctx;
+ bool sent;
+ bool completed;
};
struct fastrpc_session_ctx {
@@ -1239,6 +1241,8 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,
struct fastrpc_channel_ctx *cctx;
struct fastrpc_user *fl = ctx->fl;
struct fastrpc_msg *msg = &ctx->msg;
+ unsigned long flags;
+ bool put_ref = true;
int ret;
cctx = fl->cctx;
@@ -1255,10 +1259,23 @@ static int fastrpc_invoke_send(struct fastrpc_session_ctx *sctx,
msg->size = roundup(ctx->msg_sz, PAGE_SIZE);
fastrpc_context_get(ctx);
+ spin_lock_irqsave(&cctx->lock, flags);
+ ctx->sent = true;
+ spin_unlock_irqrestore(&cctx->lock, flags);
+
ret = rpmsg_send(cctx->rpdev->ept, (void *)msg, sizeof(*msg));
- if (ret)
- fastrpc_context_put(ctx);
+ if (ret) {
+ spin_lock_irqsave(&cctx->lock, flags);
+ if (ctx->completed)
+ put_ref = false;
+ else
+ ctx->sent = false;
+ spin_unlock_irqrestore(&cctx->lock, flags);
+
+ if (put_ref)
+ fastrpc_context_put(ctx);
+ }
return ret;
@@ -2586,6 +2603,10 @@ static int fastrpc_rpmsg_callback(struct rpmsg_device *rpdev, void *data,
spin_lock_irqsave(&cctx->lock, flags);
ctx = idr_find(&cctx->ctx_idr, ctxid);
+ if (ctx && (!ctx->sent || ctx->completed))
+ ctx = NULL;
+ if (ctx)
+ ctx->completed = true;
spin_unlock_irqrestore(&cctx->lock, flags);
if (!ctx) {
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] media: mc: use fwnode_graph_for_each_endpoint_scoped() to simpilfy code
From: Laurent Pinchart @ 2026-06-24 19:14 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-2-0a8db472af4a@nxp.com>
On Wed, Jun 24, 2026 at 01:00:10PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Use cleanup helper fwnode_graph_for_each_endpoint_scoped() to simpilfy
> code.
>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/v4l2-core/v4l2-mc.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c b/drivers/media/v4l2-core/v4l2-mc.c
> index 937d358697e19..5d7fcd67dc42e 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -324,12 +324,10 @@ EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
> int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> struct media_pad *sink, u32 flags)
> {
> - struct fwnode_handle *endpoint;
> -
> if (!(sink->flags & MEDIA_PAD_FL_SINK))
> return -EINVAL;
>
> - fwnode_graph_for_each_endpoint(src_sd->fwnode, endpoint) {
> + fwnode_graph_for_each_endpoint_scoped(src_sd->fwnode, endpoint) {
> struct fwnode_handle *remote_ep;
> int src_idx, sink_idx, ret;
> struct media_pad *src;
> @@ -397,7 +395,6 @@ int v4l2_create_fwnode_links_to_pad(struct v4l2_subdev *src_sd,
> src_sd->entity.name, src_idx,
> sink->entity->name, sink_idx, ret);
>
> - fwnode_handle_put(endpoint);
> return ret;
> }
> }
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Laurent Pinchart @ 2026-06-24 19:13 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-1-0a8db472af4a@nxp.com>
Hi Frank,
Thank you for the patch.
On Wed, Jun 24, 2026 at 01:00:09PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new
> version of the loop macro instantiates a new local struct fwnode_handle *
> that uses the __free(fwnode_handle) auto cleanup handling so that if a
> reference to a node is held on early exit from the loop the reference will
> be released. If the loop runs to completion, the child pointer will be NULL
> and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to
> safely disable the auto cleanup.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Nice idea.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> change in v2
> - collect Andy and Guoniu's reviewed-by tags
> - fix indention
> - remove extra space in commit message
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h
> index 14c304db46648..d51824c13d2cc 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child; \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
> + for (struct fwnode_handle *child __free(fwnode_handle) = \
> + fwnode_graph_get_next_endpoint(fwnode, NULL); \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
--
Regards,
Laurent Pinchart
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH] ALSA: hda/realtek: Add quirk for Acer Nitro ANV15-41
From: Oleg4260 @ 2026-06-24 19:13 UTC (permalink / raw)
To: linux-sound; +Cc: tiwai, Oleg Kucheryavenko
From: Oleg Kucheryavenko <oleg.kucheryavenko2018@gmail.com>
The Acer Nitro ANV15-41 laptop with ALC245 codec does not
detect the headset microphone in the combo jack by default.
Apply the ALC2XX_FIXUP_HEADSET_MIC quirk to fix it.
Signed-off-by: Oleg Kucheryavenko <oleg.kucheryavenko2018@gmail.com>
---
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 5d09baa6d32e..2bb42ebb9638 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6812,6 +6812,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1025, 0x169a, "Acer Swift SFG16", ALC256_FIXUP_ACER_SFG16_MICMUTE_LED),
SND_PCI_QUIRK(0x1025, 0x171e, "Acer Nitro ANV15-51", ALC245_FIXUP_ACER_MICMUTE_LED),
SND_PCI_QUIRK(0x1025, 0x173a, "Acer Swift SFG14-73", ALC245_FIXUP_ACER_MICMUTE_LED),
+ SND_PCI_QUIRK(0x1025, 0x1758, "Acer Nitro ANV15-41", ALC2XX_FIXUP_HEADSET_MIC),
SND_PCI_QUIRK(0x1025, 0x1826, "Acer Helios ZPC", ALC287_FIXUP_PREDATOR_SPK_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1025, 0x182c, "Acer Helios ZPD", ALC287_FIXUP_PREDATOR_SPK_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1025, 0x1844, "Acer Helios ZPS", ALC287_FIXUP_PREDATOR_SPK_CS35L41_I2C_2),
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] device property: Introduce fwnode_graph_for_each_endpoint_scoped()
From: Laurent Pinchart @ 2026-06-24 19:13 UTC (permalink / raw)
To: Frank.Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624-fw_scoped-v2-1-0a8db472af4a@nxp.com>
Hi Frank,
Thank you for the patch.
On Wed, Jun 24, 2026 at 01:00:09PM -0400, Frank.Li@oss.nxp.com wrote:
> From: Frank Li <Frank.Li@nxp.com>
>
> Similar to recently propose for_each_child_of_node_scoped() this new
> version of the loop macro instantiates a new local struct fwnode_handle *
> that uses the __free(fwnode_handle) auto cleanup handling so that if a
> reference to a node is held on early exit from the loop the reference will
> be released. If the loop runs to completion, the child pointer will be NULL
> and no action will be taken.
>
> The reason this is useful is that it removes the need for
> fwnode_handle_put() on early loop exits. If there is a need to retain the
> reference, then return_ptr(child) or no_free_ptr(child) may be used to
> safely disable the auto cleanup.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Reviewed-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Nice idea.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> change in v2
> - collect Andy and Guoniu's reviewed-by tags
> - fix indention
> - remove extra space in commit message
> ---
> include/linux/property.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/property.h b/include/linux/property.h
> index 14c304db46648..d51824c13d2cc 100644
> --- a/include/linux/property.h
> +++ b/include/linux/property.h
> @@ -545,6 +545,11 @@ unsigned int fwnode_graph_get_endpoint_count(const struct fwnode_handle *fwnode,
> for (child = fwnode_graph_get_next_endpoint(fwnode, NULL); child; \
> child = fwnode_graph_get_next_endpoint(fwnode, child))
>
> +#define fwnode_graph_for_each_endpoint_scoped(fwnode, child) \
> + for (struct fwnode_handle *child __free(fwnode_handle) = \
> + fwnode_graph_get_next_endpoint(fwnode, NULL); \
> + child; child = fwnode_graph_get_next_endpoint(fwnode, child))
> +
> int fwnode_graph_parse_endpoint(const struct fwnode_handle *fwnode,
> struct fwnode_endpoint *endpoint);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH bpf-next v9 5/5] selftests/bpf: add bpf_icmp_send no route test
From: Emil Tsalapatis @ 2026-06-24 19:13 UTC (permalink / raw)
To: Mahe Tardy, bpf
Cc: andrii, ast, daniel, john.fastabend, jordan, martin.lau,
yonghong.song, emil
In-Reply-To: <20260624185554.362555-6-mahe.tardy@gmail.com>
On Wed Jun 24, 2026 at 2:55 PM EDT, Mahe Tardy wrote:
> For normal live cgroup_skb paths, the skb should already be routed. The
> exception is for test run via BPF_PROG_TEST_RUN with packets created
> via bpf_prog_test_run_skb. Those lack dst route and thus the icmp_send
> would quietly fail by returning early.
>
> This test exercises this and makes sure the kfunc returns -ENETUNREACH.
>
> Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> .../bpf/prog_tests/icmp_send_kfunc.c | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c b/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
> index bb532aa0d158..ffaf0fe1880b 100644
> --- a/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
> +++ b/tools/testing/selftests/bpf/prog_tests/icmp_send_kfunc.c
> @@ -169,6 +169,29 @@ static void run_icmp_test(struct icmp_send *skel, int af, const char *ip,
> }
> }
>
> +static void run_icmp_no_route_test(struct icmp_send *skel)
> +{
> + struct ipv4_packet pkt = pkt_v4;
> + LIBBPF_OPTS(bpf_test_run_opts, opts,
> + .data_in = &pkt,
> + .data_size_in = sizeof(pkt),
> + );
> + int err;
> +
> + pkt.iph.version = 4;
> + pkt.iph.daddr = inet_addr("127.0.0.1");
> + pkt.tcp.dest = htons(80);
> + skel->bss->server_port = 80;
> + skel->bss->unreach_type = ICMP_DEST_UNREACH;
> + skel->bss->unreach_code = ICMP_HOST_UNREACH;
> + skel->data->kfunc_ret = KFUNC_RET_UNSET;
> +
> + err = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.egress), &opts);
> + if (!ASSERT_OK(err, "test_run"))
> + return;
> + ASSERT_EQ(skel->data->kfunc_ret, -ENETUNREACH, "kfunc_ret_no_route");
> +}
> +
> void test_icmp_send_unreach_cgroup(void)
> {
> struct icmp_send *skel;
> @@ -193,6 +216,9 @@ void test_icmp_send_unreach_cgroup(void)
> if (test__start_subtest("ipv6"))
> run_icmp_test(skel, AF_INET6, "::1", ICMPV6_REJECT_ROUTE);
>
> + if (test__start_subtest("no_route"))
> + run_icmp_no_route_test(skel);
> +
> cleanup:
> icmp_send__destroy(skel);
> if (cgroup_fd >= 0)
> --
> 2.34.1
^ permalink raw reply
* [PATCH] vfio/type1: validate dirty bitmap page size before use
From: Yousef Alhouseen @ 2026-06-24 19:12 UTC (permalink / raw)
To: Alex Williamson; +Cc: kvm, linux-kernel, Yousef Alhouseen
The dirty bitmap ioctl paths derive a shift with __ffs() from the
userspace supplied bitmap page size before comparing it with the IOMMU
page size. A zero page size has undefined behavior, and a non-power-of-2
value makes the bitmap size check use a different granularity than the
page size later accepted by the ioctl.
Reject invalid bitmap page sizes before using them in shift arithmetic.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/vfio/vfio_iommu_type1.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index c8151ba54..9499381d0 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -26,6 +26,7 @@
#include <linux/fs.h>
#include <linux/highmem.h>
#include <linux/iommu.h>
+#include <linux/log2.h>
#include <linux/module.h>
#include <linux/mm.h>
#include <linux/kthread.h>
@@ -2949,6 +2950,9 @@ static int vfio_iommu_type1_unmap_dma(struct vfio_iommu *iommu,
if (!access_ok((void __user *)bitmap.data, bitmap.size))
return -EINVAL;
+ if (!is_power_of_2(bitmap.pgsize))
+ return -EINVAL;
+
pgshift = __ffs(bitmap.pgsize);
ret = verify_bitmap_size(unmap.size >> pgshift,
bitmap.size);
@@ -3039,6 +3043,9 @@ static int vfio_iommu_type1_dirty_pages(struct vfio_iommu *iommu,
range.bitmap.size))
return -EINVAL;
+ if (!is_power_of_2(range.bitmap.pgsize))
+ return -EINVAL;
+
pgshift = __ffs(range.bitmap.pgsize);
ret = verify_bitmap_size(size >> pgshift,
range.bitmap.size);
--
2.54.0
^ permalink raw reply related
* [PATCH] bpf: Fix use-after-free in htab elem with bpf_task_work
From: Shengzhuo Wei @ 2026-06-24 19:11 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis,
Mykyta Yatsenko
Cc: Yao Zi, bpf, linux-kernel, Shengzhuo Wei
Deleting a hash map element that embeds a bpf_task_work can trigger a
use-after-free. After removal the element is still read under
rcu_read_lock_trace() -- by BPF programs holding a value pointer (e.g.
inside bpf_task_work_schedule) and by the task_work callback
(ctx->map_val) -- but it is recycled through bpf_mem_cache_free,
pcpu_freelist_push or bpf_lru_push_free with no grace period that waits
for rcu_read_lock_trace() readers. Separately, cancel_and_free() clears
twk->ctx to NULL, the sentinel fetch_ctx() uses for "no ctx yet", which
lets a stale pointer schedule a new callback on the deleted element.
Defer the recycle through call_rcu_tasks_trace(), which waits for
rcu_read_lock_trace() readers; the RCU callback recycles the element
through htab_elem_recycle(), dispatching bpf_mem_cache_free,
pcpu_freelist_push or bpf_lru_push_free by map type.
(bpf_mem_cache_free_rcu() is insufficient: its regular RCU grace period
does not cover rcu_read_lock_trace() readers.)
For the second race, set twk->ctx to ERR_PTR(-EBUSY) instead of NULL, so
fetch_ctx() bails on IS_ERR() and a second cancel_and_free() returns on
IS_ERR_OR_NULL(). Add check_and_init_map_value() in alloc_htab_elem()
and prealloc_lru_pop() to zero the field, since copy_map_value() skips
btf_record fields and a recycled element would otherwise inherit a stale
ERR_PTR(-EBUSY). In htab_map_free(), call rcu_barrier_tasks_trace()
before prealloc_destroy().
The LRU eviction path (htab_lru_map_delete_node) has the same issue but
needs eviction-algorithm changes and is out of scope.
Fixes: 38aa7003e369 ("bpf: task work scheduling kfuncs")
Signed-off-by: Shengzhuo Wei <me@cherr.cc>
---
This fixes a use-after-free that occurs when a hash map element
embedding a bpf_task_work is deleted (or replaced) while a task_work
callback or a BPF program still holds a pointer into it under
rcu_read_lock_trace().
Why KASAN does not catch this on its own: the BPF per-CPU allocator
(bpf_mem_cache, kernel/bpf/memalloc.c) is a custom object pool layered
on top of the slab allocator. Its fast free path, unit_free(), only
does __llist_add() onto a per-CPU free list, so the object is reused by
the next bpf_mem_cache_alloc() on the same CPU with no slab free and
therefore no KASAN quarantine or poisoning. KASAN only re-observes the
object when the cache eventually drains it back to slab (irq_work ->
free_bulk -> __free_rcu, after a grace period), by which point the UAF
window has long since closed. KASAN is thus structurally blind to UAFs
that fit inside the per-CPU free-list reuse window, and "KASAN does not
report it" is not evidence that the bug is absent.
The bug was confirmed by instrumenting the allocator: poison the object
on unit_free() (kasan_mempool_poison_object) and unpoison on
unit_alloc() (kasan_mempool_unpoison_object). With that instrumentation
on the unpatched kernel, KASAN reports a slab-use-after-free in the
bpf_task_work_schedule path (allocated-from track points at htab element
allocation via htab_map_update_elem); on the patched kernel it reports
nothing.
On the fix: call_rcu_tasks_trace() is used directly rather than
bpf_mem_cache_free_rcu(), because the readers that must be covered --
the task_work callback and the BPF programs that access the value --
hold rcu_read_lock_trace(), which a regular RCU grace period does not
wait for.
---
kernel/bpf/hashtab.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++-
kernel/bpf/helpers.c | 9 ++++--
2 files changed, 88 insertions(+), 4 deletions(-)
diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c
index 9f394e1aa2e85be46fa5f12b6a5f5873e450e323..19fa61909e4fed354f754309bc7079b5347f9e01 100644
--- a/kernel/bpf/hashtab.c
+++ b/kernel/bpf/hashtab.c
@@ -310,6 +310,7 @@ static struct htab_elem *prealloc_lru_pop(struct bpf_htab *htab, void *key,
bpf_map_inc_elem_count(&htab->map);
l = container_of(node, struct htab_elem, lru_node);
memcpy(l->key, key, htab->map.key_size);
+ check_and_init_map_value(&htab->map, htab_elem_value(l, htab->map.key_size));
return l;
}
@@ -950,12 +951,69 @@ static int htab_map_get_next_key(struct bpf_map *map, void *key, void *next_key)
return -ENOENT;
}
+/* Deferred htab_elem free for bpf_task_work maps. cancel_and_free()
+ * returns while the task_work callback may still be accessing map_val;
+ * the callback holds guard(rcu_tasks_trace), so deferring the recycle
+ * through call_rcu_tasks_trace() waits for it (and, since a tasks trace
+ * GP implies a regular RCU GP, for BPF value readers too) before the
+ * element is reused. A callback that enters after the GP finds the ctx
+ * already FREED and bails out.
+ */
+struct htab_elem_free_rcu {
+ struct rcu_head rcu;
+ struct bpf_htab *htab;
+ struct htab_elem *elem;
+};
+
+/* Return an htab_elem to its map's free pool: bpf_mem_cache_free for
+ * non-prealloc, pcpu_freelist_push for prealloc, bpf_lru_push_free for
+ * prealloc LRU.
+ */
+static void htab_elem_recycle(struct bpf_htab *htab, struct htab_elem *l)
+{
+ if (htab_is_prealloc(htab)) {
+ if (htab_is_lru(htab))
+ bpf_lru_push_free(&htab->lru, &l->lru_node);
+ else
+ pcpu_freelist_push(&htab->freelist, &l->fnode);
+ } else {
+ bpf_mem_cache_free(&htab->ma, l);
+ }
+}
+
+static void htab_elem_free_rcu_cb(struct rcu_head *head)
+{
+ struct htab_elem_free_rcu *fr = container_of(head, struct htab_elem_free_rcu, rcu);
+
+ htab_elem_recycle(fr->htab, fr->elem);
+ kfree(fr);
+}
+
+static void htab_elem_defer_free(struct bpf_htab *htab, struct htab_elem *l)
+{
+ struct htab_elem_free_rcu *fr;
+
+ fr = kmalloc_obj(*fr, GFP_ATOMIC);
+ if (WARN_ON_ONCE(!fr)) {
+ /* Fallback: immediate recycle, small UAF risk */
+ htab_elem_recycle(htab, l);
+ return;
+ }
+ fr->htab = htab;
+ fr->elem = l;
+ call_rcu_tasks_trace(&fr->rcu, htab_elem_free_rcu_cb);
+}
+
static void htab_elem_free(struct bpf_htab *htab, struct htab_elem *l)
{
check_and_cancel_fields(htab, l);
if (htab->map.map_type == BPF_MAP_TYPE_PERCPU_HASH)
bpf_mem_cache_free(&htab->pcpu_ma, l->ptr_to_pptr);
+ if (btf_record_has_field(htab->map.record, BPF_TASK_WORK)) {
+ htab_elem_defer_free(htab, l);
+ return;
+ }
bpf_mem_cache_free(&htab->ma, l);
}
@@ -1006,6 +1064,10 @@ static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l)
if (htab_is_prealloc(htab)) {
bpf_map_dec_elem_count(&htab->map);
check_and_cancel_fields(htab, l);
+ if (btf_record_has_field(htab->map.record, BPF_TASK_WORK)) {
+ htab_elem_defer_free(htab, l);
+ return;
+ }
pcpu_freelist_push(&htab->freelist, &l->fnode);
} else {
dec_elem_count(htab);
@@ -1118,6 +1180,11 @@ static struct htab_elem *alloc_htab_elem(struct bpf_htab *htab, void *key,
}
memcpy(l_new->key, key, key_size);
+ /* Re-initialize special fields for recycled elements. copy_map_value()
+ * skips btf_record fields, so a stale ERR_PTR(-EBUSY) left by
+ * bpf_task_work_cancel_and_free would persist and block new scheduling.
+ */
+ check_and_init_map_value(&htab->map, htab_elem_value(l_new, key_size));
if (percpu) {
if (prealloc) {
pptr = htab_elem_get_ptr(l_new, key_size);
@@ -1275,6 +1342,10 @@ static void htab_lru_push_free(struct bpf_htab *htab, struct htab_elem *elem)
{
check_and_cancel_fields(htab, elem);
bpf_map_dec_elem_count(&htab->map);
+ if (btf_record_has_field(htab->map.record, BPF_TASK_WORK)) {
+ htab_elem_defer_free(htab, elem);
+ return;
+ }
bpf_lru_push_free(&htab->lru, &elem->lru_node);
}
@@ -1641,9 +1712,19 @@ static void htab_map_free(struct bpf_map *map)
delete_all_elements(htab);
} else {
htab_free_prealloced_fields(htab);
- prealloc_destroy(htab);
}
+ /* For bpf_task_work maps, element frees defer recycling through
+ * call_rcu_tasks_trace() so running callbacks finish before reuse.
+ * Wait for any in-flight deferred recycles here, before the
+ * freelist/LRU and element memory are torn down.
+ */
+ if (btf_record_has_field(htab->map.record, BPF_TASK_WORK))
+ rcu_barrier_tasks_trace();
+
+ if (htab_is_prealloc(htab))
+ prealloc_destroy(htab);
+
bpf_map_free_elem_count(map);
free_percpu(htab->extra_elems);
bpf_map_area_free(htab->buckets);
diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index c18f1e16edee4cd864bdb4f2d1a526f2ab0c54f6..07088ac1f0b2d95f1e790cfc4db779bc5acbf8db 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -4454,7 +4454,10 @@ static void bpf_task_work_callback(struct callback_head *cb)
u32 idx;
void *key;
- /* Read lock is needed to protect ctx and map key/value access */
+ /* Hold rcu_read_lock_trace so that call_rcu_tasks_trace() in
+ * htab_elem_defer_free() waits for this callback to finish before
+ * recycling the htab_elem.
+ */
guard(rcu_tasks_trace)();
/*
* This callback may start running before bpf_task_work_irq() switched to
@@ -4784,8 +4787,8 @@ void bpf_task_work_cancel_and_free(void *val)
struct bpf_task_work_ctx *ctx;
enum bpf_task_work_state state;
- ctx = xchg(&twk->ctx, NULL);
- if (!ctx)
+ ctx = xchg(&twk->ctx, ERR_PTR(-EBUSY));
+ if (IS_ERR_OR_NULL(ctx))
return;
state = xchg(&ctx->state, BPF_TW_FREED);
---
base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
change-id: 20260625-bpf-htab-task-work-uaf-4621a6b8d928
Best regards,
--
Shengzhuo Wei <me@cherr.cc>
^ permalink raw reply related
* Re: [PATCH] misc: fastrpc: reject oversized inline invoke payloads
From: sashiko-bot @ 2026-06-24 19:12 UTC (permalink / raw)
To: Yousef Alhouseen; +Cc: dri-devel
In-Reply-To: <20260624185549.1669-1-alhouseenyousef@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Integer overflow in `fastrpc_get_payload_size()` accumulator leads to undersized DMA buffer and massive heap out-of-bounds write.
- [Critical] Heap buffer underflow via overlaps between mapped and unmapped buffers in `fastrpc_get_buff_overlaps()`.
- [High] SMMU isolation bypass via unverified VMA offset calculations.
- [High] Resource leak of `fastrpc_map` objects and DMA attachments for input/output handles.
- [High] Implicit integer truncation to heap buffer overflow on 32-bit architectures.
--
commit a53ab016dbb10f6c8573b1c5e13acf7acf361b1d
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
misc: fastrpc: reject oversized inline invoke payloads
fastrpc_get_args() computes inline payload spans from 64-bit user
buffer ranges, but stores each span in an int before comparing it with
the remaining DMA buffer space. A large span can truncate before the bounds
check and advance the DMA write cursor by the wrong amount. This patch keeps
the span 64-bit and fails the invoke when the serialized payload would exceed
the buffer.
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index f3a49384586d1..c60bab4f45c01 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -1067,7 +1067,7 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
> ctx->rpra = rpra;
>
> for (oix = 0; oix < ctx->nbufs; ++oix) {
> - int mlen;
> + u64 mlen;
[Severity: High]
This isn't a bug introduced by this patch, but does the use of 64-bit sizes
lead to truncation issues on 32-bit architectures?
When pkt_size is passed to dma_alloc_coherent() via __fastrpc_buf_alloc(),
the 64-bit size is implicitly truncated to a 32-bit size_t. This can result
in a small kernel allocation for values exceeding 4GB.
The bounds checks use the untruncated 64-bit lengths, and copy_from_user()
will truncate the 64-bit len to a 32-bit unsigned long. Could coordinating
these lengths to wrap around the 32-bit boundary cause copy_from_user() to
copy a large payload into the truncated DMA buffer allocation?
>
> i = ctx->olaps[oix].raix;
> len = ctx->args[i].length;
[Severity: High]
This is a pre-existing issue, but is there a risk of SMMU isolation bypass
for mapped buffers?
For mapped DMA buffers, fastrpc_get_args() computes the physical address
offset by subtracting the VMA start address:
drivers/misc/fastrpc.c:fastrpc_get_args() {
...
vma = vma_lookup(current->mm, ctx->args[i].ptr);
if (vma)
pages[i].addr += (ctx->args[i].ptr & PAGE_MASK) -
vma->vm_start;
...
}
Does the code verify that the resolved VMA actually corresponds to the
underlying dma_buf, or that offset + len is within the map's size? If not,
could an attacker forge an arbitrary IOVA offset using a large anonymous VMA
to read or write arbitrary memory mapped within the shared SMMU domain?
[ ... ]
> @@ -1107,8 +1107,10 @@ static int fastrpc_get_args(u32 kernel, struct fastrpc_invoke_ctx *ctx)
>
> mlen = ctx->olaps[oix].mend - ctx->olaps[oix].mstart;
>
> - if (rlen < mlen)
> + if (rlen < mlen) {
> + err = -EOVERFLOW;
> goto bail;
[Severity: Critical]
This is a pre-existing issue, but does rlen bypass this check if pkt_size
wraps around and rlen underflows?
In fastrpc_get_payload_size(), size accumulates the buffer lengths without
checking for wrap-around. An attacker could supply lengths such that the sum
exceeds U64_MAX, resulting in a small positive pkt_size and causing an
undersized DMA allocation.
Then in fastrpc_get_args():
rlen = pkt_size - metalen;
If pkt_size is smaller than metalen, rlen underflows to a massive 64-bit
value, which trivially bypasses this rlen < mlen check. Could this lead to
copy_from_user() copying the untruncated len into the undersized heap
allocation?
[Severity: High]
This is a pre-existing issue, but could this early exit leak DMA map
attachments for scalar handles?
In fastrpc_create_maps(), map objects are created and attached for all
arguments up to ctx->nscalars. However, when the context is freed:
drivers/misc/fastrpc.c:fastrpc_context_free() {
...
for (i = 0; i < ctx->nbufs; i++)
fastrpc_map_put(ctx->maps[i]);
...
}
The cleanup loop only iterates up to ctx->nbufs, failing to drop references
for handle maps (i >= ctx->nbufs). If this goto bail is hit, do the maps for
scalar handles remain pinned in the user process's list, potentially
exhausting kernel memory and DMA allocations?
> + }
>
> rpra[i].buf.pv = args - ctx->olaps[oix].offset;
[Severity: Critical]
This is a pre-existing issue, but can this address underflow to a location
before the allocated heap buffer?
If fastrpc_get_buff_overlaps() processes an unmapped inline buffer that
overlaps entirely within a preceding mapped buffer, it sets mstart and
mend to 0, and offset to the distance from the mapped buffer's start.
Because args would not have advanced for this buffer, could subtracting
offset from args here result in an address pointing before
ctx->buf->virt, leading to an out-of-bounds write when copy_from_user()
is called later in fastrpc_get_args()?
> pages[i].addr = ctx->buf->dma_addr -
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624185549.1669-1-alhouseenyousef@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH bpf-next v9 1/5] bpf: add bpf_icmp_send kfunc
From: Emil Tsalapatis @ 2026-06-24 19:10 UTC (permalink / raw)
To: Mahe Tardy, bpf
Cc: andrii, ast, daniel, john.fastabend, jordan, martin.lau,
yonghong.song, emil
In-Reply-To: <20260624185554.362555-2-mahe.tardy@gmail.com>
On Wed Jun 24, 2026 at 2:55 PM EDT, Mahe Tardy wrote:
> This is needed in the context of Tetragon to provide improved feedback
> (in contrast to just dropping packets) to east-west traffic when blocked
> by policies using cgroup_skb programs.
>
> This reuses concepts from netfilter reject target codepath with the
> differences that:
> * Packets are cloned since the BPF user can still let the packet pass
> (SK_PASS from the cgroup_skb progs for example) and the current skb
> need to stay untouched (cgroup_skb hooks only allow read-only skb
> payload).
> * We protect against recursion since the kfunc, by generating an ICMP
> error message, could retrigger the BPF prog that invoked it.
>
> Only ICMP_DEST_UNREACH and ICMPV6_DEST_UNREACH are currently supported.
> The interface accepts a type parameter to facilitate future extension to
> other ICMP control message types.
>
> Signed-off-by: Mahe Tardy <mahe.tardy@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
> ---
> net/core/filter.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/net/core/filter.c b/net/core/filter.c
> index 2e96b4b847ce..f3aa494ed105 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
> @@ -84,6 +84,9 @@
> #include <linux/un.h>
> #include <net/xdp_sock_drv.h>
> #include <net/inet_dscp.h>
> +#include <linux/icmpv6.h>
> +#include <net/icmp.h>
> +#include <net/ip6_route.h>
>
> #include "dev.h"
>
> @@ -12546,6 +12549,84 @@ __bpf_kfunc int bpf_xdp_pull_data(struct xdp_md *x, u32 len)
> return 0;
> }
>
> +/**
> + * bpf_icmp_send - Send an ICMP control message
> + * @skb_ctx: Packet that triggered the control message
> + * @type: ICMP type (only ICMP_DEST_UNREACH/ICMPV6_DEST_UNREACH supported)
> + * @code: ICMP code (0-15 except ICMP_FRAG_NEEDED for IPv4, 0-6 for IPv6)
> + *
> + * Sends an ICMP control message in response to the packet. The original packet
> + * is cloned before sending the ICMP message, so the BPF program can still let
> + * the packet pass if desired.
> + *
> + * Currently only ICMP_DEST_UNREACH (IPv4) and ICMPV6_DEST_UNREACH (IPv6) are
> + * supported.
> + *
> + * Return: 0 on success (send attempt), negative error code on failure:
> + * -EBUSY: Recursion detected
> + * -EPROTONOSUPPORT: Non-IP protocol
> + * -EOPNOTSUPP: Unsupported ICMP type
> + * -EINVAL: Invalid code parameter
> + * -ENETUNREACH: Unusable IPv4 route/dst attached to the skb
> + * -ENOMEM: Memory allocation failed
> + */
> +__bpf_kfunc int bpf_icmp_send(struct __sk_buff *skb_ctx, int type, int code)
> +{
> + struct sk_buff *skb = (struct sk_buff *)skb_ctx;
> + struct sk_buff *nskb;
> + struct sock *sk;
> +
> + sk = skb_to_full_sk(skb);
> + if (sk && sk->sk_kern_sock &&
> + (sk->sk_protocol == IPPROTO_ICMP || sk->sk_protocol == IPPROTO_ICMPV6))
> + return -EBUSY;
> +
> + switch (skb->protocol) {
> +#if IS_ENABLED(CONFIG_INET)
> + case htons(ETH_P_IP): {
> + if (type != ICMP_DEST_UNREACH)
> + return -EOPNOTSUPP;
> + if (code < 0 || code > NR_ICMP_UNREACH ||
> + code == ICMP_FRAG_NEEDED) /* needs a valid next-hop MTU */
> + return -EINVAL;
> +
> + /* icmp_send requires a rtable; test-run synthetic skbs lack one. */
> + if (!skb_valid_dst(skb))
> + return -ENETUNREACH;
> +
> + nskb = skb_clone(skb, GFP_ATOMIC);
> + if (!nskb)
> + return -ENOMEM;
> +
> + memset(IPCB(nskb), 0, sizeof(*IPCB(nskb)));
> + icmp_send(nskb, type, code, 0);
> + consume_skb(nskb);
> + break;
> + }
> +#endif
> +#if IS_ENABLED(CONFIG_IPV6)
> + case htons(ETH_P_IPV6):
> + if (type != ICMPV6_DEST_UNREACH)
> + return -EOPNOTSUPP;
> + if (code < 0 || code > ICMPV6_REJECT_ROUTE)
> + return -EINVAL;
> +
> + nskb = skb_clone(skb, GFP_ATOMIC);
> + if (!nskb)
> + return -ENOMEM;
> +
> + memset(IP6CB(nskb), 0, sizeof(*IP6CB(nskb)));
> + icmpv6_send(nskb, type, code, 0);
> + consume_skb(nskb);
> + break;
> +#endif
> + default:
> + return -EPROTONOSUPPORT;
> + }
> +
> + return 0;
> +}
> +
> __bpf_kfunc_end_defs();
>
> int bpf_dynptr_from_skb_rdonly(struct __sk_buff *skb, u64 flags,
> @@ -12588,6 +12669,10 @@ BTF_KFUNCS_START(bpf_kfunc_check_set_sock_ops)
> BTF_ID_FLAGS(func, bpf_sock_ops_enable_tx_tstamp)
> BTF_KFUNCS_END(bpf_kfunc_check_set_sock_ops)
>
> +BTF_KFUNCS_START(bpf_kfunc_check_set_icmp_send)
> +BTF_ID_FLAGS(func, bpf_icmp_send)
> +BTF_KFUNCS_END(bpf_kfunc_check_set_icmp_send)
> +
> static const struct btf_kfunc_id_set bpf_kfunc_set_skb = {
> .owner = THIS_MODULE,
> .set = &bpf_kfunc_check_set_skb,
> @@ -12618,6 +12703,11 @@ static const struct btf_kfunc_id_set bpf_kfunc_set_sock_ops = {
> .set = &bpf_kfunc_check_set_sock_ops,
> };
>
> +static const struct btf_kfunc_id_set bpf_kfunc_set_icmp_send = {
> + .owner = THIS_MODULE,
> + .set = &bpf_kfunc_check_set_icmp_send,
> +};
> +
> static int __init bpf_kfunc_init(void)
> {
> int ret;
> @@ -12639,6 +12729,7 @@ static int __init bpf_kfunc_init(void)
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
> &bpf_kfunc_set_sock_addr);
> ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SCHED_CLS, &bpf_kfunc_set_tcp_reqsk);
> + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_CGROUP_SKB, &bpf_kfunc_set_icmp_send);
> return ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_SOCK_OPS, &bpf_kfunc_set_sock_ops);
> }
> late_initcall(bpf_kfunc_init);
> --
> 2.34.1
^ permalink raw reply
* Re: [RFC PATCH 2/4] dma/pool: Add an API to check if DMA allocation is from pool
From: Samiullah Khawaja @ 2026-06-24 19:10 UTC (permalink / raw)
To: Pranjal Shrivastava
Cc: Marek Szyprowski, Will Deacon, Jason Gunthorpe, Pasha Tatashin,
Mike Rapoport, Pratyush Yadav, Alexander Graf, Robin Murphy,
Kevin Tian, iommu, kexec, linux-mm, linux-kernel, David Matlack,
Andrew Morton, Vipin Sharma
In-Reply-To: <aicFes0uxUFQAduC@google.com>
On Mon, Jun 08, 2026 at 06:10:02PM +0000, Pranjal Shrivastava wrote:
>On Tue, May 05, 2026 at 12:27:35AM +0000, Samiullah Khawaja wrote:
>> DMA allocations can be done through DMA pools, add an API that can be
>> used to check if an allocation is done from a pool. This will be used in
>> the later commit during preservation of DMA allocation.
>>
>> Signed-off-by: Samiullah Khawaja <skhawaja@google.com>
>> ---
>> include/linux/dma-map-ops.h | 1 +
>> kernel/dma/pool.c | 13 +++++++++++++
>> 2 files changed, 14 insertions(+)
>>
>> diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
>> index 6a1832a73cad..6a0bc4ea2467 100644
>> --- a/include/linux/dma-map-ops.h
>> +++ b/include/linux/dma-map-ops.h
>> @@ -216,6 +216,7 @@ struct page *dma_alloc_from_pool(struct device *dev, size_t size,
>> bool (*phys_addr_ok)(struct device *, phys_addr_t, size_t));
>> bool dma_free_from_pool(struct device *dev, void *start, size_t size);
>>
>> +bool dma_is_from_pool(struct device *dev, void *start, size_t size);
>> int dma_direct_set_offset(struct device *dev, phys_addr_t cpu_start,
>> dma_addr_t dma_start, u64 size);
>>
>> diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
>> index 2b2fbb709242..32ce4d6d7683 100644
>> --- a/kernel/dma/pool.c
>> +++ b/kernel/dma/pool.c
>> @@ -307,3 +307,16 @@ bool dma_free_from_pool(struct device *dev, void *start, size_t size)
>>
>> return false;
>> }
>> +
>> +bool dma_is_from_pool(struct device *dev, void *start, size_t size)
>
>Do we need struct device here? It seems unused?
>
>Nit: we only ever pass 0 gfp_flags to dma_guess_pool, should we instead
>name it: dma_is_from_atomic_pool() to be more accurate?
dma_guess_pool() goes through all of them when passing 0, look at the
prev logic inside it and how it is used by the dma_free_from_pool(). But
you are right they are all atomic, but semantically we want to check
whether it is part of any pool so lets keep it as is. WDYT?
>
>> +{
>> + struct gen_pool *pool = NULL;
>> +
>> + while ((pool = dma_guess_pool(pool, 0))) {
>> + if (!gen_pool_has_addr(pool, (unsigned long)start, size))
>> + continue;
>> + return true;
>> + }
>
>Nit: The loop looks slightly ugly, can we have:
>
>struct gen_pool *pool;
>
>for (pool = dma_guess_pool(NULL, 0); pool != NULL; pool = dma_guess_pool(pool, 0)) {
> if (gen_pool_has_addr(pool, (unsigned long)start, size))
> return true;
>}
It is a basically a copy dma_free_from_pool() without the free part, so
keeping the style consistent.
>
>> +
>> + return false;
>> +}
>> --
>> 2.54.0.545.g6539524ca2-goog
>>
>
>Thanks,
>Praan
Thanks,
Sami
^ permalink raw reply
* Re: [PATCH] misc: fastrpc: initialize invoke refcount before publish
From: sashiko-bot @ 2026-06-24 19:10 UTC (permalink / raw)
To: Yousef Alhouseen; +Cc: dri-devel
In-Reply-To: <20260624185427.1451-1-alhouseenyousef@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [Critical] The patch transforms a refcount underflow warning into an exploitable Use-After-Free (UAF) and list corruption by prematurely freeing the context on an early DSP response.
Pre-existing issues:
- [Critical] `fastrpc_rpmsg_callback()` is vulnerable to duplicate or late DSP responses, leading to Use-After-Free vulnerabilities.
- [High] If `fastrpc_internal_invoke()` is interrupted by a signal or times out, the `fastrpc_invoke_ctx` and its associated `fastrpc_user` are permanently leaked, leading to local DoS.
- [High] When the DSP crashes or is removed, pending `fastrpc_invoke_ctx` objects are permanently leaked.
--
commit 285340b375fb7017cf7735f77379c860ac74a67c
Author: Yousef Alhouseen <alhouseenyousef@gmail.com>
misc: fastrpc: initialize invoke refcount before publish
fastrpc_context_alloc() adds a new invoke context to the pending list
and the channel IDR before initializing its refcount. Initialize the
refcount before publishing the context to prevent a racing DSP
response from dropping a reference before kref_init() has run.
> diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
> index f3a49384586d1..9f2929cb39d93 100644
> --- a/drivers/misc/fastrpc.c
> +++ b/drivers/misc/fastrpc.c
> @@ -690,6 +690,7 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
> ctx->cctx = cctx;
> init_completion(&ctx->work);
> INIT_WORK(&ctx->put_work, fastrpc_context_put_wq);
> + kref_init(&ctx->refcount);
>
> spin_lock(&user->lock);
> list_add_tail(&ctx->node, &user->pending);
> @@ -705,8 +706,6 @@ static struct fastrpc_invoke_ctx *fastrpc_context_alloc(
> ctx->ctxid = ret << 4;
[Severity: Critical]
By moving kref_init() before idr_alloc_cyclic(), does this introduce a
Use-After-Free?
If a delayed or duplicate DSP response arrives immediately after
idr_alloc_cyclic() returns, fastrpc_rpmsg_callback() can find the context
in the IDR and schedule put_work. This would drop the refcount to 0,
prematurely freeing the context while the allocating thread continues execution:
drivers/misc/fastrpc.c:fastrpc_context_alloc() {
...
kref_init(&ctx->refcount);
...
ret = idr_alloc_cyclic(&cctx->ctx_idr, ctx, ...);
// DSP response arrives here, drops the only reference, freeing ctx
ctx->ctxid = ret << 4; // Use-After-Free
}
Prior to this change, the uninitialized refcount prevented the free.
> spin_unlock_irqrestore(&cctx->lock, flags);
>
> - kref_init(&ctx->refcount);
> -
> return ctx;
[Severity: Critical]
This is a pre-existing issue, but is fastrpc_rpmsg_callback() vulnerable to
duplicate or late DSP responses?
When a response arrives, it looks up the context and blindly schedules put_work
without checking if a response is expected or removing the context from the IDR:
drivers/misc/fastrpc.c:fastrpc_rpmsg_callback() {
...
ctx = idr_find(&cctx->ctx_idr, ctxid);
...
schedule_work(&ctx->put_work);
}
If a faulty DSP sends multiple responses for the same ID, could this schedule
put_work multiple times and lead to a Use-After-Free?
[Severity: High]
This isn't a bug introduced by this patch, but does fastrpc_internal_invoke()
leak the context on signals or timeouts?
If wait_for_completion_interruptible() returns -ERESTARTSYS or -ETIMEDOUT, the
error path intentionally bypasses dropping the context reference:
drivers/misc/fastrpc.c:fastrpc_internal_invoke() {
...
if (err != -ERESTARTSYS && err != -ETIMEDOUT) {
spin_lock(&fl->lock);
list_del(&ctx->node);
spin_unlock(&fl->lock);
fastrpc_context_put(ctx);
}
}
Since fastrpc_context_alloc() takes a reference on fastrpc_user, does this
create a permanent reference cycle that prevents fastrpc_user_free() from ever
being called, potentially allowing an unprivileged user to exhaust IDR slots?
[Severity: High]
This is a pre-existing issue, but are pending contexts permanently leaked when
the DSP crashes or is removed?
fastrpc_invoke_send() takes a reference on the context on behalf of the DSP:
drivers/misc/fastrpc.c:fastrpc_invoke_send() {
...
fastrpc_context_get(ctx);
ret = rpmsg_send(...);
}
When the DSP is removed, fastrpc_rpmsg_remove() notifies users but doesn't
appear to drop this extra reference:
drivers/misc/fastrpc.c:fastrpc_rpmsg_remove() {
...
list_for_each_entry(user, &cctx->users, user)
fastrpc_notify_users(user);
}
Since the DSP will never respond, does this leave the in-flight contexts and
their parent structures permanently leaked?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624185427.1451-1-alhouseenyousef@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] drm/amdgpu: fix atomics on gfx1301
From: Eric Huang @ 2026-06-24 19:09 UTC (permalink / raw)
To: amd-gfx; +Cc: David.Belanger
In-Reply-To: <20260624190702.596001-1-jinhuieric.huang@amd.com>
please ignore it.
On 2026-06-24 15:07, Eric Huang wrote:
> gfx13 needs to program DF config register as gfx12, so
> share the function of gfx12, they have the same register
> layout.
>
> Signed-off-by: Eric Huang <jinhuieric.huang@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 055cc4f1c861..56a7764f3f8f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -3385,6 +3385,7 @@ int amdgpu_discovery_set_ip_blocks(struct amdgpu_device *adev)
> break;
> case IP_VERSION(4, 15, 0):
> case IP_VERSION(4, 15, 1):
> + case IP_VERSION(5, 0, 2):
> adev->df.funcs = &df_v4_15_funcs;
> break;
> default:
^ permalink raw reply
* [PATCH v4 19/19] arm64: dts: qcom: sdm845: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 4ae8627d6dbc..2179988dbaaf 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -363,6 +363,7 @@ cluster_sleep_0: cluster-sleep-0 {
firmware {
scm {
compatible = "qcom,scm-sdm845", "qcom,scm";
+ sram = <&minidump_config>;
};
};
@@ -5192,6 +5193,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x40000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3d000 {
reg = <0x3d000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 18/19] arm64: dts: qcom: qcs615: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index fb1bbc51bb8a..a358d5441fa9 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -473,6 +473,7 @@ firmware {
scm {
compatible = "qcom,scm-qcs615", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -4654,6 +4655,10 @@ sram@14680000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@2a94c {
compatible = "qcom,pil-reloc-info";
reg = <0x2a94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 17/19] arm64: dts: qcom: sm6375: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6375.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6375.dtsi b/arch/arm64/boot/dts/qcom/sm6375.dtsi
index ccf572bb1549..71a228597093 100644
--- a/arch/arm64/boot/dts/qcom/sm6375.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6375.dtsi
@@ -307,6 +307,7 @@ scm {
compatible = "qcom,scm-sm6375", "qcom,scm";
clocks = <&rpmcc RPM_SMD_CE1_CLK>;
clock-names = "core";
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -1645,6 +1646,10 @@ sram@c125000 {
#address-cells = <1>;
#size-cells = <1>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
pil-reloc@94c {
compatible = "qcom,pil-reloc-info";
reg = <0x94c 0xc8>;
--
2.53.0
^ permalink raw reply related
* RE: [EXTERNAL] [PATCH 0/3] Fixes for inline ipsec test cases
From: Akhil Goyal @ 2026-06-24 19:09 UTC (permalink / raw)
To: Bruce Richardson, dev@dpdk.org
In-Reply-To: <20260622111835.233554-1-bruce.richardson@intel.com>
> A series of small fixes for the inline ipsec test cases, with the third
> patch being the most significant - skipping tests where we don't have the
> necessary HW support to run the tests. Previously this was leading to test
> failures when the tests should never have been run due to missing HW
> capabilities.
>
> Bruce Richardson (3):
> test/security_inline_proto: remove fast-free Tx flag
> test/security_inline_proto: fix MTU calculation underflow
> test/security_inline_proto: check for capabilities
>
> app/test/test_security_inline_proto.c | 75 +++++++++++++++++++++++++--
> 1 file changed, 70 insertions(+), 5 deletions(-)
>
Series Acked-by: Akhil Goyal <gakhil@marvell.com>
Applied to dpdk-next-crypto
^ permalink raw reply
* [PATCH v4 16/19] arm64: dts: qcom: sm6350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm6350.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm6350.dtsi b/arch/arm64/boot/dts/qcom/sm6350.dtsi
index d6adf68563cb..06892ba22875 100644
--- a/arch/arm64/boot/dts/qcom/sm6350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6350.dtsi
@@ -363,6 +363,7 @@ big_cpu_sleep_1: cpu-sleep-1-1 {
firmware {
scm: scm {
compatible = "qcom,scm-sm6350", "qcom,scm";
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -2808,6 +2809,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2e000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@28000 {
reg = <0x28000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 15/19] arm64: dts: qcom: sc7180: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index fa65c485172f..1f51fd431ce5 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -385,6 +385,7 @@ cluster_aoss_sleep: cluster-sleep-2 {
firmware {
scm: scm {
compatible = "qcom,scm-sc7180", "qcom,scm";
+ sram = <&minidump_config>;
};
};
@@ -3596,6 +3597,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x2e000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@28000 {
reg = <0x28000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 14/19] arm64: dts: qcom: sm8350: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index c830953156ec..dea97330da49 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -293,6 +293,7 @@ firmware {
scm: scm {
compatible = "qcom,scm-sm8350", "qcom,scm";
qcom,dload-mode = <&tcsr 0x13000>;
+ sram = <&minidump_config>;
#reset-cells = <1>;
};
};
@@ -3451,6 +3452,10 @@ sram@14680000 {
ranges = <0 0 0x14680000 0x40000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3d000 {
reg = <0x3d000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH v4 13/19] arm64: dts: qcom: sc7280: Add minidump SRAM config to SCM node
From: Mukesh Ojha @ 2026-06-24 19:08 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh
Cc: cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mukesh Ojha, Konrad Dybcio
In-Reply-To: <20260624190830.3131112-1-mukesh.ojha@oss.qualcomm.com>
Point the SCM node at the minidump config slot in the always-on SRAM.
Boot firmware reads this word before DDR is initialised on a warm reset
to decide where to deliver the minidump.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index fa540d8c2615..6d805cbe5b4f 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -720,6 +720,7 @@ firmware {
scm: scm {
compatible = "qcom,scm-sc7280", "qcom,scm";
qcom,dload-mode = <&tcsr_2 0x13000>;
+ sram = <&minidump_config>;
};
};
@@ -6698,6 +6699,10 @@ sram@146a5000 {
ranges = <0 0 0x146a5000 0x6000>;
+ minidump_config: minidump-sram@1c {
+ reg = <0x1c 0x4>;
+ };
+
ipa_modem_tables: modem-tables@3000 {
reg = <0x3000 0x2000>;
};
--
2.53.0
^ permalink raw reply related
* [PATCH] misc: hpilo: validate device queue entries before use
From: Yousef Alhouseen @ 2026-06-24 19:09 UTC (permalink / raw)
To: Keng-Yu Lin
Cc: Arnd Bergmann, Greg Kroah-Hartman, linux-kernel, Yousef Alhouseen
ilo_pkt_dequeue() trusts descriptor IDs and lengths read from the shared
FIFO entry. A bad entry can select a descriptor outside the allocated
queue memory or report a packet length larger than one descriptor.
Reject entries whose descriptor index or packet length exceeds the queue
layout before deriving the packet pointer returned to read and write
paths.
Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com>
---
drivers/misc/hpilo.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/hpilo.c b/drivers/misc/hpilo.c
index ff3f03ea5..9b54a81b4 100644
--- a/drivers/misc/hpilo.c
+++ b/drivers/misc/hpilo.c
@@ -160,11 +160,16 @@ static int ilo_pkt_dequeue(struct ilo_hwinfo *hw, struct ccb *ccb,
ret = fifo_dequeue(hw, fifobar, &entry);
if (ret) {
+ int pkt_len;
+
pkt_id = get_entry_id(entry);
+ pkt_len = get_entry_len(entry);
+ if (pkt_id >= NR_QENTRY || pkt_len > desc_mem_sz(1))
+ return 0;
if (id)
*id = pkt_id;
if (len)
- *len = get_entry_len(entry);
+ *len = pkt_len;
if (pkt)
*pkt = (void *)(desc + desc_mem_sz(pkt_id));
}
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.