* Re: [PATCH] arm_pmu: acpi: fix reference leak on failed device registration
From: Johan Hovold @ 2026-04-20 7:28 UTC (permalink / raw)
To: Mark Rutland
Cc: Greg Kroah-Hartman, Guangshuo Li, Will Deacon, Anshuman Khandual,
linux-arm-kernel, linux-perf-users, linux-kernel, stable
In-Reply-To: <aeCsLy-45QyeCwGA@J2N7QTR9R3>
On Thu, Apr 16, 2026 at 10:30:23AM +0100, Mark Rutland wrote:
> On Thu, Apr 16, 2026 at 09:23:33AM +0200, Johan Hovold wrote:
> > It's not just the platform code as this directly reflects the behaviour
> > of device_register() as Mark pointed out.
> >
> > It is indeed an unfortunate quirk of the driver model, but one can argue
> > that having a registration function that frees its argument on errors
> > would be even worse. And even more so when many (or most) users get this
> > right.
>
> Ah, sorry; I had missed that the _put() step would actually free the
> object (and as you explain below, how that won't work for many callers).
>
> > So if we want to change this, I think we would need to deprecate
> > device_register() in favour of explicit device_initialize() and
> > device_add().
>
> Is is possible to have {platfom_,}device_uninitialize() functions that
> does everything except the ->release() call? If we had that, then we'd
> be able to have a flow along the lines of:
>
> int some_init_function(void)
> {
> int err;
>
> platform_device_init(&static_pdev);
>
> err = platform_device_add(&static_pdev))
> if (err)
> goto out_uninit;
>
> return 0;
>
> out_uninit:
> platform_device_uninit(&static_pdev);
> return err;
> }
>
> ... which I think would align with what people generally expect to have
> to do.
The issue here is that platform_device_add() allocates a device name and
such resources are not released until the last reference is dropped.
It's been this way since 2008, but some of the static platform devices
predates that and they both lack a release callback (explicitly required
since 2003) and are not cleaned up on registration failure.
Since registration would essentially only fail during development (e.g.
due to name collision or fault injection), this is hardly something to
worry about, but we could consider moving towards dynamic objects to
address both issues.
We have a few functions for allocating *and* registering platform
devices that could be used in many of these cases (and they already
clean up after themselves on errors):
platform_device_register_simple()
platform_device_register_data()
platform_device_register_resndata()
platform_device_register_full()
and where those do not fit (and cannot be extended) we have the
underlying:
platform_device_alloc()
platform_device_add_resources()
platform_device_add_data()
plaform_device_add()
But there are some 800 static platform devices left, mostly in legacy
platform code and board files that I assume few people care about.
Johan
^ permalink raw reply
* Re: [PATCH v2 1/2] hwtracing: hisi_ptt: Propagate DMA reset timeout in trace_start()
From: Sizhe Liu @ 2026-04-20 7:32 UTC (permalink / raw)
To: Yicong Yang, Pradhan, Sanman, jonathan.cameron@huawei.com
Cc: alexander.shishkin@linux.intel.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, Sanman Pradhan, Suzuki K Poulose,
Jie Zhan
In-Reply-To: <166964d1-2d16-43e8-b4d7-27b4a5e6286d@gmail.com>
On 2026/4/17 1:25, Yicong Yang wrote:
> +cc Suzuki and Sizhe..
>
> On 2026/4/15 01:25, Pradhan, Sanman wrote:
>> From: Sanman Pradhan <psanman@juniper.net>
>>
>> hisi_ptt_wait_dma_reset_done() discards the return value of
>> readl_poll_timeout_atomic(). If the DMA engine does not complete its
>> reset within the timeout, hisi_ptt_trace_start() proceeds to start
>> tracing regardless.
>>
>> Return a bool from hisi_ptt_wait_dma_reset_done(), consistent with the
>> other wait helpers in this driver. On timeout, log an error, de-assert
>> the reset bit, and return -ETIMEDOUT. Move ctrl->started to the
>> successful path so a failed start does not leave the trace marked as
>> active.
>>
>> Fixes: ff0de066b463 ("hwtracing: hisi_ptt: Add trace function support for HiSilicon PCIe Tune and Trace device")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Sanman Pradhan <psanman@juniper.net>
> looks good to me.
>
> Reviewed-by: Yicong Yang <yangyccccc@gmail.com>
>
> I see the Suzuki has sent out the PR for 7.1, so this may wait after the merge window...
>
> thanks.
Looks good to me, thanks.
Reviewed-by: Sizhe Liu <liusizhe5@huawei.com>
>> ---
>> v2:
>> - Return bool for consistency with other wait helpers
>> - Add pci_err() on timeout
>> - De-assert RST before returning on timeout
>> - Move ctrl->started to the successful path
>>
>> drivers/hwtracing/ptt/hisi_ptt.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/hwtracing/ptt/hisi_ptt.c b/drivers/hwtracing/ptt/hisi_ptt.c
>> index 94c371c491357..b5d851281fbf0 100644
>> --- a/drivers/hwtracing/ptt/hisi_ptt.c
>> +++ b/drivers/hwtracing/ptt/hisi_ptt.c
>> @@ -171,13 +171,13 @@ static bool hisi_ptt_wait_trace_hw_idle(struct hisi_ptt *hisi_ptt)
>> HISI_PTT_WAIT_TRACE_TIMEOUT_US);
>> }
>>
>> -static void hisi_ptt_wait_dma_reset_done(struct hisi_ptt *hisi_ptt)
>> +static bool hisi_ptt_wait_dma_reset_done(struct hisi_ptt *hisi_ptt)
>> {
>> u32 val;
>>
>> - readl_poll_timeout_atomic(hisi_ptt->iobase + HISI_PTT_TRACE_WR_STS,
>> - val, !val, HISI_PTT_RESET_POLL_INTERVAL_US,
>> - HISI_PTT_RESET_TIMEOUT_US);
>> + return !readl_poll_timeout_atomic(hisi_ptt->iobase + HISI_PTT_TRACE_WR_STS,
>> + val, !val, HISI_PTT_RESET_POLL_INTERVAL_US,
>> + HISI_PTT_RESET_TIMEOUT_US);
>> }
>>
>> static void hisi_ptt_trace_end(struct hisi_ptt *hisi_ptt)
>> @@ -202,14 +202,18 @@ static int hisi_ptt_trace_start(struct hisi_ptt *hisi_ptt)
>> return -EBUSY;
>> }
>>
>> - ctrl->started = true;
>> -
>> /* Reset the DMA before start tracing */
>> val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>> val |= HISI_PTT_TRACE_CTRL_RST;
>> writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>>
>> - hisi_ptt_wait_dma_reset_done(hisi_ptt);
>> + if (!hisi_ptt_wait_dma_reset_done(hisi_ptt)) {
>> + pci_err(hisi_ptt->pdev, "timed out waiting for DMA reset\n");
>> + val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>> + val &= ~HISI_PTT_TRACE_CTRL_RST;
>> + writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>> + return -ETIMEDOUT;
>> + }
>>
>> val = readl(hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
>> val &= ~HISI_PTT_TRACE_CTRL_RST;
>> @@ -234,6 +238,8 @@ static int hisi_ptt_trace_start(struct hisi_ptt *hisi_ptt)
>> if (!hisi_ptt->trace_ctrl.is_port)
>> val |= HISI_PTT_TRACE_CTRL_FILTER_MODE;
>>
>> + ctrl->started = true;
>> +
>> /* Start the Trace */
>> val |= HISI_PTT_TRACE_CTRL_EN;
>> writel(val, hisi_ptt->iobase + HISI_PTT_TRACE_CTRL);
^ permalink raw reply
* Re: [PATCH 0/4] media: uvcvideo: Fixes for hw timestamping
From: Yunke Cao @ 2026-04-20 7:38 UTC (permalink / raw)
To: Ricardo Ribalda
Cc: Laurent Pinchart, Hans de Goede, Mauro Carvalho Chehab,
Tomasz Figa, Sergey Senozhatsky, linux-media, linux-kernel,
stable
In-Reply-To: <20260323-uvc-hwtimestamp-v1-0-aa42e3865204@chromium.org>
Hi Ricardo,
I tested the series on a SunplusIT Inc 1080p FHD Camera (2b7e:c877).
Without this series, hardware timestamping was broken (due to the
issue fixed by [PATCH 2/4] of this series).
With this series, hardware timestamping works as intended.
Tested-by: Yunke Cao <yunkec@google.com>
Best,
Yunke
On Mon, Mar 23, 2026 at 9:10 PM Ricardo Ribalda <ribalda@chromium.org> wrote:
>
> This series introduces fixes for the hardware timestamp calculations.
>
> Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
> ---
> Ricardo Ribalda (4):
> media: uvcvideo: Fix dev_sof filtering in hw timestamp
> media: uvcvideo: Use hw timestaming if the clock buffer is full
> media: uvcvideo: Relax the constrains for interpolating the hw clock
> media: uvcvideo: Do not add clock samples with small sof delta
>
> drivers/media/usb/uvc/uvc_video.c | 51 +++++++++++++++++++++++++++------------
> 1 file changed, 35 insertions(+), 16 deletions(-)
> ---
> base-commit: a7da7fb57f2a787412da1a62292a17fa00fbfbdf
> change-id: 20260309-uvc-hwtimestamp-f25dc27f5711
>
> Best regards,
> --
> Ricardo Ribalda <ribalda@chromium.org>
>
^ permalink raw reply
* Re: [REGRESSION] Return change in 6.12.80+ with volatile mounting
From: Amir Goldstein @ 2026-04-20 7:59 UTC (permalink / raw)
To: Chenglong Tang; +Cc: Derek Taylor, stable, regressions, Kevin Berry, overlayfs
In-Reply-To: <CAOdxtTaWWu_7eJWu68zf28zHQP3Y--vXTfbGFsceO47BpN3qxA@mail.gmail.com>
On Mon, Apr 20, 2026 at 8:31 AM Chenglong Tang <chenglongtang@google.com> wrote:
>
> Hi, Amir,
>
> Thanks for looking into this! To answer your questions:
>
> 1. Production vs. Test Suite Impact
>
> The immediate failure we encountered is in containerd's integration
> test suite (TestImageVolumeCheckVolatileOption). The test explicitly
> reads /proc/mounts and expects the exact string "volatile".
>
> In default production, containerd passes the legacy "volatile" string
> to the mount syscall, which your patch correctly handles under the
> hood. So the standard "happy path" is not broken in production.
>
> 2. The purpose of WithTempMount() / RemoveVolatileOption
>
> Containerd regularly makes temporary overlay mounts (e.g., for
> unpacking layers). Because overlayfs rejects reusing upper/work dirs
> from a volatile mount, containerd uses RemoveVolatileOption to strip
> the volatile flag before these temporary mounts.
>
> Currently, containerd's RemoveVolatileOption does an exact string
> match for "volatile". While it works for the default path, there is a
> production edge case: if a user explicitly configures their container
> runtime to use the new "fsync=volatile" option, older containerd
> binaries will fail to strip it, and the temporary mounts will be
> rejected by the kernel.
I need to challenge this specific argument because I do not agree
that this edge case could be considered a regression at all.
An admin from the past could not have set an explicit
"fsync=volatile" mount option.
Though experiment - overlayfs adds a new mode fsync=off
which is more loose than "volatile" because "volatile" can actually
return error on fsync in some cases.
Overlayfs would also not allow to reuse workdir from such
a mount.
So would you then claim that adding the new mount option
"fsync=off" is a regression because of the edge case that an admin
decided to explicitly add "fsync=off" and RemoveVolatileOption()
does not handle it.
I don't buy it.
There is a more correct way to handle this situation and it is
documented in overlayfs.rst:
"When overlay is mounted with "volatile" option, the directory
"$workdir/work/incompat/volatile" is created. During next mount, overlay
checks for this directory and refuses to mount if present. This is a strong
indicator that the user should discard upper and work directories and create
fresh ones. In very limited cases where the user knows that the system has
not crashed and contents of upperdir are intact, the "volatile" directory
can be removed."
containerd unpacking layers falls under this very limited case.
containerd can syncfs() workdir after unpack & unmount of temp
overlayfs and remove the "incompat/volatile" directory and then
the upperdir/workdir are are free to be remounted.
>
> Conclusion
>
> While containerd could theoretically patch their code to accept
> strings.Contains() or fsync=volatile going forward, there are many
Following the documentation advise would be better.
> existing containerd binaries in the wild. Given that this patch breaks
> containerd's CI tests and introduces an edge case for
> RemoveVolatileOption, it might be safest to fix ovl_show_options in
> the kernel to continue outputting the legacy "volatile" string to
> strictly guarantee backwards compatibility with userspace.
>
Considering my comments above, I think we have not yet reached
the point where the backward compat "volatile" string is called for,
but with other reports from production workloads, we could get there.
Thanks for the clear and honest explanations of the containerd situation!
Amir.
^ permalink raw reply
* Re: [PATCH v2 1/4] HID: pass the buffer size to hid_report_raw_event
From: Benjamin Tissoires @ 2026-04-20 8:01 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Jiri Kosina, Filipe Laíns, Bastien Nocera, Ping Cheng,
Jason Gerecke, Viresh Kumar, Johan Hovold, Alex Elder,
Greg Kroah-Hartman, Lee Jones, linux-input, linux-kernel,
greybus-dev, linux-staging, linux-usb, stable
In-Reply-To: <938e8afadcbf2d7b9f0397e24926224985d9c385.camel@icenowy.me>
On Apr 20 2026, Icenowy Zheng wrote:
> 在 2026-04-16四的 16:48 +0200，Benjamin Tissoires写道：
> > commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > bogus memset()") enforced the provided data to be at least the size
> > of
> > the declared buffer in the report descriptor to prevent a buffer
> > overflow. However, we can try to be smarter by providing both the
> > buffer
> > size and the data size, meaning that hid_report_raw_event() can make
> > better decision whether we should plaining reject the buffer (buffer
> > overflow attempt) or if we can safely memset it to 0 and pass it to
> > the
> > rest of the stack.
> >
> > Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
> > bogus memset()")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
> > ---
> > drivers/hid/bpf/hid_bpf_dispatch.c | 6 ++++--
> > drivers/hid/hid-core.c | 42 +++++++++++++++++++++++++---
> > ----------
> > drivers/hid/hid-gfrm.c | 4 ++--
> > drivers/hid/hid-logitech-hidpp.c | 2 +-
> > drivers/hid/hid-multitouch.c | 2 +-
> > drivers/hid/hid-primax.c | 2 +-
> > drivers/hid/hid-vivaldi-common.c | 2 +-
> > drivers/hid/wacom_sys.c | 6 +++---
> > drivers/staging/greybus/hid.c | 2 +-
> > include/linux/hid.h | 4 ++--
> > include/linux/hid_bpf.h | 14 ++++++++-----
> > 11 files changed, 53 insertions(+), 33 deletions(-)
>
> ============ 8< ===================
>
> > diff --git a/drivers/staging/greybus/hid.c
> > b/drivers/staging/greybus/hid.c
> > index 1f58c907c036..37e8605c6767 100644
> > --- a/drivers/staging/greybus/hid.c
> > +++ b/drivers/staging/greybus/hid.c
> > @@ -201,7 +201,7 @@ static void gb_hid_init_report(struct gb_hid
> > *ghid, struct hid_report *report)
> > * we just need to setup the input fields, so using
> > * hid_report_raw_event is safe.
> > */
> > - hid_report_raw_event(ghid->hid, report->type, ghid->inbuf,
> > size, 1);
> > + hid_report_raw_event(ghid->hid, report->type, ghid->inbuf,
> > ghib->bufsize, size, 1);
>
> Oops, "ghid" is misspelled here...
Damn, you're correct. Sorry.
Jiri, do you want me to send v3? Or can you fix it while applying?
>
> Found this when building some gaint kernel with this patchset.
Thanks a lot for spotting this.
Cheers,
Benjamin
>
> Thanks,
> Icenowy
>
> > }
> >
> > static void gb_hid_init_reports(struct gb_hid *ghid)
>
^ permalink raw reply
* Re: [PATCH v2] dmaengine: Fix refcount leak in channel register error path
From: Guangshuo Li @ 2026-04-20 8:03 UTC (permalink / raw)
To: Frank Li; +Cc: Vinod Koul, Dave Jiang, dmaengine, linux-kernel, stable
In-Reply-To: <aeXGZIrLhqj5hWG8@lizhi-Precision-Tower-5810>
Hi Frank,
Thanks for reviewing.
On Mon, 20 Apr 2026 at 14:23, Frank Li <Frank.li@nxp.com> wrote:
>
>
> I think it is meanless, no one reproduce this. Provide tools link if open
> source. Or you descript how problem happen.
>
The issue was initially reported by a static analysis tool I am developing.
It is still under development and is not open source at this moment.
I also manually reviewed the code path. The problem happens because
device_register() is implemented as:
int device_register(struct device *dev)
{
device_initialize(dev);
return device_add(dev);
}
That means even if device_register() fails, it has already called
device_initialize() and initialized the device reference count to 1.
Also, the comment for device_register() explicitly says:
NOTE: _Never_ directly free @dev after calling this function, even
if it returned an error! Always use put_device() to give up the
reference initialized in this function instead.
In the current code, if device_register(&chan->dev->device) fails, the
error path falls through to:
kfree(chan->dev);
This bypasses the reference-count-based device release path and can lead to
a refcount leak.
> > err_out_ida:
> > ida_free(&device->chan_ida, chan->chan_id);
> > + put_device(&chan->dev->device);
> > + chan->dev = NULL;
> > + goto err_free_local;
>
> avoid err path goto again
>
> >
Thanks for pointing this out. How about this:
err_out_ida:
ida_free(&device->chan_ida, chan->chan_id);
+ put_device(&chan->dev->device);
+ chan->dev = NULL;
+ free_percpu(chan->local);
+ chan->local = NULL;
+ return rc;
+
err_free_dev:
kfree(chan->dev);
err_free_local:
free_percpu(chan->local);
chan->local = NULL;
return rc;
This way, put_device() is only used for the post-device_register()
failure path, while kfree(chan->dev) remains for the earlier failure
path, and the extra goto can be avoided as well.
Thanks,
Guangshuo
^ permalink raw reply
* Re: [PATCH] arm_pmu: acpi: fix reference leak on failed device registration
From: Greg Kroah-Hartman @ 2026-04-20 8:05 UTC (permalink / raw)
To: Johan Hovold
Cc: Mark Rutland, Guangshuo Li, Will Deacon, Anshuman Khandual,
linux-arm-kernel, linux-perf-users, linux-kernel, stable
In-Reply-To: <aeXVr5enpjb3rfq7@hovoldconsulting.com>
On Mon, Apr 20, 2026 at 09:28:47AM +0200, Johan Hovold wrote:
> On Thu, Apr 16, 2026 at 10:30:23AM +0100, Mark Rutland wrote:
> > On Thu, Apr 16, 2026 at 09:23:33AM +0200, Johan Hovold wrote:
>
> > > It's not just the platform code as this directly reflects the behaviour
> > > of device_register() as Mark pointed out.
> > >
> > > It is indeed an unfortunate quirk of the driver model, but one can argue
> > > that having a registration function that frees its argument on errors
> > > would be even worse. And even more so when many (or most) users get this
> > > right.
> >
> > Ah, sorry; I had missed that the _put() step would actually free the
> > object (and as you explain below, how that won't work for many callers).
> >
> > > So if we want to change this, I think we would need to deprecate
> > > device_register() in favour of explicit device_initialize() and
> > > device_add().
> >
> > Is is possible to have {platfom_,}device_uninitialize() functions that
> > does everything except the ->release() call? If we had that, then we'd
> > be able to have a flow along the lines of:
> >
> > int some_init_function(void)
> > {
> > int err;
> >
> > platform_device_init(&static_pdev);
> >
> > err = platform_device_add(&static_pdev))
> > if (err)
> > goto out_uninit;
> >
> > return 0;
> >
> > out_uninit:
> > platform_device_uninit(&static_pdev);
> > return err;
> > }
> >
> > ... which I think would align with what people generally expect to have
> > to do.
>
> The issue here is that platform_device_add() allocates a device name and
> such resources are not released until the last reference is dropped.
>
> It's been this way since 2008, but some of the static platform devices
> predates that and they both lack a release callback (explicitly required
> since 2003) and are not cleaned up on registration failure.
>
> Since registration would essentially only fail during development (e.g.
> due to name collision or fault injection), this is hardly something to
> worry about, but we could consider moving towards dynamic objects to
> address both issues.
Agreed, this whole thing, including the error handling, is all just
theoretical as no real user ever hits this, which is why it has been
_way_ down my priority list.
> We have a few functions for allocating *and* registering platform
> devices that could be used in many of these cases (and they already
> clean up after themselves on errors):
>
> platform_device_register_simple()
> platform_device_register_data()
> platform_device_register_resndata()
> platform_device_register_full()
>
> and where those do not fit (and cannot be extended) we have the
> underlying:
>
> platform_device_alloc()
> platform_device_add_resources()
> platform_device_add_data()
> plaform_device_add()
>
> But there are some 800 static platform devices left, mostly in legacy
> platform code and board files that I assume few people care about.
Yes, I agree that we do have all of the needed apis here already, we
should just work at converting existing drivers to the new apis OR just
not caring at all as again, no one will ever hit these code paths :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v1 2/2] drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout()
From: Boris Brezillon @ 2026-04-20 8:08 UTC (permalink / raw)
To: Gyeyoung Baek
Cc: Tomeu Vizoso, Rob Herring, Steven Price, Adrián Larumbe,
Oded Gabbay, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, dri-devel, linux-kernel, stable
In-Reply-To: <fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com>
On Sun, 19 Apr 2026 16:17:16 +0900
Gyeyoung Baek <gye976@gmail.com> wrote:
> dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
> on success, 0 on timeout, and -errno on failure.
>
> panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
> ioctl handler, so positive values reach userspace as bogus errors.
> Explicitly set ret to 0 on the success path.
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 3d0bdba2a..784e36d72 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -390,6 +390,8 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void *data,
> true, timeout);
> if (!ret)
> ret = timeout ? -ETIMEDOUT : -EBUSY;
> + else if (ret > 0)
> + ret = 0;
>
> drm_gem_object_put(gem_obj);
>
^ permalink raw reply
* Re: [PATCH v5] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: Kangzheng Gu @ 2026-04-20 8:09 UTC (permalink / raw)
To: Simon Horman
Cc: Paolo Abeni, davem, edumazet, kuba, kees, thorsten.blum, arnd,
sjur.brandeland, netdev, linux-kernel, stable
In-Reply-To: <20260414112951.GD469338@kernel.org>
Thanks for all of your advice, I am preparing a new version of patch now.
Simon Horman <horms@kernel.org> 于2026年4月14日周二 19:29写道：
>
> On Mon, Apr 13, 2026 at 11:30:53AM +0200, Paolo Abeni wrote:
> > On 4/12/26 3:57 PM, Simon Horman wrote:
> > > I am wondering if it would be best to follow the pattern for
> > > writing linkparam.u.utility.name elsewhere in this function.
> > > That:
> > > 1. Uses a somewhat more succinct loop control structure
> > > 2. Silently truncates input without updating cmdrsp if overrun would occur
> > >
> > > Something like this (compile tested only!):
> > >
> > > diff --git a/net/caif/cfctrl.c b/net/caif/cfctrl.c
> > > index c6cc2bfed65d..ba184c11386e 100644
> > > --- a/net/caif/cfctrl.c
> > > +++ b/net/caif/cfctrl.c
> > > @@ -15,6 +15,7 @@
> > > #include <net/caif/cfctrl.h>
> > >
> > > #define container_obj(layr) container_of(layr, struct cfctrl, serv.layer)
> > > +#define RFM_VOLUME_LEN 20
> > > #define UTILITY_NAME_LENGTH 16
> > > #define CFPKT_CTRL_PKT_LEN 20
> > >
> > > @@ -414,10 +415,11 @@ static int cfctrl_link_setup(struct cfctrl *cfctrl, struct cfpkt *pkt, u8 cmdrsp
> > > */
> > > linkparam.u.rfm.connid = cfpkt_extr_head_u32(pkt);
> > > cp = (u8 *) linkparam.u.rfm.volume;
> > > - for (tmp = cfpkt_extr_head_u8(pkt);
> > > - cfpkt_more(pkt) && tmp != '\0';
> > > - tmp = cfpkt_extr_head_u8(pkt))
> > > + caif_assert(sizeof(linkparam.u.rfm.volume) >= RFM_VOLUME_LEN);
> > > + for(i = 0; i < RFM_VOLUME_LEN - 1 && cfpkt_more(pkt); i++) {
> > > + tmp = cfpkt_extr_head_u8(pkt);
> > > *cp++ = tmp;
> > > + }
> > > *cp = '\0';
> > >
> > > if (CFCTRL_ERR_BIT & cmdrsp)
> >
> > I agree that the code suggested by Simon is clearer. Note that AFAICS it
> > lacks an additional `tmp!= '\0'` check to break the loop, but even with
> > that added it should be preferable.
>
> Sorry, I left out the `tmp!= '\0' check.
> That was unintentional and I agree it should be there.
^ permalink raw reply
* Re: [PATCH v5] net: caif: fix stack out-of-bounds write in cfctrl_link_setup()
From: Arnd Bergmann @ 2026-04-20 8:14 UTC (permalink / raw)
To: Kangzheng Gu, Simon Horman
Cc: Paolo Abeni, David S . Miller, Eric Dumazet, Jakub Kicinski,
Kees Cook, Thorsten Blum, sjur.brandeland, Netdev, linux-kernel,
stable
In-Reply-To: <CAKvcANPEa91paujTQjpW2hZhpXEhwfOjjy6CsN=OJ32iXYXdTA@mail.gmail.com>
On Mon, Apr 20, 2026, at 10:09, Kangzheng Gu wrote:
> Thanks for all of your advice, I am preparing a new version of patch now.
If you are actively using CAIF, please chime in at
https://lore.kernel.org/all/20260416182829.1440262-1-kuba@kernel.org/
If you are not actually using CAIF, maybe wait a little bit before
spending more time on it because the patches may no longer
apply if it gets removed due to lack of users.
Arnd
^ permalink raw reply
* Re: [PATCH v2] drm/bridge: dw-hdmi-qp: Guard clear_audio_infoframe when PHY is down
From: Dmitry Baryshkov @ 2026-04-20 9:00 UTC (permalink / raw)
To: Frank Zhang
Cc: andrzej.hajda, neil.armstrong, rfoss, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, detlev.casanova, cristian.ciocaltea,
Laurent.pinchart, jonas, jernej.skrabec, dri-devel, linux-kernel,
stable
In-Reply-To: <9c198d0e-a675-4d7e-a485-5a8ee4d97f88@gmail.com>
On Mon, Apr 20, 2026 at 02:11:28PM +0800, Frank Zhang wrote:
> On 4/19/26 08:40, Dmitry Baryshkov wrote:
> > On Sat, Apr 18, 2026 at 06:19:36PM +0800, Frank Zhang wrote:
> > > The following panic was observed during system reboot:
> > >
> > > Kernel panic - not syncing: Asynchronous SError Interrupt
> > > CPU: 7 UID: 1000 PID: 2637 Comm: pipewire ... 6.19.10-300.fc44.aarch64
> > > Call trace:
> > > ...
> > > regmap_update_bits_base+0x5c/0x90
> > > dw_hdmi_qp_bridge_clear_infoframe+0xb0/0x120 [dw_hdmi_qp]
> > > drm_bridge_connector_clear_infoframe+0x28/0x48 [drm_display_helper]
> > > ...
> > > dw_hdmi_qp_audio_disable+0x24/0xb8 [dw_hdmi_qp]
> > > drm_bridge_connector_audio_shutdown+0x30/0x60 [drm_display_helper]
> > > drm_connector_hdmi_audio_shutdown+0x24/0x38 [drm_display_helper]
> > > hdmi_codec_shutdown+0x60/0x90 [snd_soc_hdmi_codec]
> > > ...
> > > snd_pcm_release_substream.part.0+0x44/0xd8 [snd_pcm]
> > > snd_pcm_release+0x60/0xe8 [snd_pcm]
> > > ...
> > >
> > > The root cause is pipewire tries to close the HDMI audio device after
> > > atomic_disable(), which sets tmds_char_rate to 0 and disable the PHY.
> > >
> > > In this case, dw_hdmi_qp_audio_disable() will call
> > > drm_atomic_helper_connector_hdmi_clear_audio_infoframe() directly,
> > > accessing registers without checking tmds_char_rate.
> > >
> > > Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside the
> > > if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable().
> > >
> > > Fixes: fd0141d1a8a2 ("drm/bridge: synopsys: Add audio support for dw-hdmi-qp")
> > > Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>
> > >
> > > ---
> > > Changes in v2:
> > > - Move drm_atomic_helper_connector_hdmi_clear_audio_infoframe() inside
> > > the if (hdmi->tmds_char_rate) of dw_hdmi_qp_audio_disable().
> > > - Link to v1: https://lore.kernel.org/all/20260416093150.13853-1-rmxpzlb@gmail.com/
> > >
> > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > index d649a1cf07f5..7760527484c8 100644
> > > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c
> > > @@ -526,10 +526,10 @@ static void dw_hdmi_qp_audio_disable(struct drm_bridge *bridge,
> > > {
> > > struct dw_hdmi_qp *hdmi = dw_hdmi_qp_from_bridge(bridge);
> > > - drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector);
> > > -
> > > - if (hdmi->tmds_char_rate)
> > > + if (hdmi->tmds_char_rate) {
> > > + drm_atomic_helper_connector_hdmi_clear_audio_infoframe(connector);
> > > dw_hdmi_qp_audio_disable_regs(hdmi);
> > > + }
> >
> > Will audio and audio infoframe remain disabled after consequetive
> > atomic_enable() call?
> >
> > > }
> > > static int dw_hdmi_qp_i2c_read(struct dw_hdmi_qp *hdmi,
> > > --
> > > 2.53.0
> > >
> >
>
> Sorry, I missed clearing the audio infoframe when the PHY is down. The next
> atomic_enable() will write the stale audio infoframe. My mistake.
>
> To clear the stale audio infoframe, dw_hdmi_qp_audio_disable() can handle it
> in the else branch directly, but this seems like a layering violation for a
> bridge driver
>
> I think the better approach is to add a 'reset_audio_infoframe' interface in
> drm_hdmi_state_helper.c that does basically the same as
> drm_atomic_helper_connector_hdmi_clear_audio_infoframe(), but only clearing
> the software state without calling clear_infoframe(). It's also a bit odd
> since it would only be used by dw-hdmi-qp.
That sounds too fine-grained and it also will not work straight ahead...
Just for my understanding, let's consider the opposite situation: the
user tries to start audio playback before setting the mode. How is it
handled in the driver?
>
> I'd like to get the maintainers' opinion about adding such an interface.
>
> Thanks,
> Frank Zhang
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] fuse: reject oversized dirents in page cache
From: Miklos Szeredi @ 2026-04-20 9:01 UTC (permalink / raw)
To: Christian Brauner; +Cc: Samuel Page, linux-fsdevel, stable, Qi Tang, Zijun Hu
From: Samuel Page <sam@bynar.io>
fuse_add_dirent_to_cache() computes a serialized dirent size from the
server-controlled namelen field and copies the dirent into a single
page-cache page. The existing logic only checks whether the dirent fits
in the remaining space of the current page and advances to a fresh page
if not. It never checks whether the dirent itself exceeds PAGE_SIZE.
As a result, a malicious FUSE server can return a dirent with
namelen=4095, producing a serialized record size of 4120 bytes. On 4 KiB
page systems this causes memcpy() to overflow the cache page by 24 bytes
into the following kernel page.
Reject dirents that cannot fit in a single page before copying them into
the readdir cache.
Fixes: 69e34551152a ("fuse: allow caching readdir")
Cc: stable@vger.kernel.org # v6.16+
Assisted-by: Bynario AI
Signed-off-by: Samuel Page <sam@bynar.io>
Reported-by: Qi Tang <tpluszz77@gmail.com>
Reported-by: Zijun Hu <nightu@northwestern.edu>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
---
fs/fuse/readdir.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/fuse/readdir.c b/fs/fuse/readdir.c
index c88194e52d18..db5ae8ec1030 100644
--- a/fs/fuse/readdir.c
+++ b/fs/fuse/readdir.c
@@ -41,6 +41,10 @@ static void fuse_add_dirent_to_cache(struct file *file,
unsigned int offset;
void *addr;
+ /* Dirent doesn't fit in readdir cache page? Skip caching. */
+ if (reclen > PAGE_SIZE)
+ return;
+
spin_lock(&fi->rdc.lock);
/*
* Is cache already completed? Or this entry does not go at the end of
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5] mtd: spi-nor: Fix SST AAI write mode opcode handling
From: Sanjaikumar V S @ 2026-04-20 9:02 UTC (permalink / raw)
To: pratyush
Cc: hd, linux-kernel, linux-mtd, miquel.raynal, mwalle, richard,
sanjaikumar.vs, sanjaikumarvs, stable, tudor.ambarus, vigneshr
In-Reply-To: <40364d66-f8a2-4efb-a4d3-70f0aa3137e2@os-cillation.de>
Hi Pratyush,
In v4 you suggested updating dirmap_info with the right opcodes. I went
with a different approach in v5 -- disabling dirmap for SST AAI devices
in sst_nor_late_init() instead. The reasoning is that updating
dirmap_info at runtime is problematic since AAI requires dynamic opcode
and address byte changes per write, and controllers may cache the
template at dirmap_create time.
Hendrik has tested this approach on his SST25VF032B.
Does this approach work for you, or would you prefer a different
direction?
Thanks,
Sanjaikumar
^ permalink raw reply
* Re: [PATCH v2] gpu: host1x: Fix device reference leak in device_add() error path
From: Guangshuo Li @ 2026-04-20 9:05 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, David Airlie, Simona Vetter,
Vamsee Vardhan Thummala, linux-kernel, dri-devel, linux-tegra,
stable
In-Reply-To: <q6Ni253ETr-zY8OZRWnm4g@nvidia.com>
Hi Mikko,
Thanks for reviewing.
On Mon, 20 Apr 2026 at 15:19, Mikko Perttunen <mperttunen@nvidia.com> wrote:
>
> Unrelated ..
>
Sorry about the unrelated change in drivers/firmware/edd.c. It was
included by mistake due to my carelessness when doing git add.
> This isn't a leak -- if device_add fails, the device is still on the
> device list, though in a "stuck" state, and will get cleaned up through
> host1x_device_del.
>
You're right. I misunderstood this path: if device_add() fails here,
the device remains on host1x->devices and can still be cleaned up
later via host1x_device_del(), so this is not a real leak.
I'll drop this host1x change.
Best regards,
Guangshuo
^ permalink raw reply
* Re: [PATCH] drm/i915: skip __i915_request_skip() for already signaled requests
From: Krzysztof Karas @ 2026-04-20 9:18 UTC (permalink / raw)
To: Sebastian Brzezinka; +Cc: intel-gfx, andi.shyti, stable
In-Reply-To: <fe76921d35b6ae85aa651822726d0d9815aa5362.1776339012.git.sebastian.brzezinka@intel.com>
Hi Sebastian,
On 2026-04-16 at 13:31:18 +0200, Sebastian Brzezinka wrote:
> After a GPU reset the HWSP is zeroed, so previously completed
> requests appear incomplete. If such a request is picked up during
> reset_rewind() and marked guilty, i915_request_set_error_once()
> returns early (fence already signaled), leaving fence.error without
> a fatal error code. The subsequent __i915_request_skip() then hits:
> ```
> GEM_BUG_ON(!fatal_error(rq->fence.error))
> ```
>
> Fixes a kernel BUG observed on Sandy Bridge (Gen6) during
By "Fixes" do you mean this patch? Or are you referring to the
tag "Fixes:" below? If former would be the case, then imperative
form might be better: Fix.
In any case the patch looks sane:
Reviewed-by: Krzysztof Karas <krzysztof.karas@intel.com>
> heartbeat-triggered engine resets.
> ```
> kernel BUG at drivers/gpu/drm/i915/i915_request.c:556!
> RIP: __i915_request_skip+0x15e/0x1d0 [i915]
> ...
> __i915_request_reset+0x212/0xa70 [i915]
> reset_rewind+0xe4/0x280 [i915]
> intel_gt_reset+0x30d/0x5b0 [i915]
> heartbeat+0x516/0x530 [i915]
> ```
>
> Guard __i915_request_skip() with i915_request_signaled(), if the
> fence is already signaled, the ring content is committed and there
> is nothing left to skip.
>
> Cc: stable@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/13729
> Fixes: 36e191f0644b ("drm/i915: Apply i915_request_skip() on submission")
> Signed-off-by: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 37272871b0f2..b728a5171e93 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -133,7 +133,8 @@ void __i915_request_reset(struct i915_request *rq, bool guilty)
> rcu_read_lock(); /* protect the GEM context */
> if (guilty) {
> i915_request_set_error_once(rq, -EIO);
> - __i915_request_skip(rq);
> + if (!i915_request_signaled(rq))
> + __i915_request_skip(rq);
> banned = mark_guilty(rq);
> } else {
> i915_request_set_error_once(rq, -EAGAIN);
> --
> 2.53.0
>
--
Best Regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6.12.y 0/2] gpiolib: backport fa17f749ee5b and a7ac22d53d09
From: Bartosz Golaszewski @ 2026-04-20 9:26 UTC (permalink / raw)
To: Quentin Schulz
Cc: Heiko Stuebner, stable, linux-gpio, linux-kernel,
Bartosz Golaszewski, Quentin Schulz, Kent Gibson,
Paweł Narewski, Jakub Lewalski, Bartosz Golaszewski,
Linus Walleij, Bartosz Golaszewski, Andy Shevchenko
In-Reply-To: <20260415-6-12-gpiolib-cve-2026-22986-v1-0-3a7a6de332eb@cherry.de>
On Wed, 15 Apr 2026 13:15:39 +0200, Quentin Schulz <foss+kernel@0leil.net> said:
> Backport a7ac22d53d09 ("gpiolib: fix race condition for gdev->srcu") to
> 6.12.y. To make the git context difference between commit a7ac22d53d09
> and its backport in 6.12.y smaller, also backport fa17f749ee5b
> ("gpiolib: unify two loops initializing GPIO descriptors").
>
> a7ac22d53d09 fixes an issue reported as being present since 6.9. It's
> been fixed in 6.19 and backported to 6.18.y in fb674c8f1a5d8.
>
> The git context difference could be even smaller if we also backported
> d4f335b410dd ("gpiolib: rename GPIO chip printk macros") but its
> cherry-pick conflicts so I decided to not include it for now. It was
> backported to 6.18.y though (because it applied cleanly and helped
> a7ac22d53d09 being cleanly applied as well, see
> https://lore.kernel.org/stable/2026011530-owl-savage-9b8e@gregkh/).
>
> The changes between a7ac22d53d09 in v6.19 and the second patch of this
> series is (according to git range-diff):
>
> """
> ## drivers/gpio/gpiolib.c ##
> @@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> gdev->ngpio = gc->ngpio;
> gdev->can_sleep = gc->can_sleep;
>
> -+ rwlock_init(&gdev->line_state_lock);
> -+ RAW_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
> ++ BLOCKING_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
> + BLOCKING_INIT_NOTIFIER_HEAD(&gdev->device_notifier);
> +
> + ret = init_srcu_struct(&gdev->srcu);
> @@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, voi
> @@ drivers/gpio/gpiolib.c: int gpiochip_add_data_with_key(struct gpio_chip *gc, void *data,
> ret = gpiodev_add_to_list_unlocked(gdev);
> if (ret) {
> - gpiochip_err(gc, "GPIO integer space overlap, cannot add chip\n");
> + chip_err(gc, "GPIO integer space overlap, cannot add chip\n");
> - goto err_free_label;
> + goto err_cleanup_desc_srcu;
> }
> }
>
> -- rwlock_init(&gdev->line_state_lock);
> -- RAW_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
> +- BLOCKING_INIT_NOTIFIER_HEAD(&gdev->line_state_notifier);
> - BLOCKING_INIT_NOTIFIER_HEAD(&gdev->device_notifier);
> -
> - ret = init_srcu_struct(&gdev->srcu);
> """
>
> s/gpiochip_err/chip_err/ aside, the rest of the diff comes from feature
> commits which do not fit the rules for backporting to stable.
>
> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
> ---
> Bartosz Golaszewski (1):
> gpiolib: unify two loops initializing GPIO descriptors
>
> Paweł Narewski (1):
> gpiolib: fix race condition for gdev->srcu
>
> drivers/gpio/gpiolib.c | 43 +++++++++++++++++++++----------------------
> 1 file changed, 21 insertions(+), 22 deletions(-)
> ---
> base-commit: e7a3953084a7050ca349010deb22546834c2e196
> change-id: 20260415-6-12-gpiolib-cve-2026-22986-f0b4331c0aa1
>
> Best regards,
> --
> Quentin Schulz <quentin.schulz@cherry.de>
>
>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states
From: Breno Leitao @ 2026-04-20 9:27 UTC (permalink / raw)
To: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Len Brown, Huisong Li
Cc: Rafael J. Wysocki, linux-acpi, linux-arm-kernel, linux-kernel,
pjaroszynski, rmikey, kernel-team, stable, Breno Leitao
Commit cac173bea57d ("ACPI: processor: idle: Rework the handling of
acpi_processor_ffh_lpi_probe()") moved the acpi_processor_ffh_lpi_probe()
call from acpi_processor_setup_cpuidle_dev(), where its return value was
ignored, to acpi_processor_get_power_info(), where it is now treated as
a hard failure. As a result, platforms where psci_acpi_cpu_init_idle()
returned -ENODEV stopped registering any cpuidle states, forcing CPUs to
busy-poll when idle.
On NVIDIA Grace (aarch64) systems with PSCIv1.1, pr->power.count is 1
(only WFI, no deep PSCI states beyond it), so the previous
"count = pr->power.count - 1; if (count <= 0) return -ENODEV;" check
returned -ENODEV for all 72 CPUs and disabled cpuidle entirely.
The lpi_states count is already validated in acpi_processor_get_lpi_info(),
so the check here is redundant. Simplify the loop to iterate over
lpi_states[1..power.count). When only WFI is present, the loop body
simply does not execute and the function returns 0, which is the correct
outcome: there is nothing to validate for FFH and no error to report.
Suggested-by: Huisong Li <lihuisong@huawei.com>
Cc: stable@vger.kernel.org
Fixes: cac173bea57d ("ACPI: processor: idle: Rework the handling of acpi_processor_ffh_lpi_probe()")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/acpi/arm64/cpuidle.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/acpi/arm64/cpuidle.c b/drivers/acpi/arm64/cpuidle.c
index 801f9c4501425..c68a5db8ebba8 100644
--- a/drivers/acpi/arm64/cpuidle.c
+++ b/drivers/acpi/arm64/cpuidle.c
@@ -16,7 +16,7 @@
static int psci_acpi_cpu_init_idle(unsigned int cpu)
{
- int i, count;
+ int i;
struct acpi_lpi_state *lpi;
struct acpi_processor *pr = per_cpu(processors, cpu);
@@ -30,14 +30,10 @@ static int psci_acpi_cpu_init_idle(unsigned int cpu)
if (!psci_ops.cpu_suspend)
return -EOPNOTSUPP;
- count = pr->power.count - 1;
- if (count <= 0)
- return -ENODEV;
-
- for (i = 0; i < count; i++) {
+ for (i = 1; i < pr->power.count; i++) {
u32 state;
- lpi = &pr->power.lpi_states[i + 1];
+ lpi = &pr->power.lpi_states[i];
/*
* Only bits[31:0] represent a PSCI power_state while
* bits[63:32] must be 0x0 as per ARM ACPI FFH Specification
---
base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
change-id: 20260413-ffh-93f68b2f46a3
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* [PATCH] btrfs: check and set EXTENT_DELALLOC_NEW before clearing EXTENT_DELALLOC
From: Qu Wenruo @ 2026-04-20 9:31 UTC (permalink / raw)
To: linux-btrfs; +Cc: stable
[WARNING]
When running test cases with injected errors or shutdown, e.g.
generic/388 or generic/475, there is a chance that the following kernel
warning is triggered:
BTRFS info (device dm-2): first mount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff
BTRFS info (device dm-2): using crc32c checksum algorithm
BTRFS info (device dm-2): checking UUID tree
BTRFS info (device dm-2): turning on async discard
BTRFS info (device dm-2): enabling free space tree
BTRFS critical (device dm-2 state E): emergency shutdown
------------[ cut here ]------------
WARNING: extent_io.c:1742 at extent_writepage_io+0x437/0x520 [btrfs], CPU#2: kworker/u43:2/651591
CPU: 2 UID: 0 PID: 651591 Comm: kworker/u43:2 Tainted: G W OE 7.0.0-rc6-custom+ #365 PREEMPT(full) 5804053f02137e627472d94b5128cc9fcb110e88
RIP: 0010:extent_writepage_io+0x437/0x520 [btrfs]
Call Trace:
<TASK>
extent_write_cache_pages+0x2a5/0x820 [btrfs 70299925d0856939e93b17d480651713b3cbba58]
btrfs_writepages+0x74/0x130 [btrfs 70299925d0856939e93b17d480651713b3cbba58]
do_writepages+0xd0/0x160
__writeback_single_inode+0x42/0x340
writeback_sb_inodes+0x22d/0x580
wb_writeback+0xc6/0x360
wb_workfn+0xbd/0x470
process_one_work+0x198/0x3b0
worker_thread+0x1c8/0x330
kthread+0xee/0x120
ret_from_fork+0x2a6/0x330
ret_from_fork_asm+0x11/0x20
</TASK>
---[ end trace 0000000000000000 ]---
BTRFS error (device dm-2 state E): root 5 ino 259 folio 1323008 is marked dirty without notifying the fs
BTRFS error (device dm-2 state E): failed to submit blocks, root=5 inode=259 folio=1323008 submit_bitmap=0: -117
BTRFS info (device dm-2 state E): last unmount of filesystem d8a19a28-3232-4809-b0df-38df83e71bff
[CAUSE]
Inside btrfs we have the following pattern in several locations, for
example inside btrfs_dirty_folio():
btrfs_clear_extent_bit(&inode->io_tree, start_pos, end_of_last_block,
EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
cached);
ret = btrfs_set_extent_delalloc(inode, start_pos, end_of_last_block,
extra_bits, cached);
if (ret)
return ret;
However btrfs_set_extent_delalloc() can return IO errors other than -ENOMEM
through the following callchain:
btrfs_set_extent_delalloc()
\- btrfs_find_new_delalloc_bytes()
\- btrfs_get_extent()
\- btrfs_lookup_file_extent()
\- btrfs_search_slot()
When such IO error happened, the previous btrfs_clear_extent_bit() has
cleared the EXTENT_DELALLOC for the range, and we're expecting
btrfs_set_extent_delalloc() to re-set EXTENT_DELALLOC.
But since btrfs_set_extent_delalloc() failed before
btrfs_set_extent_bit(), EXTENT_DELALLOC flag is no longere present.
And if the folio range is dirty before entering
btrfs_set_extent_delalloc(), we got a dirty folio but no EXTENT_DELALLOC
flag now.
Then we hit the folio writeback:
extent_writepage()
|- writepage_delalloc()
| No ordered extent is created, as there is no EXTENT_DELALLOC set
| for the folio range.
| This also means the folio has no ordered flag set.
|
|- extent_writepage_io()
\- if (unlikely(!folio_test_ordered(folio))
Now we hit the warning.
[FIX]
Introduce a new helper, btrfs_reset_extent_delalloc() to replace the
currently open-coded btrfs_clear_extent_bit() +
btrfs_set_extent_delalloc() combination.
Instead of calling btrfs_clear_extent_bit() first, update
EXTENT_DELALLOC_NEW first, as that part can fail due to metadata IO,
meanwhile btrfs_clear_extent_bit() and btrfs_set_extent_bit() can really
only fail with -ENOMEM.
This allows us to fail early without clearing EXTENT_DELALLOC bit, so
even if that new btrfs_reset_extent_delalloc() failed before touching
EXTENT_DELALLOC, the existing dirty range will still have their old
EXTENT_DELALLOC flag present, thus avoid the warning.
Cc: stable@vger.kernel.org # 6.1+
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
fs/btrfs/btrfs_inode.h | 3 +++
fs/btrfs/file.c | 25 +++---------------
fs/btrfs/inode.c | 59 +++++++++++++++++++++++++++++++++++++-----
fs/btrfs/reflink.c | 4 +--
4 files changed, 59 insertions(+), 32 deletions(-)
diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h
index 6e696b350dc5..ad523549d8b4 100644
--- a/fs/btrfs/btrfs_inode.h
+++ b/fs/btrfs/btrfs_inode.h
@@ -569,6 +569,9 @@ int btrfs_start_delalloc_roots(struct btrfs_fs_info *fs_info, long nr,
int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
unsigned int extra_bits,
struct extent_state **cached_state);
+int btrfs_reset_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
+ unsigned int extra_bits,
+ struct extent_state **cached_state);
struct btrfs_new_inode_args {
/* Input */
diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c
index a6f641a41d99..ab536a304500 100644
--- a/fs/btrfs/file.c
+++ b/fs/btrfs/file.c
@@ -85,16 +85,8 @@ int btrfs_dirty_folio(struct btrfs_inode *inode, struct folio *folio, loff_t pos
end_of_last_block = start_pos + num_bytes - 1;
- /*
- * The pages may have already been dirty, clear out old accounting so
- * we can set things up properly
- */
- btrfs_clear_extent_bit(&inode->io_tree, start_pos, end_of_last_block,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
- cached);
-
- ret = btrfs_set_extent_delalloc(inode, start_pos, end_of_last_block,
- extra_bits, cached);
+ ret = btrfs_reset_extent_delalloc(inode, start_pos, end_of_last_block,
+ extra_bits, cached);
if (ret)
return ret;
@@ -1952,18 +1944,7 @@ static vm_fault_t btrfs_page_mkwrite(struct vm_fault *vmf)
}
}
- /*
- * page_mkwrite gets called when the page is firstly dirtied after it's
- * faulted in, but write(2) could also dirty a page and set delalloc
- * bits, thus in this case for space account reason, we still need to
- * clear any delalloc bits within this page range since we have to
- * reserve data&meta space before lock_page() (see above comments).
- */
- btrfs_clear_extent_bit(io_tree, page_start, end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING |
- EXTENT_DEFRAG, &cached_state);
-
- ret = btrfs_set_extent_delalloc(inode, page_start, end, 0, &cached_state);
+ ret = btrfs_reset_extent_delalloc(inode, page_start, end, 0, &cached_state);
if (ret < 0) {
btrfs_unlock_extent(io_tree, page_start, page_end, &cached_state);
goto out_unlock;
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 71129502333a..0dc5fe7f7705 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -2810,7 +2810,10 @@ int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
unsigned int extra_bits,
struct extent_state **cached_state)
{
- WARN_ON(PAGE_ALIGNED(end));
+ const u32 blocksize = inode->root->fs_info->sectorsize;
+
+ ASSERT(IS_ALIGNED(start, blocksize), "start=%llu", start);
+ ASSERT(IS_ALIGNED(end + 1, blocksize), "end=%llu", end);
if (start >= i_size_read(&inode->vfs_inode) &&
!(inode->flags & BTRFS_INODE_PREALLOC)) {
@@ -2833,6 +2836,53 @@ int btrfs_set_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
EXTENT_DELALLOC | extra_bits, cached_state);
}
+/*
+ * Clear the old accounting flags and set EXTENT_DELALLOC for the range.
+ *
+ * Return <0 for error, in that case no range has EXTENT_DELALLOC bit cleared or set.
+ */
+int btrfs_reset_extent_delalloc(struct btrfs_inode *inode, u64 start, u64 end,
+ unsigned int extra_bits,
+ struct extent_state **cached_state)
+{
+ const u32 blocksize = inode->root->fs_info->sectorsize;
+
+ /* The @extra_bits can only be EXTENT_NORESERVE for now. */
+ ASSERT(!(extra_bits & ~EXTENT_NORESERVE));
+
+ /* Basic alignment check. */
+ ASSERT(IS_ALIGNED(start, blocksize), "start=%llu", start);
+ ASSERT(IS_ALIGNED(end + 1, blocksize), "end=%llu", end);
+
+ /*
+ * Check and set DELALLOC_NEW flags, this needs to search tree thus
+ * can fail early.
+ * Thus we want to do this before clearing DELALLOC_EXTENT.
+ */
+ if (start >= i_size_read(&inode->vfs_inode) &&
+ !(inode->flags & BTRFS_INODE_PREALLOC)) {
+ /*
+ * There can't be any extents following eof in this case so just
+ * set the delalloc new bit for the range directly.
+ */
+ extra_bits |= EXTENT_DELALLOC_NEW;
+ } else {
+ int ret;
+
+ ret = btrfs_find_new_delalloc_bytes(inode, start,
+ end + 1 - start,
+ cached_state);
+ if (unlikely(ret))
+ return ret;
+ }
+ /* Clear the old accounting as the range may already be dirty. */
+ btrfs_clear_extent_bit(&inode->io_tree, start, end,
+ EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING |
+ EXTENT_DEFRAG, cached_state);
+ return btrfs_set_extent_bit(&inode->io_tree, start, end,
+ EXTENT_DELALLOC | extra_bits, cached_state);
+}
+
static int insert_reserved_file_extent(struct btrfs_trans_handle *trans,
struct btrfs_inode *inode, u64 file_pos,
struct btrfs_file_extent_item *stack_fi,
@@ -4973,12 +5023,7 @@ int btrfs_truncate_block(struct btrfs_inode *inode, u64 offset, u64 start, u64 e
goto again;
}
- btrfs_clear_extent_bit(&inode->io_tree, block_start, block_end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG,
- &cached_state);
-
- ret = btrfs_set_extent_delalloc(inode, block_start, block_end, 0,
- &cached_state);
+ ret = btrfs_reset_extent_delalloc(inode, block_start, block_end, 0, &cached_state);
if (ret) {
btrfs_unlock_extent(io_tree, block_start, block_end, &cached_state);
goto out_unlock;
diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
index 14742abe0f92..fb34598a77ff 100644
--- a/fs/btrfs/reflink.c
+++ b/fs/btrfs/reflink.c
@@ -94,9 +94,7 @@ static int copy_inline_to_page(struct btrfs_inode *inode,
if (ret < 0)
goto out_unlock;
- btrfs_clear_extent_bit(&inode->io_tree, file_offset, range_end,
- EXTENT_DELALLOC | EXTENT_DO_ACCOUNTING | EXTENT_DEFRAG, NULL);
- ret = btrfs_set_extent_delalloc(inode, file_offset, range_end, 0, NULL);
+ ret = btrfs_reset_extent_delalloc(inode, file_offset, range_end, 0, NULL);
if (ret)
goto out_unlock;
--
2.53.0
^ permalink raw reply related
* [PATCH] powerpc/pseries/papr-hvpipe: fix NULL dereference in handle creation
From: Guangshuo Li @ 2026-04-20 9:38 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Mahesh Salgaonkar, Tyrel Datwyler,
Haren Myneni, Guangshuo Li, Christian Brauner, Kees Cook,
linuxppc-dev, linux-kernel
Cc: stable
papr_hvpipe_dev_create_handle() transfers ownership of src_info with
retain_and_null_ptr(src_info) after anon_inode_getfile() succeeds.
However, retain_and_null_ptr() clears src_info immediately, and the
function then still dereferences src_info in the subsequent list_add().
Store the transferred pointer in a separate variable and use that for
the list insertion.
Manually identified during code review.
Fixes: 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
arch/powerpc/platforms/pseries/papr-hvpipe.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/papr-hvpipe.c b/arch/powerpc/platforms/pseries/papr-hvpipe.c
index 14ae480d060a..497eb967611b 100644
--- a/arch/powerpc/platforms/pseries/papr-hvpipe.c
+++ b/arch/powerpc/platforms/pseries/papr-hvpipe.c
@@ -480,6 +480,7 @@ static const struct file_operations papr_hvpipe_handle_ops = {
static int papr_hvpipe_dev_create_handle(u32 srcID)
{
struct hvpipe_source_info *src_info __free(kfree) = NULL;
+ struct hvpipe_source_info *owned_src_info;
spin_lock(&hvpipe_src_list_lock);
/*
@@ -509,7 +510,7 @@ static int papr_hvpipe_dev_create_handle(u32 srcID)
if (fdf.err)
return fdf.err;
- retain_and_null_ptr(src_info);
+ owned_src_info = retain_and_null_ptr(src_info);
spin_lock(&hvpipe_src_list_lock);
/*
* If two processes are executing ioctl() for the same
@@ -520,7 +521,7 @@ static int papr_hvpipe_dev_create_handle(u32 srcID)
spin_unlock(&hvpipe_src_list_lock);
return -EALREADY;
}
- list_add(&src_info->list, &hvpipe_src_list);
+ list_add(&owned_src_info->list, &hvpipe_src_list);
spin_unlock(&hvpipe_src_list_lock);
return fd_publish(fdf);
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries/papr-hvpipe: fix NULL dereference in handle creation
From: Greg KH @ 2026-04-20 9:44 UTC (permalink / raw)
To: Guangshuo Li
Cc: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Mahesh Salgaonkar, Tyrel Datwyler,
Haren Myneni, Christian Brauner, Kees Cook, linuxppc-dev,
linux-kernel, stable
In-Reply-To: <20260420093856.123681-1-lgs201920130244@gmail.com>
On Mon, Apr 20, 2026 at 05:38:56PM +0800, Guangshuo Li wrote:
> papr_hvpipe_dev_create_handle() transfers ownership of src_info with
> retain_and_null_ptr(src_info) after anon_inode_getfile() succeeds.
> However, retain_and_null_ptr() clears src_info immediately, and the
> function then still dereferences src_info in the subsequent list_add().
>
> Store the transferred pointer in a separate variable and use that for
> the list insertion.
>
> Manually identified during code review.
>
> Fixes: 6d3789d347a7af5c4b0b2da3af47b8d9da607ab2 ("papr-hvpipe: convert papr_hvpipe_dev_create_handle() to FD_PREPARE()")
Please use the proper notation here, as the documentation asks you to.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix
From: Manivannan Sadhasivam @ 2026-04-20 9:44 UTC (permalink / raw)
To: Nitin Rawat
Cc: vkoul, neil.armstrong, konrad.dybcio, dmitry.baryshkov, abel.vesa,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 04:18:51PM +0530, Nitin Rawat wrote:
> Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared
> sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base
> table to fix Gear 4 operation on SM8650.
>
> However, this change inadvertently broke kaanapali and SM8750 SoCs
> which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5
> configuration but use their own sm8750_ufsphy_pcs base table. After the
> change, kaanapali PHYs are left without the required PLL_CNTL = 0x33
> setting, causing the PHY PLL to remain at its hardware reset default
> value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts.
>
> Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry
> to the sm8750_ufsphy_pcs table, mirroring what the original commit
> already did for sm8650_ufsphy_pcs.
>
> Cc: stable@vger.kernel.org # v6.19.12
> Fixes: 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
- Mani
> ---
> drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index 771bc7c2ab50..b87314c8379d 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -1112,6 +1112,7 @@ static const struct qmp_phy_init_tbl sm8750_ufsphy_pcs[] = {
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PCS_CTRL1, 0x40),
> + QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x33),
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0f),
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_SIGDET_CTRL2, 0x68),
> QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_POST_EMP_LVL_S4, 0x0e),
> --
> 2.34.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH net] netconsole: avoid out-of-bounds access on empty string in trim_newline()
From: Breno Leitao @ 2026-04-20 10:18 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Matthew Wood
Cc: netdev, linux-kernel, kernel-team, stable, Breno Leitao
trim_newline() unconditionally dereferences s[len - 1] after computing
len = strnlen(s, maxlen). When the string is empty, len is 0 and the
expression underflows to s[(size_t)-1], reading (and potentially
writing) one byte before the buffer.
The two callers feed trim_newline() with the result of strscpy() from
configfs store callbacks (dev_name_store, userdatum_value_store).
configfs guarantees count >= 1 reaches the callback, but the byte
itself can be NUL: a userspace write(fd, "\0", 1) leaves the
destination empty after strscpy() and triggers the underflow. The OOB
write only fires if the adjacent byte happens to be '\n', so this is
not a security issue, but the access is undefined behaviour either way.
This pattern is commonly flagged by LLM-based code reviewers. While it
is not a security fix, the underlying access is undefined behaviour and
the change is small and self-contained, so it is a reasonable candidate
for the stable trees.
Guard the dereference on a non-zero length.
Fixes: ae001dc67907 ("net: netconsole: move newline trimming to function")
Cc: stable@vger.kernel.org
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/netconsole.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 3c9acd6e49e86..205384dab89a6 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -497,6 +497,8 @@ static void trim_newline(char *s, size_t maxlen)
size_t len;
len = strnlen(s, maxlen);
+ if (!len)
+ return;
if (s[len - 1] == '\n')
s[len - 1] = '\0';
}
---
base-commit: c7275b05bc428c7373d97aa2da02d3a7fa6b9f66
change-id: 20260420-netcons_trim_newline-36f6ec3b9820
Best regards,
--
Breno Leitao <leitao@debian.org>
^ permalink raw reply related
* [PATCH] wifi: ath11k: fix warning when unbinding
From: Jose Ignacio Tornos Martinez @ 2026-04-20 11:01 UTC (permalink / raw)
To: jjohnson
Cc: linux-wireless, ath11k, linux-kernel,
Jose Ignacio Tornos Martinez, stable
If there is an error during some initialization related to firmware,
the buffers dp->tx_ring[i].tx_status are released.
However this is released again when the device is unbinded (ath11k_pci),
and we get:
WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
Call Trace:
free_large_kmalloc
ath11k_dp_free
ath11k_core_deinit
ath11k_pci_remove
...
The issue is always reproducible from a VM because the MSI addressing
initialization is failing.
In order to fix the issue, just set the buffers to NULL after releasing in
order to avoid the double free.
Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/wireless/ath/ath11k/dp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
index bbb86f165141..5a50b623bd07 100644
--- a/drivers/net/wireless/ath/ath11k/dp.c
+++ b/drivers/net/wireless/ath/ath11k/dp.c
@@ -1040,6 +1040,7 @@ void ath11k_dp_free(struct ath11k_base *ab)
idr_destroy(&dp->tx_ring[i].txbuf_idr);
spin_unlock_bh(&dp->tx_ring[i].tx_idr_lock);
kfree(dp->tx_ring[i].tx_status);
+ dp->tx_ring[i].tx_status = NULL;
}
/* Deinit any SOC level resource */
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1 2/2] drm/panfrost: Fix wait_bo ioctl leaking positive return from dma_resv_wait_timeout()
From: Steven Price @ 2026-04-20 11:18 UTC (permalink / raw)
To: Gyeyoung Baek, Tomeu Vizoso, Boris Brezillon, Rob Herring,
Adrián Larumbe
Cc: Oded Gabbay, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, dri-devel, linux-kernel, stable
In-Reply-To: <fe33f82fded7be1c18e2e0eb2db451d5a738cf39.1776581974.git.gye976@gmail.com>
On 19/04/2026 08:17, Gyeyoung Baek wrote:
> dma_resv_wait_timeout() returns a positive 'remaining jiffies' value
> on success, 0 on timeout, and -errno on failure.
>
> panfrost_ioctl_wait_bo() returns this 'long' result from an int-typed
> ioctl handler, so positive values reach userspace as bogus errors.
> Explicitly set ret to 0 on the success path.
>
> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gyeyoung Baek <gye976@gmail.com>
Reviewed-by: Steven Price <steven.price@arm.com>
> ---
> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c
> index 3d0bdba2a..784e36d72 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_drv.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c
> @@ -390,6 +390,8 @@ panfrost_ioctl_wait_bo(struct drm_device *dev, void *data,
> true, timeout);
> if (!ret)
> ret = timeout ? -ETIMEDOUT : -EBUSY;
> + else if (ret > 0)
> + ret = 0;
>
> drm_gem_object_put(gem_obj);
>
^ permalink raw reply
* Re: [PATCH] phy: qcom-qmp-ufs: Fix kaanapali PHY PLL lock failure after SM8650 G4 fix
From: Abel Vesa @ 2026-04-20 11:30 UTC (permalink / raw)
To: Nitin Rawat
Cc: vkoul, neil.armstrong, konrad.dybcio, dmitry.baryshkov, mani,
linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260415104851.2763238-1-nitin.rawat@oss.qualcomm.com>
On 26-04-15 16:18:51, Nitin Rawat wrote:
> Commit 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> moved QPHY_V6_PCS_UFS_PLL_CNTL register configuration from the shared
> sm8650_ufsphy_g5_pcs table to the SM8650-specific sm8650_ufsphy_pcs base
> table to fix Gear 4 operation on SM8650.
>
> However, this change inadvertently broke kaanapali and SM8750 SoCs
> which also rely on the shared sm8650_ufsphy_g5_pcs table for Gear 5
> configuration but use their own sm8750_ufsphy_pcs base table. After the
> change, kaanapali PHYs are left without the required PLL_CNTL = 0x33
> setting, causing the PHY PLL to remain at its hardware reset default
> value, preventing PLL lock and resulting in DME_LINKSTARTUP timeouts.
>
> Fix this by adding the missing QPHY_V6_PCS_UFS_PLL_CNTL = 0x33 entry
> to the sm8750_ufsphy_pcs table, mirroring what the original commit
> already did for sm8650_ufsphy_pcs.
>
> Cc: stable@vger.kernel.org # v6.19.12
> Fixes: 81af9e40e2e4 ("phy: qcom: qmp-ufs: Fix SM8650 PCS table for Gear 4")
> Signed-off-by: Nitin Rawat <nitin.rawat@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
^ 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