* Re: [PATCH v2 7/7] commit-reach: terminate merge-base walk when one paint side is exhausted
From: Derrick Stolee @ 2026-06-24 15:07 UTC (permalink / raw)
To: Kristofer Karlsson
Cc: Kristofer Karlsson via GitGitGadget, git, Elijah Newren
In-Reply-To: <CAL71e4N1zMz=v9umGdGPTvLP1nF-tNLVQc+vAEBnekt2L0b6zQ@mail.gmail.com>
On 6/24/2026 10:47 AM, Kristofer Karlsson wrote:
> On Wed, 24 Jun 2026 at 16:02, Derrick Stolee <stolee@gmail.com> wrote:
>>> - test_trace2_data paint_down_to_common steps 81 <trace-half.txt
>>> + test_trace2_data paint_down_to_common steps 57 <trace-half.txt
>>> '
>> I love to see these steps change. If you take my suggestion to
>> update more tests with these checks, then this diff will get bigger
>> (but in a deserved way).
>
> I will try to add them to some (but not all) tests since it's more
> closely related to performance than correctness and I want to
> avoid making too many tests overly fragile.
In this case, I think it's more about protecting all of our special-
cased termination conditions. The rigidity means that it is hard to
accidentally change the behavior. It does have the downside that
more tests need to change if there is an intentional change, but it
also gives the same _evidence_ that the change has the intended
impact.
We are definitely leaning into personal preferences, though. There
is no hard rule one way or another.
Thanks,
-Stolee
^ permalink raw reply
* Re: [PATCH v2 2/4] mm: drop stale folio_ref_count()==1 check in do_swap_page reuse logic
From: David Hildenbrand (Arm) @ 2026-06-24 15:07 UTC (permalink / raw)
To: Barry Song (Xiaomi), akpm, linux-mm
Cc: baoquan.he, chrisl, jp.kobryn, kasong, liam, linux-kernel, ljs,
mhocko, nphamcs, rppt, shakeel.butt, shikemeng, surenb,
usama.arif, vbabka, youngjun.park
In-Reply-To: <20260623231635.43086-3-baohua@kernel.org>
On 6/24/26 01:16, Barry Song (Xiaomi) wrote:
> The "we just allocated them without exposing them to the swapcache"
> case no longer exists, as Kairui has routed synchronous I/O through
> the swapcache as well in his series "unify swapin use swap cache and
> cleanup flags"[1]. As a result, folio_ref_count() should never be 1
> in this path, since at least two references are held (base ref plus
> swapcache). Remove the folio_ref_count()==1 check and update the
> comment accordingly.
>
> [1] https://lore.kernel.org/all/20251220-swap-table-p2-v5-0-8862a265a033@tencent.com/
>
> Acked-by: Usama Arif <usama.arif@linux.dev>
> Reviewed-by: Kairui Song <kasong@tencent.com>
> Reviewed-by: Baoquan He <baoquan.he@linux.dev>
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> ---
> mm/memory.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index f6848f4234a6..abd0adcf65f0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -5049,12 +5049,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>
> /*
> * Same logic as in do_wp_page(); however, optimize for pages that are
s/Same/Similar/ ?
> - * certainly not shared either because we just allocated them without
> - * exposing them to the swapcache or because the swap entry indicates
> - * exclusivity.
> + * certainly not because the swap entry indicates exclusivity.
> */
> - if (!folio_test_ksm(folio) &&
> - (exclusive || folio_ref_count(folio) == 1)) {
> + if (!folio_test_ksm(folio) && exclusive) {
Hmm, but KSM folios should never have "exclusive" set. So I think you can drop
that as well (was only relevant with folio_ref_count==1 check IIRC).
--
Cheers,
David
^ permalink raw reply
* [PATCH v3 0/3] Add and use abstraction for synchronize_rcu()
From: Philipp Stanner @ 2026-06-24 15:07 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
Philipp Stanner
Cc: rust-for-linux, linux-kernel, linux-fsdevel, rcu
Changes since v2:
- Compromise docu for "RCU versus atomic context" a bit better
- Add respective R-b's
Changes since v1:
- Vertically format imports. (Onur)
- Make the new function #[inline]. (Alice)
- Add Alice's R-b.
Philipp Stanner (3):
rust: sync: Add abstraction for synchronize_rcu()
rust: revocable: Use safe synchronize_rcu() abstraction
rust: sync: Use safe synchronize_rcu() abstraction in poll
rust/kernel/revocable.rs | 9 ++++++---
rust/kernel/sync/poll.rs | 10 ++++++----
rust/kernel/sync/rcu.rs | 16 ++++++++++++++++
3 files changed, 28 insertions(+), 7 deletions(-)
base-commit: 43a393185e33e573a374c1d4f7ddf6481484ef8d
--
2.54.0
^ permalink raw reply
* [PATCH v3 1/3] rust: sync: Add abstraction for synchronize_rcu()
From: Philipp Stanner @ 2026-06-24 15:07 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
Philipp Stanner
Cc: rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <20260624150704.1504001-2-phasta@kernel.org>
synchronize_rcu() is a frequently used C function which is always safe
to be called.
Add a safe abstraction for synchronize_rcu().
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
---
rust/kernel/sync/rcu.rs | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/rust/kernel/sync/rcu.rs b/rust/kernel/sync/rcu.rs
index a32bef6e490b..2bae76d229f0 100644
--- a/rust/kernel/sync/rcu.rs
+++ b/rust/kernel/sync/rcu.rs
@@ -50,3 +50,19 @@ fn drop(&mut self) {
pub fn read_lock() -> Guard {
Guard::new()
}
+
+/// Wait for one RCU grace period.
+///
+/// Waits for all RCU read-side critical sections (such as those established by
+/// a [`rcu::Guard`]) at the moment of the function call to finish.
+///
+/// Does not prevent new read-side critical sections from starting, which may
+/// begin and run while this call is blocking.
+///
+/// Note that this is one of the RCU primitives which must not be called in
+/// atomic context.
+#[inline]
+pub fn synchronize_rcu() {
+ // SAFETY: `synchronize_rcu()` is always safe to be called from process context.
+ unsafe { bindings::synchronize_rcu() };
+}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 2/3] clk: qcom: camcc-glymur: Add camera clock controller driver
From: sashiko-bot @ 2026-06-24 15:08 UTC (permalink / raw)
To: Jagadeesh Kona; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260624-glymur_camcc-v5-2-a321df74b1a1@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Incorrect register offsets for CSI4 clocks due to a copy-paste error.
- [High] Missing `cam_cc_pll2_out_even` struct definition resulting in incorrect CCF frequency calculation for EVEN PLL output.
--
commit 4ff3f366f401331dcb96c0eb65a3236a34345740
Author: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
clk: qcom: camcc-glymur: Add camera clock controller driver
Add support for the camera clock controller for camera clients
to be able to request for camcc clocks on Glymur platform.
> diff --git a/drivers/clk/qcom/camcc-glymur.c b/drivers/clk/qcom/camcc-glymur.c
> new file mode 100644
> index 0000000000000..a80f05b7bc484
> --- /dev/null
> +++ b/drivers/clk/qcom/camcc-glymur.c
[ ... ]
> @@ -0,0 +1,2280 @@
[ ... ]
> +static const struct parent_map cam_cc_parent_map_1[] = {
> + { P_BI_TCXO, 0 },
> + { P_CAM_CC_PLL2_OUT_EVEN, 3 },
> + { P_CAM_CC_PLL2_OUT_MAIN, 5 },
> +};
> +
> +static const struct clk_parent_data cam_cc_parent_data_1[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &cam_cc_pll2.clkr.hw },
> + { .hw = &cam_cc_pll2.clkr.hw },
[Severity: High]
Does this code miss the cam_cc_pll2_out_even struct definition?
Index 1 should point to &cam_cc_pll2_out_even.clkr.hw to represent the divided
EVEN output of the PLL. The duplicated pointer results in the Common Clock
Framework seeing the raw PLL rate without division. When a clock relying on this
parent map switches to the EVEN hardware mux, the framework might calculate the
downstream clock is running at twice its actual hardware frequency.
> +};
[ ... ]
> +static struct clk_rcg2 cam_cc_csi4phytimer_clk_src = {
> + .cmd_rcgr = 0x15124,
[Severity: High]
Are these register offsets correct for the CSI4 PHY timer clock source?
On identical or highly similar reference hardware designs, offsets 0x15124,
0x15250, and 0x15254 map to the CSI2 PHY branch and timer clocks, while
CSI4 is typically mapped to 0x1538c, 0x154b8, and 0x154bc.
Writing configuration to these offsets for CSI4 might incorrectly modify CSI2
clock registers, preventing the CSI4 camera interface from being clocked
properly and potentially inducing unintended behavior on the CSI2 IP block.
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = cam_cc_parent_map_0,
> + .freq_tbl = ftbl_cam_cc_csi0phytimer_clk_src,
[ ... ]
> +static struct clk_branch cam_cc_csi4phytimer_clk = {
> + .halt_reg = 0x15250,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x15250,
[Severity: High]
Could this offset be incorrect as well? As mentioned above, 0x15250 usually
corresponds to the CSI2 PHY timer branch clock.
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "cam_cc_csi4phytimer_clk",
[ ... ]
> +static struct clk_branch cam_cc_csiphy4_clk = {
> + .halt_reg = 0x15254,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x15254,
[Severity: High]
Is this the correct offset for the CSI4 PHY branch clock? It seems this might
also be pointing to the CSI2 PHY branch clock.
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "cam_cc_csiphy4_clk",
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-glymur_camcc-v5-0-a321df74b1a1@oss.qualcomm.com?part=2
^ permalink raw reply
* [PATCH v3 2/3] rust: revocable: Use safe synchronize_rcu() abstraction
From: Philipp Stanner @ 2026-06-24 15:07 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
Philipp Stanner
Cc: rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <20260624150704.1504001-2-phasta@kernel.org>
We now have a safe wrapper for the foreign function synchronize_rcu().
Use it in revocable.rs.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
---
rust/kernel/revocable.rs | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/rust/kernel/revocable.rs b/rust/kernel/revocable.rs
index 0f4ae673256d..f539603349f1 100644
--- a/rust/kernel/revocable.rs
+++ b/rust/kernel/revocable.rs
@@ -7,7 +7,11 @@
use pin_init::Wrapper;
-use crate::{bindings, prelude::*, sync::rcu, types::Opaque};
+use crate::{
+ prelude::*,
+ sync::rcu,
+ types::Opaque, //
+};
use core::{
marker::PhantomData,
ops::Deref,
@@ -161,8 +165,7 @@ unsafe fn revoke_internal<const SYNC: bool>(&self) -> bool {
if revoke {
if SYNC {
- // SAFETY: Just an FFI call, there are no further requirements.
- unsafe { bindings::synchronize_rcu() };
+ rcu::synchronize_rcu();
}
// SAFETY: We know `self.data` is valid because only one CPU can succeed the
--
2.54.0
^ permalink raw reply related
* [PATCH v3 3/3] rust: sync: Use safe synchronize_rcu() abstraction in poll
From: Philipp Stanner @ 2026-06-24 15:07 UTC (permalink / raw)
To: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Daniel Almeida, Tamir Duberstein,
Alexandre Courbot, Onur Özkan, Alexander Viro,
Christian Brauner, Jan Kara, Lyude Paul, Paul E. McKenney,
Frederic Weisbecker, Neeraj Upadhyay, Joel Fernandes,
Josh Triplett, Uladzislau Rezki, Steven Rostedt,
Mathieu Desnoyers, Lai Jiangshan, Zqiang, Christian Schrefl,
Philipp Stanner
Cc: rust-for-linux, linux-kernel, linux-fsdevel, rcu
In-Reply-To: <20260624150704.1504001-2-phasta@kernel.org>
We now have a safe wrapper for the foreign function synchronize_rcu().
Use it in poll.rs.
Signed-off-by: Philipp Stanner <phasta@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Onur Özkan <work@onurozkan.dev>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Gary Guo <gary@garyguo.net>
---
rust/kernel/sync/poll.rs | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/rust/kernel/sync/poll.rs b/rust/kernel/sync/poll.rs
index 0ec985d560c8..30ebeea1702f 100644
--- a/rust/kernel/sync/poll.rs
+++ b/rust/kernel/sync/poll.rs
@@ -8,7 +8,11 @@
bindings,
fs::File,
prelude::*,
- sync::{CondVar, LockClassKey},
+ sync::{
+ CondVar,
+ LockClassKey,
+ rcu::synchronize_rcu, //
+ }, //
};
use core::{marker::PhantomData, ops::Deref};
@@ -99,8 +103,6 @@ fn drop(self: Pin<&mut Self>) {
unsafe { bindings::__wake_up_pollfree(self.inner.wait_queue_head.get()) };
// Wait for epoll items to be properly removed.
- //
- // SAFETY: Just an FFI call.
- unsafe { bindings::synchronize_rcu() };
+ synchronize_rcu();
}
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v5 1/9] mm/memory: add memory_block_aligned_range() helper
From: sashiko-bot @ 2026-06-24 15:08 UTC (permalink / raw)
To: Gregory Price; +Cc: linux-cxl, nvdimm
In-Reply-To: <20260624145744.3532049-2-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but elevating the math into a generic helper codifies a vulnerability: boundary calculations in `memory_block_aligned_range()` can mathematically underflow or overflow, bypassing the recommended validity check and producing massive invalid ranges.
--
commit 6ed2cd40240e54e5a9638798bd15e535e425a3da
Author: Gregory Price <gourry@gourry.net>
mm/memory: add memory_block_aligned_range() helper
Memory hotplug operations require ranges aligned to memory block
boundaries. This is a generic operation for hotplug. Add
memory_block_aligned_range() as a common helper in <linux/memory.h>
that aligns the start address up and end address down to memory block
boundaries. Update dax/kmem to use this helper.
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index a18e2b968e4da..592171ec10f49 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
[ ... ]
> @@ -33,9 +33,7 @@ static int dax_kmem_range(struct dev_dax *dev_dax, int i, struct range *r)
> struct dev_dax_range *dax_range = &dev_dax->ranges[i];
> struct range *range = &dax_range->range;
>
> - /* memory-block align the hotplug range */
> - r->start = ALIGN(range->start, memory_block_size_bytes());
> - r->end = ALIGN_DOWN(range->end + 1, memory_block_size_bytes()) - 1;
> + *r = memory_block_aligned_range(range);
> if (r->start >= r->end) {
> r->start = range->start;
> r->end = range->end;
[ ... ]
> diff --git a/include/linux/memory.h b/include/linux/memory.h
> index 463dc02f6cff0..9f5ef0309f773 100644
> --- a/include/linux/memory.h
> +++ b/include/linux/memory.h
[ ... ]
> @@ -100,6 +101,27 @@ int arch_get_memory_phys_device(unsigned long start_pfn);
> unsigned long memory_block_size_bytes(void);
> int set_memory_block_size_order(unsigned int order);
>
> +/**
> + * memory_block_aligned_range - align a physical address range to memory blocks
> + * @range: the input range to align
> + *
> + * Aligns the start address up and the end address down to memory block
> + * boundaries. This is required for memory hotplug operations which must
> + * operate on memory-block aligned ranges.
> + *
> + * Returns the aligned range. Callers should check that the returned
> + * range is valid (aligned.start < aligned.end) before using it.
> + */
> +static inline struct range memory_block_aligned_range(const struct range *range)
> +{
> + struct range aligned;
> +
> + aligned.start = ALIGN(range->start, memory_block_size_bytes());
> + aligned.end = ALIGN_DOWN(range->end + 1, memory_block_size_bytes()) - 1;
[Severity: High]
This isn't a bug introduced by this patch, but elevating the math into a
generic helper codifies an issue. Could this boundary calculation underflow
and produce massive invalid ranges?
If a caller provides an unaligned physical address range that falls entirely
before the first memory block boundary, for example when
range->end + 1 < memory_block_size_bytes(), the ALIGN_DOWN calculation
evaluates to 0.
Subtracting 1 then causes aligned.end to underflow to U64_MAX.
While it is physically unlikely for a DAX device to be located below 128MB,
an edge case near physical address 0 triggers this underflow.
When this happens, the invalid range check in dax_kmem_range() is bypassed:
drivers/dax/kmem.c:dax_kmem_range() {
...
*r = memory_block_aligned_range(range);
if (r->start >= r->end) {
...
}
Because r->end evaluates to U64_MAX and aligned.start aligns up to 128MB
(if range->start > 0), the check 128MB >= U64_MAX is false. This incorrectly
signals the empty range as valid and aligned.
In contrast, an empty range in a higher memory block correctly fails this
check.
If this underflowed range is then passed to hotplug APIs like
__add_memory_driver_managed(), could it cause an immediate OOM and kernel
crash as the system attempts to allocate tracking structures for millions of
memory blocks?
> +
> + return aligned;
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145744.3532049-1-gourry@gourry.net?part=1
^ permalink raw reply
* Re: [PATCH] test/cxl-mbox: Regression test for huge CXL_MEM_SEND_COMMAND out.size
From: sashiko-bot @ 2026-06-24 15:08 UTC (permalink / raw)
To: Richard Cheng; +Cc: linux-cxl, nvdimm
In-Reply-To: <20260624145843.55116-1-icheng@nvidia.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] User-space ndctl test patch mistakenly submitted to the Linux kernel tree.
- [Medium] Brittle error handling in test script module loading.
--
commit d71b88195f1dc438adbcafc668b1cd91cd8a75fe
Author: Richard Cheng <icheng@nvidia.com>
test/cxl-mbox: Regression test for huge CXL_MEM_SEND_COMMAND out.size
This commit introduces a regression test for a CXL mailbox issue where a huge
out.size parameter could trigger a size > INT_MAX kvmalloc() WARN. The test
uses the cxl_test mock memdev and directly issues the CXL_MEM_SEND_COMMAND
ioctl.
Link: https://lore.kernel.org/all/20260624144147.53997-1-icheng@nvidia.com/
> diff --git a/test/cxl-mbox.c b/test/cxl-mbox.c
> new file mode 100644
> index 0000000000000..d81327ba17df4
> --- /dev/null
> +++ b/test/cxl-mbox.c
> @@ -0,0 +1,129 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2026 Nvidia Corporation. All rights reserved.
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <stdio.h>
> +#include <stdint.h>
> +#include <stddef.h>
> +#include <stdlib.h>
> +#include <syslog.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <sys/ioctl.h>
> +#include <cxl/libcxl.h>
[Severity: Medium]
Is this test actually intended for the ndctl repository rather than the Linux
kernel tree? It looks like it includes <cxl/libcxl.h>, which is an ndctl
user-space library header not present in the Linux kernel tree.
[ ... ]
> diff --git a/test/cxl-mbox.sh b/test/cxl-mbox.sh
> new file mode 100755
> index 0000000000000..67fecf5a3f46f
> --- /dev/null
> +++ b/test/cxl-mbox.sh
> @@ -0,0 +1,48 @@
> +#!/bin/bash -Ex
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2026 Nvidia Corporation. All rights reserved.
> +
> +. $(dirname "$0")/common
[Severity: Medium]
Does this source a 'common' test framework script from ndctl that does not
exist in the kernel tree?
> +
> +BIN="$TEST_PATH"/cxl-mbox
> +rc=77
> +# 237 is -ENODEV
> +ERR_NODEV=237
> +# TAINT_WARN is bit 9
> +TAINT_WARN=512
> +
> +trap 'err $LINENO' ERR
> +
> +modprobe -r cxl_test 2>/dev/null
> +modprobe cxl_test
> +# cxl_test alone does not autoload the mock memdev module on this box
> +modprobe cxl_mock_mem
[Severity: Medium]
Because this script runs with set -e (from the #!/bin/bash -Ex line), will
these unprotected modprobe commands immediately trigger the ERR trap and
abort the script if the modules are missing, instead of gracefully skipping
the test?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145843.55116-1-icheng@nvidia.com?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-24 15:08 UTC (permalink / raw)
To: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Leo Yan,
Yuanfang Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <471d7a92-3629-4274-a303-8906d3626037@arm.com>
On 6/24/2026 9:51 PM, Suzuki K Poulose wrote:
> On 24/06/2026 14:48, Jie Gan wrote:
>>
>>
>> On 6/24/2026 9:27 PM, Konrad Dybcio wrote:
>>> On 6/24/26 11:49 AM, Jie Gan wrote:
>>>> The AMBA bus attempts to read the CID/PID of a device before invoking
>>>> its probe function if the arm,primecell-periphid property is absent.
>>>> This causes a deferred probe issue for the TraceNoC device, as the
>>>> CID/PID cannot be read from the periphid register.
>>>
>>> Why does it probe defer?
>>>
>>
>> For an AMBA device, the periphid is mandatory for probing. In the
>> amba_match function, AMBA attempts to read the periphid from the CID/
>> PID registers if the arm,primecell-periphid property is absent in the
>> device tree. If this read fails, it returns -EPROBE_DEFER, and the
>> probe ultimately fails.
>
> Why does it fail ? power management ? hw broken ? Is it really AMBA or
> do you pretend that to be an AMBA device by faking the CID/PID?
The CID reads as 0 from the register, which I suspect is a hardware
design issue. I have not yet confirmed this with the hardware team. As a
workaround, I provided a fake periphid via a DT property to bypass
amba_read_periphid.
Leo commented in other thread:
>>tnoc.c registers both an AMBA driver and a platform driver. Shouldn't
>>it
>>be registered as a platform device instead?
The platform driver is intended for the interconnect TraceNoC device and
is not designed to allocate an ATID. The issue is that the TPDM device
borrows the ATID from the TraceNoC device, resulting in the ATID always
being 0 when associated with an interconnect NoC device.
However, I believe it is acceptable to allocate an ATID for the itNoC
device and the issue can be fixed with this way.
Thanks,
Jie
>
> Suzuki
>
>
>> Most AMBA devices expose valid CID/PID registers, so specifying
>> arm,primecell-periphid in the device tree is usually unnecessary.
>> However, for the TraceNoC device in this case, AMBA cannot reliably
>> read the periphid from the corresponding registers.
>>
>>> And is this required for all TNOC devices?
>>
>> So far, the TNOC device has been added to sm8750, Glymur, and
>> Kaanapali platforms, and all exhibit probe failures due to the same
>> root cause.
>>
>> I prefer to fix it on Kaanapali first.
>>
>> Thanks,
>> Jie
>>
>>>
>>> Konrad
>>
>
^ permalink raw reply
* Re: [PATCH v5 7/9] dax/kmem: extract hotplug/hotremove helper functions
From: sashiko-bot @ 2026-06-24 15:09 UTC (permalink / raw)
To: Gregory Price; +Cc: nvdimm, linux-cxl
In-Reply-To: <20260624145744.3532049-8-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] dax_kmem_do_hotplug() unconditionally attempts to hotplug memory for all ranges without verifying successful resource reservation, leading to a permanent memory leak and potential use-after-free.
--
commit 5d9cdda5cefdb148a54897a713788ec98f55e42a
Author: Gregory Price <gourry@gourry.net>
dax/kmem: extract hotplug/hotremove helper functions
Refactor kmem _probe() _remove() by extracting init, cleanup, hotplug,
and hot-remove logic into separate helper functions:
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index 0a184c0878ddf..a45e50def5371 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
[ ... ]
> @@ -63,14 +63,195 @@ static void kmem_put_memory_types(void)
> mt_put_memory_types(&kmem_memory_types);
> }
>
> +/**
> + * dax_kmem_do_hotplug - hotplug memory for dax kmem device
> + * @dev_dax: the dev_dax instance
> + * @data: the dax_kmem_data structure with resource tracking
> + *
> + * Hotplugs all ranges in the dev_dax region as system memory.
> + *
> + * Returns the number of successfully mapped ranges, or negative error.
> + */
> +static int dax_kmem_do_hotplug(struct dev_dax *dev_dax,
> + struct dax_kmem_data *data,
> + int online_type)
> +{
> + struct device *dev = &dev_dax->dev;
> + int i, rc, onlined = 0;
> + mhp_t mhp_flags;
> +
> + for (i = 0; i < dev_dax->nr_range; i++) {
> + struct range range;
> +
> + rc = dax_kmem_range(dev_dax, i, &range);
> + if (rc)
> + continue;
> +
> + mhp_flags = MHP_NID_IS_MGID;
> + if (dev_dax->memmap_on_memory)
> + mhp_flags |= MHP_MEMMAP_ON_MEMORY;
> +
> + /*
> + * Ensure that future kexec'd kernels will not treat
> + * this as RAM automatically.
> + */
> + rc = __add_memory_driver_managed(data->mgid, range.start,
> + range_len(&range), kmem_name, mhp_flags,
> + online_type);
[Severity: High]
Does this unconditionally add memory even for ranges that failed to reserve
resources?
If dax_kmem_init_resources() succeeds on the first range but fails on a
subsequent range, it leaves data->res[i] = NULL and continues because
mapped > 0.
Then dax_kmem_do_hotplug() iterates over all ranges again and unconditionally
calls __add_memory_driver_managed() for the range that failed reservation.
If memory addition succeeds, the memory is brought online without an I/O
resource reservation. Later, during device removal, dax_kmem_do_hotremove()
skips ranges where !data->res[i], which permanently leaks the online memory.
When the backing device is physically removed, any access to this memory
could cause a crash.
Should there be an if (!data->res[i]) continue; check here to ensure we only
hotplug memory for successfully reserved regions?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145744.3532049-1-gourry@gourry.net?part=7
^ permalink raw reply
* Re: [PATCH v2 3/3] iio: magnetometer: st_magn: honour st,fullscale-milligauss DT property
From: Jonathan Cameron @ 2026-06-24 15:09 UTC (permalink / raw)
To: me
Cc: github.com, Andy Shevchenko, David Lechner, Nuno Sá,
Andy Shevchenko, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, Denis Ciocca, Lars-Peter Clausen,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Denis Ciocca,
Linus Walleij, linux-iio, linux-kernel, llvm, devicetree
In-Reply-To: <edcf262b530a88ee602fa07edc8382ac@herrie.org>
On Wed, 24 Jun 2026 06:18:45 +0200
me@herrie.org wrote:
> On 2026-06-23 21:49, Andy Shevchenko wrote:
> > On Tue, Jun 23, 2026 at 08:29:16PM +0100, Jonathan Cameron wrote:
> >> On Tue, 16 Jun 2026 15:02:06 +0200
> >> Herman van Hazendonk <github.com@herrie.org> wrote:
> >>
> >> > The ST magnetometer core's common probe hardcodes fs_avl[0] -- the
> >> > highest-sensitivity full-scale supported by the chip -- as the
> >> > starting range. For the LSM303DLH that is +/-1.3 G; for the
> >> > LSM303DLHC and LSM303DLM it is +/-2 G; for the LIS3MDL it is +/-4 G.
> >> >
> >> > That is the right default for "minimal noise floor at a desk", but
> >> > it leaves no margin for boards that pick up appreciable DC bias from
> >> > nearby PCB structures. On the HP TouchPad (apq8060 / tenderloin) the
> >> > LSM303DLH magnetometer is mounted close enough to the surrounding
> >> > power planes that X reads back as the chip's 0xF000 overflow
> >> > sentinel (== -4096 raw, the value the chip publishes when the ADC
> >> > saturates) on every sample at the chip-default range, while Y and Z
> >> > fall well within the +/-1.3 G window.
> >> >
> >> > Parse the st,fullscale-milligauss device-tree property (documented
> >> > separately in dt-bindings/iio/st,st-sensors.yaml) in the
> >> > magnetometer common probe to select the initial fs_avl entry by its
> >> > mg value. The DT binding pins the accepted value set per compatible
> >> > via allOf/if-then enum clauses, so a malformed mg value fails
> >> > dt_binding_check rather than reaching the driver. Sensors with a
> >> > fixed full-scale (fs.addr == 0: LSM303AGR, LIS2MDL, IIS2MDC) have no
> >> > register to switch and the property is rejected outright for them
> >> > in the binding; the parse block is additionally gated on fs.addr as
> >> > defence in depth against stale DTBs.
> >> >
> >> > Per-sensor mg ranges are listed in st_magn_sensors_settings[]. For
> >> > LSM303DLH and LSM303DLHC/DLM the valid values are 1300, 1900, 2500,
> >> > 4000, 4700, 5600 and 8100; for LIS3MDL, LSM9DS1-magn and LSM303C-magn
> >> > they are 4000, 8000, 12000, 16000.
> >> >
> >> > Empirical scale sweep on the HP TouchPad confirmed that on this
> >> > board any fs_avl >= 1 produces non-saturated X readings:
> >> >
> >> > scale (0.001 G/LSB) | X raw Y raw Z raw
> >> > --------------------+-------------------------------
> >> > 1.100 | -4096 44 46 (X saturated)
> >> > 0.855 | -547 37 37 (clean)
> >> > 0.670 | -433 94 103 (clean)
> >> > 0.450 | -266 44 71 (clean)
> >> > 0.400 | -235 34 65 (clean)
> >> > 0.330 | -196 27 56 (clean)
> >> > 0.230 | -145 15 40 (clean)
> >> >
> >> > 2500 mg is the natural choice for tenderloin: comfortably outside
> >> > the saturation regime while keeping useful precision for compass
> >> > applications.
> >> >
> >> > Assisted-by: Claude:claude-opus-4-7 sparse smatch clang-analyzer coccinelle checkpatch
> >> > Assisted-by: Sashiko:claude-opus-4-7
> >> Hmm. First time I remember seeing Sashiko credited like this. Seems
> >> like pretty much
> >> every patch series of any complexity would end up crediting sashiko.
> >> Out of curiosity were you just looking at reports, or were you running
> >> it locally to
> >> help with development?
> >
> > I believe it's the second one, because LKML version uses Gemini (as far
> > as I
> > understand the case). At least that's why I haven't commented on this
> > tag.
> I have the whole toolchain running locally to avoid too many submissions
> and
> feedback from Sashiko with Gemini after submitting. For small drivers I
> can run
> Gemini locally as well, usually stick with Claude Opus 4.7 since that's
> what I
> have a subscription for. For very complicated and large drivers Claude
> Opus
> tends to time out even with 1 or 2 hour, so I fall back to Claude Haiku
> 4.5
> (which catches quite a few things, but is not as thorough as Opus or
> Gemini).
>
> Seeing Sashiko tends to provide different feedback on different rounds,
> I try
> to only submit when Sashiko and all others are clean.
>
> Hope this clarifies!
Thank! I loose track of all these models :) So the summary is very
useful. I've been meaning to get a similar flow in place myself for
checking local stuff (not that I'm doing any development at the moment)
Jonathan
>
> Herman
^ permalink raw reply
* Re: [PATCH v3 7/7] rust: io: mem: return DevresLt from IoMem/ExclusiveIoMem::into_devres()
From: Alexandre Courbot @ 2026-06-24 15:09 UTC (permalink / raw)
To: Danilo Krummrich
Cc: gregkh, rafael, ojeda, boqun, gary, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, ecourtney, m.wilczynski, david.m.ertman,
ira.weiny, leon, daniel.almeida, bhelgaas, kwilczynski,
driver-core, linux-kernel, nova-gpu, dri-devel, linux-pwm,
rust-for-linux
In-Reply-To: <20260618230834.812007-8-dakr@kernel.org>
On Fri Jun 19, 2026 at 8:08 AM JST, Danilo Krummrich wrote:
> Implement ForLt and CovariantForLt for IoMem<'static, SIZE> and
> ExclusiveIoMem<'static, SIZE> so that DevresLt can shorten the stored
> 'static lifetime back to the caller's borrow lifetime.
>
> CovariantForLt is sound because both types only hold &'a Device<Bound>,
> which is covariant over 'a.
>
> Since DevresLt::new() handles the lifetime transmutation internally,
> into_devres() no longer needs an explicit transmute to 'static.
>
> Add DevresIoMem<SIZE> and DevresExclusiveIoMem<SIZE> type aliases.
>
> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
^ permalink raw reply
* Re: [PATCH] x86/fred: Send an EVENT_CHECK IPI on exit from NMI
From: Andrew Cooper @ 2026-06-24 15:09 UTC (permalink / raw)
To: Jan Beulich
Cc: Andrew Cooper, Roger Pau Monné, Teddy Astie,
Oleksii Kurochko, Xen-devel
In-Reply-To: <a7ce9d22-7ab9-4638-8ffd-2ffb9bc55df9@suse.com>
On 24/06/2026 3:47 pm, Jan Beulich wrote:
> On 24.06.2026 16:23, Andrew Cooper wrote:
>> --- a/xen/arch/x86/x86_64/entry-fred.S
>> +++ b/xen/arch/x86/x86_64/entry-fred.S
>> @@ -20,6 +20,12 @@ FUNC(entry_FRED_R3, 4096)
>> GET_STACK_END(14)
>> movq STACK_CPUINFO_FIELD(current_vcpu)(%r14), %rbx
>>
>> + /* NMIs need special handling on return to guest. */
>> + movzbl UREGS_ss + 6(%rsp), %eax
>> + and $0xf, %eax
>> + cmp $X86_ET_NMI, %al
>> + je nmi_exit_to_guest
>> +
>> jmp test_all_events
> Actually, how about shrinking this to just
>
> test %al, %al
> jnz nmi_exit_to_guest
>
> by having entry_from_pv() return a boolean?
I considered that, and dismissed it.
It involve changing large chunks of traps.c (simply to compile) and puts
far more than 4 instructions of logic onto the common path.
~Andrew
^ permalink raw reply
* Re: [PATCH 26/37] drm: event-notifier: add mechanism to notify about hotplug events
From: Maxime Ripard @ 2026-06-24 15:09 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJ4EWMIX84PN.3VTENLJT2FWDH@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]
On Tue, Jun 09, 2026 at 11:30:52AM +0200, Luca Ceresoli wrote:
> On Mon Jun 8, 2026 at 2:13 PM CEST, Maxime Ripard wrote:
> > On Tue, May 19, 2026 at 12:37:43PM +0200, Luca Ceresoli wrote:
> >> In preparation for supporting DRM bridge hotplug, add an event notifier to
> >> allow interested parties to be notified about events they need to react to.
> >>
> >> For the initial implementation of bridge hotplug, two events are needed:
> >> bridge detach (happening in drm_bridge.c) and MIPI device attach to MIPI
> >> host (happening in drm_mipi_dsi.c).
> >>
> >> For this reason implement the event notifier in a new common file that
> >> event producers can easily use to send events.
> >>
> >> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> >
> > So, you claim in the commit message that it's about a hotplug event, but
> > the only events are the bridge being attached and detached, so not a
> > hotplug event?
> >
> > And why a bridge would want to be notified that itself (or another?)
> > bridge is being attached or detached?
> >
> > You need documentation, and a more descriptive commit message.
>
> Yes.
>
> But before that I need a decision about the scope we want to give to this
> notifier. It is a very generic module, with basically no dependencies, so
> people will try to add more unrelated events and we'd need to set a
> boundary.
>
> Options:
>
> * Should it be for hotplug-related events only?
> * Should it be for any DRM event that needs notifications?
> * Something else?
>
> I'm happy to write that in the docs and commit message once it's agreed, so
> any comments would be welcome right now.
At the end of the day, you'd be the first user of it, so you get to make
the rules, but they should be written down :)
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [ndctl PATCH RESEND] test/cxl-mbox: Regression test for huge CXL_MEM_SEND_COMMAND out.size
From: sashiko-bot @ 2026-06-24 15:09 UTC (permalink / raw)
To: Richard Cheng; +Cc: linux-cxl, nvdimm
In-Reply-To: <20260624150158.55264-1-icheng@nvidia.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Patch submitted to the wrong repository: adds `ndctl` userspace test files to the kernel tree.
--
commit a640ffeb53f9a730f09dcd04ab6a813beaced234
Author: Richard Cheng <icheng@nvidia.com>
test/cxl-mbox: Regression test for huge CXL_MEM_SEND_COMMAND out.size
This patch introduces a regression test for an unbounded kvzalloc() in
cxl_mbox_cmd_ctor(). It creates a raw struct cxl_send_command and issues
the ioctl directly against the cxl_test mock memdev.
Link: https://lore.kernel.org/all/20260624144147.53997-1-icheng@nvidia.com/
> diff --git a/test/cxl-mbox.c b/test/cxl-mbox.c
> new file mode 100644
> index 0000000000000..d81327ba17df4
> --- /dev/null
> +++ b/test/cxl-mbox.c
> @@ -0,0 +1,129 @@
[ ... ]
> +#include <string.h>
> +#include <unistd.h>
> +#include <sys/ioctl.h>
> +#include <cxl/libcxl.h>
[Severity: Low]
Was this patch intended for the ndctl repository instead of the Linux
kernel tree? This includes an ndctl userspace library header that does
not exist in the kernel tree.
> +#include <cxl/cxl_mem.h>
> +
> +static const char provider[] = "cxl_test";
[ ... ]
> diff --git a/test/cxl-mbox.sh b/test/cxl-mbox.sh
> new file mode 100755
> index 0000000000000..67fecf5a3f46f
> --- /dev/null
> +++ b/test/cxl-mbox.sh
> @@ -0,0 +1,48 @@
> +#!/bin/bash -Ex
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2026 Nvidia Corporation. All rights reserved.
> +
> +. $(dirname "$0")/common
[Severity: Low]
Does this code rely on an ndctl test dependency script that is absent from
the kernel tree? It looks like both this script and the C file above are
userspace tests belonging to the ndctl project rather than the kernel.
> +
> +BIN="$TEST_PATH"/cxl-mbox
> +rc=77
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624150158.55264-1-icheng@nvidia.com?part=1
^ permalink raw reply
* Re: [PATCH v2] block: serialize elevator changes for the same queue using a writer lock
From: Ming Lei @ 2026-06-24 15:09 UTC (permalink / raw)
To: Shin'ichiro Kawasaki; +Cc: linux-block, Jens Axboe, Nilay Shroff
In-Reply-To: <ajvCBkxdTCNt9JWI@shinmob>
On Wed, Jun 24, 2026 at 08:48:16PM +0900, Shin'ichiro Kawasaki wrote:
> On Jun 24, 2026 / 04:44, Ming Lei wrote:
> > On Tue, Jun 23, 2026 at 10:32:38AM +0900, Shin'ichiro Kawasaki wrote:
> [...]
> > > Please refer to [1] for details of the failure. Also, I created a
> > > blktests test case that recreates the hang [2], which I used to test the
> > > fix.
> > >
> > > * Changes from RFC v1
> > > - Instead of adding a new mutex to struct request_queue, replace the
> > > reader lock on update_nr_hwq_lock with the writer lock in
> > > elv_iosched_store().
> > >
> > > [1] https://lore.kernel.org/linux-block/20260611074200.474676-1-shinichiro.kawasaki@wdc.com/
> > > [2] https://github.com/kawasaki/blktests/commit/8e80b3ccc0bbbe3f209d00eacd138d020de97fc6
> > >
> > > block/elevator.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> [...]
> > I feel this is still abuse of the above lock, which serves writer vs
> > reader wrt. updating hw queue.
> >
> > How about the following fix?
>
> (snip)
>
> Thank you for the idea. I applied the suggested fix on top of the v7.1 kernel,
> and ran the test case that does the concurrent write to the sysfs sched file
> [2]. Unfortunately, the test case hung. Before the hang, the kernel reported
> WARNs in sysfs_create_dir_ns() [3]. KASAN slab-use-after-free was observed also.
> I also noticed that another WARN was observed during boot [4].
Looks this change isn't enough, and it is a bit hard to deal with the
two-stage switch by re-lock, and it may require sched debugfs & elevator queue
reg/unreg refactor.
Let's fix with your simpler way first.
Thanks,
Ming
^ permalink raw reply
* Re: [PATCH v5 13/16] media: iris: Introduce buffer size calculations for AR50LT
From: Vikash Garodia @ 2026-06-24 15:10 UTC (permalink / raw)
To: Dmitry Baryshkov, Abhinav Kumar, Bryan O'Donoghue,
Mauro Carvalho Chehab, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vishnu Reddy
Cc: linux-media, linux-arm-msm, linux-kernel, devicetree,
Dikshita Agarwal
In-Reply-To: <20260616-iris-ar50lt-v5-13-583b42770b6a@oss.qualcomm.com>
On 6/16/2026 5:34 AM, Dmitry Baryshkov wrote:
> From: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
>
> Introduces AR50LT buffer size calculation for both encoder and
> decoder. Reuse the buffer size calculation which are common, while
> adding the AR50LT specific ones separately.
>
> Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/media/platform/qcom/iris/iris_vpu_buffer.c | 401 +++++++++++++++++++++
> drivers/media/platform/qcom/iris/iris_vpu_buffer.h | 37 ++
> 2 files changed, 438 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> index 4a39b8fef52b..ca03d6570513 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> @@ -50,6 +50,32 @@ static u32 hfi_buffer_bin_h264d(u32 frame_width, u32 frame_height, u32 num_vpp_p
> return size_h264d_hw_bin_buffer(n_aligned_w, n_aligned_h, num_vpp_pipes);
> }
>
> +static u32 size_h264d_hw_bin_buffer_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size_bin_hdr, size_bin_res;
> +
> + size_yuv = ((frame_width * frame_height * 3) >> 1);
> + if (size_yuv <= 1920 * 1088 * 3 / 2) {
> + size_bin_hdr = size_yuv * H264_CABAC_HDR_RATIO_SM_TOT;
> + size_bin_res = size_yuv * H264_CABAC_RES_RATIO_SM_TOT;
> + } else {
> + size_bin_hdr = (size_yuv * 3) / 5;
> + size_bin_res = (size_yuv * 3) / 2;
> + }
> + size_bin_hdr = ALIGN(size_bin_hdr, DMA_ALIGNMENT);
> + size_bin_res = ALIGN(size_bin_res, DMA_ALIGNMENT);
> +
> + return size_bin_hdr + size_bin_res;
> +}
> +
> +static u32 hfi_buffer_bin_h264d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 n_aligned_h = ALIGN(frame_height, 16);
> + u32 n_aligned_w = ALIGN(frame_width, 16);
> +
> + return size_h264d_hw_bin_buffer_ar50lt(n_aligned_w, n_aligned_h, num_vpp_pipes);
> +}
> +
> static u32 size_av1d_hw_bin_buffer(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 size_yuv, size_bin_hdr, size_bin_res;
> @@ -103,6 +129,21 @@ static u32 hfi_buffer_bin_vp9d(u32 frame_width, u32 frame_height, u32 num_vpp_pi
> return _size * num_vpp_pipes;
> }
>
> +static u32 hfi_buffer_bin_vp9d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size;
> +
> + size_yuv = ALIGN(frame_width, 16) * ALIGN(frame_height, 16) * 3 / 2;
> + size_yuv = ALIGN(size_yuv, DMA_ALIGNMENT);
> +
> + size = ALIGN(((((MAX(size_yuv, VPX_DECODER_FRAME_BIN_BUFFER_SIZE)) * 6) / 5) /
MAX() or max() ?
> + num_vpp_pipes), DMA_ALIGNMENT) +
> + ALIGN((((MAX(size_yuv, VPX_DECODER_FRAME_BIN_BUFFER_SIZE)) * 4) / num_vpp_pipes),
> + DMA_ALIGNMENT);
> +
> + return size * num_vpp_pipes;
> +}
> +
> static u32 hfi_buffer_bin_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 n_aligned_w = ALIGN(frame_width, 16);
> @@ -111,6 +152,32 @@ static u32 hfi_buffer_bin_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_p
> return size_h265d_hw_bin_buffer(n_aligned_w, n_aligned_h, num_vpp_pipes);
> }
>
> +static u32 size_h265d_hw_bin_buffer_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_yuv, size_bin_hdr, size_bin_res;
> +
> + size_yuv = ((frame_width * frame_height * 3) >> 1);
> + if (size_yuv <= ((BIN_BUFFER_THRESHOLD * 3) >> 1)) {
> + size_bin_hdr = size_yuv * H265_CABAC_HDR_RATIO_SM_TOT;
> + size_bin_res = size_yuv * H265_CABAC_RES_RATIO_SM_TOT;
> + } else {
> + size_bin_hdr = (size_yuv * 41) / 50;
> + size_bin_res = (size_yuv * 59) / 50;
> + }
> + size_bin_hdr = ALIGN(size_bin_hdr, DMA_ALIGNMENT);
> + size_bin_res = ALIGN(size_bin_res, DMA_ALIGNMENT);
> +
> + return size_bin_hdr + size_bin_res;
> +}
> +
> +static u32 hfi_buffer_bin_h265d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 n_aligned_w = ALIGN(frame_width, 16);
> + u32 n_aligned_h = ALIGN(frame_height, 16);
> +
> + return size_h265d_hw_bin_buffer_ar50lt(n_aligned_w, n_aligned_h, num_vpp_pipes);
> +}
> +
> static u32 hfi_buffer_comv_h264d(u32 frame_width, u32 frame_height, u32 _comv_bufcount)
> {
> u32 frame_height_in_mbs = DIV_ROUND_UP(frame_height, 16);
> @@ -174,6 +241,14 @@ static u32 size_h264d_bse_cmd_buf(u32 frame_height)
> SIZE_H264D_BSE_CMD_PER_BUF;
> }
>
> +static u32 size_h264d_bse_cmd_buf_ar50lt(u32 frame_height)
> +{
> + u32 height = ALIGN(frame_height, 32);
> +
> + return min_t(u32, (DIV_ROUND_UP(height, 16) * 12), H264D_MAX_SLICE) *
> + SIZE_H264D_BSE_CMD_PER_BUF;
> +}
> +
> static u32 size_h265d_bse_cmd_buf(u32 frame_width, u32 frame_height)
> {
> u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> @@ -185,6 +260,18 @@ static u32 size_h265d_bse_cmd_buf(u32 frame_width, u32 frame_height)
> return _size;
> }
>
> +static u32 size_h265d_bse_cmd_buf_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS)) *
> + NUM_HW_PIC_BUF, DMA_ALIGNMENT);
> +
> + _size = min_t(u32, _size, H265D_MAX_SLICE_AR50LT + 1);
> + _size = 2 * _size * SIZE_H265D_BSE_CMD_PER_BUF;
> +
> + return _size;
> +}
> +
> static u32 hfi_buffer_persist_h265d(u32 rpu_enabled)
> {
> return ALIGN((SIZE_SLIST_BUF_H265 * NUM_SLIST_BUF_H265 +
> @@ -195,6 +282,13 @@ static u32 hfi_buffer_persist_h265d(u32 rpu_enabled)
> DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_persist_h265d_ar50lt(void)
> +{
> + return ALIGN((SIZE_SLIST_BUF_H265 * NUM_SLIST_BUF_H265 +
> + H265_NUM_TILE * sizeof(u32) + NUM_HW_PIC_BUF * SIZE_SEI_USERDATA),
> + DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 hfi_iris3_vp9d_comv_size(void)
> {
> @@ -212,6 +306,13 @@ static u32 hfi_buffer_persist_vp9d(void)
> HDR10_HIST_EXTRADATA_SIZE;
> }
>
> +static u32 hfi_buffer_persist_vp9d_ar50lt(void)
> +{
> + return ALIGN(VP9_NUM_PROBABILITY_TABLE_BUF * VP9_PROB_TABLE_SIZE, DMA_ALIGNMENT) +
> + ALIGN(hfi_iris3_vp9d_comv_size(), DMA_ALIGNMENT) +
> + ALIGN(MAX_SUPERFRAME_HEADER_LEN, DMA_ALIGNMENT);
> +}
> +
> static u32 size_h264d_vpp_cmd_buf(u32 frame_height)
> {
> u32 size, height = ALIGN(frame_height, 32);
> @@ -222,6 +323,16 @@ static u32 size_h264d_vpp_cmd_buf(u32 frame_height)
> return size > VPP_CMD_MAX_SIZE ? VPP_CMD_MAX_SIZE : size;
> }
>
> +static u32 size_h264d_vpp_cmd_buf_ar50lt(u32 frame_height)
> +{
> + u32 size, height = ALIGN(frame_height, 32);
> +
> + size = min_t(u32, (DIV_ROUND_UP(height, 16) * 12), H264D_MAX_SLICE) *
> + SIZE_H264D_VPP_CMD_PER_BUF;
> +
> + return size > VPP_CMD_MAX_SIZE ? VPP_CMD_MAX_SIZE : size;
> +}
> +
> static u32 hfi_buffer_persist_h264d(void)
> {
> return ALIGN(SIZE_SLIST_BUF_H264 * NUM_SLIST_BUF_H264 +
> @@ -230,6 +341,11 @@ static u32 hfi_buffer_persist_h264d(void)
> DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_persist_h264d_ar50lt(void)
> +{
> + return ALIGN((SIZE_SLIST_BUF_H264 * NUM_SLIST_BUF_H264), DMA_ALIGNMENT);
> +}
> +
> static u32 hfi_buffer_persist_av1d(u32 max_width, u32 max_height, u32 total_ref_count)
> {
> u32 comv_size, size;
> @@ -255,6 +371,17 @@ static u32 hfi_buffer_non_comv_h264d(u32 frame_width, u32 frame_height, u32 num_
> return ALIGN(size, DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_non_comv_h264d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 size_bse = size_h264d_bse_cmd_buf_ar50lt(frame_height);
> + u32 size_vpp = size_h264d_vpp_cmd_buf_ar50lt(frame_height);
> + u32 size = ALIGN(size_bse, DMA_ALIGNMENT) +
> + ALIGN(size_vpp, DMA_ALIGNMENT) +
> + ALIGN(SIZE_HW_PIC(SIZE_H264D_HW_PIC_T), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_h265d_vpp_cmd_buf(u32 frame_width, u32 frame_height)
> {
> u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> @@ -269,6 +396,20 @@ static u32 size_h265d_vpp_cmd_buf(u32 frame_width, u32 frame_height)
> return _size;
> }
>
> +static u32 size_h265d_vpp_cmd_buf_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + u32 _size = ALIGN(((ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS)) *
> + NUM_HW_PIC_BUF, DMA_ALIGNMENT);
> + _size = min_t(u32, _size, H265D_MAX_SLICE_AR50LT + 1);
> + _size = ALIGN(_size, 4);
> + _size = 2 * _size * SIZE_H265D_VPP_CMD_PER_BUF_AR50LT;
> + if (_size > VPP_CMD_MAX_SIZE)
> + _size = VPP_CMD_MAX_SIZE;
> +
> + return _size;
> +}
> +
> static u32 hfi_buffer_non_comv_h265d(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> {
> u32 _size_bse = size_h265d_bse_cmd_buf(frame_width, frame_height);
> @@ -285,6 +426,20 @@ static u32 hfi_buffer_non_comv_h265d(u32 frame_width, u32 frame_height, u32 num_
> return ALIGN(_size, DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_non_comv_h265d_ar50lt(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + u32 _size_bse = size_h265d_bse_cmd_buf_ar50lt(frame_width, frame_height);
> + u32 _size_vpp = size_h265d_vpp_cmd_buf_ar50lt(frame_width, frame_height);
> + u32 _size = ALIGN(_size_bse, DMA_ALIGNMENT) +
> + ALIGN(_size_vpp, DMA_ALIGNMENT) +
> + ALIGN(2 * sizeof(u16) *
> + (ALIGN(frame_width, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS) *
> + (ALIGN(frame_height, LCU_MAX_SIZE_PELS) / LCU_MIN_SIZE_PELS), DMA_ALIGNMENT) +
> + ALIGN(SIZE_HW_PIC(SIZE_H265D_HW_PIC_T), DMA_ALIGNMENT);
> +
> + return ALIGN(_size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_vpss_lb(u32 frame_width, u32 frame_height)
> {
> u32 opb_lb_wr_llb_y_buffer_size, opb_lb_wr_llb_uv_buffer_size;
> @@ -317,6 +472,13 @@ u32 size_h265d_lb_fe_top_data(u32 frame_width, u32 frame_height)
> (ALIGN(frame_width, 64) + 8) * 2;
> }
>
> +static inline
> +u32 size_h265d_lb_fe_top_data_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return ALIGN(MAX_FE_NBR_DATA_LUMA_LINE_BUFFER_SIZE *
> + (ALIGN(frame_width, 64) + 8), DMA_ALIGNMENT) * 2;
> +}
> +
> static inline
> u32 size_h265d_lb_fe_top_ctrl(u32 frame_width, u32 frame_height)
> {
> @@ -348,6 +510,17 @@ u32 size_h265d_lb_se_left_ctrl(u32 frame_width, u32 frame_height)
> MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
> }
>
> +static inline
> +u32 size_h265d_lb_se_left_ctrl_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return max_t(u32, ((frame_height + 16 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE_AR50LT,
> + max_t(u32, ((frame_height + 32 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE_AR50LT,
> + ((frame_height + 64 - 1) / 8) *
> + MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE_AR50LT));
> +}
> +
> static inline
> u32 size_h265d_lb_pe_top_data(u32 frame_width, u32 frame_height)
> {
> @@ -355,6 +528,13 @@ u32 size_h265d_lb_pe_top_data(u32 frame_width, u32 frame_height)
> (ALIGN(frame_width, LCU_MIN_SIZE_PELS) / LCU_MIN_SIZE_PELS);
> }
>
> +static inline
> +u32 size_h265d_lb_pe_top_data_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return MAX_PE_NBR_DATA_LCU64_LINE_BUFFER_SIZE_AR50LT *
> + (ALIGN(frame_width, LCU_MIN_SIZE_PELS) / LCU_MIN_SIZE_PELS);
> +}
> +
> static inline
> u32 size_h265d_lb_vsp_top(u32 frame_width, u32 frame_height)
> {
> @@ -404,6 +584,29 @@ u32 hfi_buffer_line_h265d(u32 frame_width, u32 frame_height, bool is_opb, u32 nu
> return ALIGN((_size + vpss_lb_size), DMA_ALIGNMENT);
> }
>
> +static inline
> +u32 hfi_buffer_line_h265d_ar50lt(u32 frame_width, u32 frame_height, bool is_opb, u32 num_vpp_pipes)
> +{
> + u32 size;
> +
> + size = ALIGN(size_h265d_lb_fe_top_data_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_fe_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_fe_left_ctrl(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_se_left_ctrl_ar50lt(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_se_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_pe_top_data_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_vsp_top(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_h265d_lb_vsp_left(frame_width, frame_height),
> + DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h265d_lb_recon_dma_metadata_wr(frame_width, frame_height),
> + DMA_ALIGNMENT) * 4 +
> + ALIGN(size_h265d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 size_vpxd_lb_fe_left_ctrl(u32 frame_width, u32 frame_height)
> {
> @@ -438,6 +641,17 @@ u32 size_vpxd_lb_se_left_ctrl(u32 frame_width, u32 frame_height)
> MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE));
> }
>
> +static inline
> +u32 size_vpxd_lb_se_left_ctrl_ar50lt(u32 frame_width, u32 frame_height)
> +{
> + return max_t(u32, ((frame_height + 15) >> 4) *
> + MAX_SE_NBR_CTRL_LCU16_LINE_BUFFER_SIZE_AR50LT,
> + max_t(u32, ((frame_height + 31) >> 5) *
> + MAX_SE_NBR_CTRL_LCU32_LINE_BUFFER_SIZE_AR50LT,
> + ((frame_height + 63) >> 6) *
> + MAX_SE_NBR_CTRL_LCU64_LINE_BUFFER_SIZE_AR50LT));
> +}
> +
> static inline
> u32 size_vpxd_lb_recon_dma_metadata_wr(u32 frame_width, u32 frame_height)
> {
> @@ -492,6 +706,19 @@ u32 hfi_iris3_vp9d_lb_size(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> ALIGN(size_vp9d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> }
>
> +static inline
> +u32 hfi_ar50lt_vp9d_lb_size(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> + return ALIGN(size_vpxd_lb_fe_left_ctrl(frame_width, frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_vpxd_lb_se_left_ctrl_ar50lt(frame_width, frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_vp9d_lb_vsp_top(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vpxd_lb_se_top_ctrl(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vp9d_lb_pe_top_data(frame_width, frame_height), DMA_ALIGNMENT) +
> + ALIGN(size_vp9d_lb_fe_top_data(frame_width, frame_height), DMA_ALIGNMENT);
> +}
> +
> static inline
> u32 hfi_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_min, bool is_opb,
> u32 num_vpp_pipes)
> @@ -507,6 +734,13 @@ u32 hfi_buffer_line_vp9d(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_mi
> return _lb_size + vpss_lb_size + 4096;
> }
>
> +static inline
> +u32 hfi_buffer_line_vp9d_ar50lt(u32 frame_width, u32 frame_height, u32 _yuv_bufcount_min,
> + bool is_opb, u32 num_vpp_pipes)
> +{
> + return hfi_ar50lt_vp9d_lb_size(frame_width, frame_height, num_vpp_pipes);
pls keep same name across like "hfi_buffer_line_vp9d_ar50lt" and
"hfi_ar50lt_vp9d_lb_size" or combine these 2 apis, as the one just calls
the other.
> +}
> +
> static u32 hfi_buffer_line_h264d(u32 frame_width, u32 frame_height,
> bool is_opb, u32 num_vpp_pipes)
> {
> @@ -529,6 +763,25 @@ static u32 hfi_buffer_line_h264d(u32 frame_width, u32 frame_height,
> return ALIGN((size + vpss_lb_size), DMA_ALIGNMENT);
> }
>
> +static u32 hfi_buffer_line_h264d_ar50lt(u32 frame_width, u32 frame_height,
> + bool is_opb, u32 num_vpp_pipes)
> +{
> + u32 size;
> +
> + size = ALIGN(size_h264d_lb_fe_top_data_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_fe_top_ctrl_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_fe_left_ctrl(frame_height), DMA_ALIGNMENT) * num_vpp_pipes +
> + ALIGN(size_h264d_lb_se_top_ctrl_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_se_left_ctrl_ar50lt(frame_height), DMA_ALIGNMENT) *
> + num_vpp_pipes +
> + ALIGN(size_h264d_lb_pe_top_data_ar50lt(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_vsp_top(frame_width), DMA_ALIGNMENT) +
> + ALIGN(size_h264d_lb_recon_dma_metadata_wr(frame_height), DMA_ALIGNMENT) * 2 +
> + ALIGN(size_h264d_qp(frame_width, frame_height), DMA_ALIGNMENT);
> +
> + return ALIGN(size, DMA_ALIGNMENT);
> +}
> +
> static u32 size_av1d_lb_opb_wr1_nv12_ubwc(u32 frame_width, u32 frame_height)
> {
> u32 size, y_width, y_width_a = 128;
> @@ -724,6 +977,23 @@ static u32 iris_vpu_dec_bin_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_bin_size(struct iris_inst *inst)
> +{
> + u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
> + struct v4l2_format *f = inst->fmt_src;
> + u32 height = f->fmt.pix_mp.height;
> + u32 width = f->fmt.pix_mp.width;
> +
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_bin_h264d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_bin_h265d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_VP9)
> + return hfi_buffer_bin_vp9d_ar50lt(width, height, num_vpp_pipes);
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_comv_size(struct iris_inst *inst)
> {
> u32 num_comv = VIDEO_MAX_FRAME;
> @@ -785,6 +1055,18 @@ static u32 iris_vpu_dec_persist_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_persist_size(struct iris_inst *inst)
> +{
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_persist_h264d_ar50lt();
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_persist_h265d_ar50lt();
> + else if (inst->codec == V4L2_PIX_FMT_VP9)
> + return hfi_buffer_persist_vp9d_ar50lt();
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_dpb_size(struct iris_inst *inst)
> {
> if (iris_split_mode_enabled(inst))
> @@ -808,6 +1090,21 @@ static u32 iris_vpu_dec_non_comv_size(struct iris_inst *inst)
> return 0;
> }
>
> +static u32 iris_vpu_ar50lt_dec_non_comv_size(struct iris_inst *inst)
> +{
> + u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
neither of below api uses this variable ?
> + struct v4l2_format *f = inst->fmt_src;
> + u32 height = f->fmt.pix_mp.height;
> + u32 width = f->fmt.pix_mp.width;
> +
> + if (inst->codec == V4L2_PIX_FMT_H264)
> + return hfi_buffer_non_comv_h264d_ar50lt(width, height, num_vpp_pipes);
> + else if (inst->codec == V4L2_PIX_FMT_HEVC)
> + return hfi_buffer_non_comv_h265d_ar50lt(width, height, num_vpp_pipes);
> +
> + return 0;
> +}
> +
> static u32 iris_vpu_dec_line_size(struct iris_inst *inst)
> {
> u32 num_vpp_pipes = inst->core->iris_platform_data->num_vpp_pipe;
> @@ -833,6 +1130,29 @@ static u32 iris_vpu_dec_line_size(struct iris_inst *inst)
> return 0;
> }
>
Regards,
Vikash
^ permalink raw reply
* Re: [PATCH v2 3/4] mm: entirely remove lru_add_drain in do_swap_page
From: David Hildenbrand (Arm) @ 2026-06-24 15:10 UTC (permalink / raw)
To: Barry Song (Xiaomi), akpm, linux-mm
Cc: baoquan.he, chrisl, jp.kobryn, kasong, liam, linux-kernel, ljs,
mhocko, nphamcs, rppt, shakeel.butt, shikemeng, surenb,
usama.arif, vbabka, youngjun.park
In-Reply-To: <20260623231635.43086-4-baohua@kernel.org>
On 6/24/26 01:16, Barry Song (Xiaomi) wrote:
> We are doing a lot of redundant lru_add_drain() calls in
> do_swap_page(), especially for synchronous I/O devices. For
> example, the test program below currently ends up draining
> lru_cache 100% of the time:
>
> int main(int argc, char *argv[])
> {
> int i;
> #define SIZE 100*1024*1024
> while(1) {
> volatile int *p = mmap(0, SIZE, PROT_READ | PROT_WRITE,
> MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>
> for (int i = 0; i < SIZE/sizeof(int); i++)
> p[i] = i%64;
> madvise((void *)p, SIZE, MADV_PAGEOUT);
> for (int i = 0; i < SIZE/sizeof(int); i++)
> p[i] = i%64;
> munmap(p, SIZE);
> }
> return 0;
> }
>
> Folio reuse now relies primarily on the exclusive hint, making
> lru_cache draining to drop the refcount in lru_cache largely
> irrelevant.
Makes sense, we'll fallback to do_wp_page() where we handle the non-exclusive
either way.
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] s390/monwriter: Reject buffer reuse with different data length
From: Christian Borntraeger @ 2026-06-24 15:10 UTC (permalink / raw)
To: Gerald Schaefer, linux-s390; +Cc: Heiko Carstens, Alexander Gordeev
In-Reply-To: <20260623174406.189869-1-gerald.schaefer@linux.ibm.com>
Am 23.06.26 um 19:44 schrieb Gerald Schaefer:
> When data buffers are reused, e.g. for interval sample records, the
> first record determines the data length, and the size of the buffer for
> user copy. Current monwriter code does not check if the data length was
> changed for subsequent records, which also would never happen for valid
> user programs.
>
> However, a malicious user could change the data length, resulting in out
> of bounds user copy to the kernel buffer, and memory corruption. By
> default, the monwriter misc device is created with root-only permissions,
> so practical impact is typically low.
>
> Fix this by checking for changed data length and rejecting such records.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com>
^ permalink raw reply
* Re: [RFC][PATCH v2] perf: Fix perf_addr_filters_afjust()
From: Leo Yan @ 2026-06-24 15:10 UTC (permalink / raw)
To: Peter Zijlstra
Cc: mingo, acme, namhyung, mark.rutland, alexander.shishkin, jolsa,
irogers, adrian.hunter, james.clark, linux-perf-users,
linux-kernel, suzuki.poulose, mike.leach
In-Reply-To: <20260623091426.GF49529@noisy.programming.kicks-ass.net>
On Tue, Jun 23, 2026 at 11:14:26AM +0200, Peter Zijlstra wrote:
>
> - adjust lock order; since perf_event_addr_filters_apply() takes mmap_lock
> inside child_mutex.
>
> - note that perf_event_mmap() is called by the thread doing the
> mmap()/mprotect()/.. operation, but not the other threads in the address
> space that might have inherited the same event.
>
> - have perf_addr_filters_adjust() iterate the child_list to find all other
> events for tasks that have the same mm.
>
> - since this can now adjust addr_filter_ranges[] for remote events, make sure
> to adjust things while holding ctx->lock; local_irq_disable() as implied by
> the ifh->lock is no longer suffient to serialize against event scheduling.
>
> - per the previous locking order; perf_event_mmap(), which is called holding
> mmap_lock, cannot take child_mutex, as such, make child_list RCU protected
> and iterate under RCU.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Just verified this patch with Arm CoreSight:
perf record -e cs_etm//u --filter 'filter traced_region @/root/test' -- /root/test
The workload forks a child process to inherited the event, also used
trace_printk() to confirm perf_event_addr_filters_adjust() has been hit.
No warning reported by LOCKDEP.
Tested-by: Leo Yan <leo.yan@arm.com>
If you want me to try any specific test, pleaset let me know and I am
glad to give a run.
Maybe it is good to fix typo in the subject: s/afjust()/adjust()/.
^ permalink raw reply
* Re: [PATCH v2 11/13] alloc_tag: Move to mm/
From: Lorenzo Stoakes @ 2026-06-24 15:11 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: Brendan Jackman, Andrew Morton, Vlastimil Babka, Michal Hocko,
Johannes Weiner, Zi Yan, Muchun Song, Oscar Salvador,
David Hildenbrand, Liam R. Howlett, Mike Rapoport, Matthew Brost,
Joshua Hahn, Rakie Kim, Byungchul Park, Ying Huang,
Alistair Popple, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Sebastian Andrzej Siewior, Clark Williams,
Steven Rostedt, Harry Yoo (Oracle), Gregory Price,
Alexei Starovoitov, Matthew Wilcox, linux-mm, linux-kernel,
linux-rt-devel
In-Reply-To: <CAJuCfpHqvLVnycuufO6Kf3S_RSFjyDRUnTGDyu3VW0kQ90tiHQ@mail.gmail.com>
On Tue, Jun 23, 2026 at 04:48:04PM -0700, Suren Baghdasaryan wrote:
> On Tue, Jun 23, 2026 at 10:29 AM Lorenzo Stoakes <ljs@kernel.org> wrote:
> >
> > On Mon, Jun 22, 2026 at 10:01:38AM +0000, Brendan Jackman wrote:
> > > This is logically mm code. Moving to mm/ allows access to mm/internal.h
> > >
> > > Signed-off-by: Brendan Jackman <jackmanb@google.com>
> >
> > Sorry to be a pain, but I feel that this change should be dealt with separately
> > perhaps as a pre-requisite to this series.
>
> I know you have an idea for some cleanup. Let's wait for your patch
> and then rebase this series over it. In the meantime I'll start
> reviewing the rest.
Thanks!
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v5 8/9] dax/kmem: add sysfs interface for atomic whole-device hotplug
From: sashiko-bot @ 2026-06-24 15:11 UTC (permalink / raw)
To: Gregory Price; +Cc: nvdimm, linux-cxl
In-Reply-To: <20260624145744.3532049-9-gourry@gourry.net>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The protection against deadlocks during driver unbind can be completely bypassed if the underlying memory blocks are manually onlined via the core memory sysfs, causing state desynchronization.
- [Medium] any_hotremove_failed is irrevocably set on recoverable sysfs hotremove failures, leading to a permanent leak of kmem_name.
--
commit fa89899811083ada324ea3db8204b1c135005af5
Author: Gregory Price <gourry@gourry.net>
Subject: dax/kmem: add sysfs interface for atomic whole-device hotplug
This patch adds a new 'state' sysfs attribute for dax_kmem devices to enable
atomic whole-device hotplug operations. It also updates the unbind logic to
prevent deadlocks by omitting memory removal if the memory blocks are
currently online.
> diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> index a45e50def5371..340486586d82c 100644
> --- a/drivers/dax/kmem.c
> +++ b/drivers/dax/kmem.c
[ ... ]
> +static int dax_kmem_do_hotremove(struct dev_dax *dev_dax,
> + struct dax_kmem_data *data)
> +{
[ ... ]
> + rc = offline_and_remove_memory_ranges(ranges, nr_ranges);
> + kfree(ranges);
> + if (rc) {
> + any_hotremove_failed = true;
> + dev_err(dev, "hotremove failed, device left online: %d\n", rc);
> + return rc;
> + }
[Severity: Medium]
Does this permanently leak kmem_name on recoverable sysfs failures?
If a user attempts to unplug a device via sysfs and the hotremove fails
transiently (e.g., due to memory being in use), any_hotremove_failed is set
to true. Even if the user retries and the unplug later succeeds, this global
flag is never cleared, which will prevent freeing kmem_name during module
unload.
[ ... ]
> @@ -348,20 +490,26 @@ static int dev_dax_kmem_probe(struct dev_dax *dev_dax)
> #ifdef CONFIG_MEMORY_HOTREMOVE
> static void dev_dax_kmem_remove(struct dev_dax *dev_dax)
> {
[ ... ]
> + if (dax_kmem_state_is_online(data->state)) {
> + dev_warn(dev, "Hotplug regions stuck online until reboot\n");
> + any_hotremove_failed = true;
> + return;
> + } else if (data->state == MMOP_OFFLINE &&
> + dax_kmem_do_hotremove(dev_dax, data)) {
> + dev_warn(dev, "Unplug failed, resources leaked until reboot\n");
> return;
> }
[Severity: High]
Can this deadlock during unbind if the memory state is desynchronized?
If the device is configured with auto_online_blocks=offline, data->state is
initially MMOP_OFFLINE. If a user manually onlines the underlying memory
blocks via the generic /sys/devices/system/memory/memoryX/state sysfs
interface, data->state remains MMOP_OFFLINE.
During unbind, dev_dax_kmem_remove() will evaluate
dax_kmem_state_is_online(data->state) as false and proceed to call
dax_kmem_do_hotremove() instead of safely aborting. This attempts to offline
the blocks while holding the device unbind lock, bypassing the intended
deadlock protection.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145744.3532049-1-gourry@gourry.net?part=8
^ permalink raw reply
* Re: [RFC PATCH 4/5] migration: write up code to run fast snapshot load in qemu_loadvm_state
From: Fabiano Rosas @ 2026-06-24 15:10 UTC (permalink / raw)
To: Aadeshveer Singh, qemu-devel
Cc: peterx, pbonzini, philmd, lvivier, ayoub, Aadeshveer Singh
In-Reply-To: <20260618032010.88755-5-aadeshveer07@gmail.com>
Aadeshveer Singh <aadeshveer07@gmail.com> writes:
> When both mapped-ram and postcopy-ram are set, divert from
> qemu_loadvm_state to run fast snapshot load
>
> Initialize postcopy RAM state and register RAM Blocks with userfaultfd
> via ram_postcopy_incoming_init() and postcopy_ram_incoming_setup().
> Launch fault thread before VM to serve faults for some hardwares
> emulation that need to read RAM (like vapic devices). Populate bitmaps
> and offset tables while reading file in qemu_loadvm_state_main. Call to
> qemu_loadvm_state_postcopy() which starts the VM using
> loadvm_postcopy_handle_run_bh() and launches eager load thread.
>
> Skip scheduling process_incoming_migration_bh() in
> process_incoming_migration_co(), for fast snapshot load as the state
> cleanup is managed by eager load thread on completion.
>
> Skip setting migration status to ACTIVE in process_incoming_migration_co
> and set set it to POSTCOPY_DEVICE in qemu_loadvm_state() itself.
>
> Remove the capability check that rejected mapped-ram and postcopy-ram
> being set simultaneously, as this combination now corresponds to fast
> snapshot load. The corresponding test will be updated in following
> patch.
>
> Signed-off-by: Aadeshveer Singh <aadeshveer07@gmail.com>
> ---
> migration/migration.c | 10 ++++++---
> migration/options.c | 6 -----
> migration/savevm.c | 52 +++++++++++++++++++++++++++++++++++++++++--
> migration/savevm.h | 2 ++
> 4 files changed, 59 insertions(+), 11 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 074d3f2c69..e1ac310e20 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -756,8 +756,10 @@ process_incoming_migration_co(void *opaque)
>
> mis->largest_page_size = qemu_ram_pagesize_largest();
> postcopy_state_set(POSTCOPY_INCOMING_NONE);
> - migrate_set_state(&mis->state, MIGRATION_STATUS_SETUP,
> - MIGRATION_STATUS_ACTIVE);
> + if (!migrate_fast_snapshot_load()) {
> + migrate_set_state(&mis->state, MIGRATION_STATUS_SETUP,
> + MIGRATION_STATUS_ACTIVE);
> + }
>
> mis->loadvm_co = qemu_coroutine_self();
> ret = qemu_loadvm_state(mis->from_src_file, &local_err);
> @@ -786,7 +788,9 @@ process_incoming_migration_co(void *opaque)
> colo_incoming_co();
> }
>
> - migration_bh_schedule(process_incoming_migration_bh, mis);
> + if (!migrate_fast_snapshot_load()) {
> + migration_bh_schedule(process_incoming_migration_bh, mis);
> + }
This inconspicuous 4 line hunk will cause bugs for years to come. =D
We should try to include the fast_snapshot actions within the incoming
BH so the paths are the same in both types of migration. Ideally we'd
merge all the BHs in a single one.
> goto out;
>
> fail:
> diff --git a/migration/options.c b/migration/options.c
> index 5f80dd5b42..3f447cf7b2 100644
> --- a/migration/options.c
> +++ b/migration/options.c
> @@ -732,12 +732,6 @@ bool migrate_caps_check(bool *old_caps, bool *new_caps, Error **errp)
> "Mapped-ram migration is incompatible with xbzrle");
> return false;
> }
> -
> - if (new_caps[MIGRATION_CAPABILITY_POSTCOPY_RAM]) {
> - error_setg(errp,
> - "Mapped-ram migration is incompatible with postcopy");
> - return false;
> - }
Just checking: Does this allow any type of migration that is not covered
by this series?
> }
>
> /*
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 23adaf9dd9..f10cc3c2fc 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -2959,6 +2959,32 @@ static bool postcopy_pause_incoming(MigrationIncomingState *mis)
> return true;
> }
>
> +/*
> + * Starts the VM and launches the eager thread for fast snapshot load
> + */
> +int qemu_loadvm_state_postcopy(QEMUFile *f, MigrationIncomingState *mis,
> + Error **errp)
> +{
> + ERRP_GUARD();
> + int ret = 0;
> +
> + postcopy_state_set(POSTCOPY_INCOMING_RUNNING);
> +
> + migration_bh_schedule(loadvm_postcopy_handle_run_bh, mis);
> +
> + migrate_set_state(&mis->state, MIGRATION_STATUS_POSTCOPY_DEVICE,
> + MIGRATION_STATUS_POSTCOPY_ACTIVE);
> +
> + ret = postcopy_ram_eager_load_setup(mis);
> + if (ret) {
> + error_prepend(errp,
> + "Failed to setup eager load for fast snapshot load: ");
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> int qemu_loadvm_state_main(QEMUFile *f, MigrationIncomingState *mis,
> Error **errp)
> {
> @@ -3067,8 +3093,30 @@ int qemu_loadvm_state(QEMUFile *f, Error **errp)
>
> cpu_synchronize_all_pre_loadvm();
>
> - ret = qemu_loadvm_state_main(f, mis, errp);
> - qemu_event_set(&mis->main_thread_load_event);
> + if (migrate_fast_snapshot_load()) {
> + migrate_set_state(&mis->state, MIGRATION_STATUS_SETUP,
> + MIGRATION_STATUS_POSTCOPY_DEVICE);
> +
> + if (ram_postcopy_incoming_init(mis, errp)) {
> + return -EINVAL;
> + }
> +
> + postcopy_state_set(POSTCOPY_INCOMING_LISTENING);
> + if (postcopy_ram_incoming_setup(mis)) {
> + return -EINVAL;
> + }
> +
> + ret = qemu_loadvm_state_main(f, mis, errp);
> +
> + qemu_event_set(&mis->main_thread_load_event);
> +
> + if (ret == 0) {
> + ret = qemu_loadvm_state_postcopy(f, mis, errp);
> + }
> + } else {
> + ret = qemu_loadvm_state_main(f, mis, errp);
> + qemu_event_set(&mis->main_thread_load_event);
> + }
>
> trace_qemu_loadvm_state_post_main(ret);
>
> diff --git a/migration/savevm.h b/migration/savevm.h
> index 96fdf96d4e..9656acd7fe 100644
> --- a/migration/savevm.h
> +++ b/migration/savevm.h
> @@ -67,6 +67,8 @@ void qemu_savevm_send_postcopy_ram_discard(QEMUFile *f, const char *name,
> int qemu_save_device_state(QEMUFile *f, Error **errp);
> int qemu_loadvm_state(QEMUFile *f, Error **errp);
> void qemu_loadvm_state_cleanup(MigrationIncomingState *mis);
> +int qemu_loadvm_state_postcopy(QEMUFile *f, MigrationIncomingState *mis,
> + Error **errp);
> int qemu_loadvm_state_main(QEMUFile *f, MigrationIncomingState *mis,
> Error **errp);
> int qemu_load_device_state(QEMUFile *f, Error **errp);
^ permalink raw reply
* Re: [PATCH] scsi: target: tcm_fc: annotate session hash traversals
From: sashiko-bot @ 2026-06-24 15:11 UTC (permalink / raw)
To: Runyu Xiao; +Cc: linux-scsi
In-Reply-To: <20260624145320.3429431-1-runyu.xiao@seu.edu.cn>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Unsafe RCU list traversal in `ft_sess_delete_all` causing Iterator Use-After-Free.
- [Critical] `ft_sess_get` uses `kref_get` instead of `kref_get_unless_zero` during RCU list traversal, causing refcount corruption.
--
commit 3175abadc099d1a62c16806e23dfcc68463481a8
Author: Runyu Xiao <runyu.xiao@seu.edu.cn>
scsi: target: tcm_fc: annotate session hash traversals
This commit adds lockdep condition annotations to several RCU hlist
traversals in the TCM FC session hash to document the writer-side
protection under ft_lport_lock.
> diff --git a/drivers/target/tcm_fc/tfc_sess.c b/drivers/target/tcm_fc/tfc_sess.c
> index 797be06ab71b8..84a6f29a1b5f8 100644
> --- a/drivers/target/tcm_fc/tfc_sess.c
> +++ b/drivers/target/tcm_fc/tfc_sess.c
[ ... ]
> @@ -291,7 +293,8 @@ static void ft_sess_delete_all(struct ft_tport *tport)
>
> for (head = tport->hash;
> head < &tport->hash[FT_SESS_HASH_SIZE]; head++) {
> - hlist_for_each_entry_rcu(sess, head, hash) {
> + hlist_for_each_entry_rcu(sess, head, hash,
> + lockdep_is_held(&ft_lport_lock)) {
> ft_sess_unhash(sess);
> ft_close_sess(sess); /* release from table */
> }
[Severity: Critical]
This isn't a bug introduced by this patch, but is it safe to use the standard
hlist_for_each_entry_rcu macro here while the elements are being destroyed?
During ft_sess_delete_all(), the code unlinks the session and calls
ft_close_sess(). This drops the final reference and queues the object for RCU
freeing.
Because the iteration does not hold rcu_read_lock(), the thread can be
preempted after ft_close_sess() returns. If the RCU grace period expires
during this preemption, the session object is freed.
When the thread resumes, the iterator macro will evaluate the next pointer
using the freed object, resulting in a use-after-free:
rcu_dereference_raw(hlist_next_rcu(&(sess)->hash))
Should this use a safe iteration mechanism such as a while loop checking
!hlist_empty(head) instead?
While looking at the session hash logic, I noticed another pre-existing
issue in the reader path:
drivers/target/tcm_fc/tfc_sess.c:ft_sess_get() {
...
hlist_for_each_entry_rcu(sess, head, hash) {
if (sess->port_id == port_id) {
kref_get(&sess->kref);
rcu_read_unlock();
return sess;
}
}
...
}
[Severity: Critical]
This is a pre-existing issue, but does this kref_get() risk reviving a
session that has already dropped its reference count to zero?
If a remote port sends a data frame concurrently with a process logout
request, the reader thread in ft_sess_get() could find the target session
but get preempted before executing kref_get().
Concurrently, the writer thread handling the logout in ft_sess_delete()
removes the session from the list and drops the final kref to 0, queuing
it for freeing.
When the reader thread resumes, it unconditionally increments the zero-ref
kref, resulting in accessing an object queued for destruction.
Does the reader need to use kref_get_unless_zero() here and handle the
failure case appropriately?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624145320.3429431-1-runyu.xiao@seu.edu.cn?part=1
^ permalink raw reply
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.