impl_list_item_mod.rs calls container_of() without unsafe blocks at a
couple of places. Since container_of() is an unsafe macro / function,
the blocks are strictly necessary.
For unknown reasons, that problem was so far not visible and only gets
visible once one utilizes the list implementation from within the core
crate:
error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub`
is unsafe and requires unsafe block
--> rust/kernel/lib.rs:252:29
|
252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
|
note: an unsafe function restricts its caller, but its body is safe by default
--> rust/kernel/list/impl_list_item_mod.rs:216:13
|
216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
= note: requested on the command line with `-D unsafe-op-in-unsafe-fn`
= note: this error originates in the macro `$crate::container_of` which comes
from the expansion of the macro `impl_list_item`
Add unsafe blocks to container_of to fix the issue.
Cc: stable(a)vger.kernel.org # v6.17+
Fixes: c77f85b347dd ("rust: list: remove OFFSET constants")
Suggested-by: Alice Ryhl <aliceryhl(a)google.com>
Signed-off-by: Philipp Stanner <phasta(a)kernel.org>
---
rust/kernel/list/impl_list_item_mod.rs | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/rust/kernel/list/impl_list_item_mod.rs b/rust/kernel/list/impl_list_item_mod.rs
index 202bc6f97c13..7052095efde5 100644
--- a/rust/kernel/list/impl_list_item_mod.rs
+++ b/rust/kernel/list/impl_list_item_mod.rs
@@ -217,7 +217,7 @@ unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
// SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it
// points at the field `$field` in a value of type `Self`. Thus, reversing that
// operation is still in-bounds of the allocation.
- $crate::container_of!(me, Self, $($field).*)
+ unsafe { $crate::container_of!(me, Self, $($field).*) }
}
// GUARANTEES:
@@ -242,7 +242,7 @@ unsafe fn post_remove(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
// SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it
// points at the field `$field` in a value of type `Self`. Thus, reversing that
// operation is still in-bounds of the allocation.
- $crate::container_of!(me, Self, $($field).*)
+ unsafe { $crate::container_of!(me, Self, $($field).*) }
}
}
)*};
@@ -270,9 +270,9 @@ unsafe fn prepare_to_insert(me: *const Self) -> *mut $crate::list::ListLinks<$nu
// SAFETY: The caller promises that `me` points at a valid value of type `Self`.
let links_field = unsafe { <Self as $crate::list::ListItem<$num>>::view_links(me) };
- let container = $crate::container_of!(
+ let container = unsafe { $crate::container_of!(
links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner
- );
+ ) };
// SAFETY: By the same reasoning above, `links_field` is a valid pointer.
let self_ptr = unsafe {
@@ -319,9 +319,9 @@ unsafe fn view_links(me: *const Self) -> *mut $crate::list::ListLinks<$num> {
// `ListArc` containing `Self` until the next call to `post_remove`. The value cannot
// be destroyed while a `ListArc` reference exists.
unsafe fn view_value(links_field: *mut $crate::list::ListLinks<$num>) -> *const Self {
- let container = $crate::container_of!(
+ let container = unsafe { $crate::container_of!(
links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner
- );
+ ) };
// SAFETY: By the same reasoning above, `links_field` is a valid pointer.
let self_ptr = unsafe {
--
2.49.0
From: "Mario Limonciello (AMD)" <superm1(a)kernel.org>
During the suspend sequence VPE is already going to be power gated
as part of vpe_suspend(). It's unnecessary to call during calls to
amdgpu_device_set_pg_state().
It actually can expose a race condition with the firmware if s0i3
sequence starts as well. Drop these calls.
Cc: stable(a)vger.kernel.org
Cc: Peyton.Lee(a)amd.com
Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 81587f8d66c2..22db0e4154e4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3419,10 +3419,11 @@ int amdgpu_device_set_pg_state(struct amdgpu_device *adev,
(adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_GFX ||
adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_SDMA))
continue;
- /* skip CG for VCE/UVD, it's handled specially */
+ /* skip CG for VCE/UVD/VPE, it's handled specially */
if (adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_UVD &&
adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCE &&
adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCN &&
+ adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VPE &&
adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_JPEG &&
adev->ip_blocks[i].version->funcs->set_powergating_state) {
/* enable powergating to save power */
--
2.51.2
In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping
metrics_lock. Since this lock protects the lifetime of oa_config, an
attacker could guess the id and call xe_oa_remove_config_ioctl() with
perfect timing, freeing oa_config before we dereference it, leading to
a potential use-after-free.
Fix this by caching the id in a local variable while holding the lock.
v2: (Matt A)
- Dropped mutex_unlock(&oa->metrics_lock) ordering change from
xe_oa_remove_config_ioctl()
Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614
Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops")
Cc: <stable(a)vger.kernel.org> # v6.11+
Suggested-by: Matthew Auld <matthew.auld(a)intel.com>
Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav(a)intel.com>
---
drivers/gpu/drm/xe/xe_oa.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c
index 87a2bf53d661..890c363282ae 100644
--- a/drivers/gpu/drm/xe/xe_oa.c
+++ b/drivers/gpu/drm/xe/xe_oa.c
@@ -2403,11 +2403,13 @@ int xe_oa_add_config_ioctl(struct drm_device *dev, u64 data, struct drm_file *fi
goto sysfs_err;
}
- mutex_unlock(&oa->metrics_lock);
+ id = oa_config->id;
+
+ drm_dbg(&oa->xe->drm, "Added config %s id=%i\n", oa_config->uuid, id);
- drm_dbg(&oa->xe->drm, "Added config %s id=%i\n", oa_config->uuid, oa_config->id);
+ mutex_unlock(&oa->metrics_lock);
- return oa_config->id;
+ return id;
sysfs_err:
mutex_unlock(&oa->metrics_lock);
--
2.43.0
Commit under Fixes added support for power regulators on the J721E SK
board. However, while doing so, it incorrectly assigned a non-existent
pinmux within the WKUP Pinmux region (pinctrl@4301c000) instead of using
the MAIN Pinmux region (pinctrl@11c000). This leads to the following
silent failure:
pinctrl-single 4301c000.pinctrl: mux offset out of range: 0x1dc (0x178)
The datasheet for the J721E SoC [0] specifies on page 142 that the
pinmux of interest which is Ball Y1 is PADCONFIG119 and the address
corresponding to it is 0x00011C1DC which belongs to the MAIN Pinmux
region.
Hence, fix this.
[0]: https://www.ti.com/lit/ds/symlink/tda4vm.pdf
Fixes: 97b67cc102dc ("arm64: dts: ti: k3-j721e-sk: Add DT nodes for power regulators")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Siddharth Vadapalli <s-vadapalli(a)ti.com>
---
Hello,
This patch is based on commit
e7c375b18160 Merge tag 'vfs-6.18-rc7.fixes' of gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs
of Mainline Linux.
Regards,
Siddharth.
arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
index 5e5784ef6f85..77dcc160eda3 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts
@@ -474,6 +474,12 @@ rpi_header_gpio1_pins_default: rpi-header-gpio1-default-pins {
J721E_IOPAD(0x234, PIN_INPUT, 7) /* (U3) EXT_REFCLK1.GPIO1_12 */
>;
};
+
+ vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
+ pinctrl-single,pins = <
+ J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */
+ >;
+ };
};
&wkup_pmx0 {
@@ -536,12 +542,6 @@ J721E_WKUP_IOPAD(0xd4, PIN_OUTPUT, 7) /* (G26) WKUP_GPIO0_9 */
>;
};
- vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
- pinctrl-single,pins = <
- J721E_IOPAD(0x1dc, PIN_OUTPUT, 7) /* (Y1) SPI1_CLK.GPIO0_118 */
- >;
- };
-
wkup_uart0_pins_default: wkup-uart0-default-pins {
pinctrl-single,pins = <
J721E_WKUP_IOPAD(0xa0, PIN_INPUT, 0) /* (J29) WKUP_UART0_RXD */
--
2.51.1
On Tue, Nov 18, 2025 at 02:45:50PM +0800, Pavel Tikhomirov wrote:
> If unshare_nsproxy_namespaces() successfully creates the new_nsproxy,
> but then set_cred_ucounts() fails, on its error path there is no cleanup
> for new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy
> if it's not NULL on this error path.
>
> Fixes: 905ae01c4ae2a ("Add a reference to ucounts for each cred")
> Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Cc: stable(a)vger.kernel.org
Acked-by: Alexey Gladkov <legion(a)kernel.org>
> ---
> kernel/fork.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 3da0f08615a95..6f7332e3e0c8c 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_flags)
>
> if (new_cred) {
> err = set_cred_ucounts(new_cred);
> - if (err)
> + if (err) {
> + if (new_nsproxy)
> + free_nsproxy(new_nsproxy);
> goto bad_unshare_cleanup_cred;
> + }
> }
>
> if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) {
> --
> 2.51.1
>
--
Rgrds, legion
This series adds the A8xx HWL along with Adreno 840 GPU support to the
drm-msm driver. A8x is the next generation in the Adreno family,
featuring a significant hardware design change. A major update to the
design is the introduction of 'Slice' architecture. Slices are sort of
mini-GPUs within the GPU which are more independent in processing Graphics
and compute workloads. Also, in addition to the BV and BR pipe we saw in
A7x, CP has more concurrency with additional pipes.
From KMD-HW SWI perspective, there is significant register shuffling in
some of the blocks. For slice or aperture related registers which are
virtualized now, KMD/crashdumper has to configure an aperture register
to access them. On the GMU front, there are some shuffling in register
offsets, but it is manageable as of now. There is a new HFI message to
transfer data tables and new power related features to support higher
peak currents and thermal mitigations.
Adreno 840 GPU is the second generation architecture in the A8x family
present in Kaanapali (a.k.a Snapdragon 8 Elite Gen 5) chipset [1]. It
has a maximum of 3 slices with 2 SPs per slice. Along with the 3-slice
configuration, there is also another 2-slice SKU (Partial Slice SKU).
A840 GPU has a bigger 18MB of GMEM which can be utilized for graphics
and compute workload. It also features improved Concurrent binning
support, UBWC v6 etc.
Adreno X2-85 GPU present in Glymur chipset is very similar to A840
architecturally. So adding initial support for it requires just an
additional entry in the catalog with the necessary register lists.
This series adds only the driver side support along with a few dt bindings
updates. Devicetree patches will be sent separately, but those who
are interested can take look at it from the Qualcomm's public tree [2].
Features like coredump, gmu power features, ifpc, preemption etc will be
added in a future series.
Initial few patches are for improving code sharing between a6xx/a7xx and
a8x routines. Then there is a patch to rebase GMU register offsets from
GPU's base. Rest of the patches add A8x HWL and Adreno 840/X2-85 GPU
support.
Mesa support for A8x/A840 GPU is WIP and will be posted in the near
future.
The last patch in the series ("drm/msm/a8xx: Add UBWC v6 support") has a
compile time dependency on the below patch from the qcom-soc tree
("soc: qcom: ubwc: Add config for Kaanapali"):
https://lore.kernel.org/lkml/20250930-kaana-gpu-support-v1-1-73530b0700ed@o…
[1] https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-…
[2] https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/commit/5fb72c2790…
Signed-off-by: Akhil P Oommen <akhilpo(a)oss.qualcomm.com>
---
Changes in v4:
- Rebase on top of msm-next
- Clean up AQE bo during a6xx_destroy (Konrad)
- Split out UBWC v6 support into a separate patch to ease merge (Rob)
- Rebase gmu register list's offsets in a6xx_gpu_state
- Add a new patch#1 to fix Out of boud register access
- Link to v3: https://lore.kernel.org/r/20251114-kaana-gpu-support-v3-0-92300c7ec8ff@oss.…
Changes in v3:
- Squash gpu smmu bindings patches for Kaana and Glymur (Krzysztof)
- Reuse a6xx_flush() and drop the patch that added submit_flush callback
- Fix GBIF configs for a640 and a650 family (Konrad)
- Add partial SKU detection support
- Correct Chipids in the catalog
- Add a new patch to drop SCRATCH reg dumps (Rob)
- Read slice info right after CX gdsc is up
- Don't drop raytracing support if preemption is unsupported
- Drop the unused A840 pwrup list (Konrad)
- Updates to A840 nonctxt list (Rob)
- Capture trailers
- Link to v2: https://lore.kernel.org/r/20251110-kaana-gpu-support-v2-0-bef18acd5e94@oss.…
Changes in v2:
- Rebase on top of next-20251110 tag
- Include support for Glymur chipset
- Drop the ubwc_config driver patch as it is picked up
- Sync the latest a6xx register definitions from Rob's tree
- New patch to do LRZ flush to fix pagefaults
- Reuse a7xx_cx_mem_init(). Dropped related patch (Connor)
- Few changes around cp protect configuration to align it with downstream
- Fix the incorrect register usage at few places
- Updates to non-ctxt register list
- Serialize aperture updates (Rob)
- More helpful cp error irq logging
- Split A8x GMU support patch (Dmitry)
- Use devm_platform_get_and_ioremap_resource in GMU init (Konrad)
- Link to v1: https://lore.kernel.org/r/20250930-kaana-gpu-support-v1-0-73530b0700ed@oss.…
---
Akhil P Oommen (22):
drm/msm/a6xx: Fix out of bound IO access in a6xx_get_gmu_registers
drm/msm/a6xx: Flush LRZ cache before PT switch
drm/msm/a6xx: Fix the gemnoc workaround
drm/msm/a6xx: Skip dumping SCRATCH registers
drm/msm/adreno: Common-ize PIPE definitions
drm/msm/adreno: Move adreno_gpu_func to catalogue
drm/msm/adreno: Move gbif_halt() to adreno_gpu_func
drm/msm/adreno: Add MMU fault handler to adreno_gpu_func
drm/msm/a6xx: Sync latest register definitions
drm/msm/a6xx: Rebase GMU register offsets
drm/msm/a8xx: Add support for A8x GMU
drm/msm/a6xx: Improve MX rail fallback in RPMH vote init
drm/msm/a6xx: Share dependency vote table with GMU
drm/msm/adreno: Introduce A8x GPU Support
drm/msm/adreno: Support AQE engine
drm/msm/a8xx: Add support for Adreno 840 GPU
drm/msm/adreno: Do CX GBIF config before GMU start
drm/msm/a8xx: Add support for Adreno X2-85 GPU
dt-bindings: arm-smmu: Add Kaanapali and Glymur GPU SMMU
dt-bindings: display/msm/gmu: Add Adreno 840 GMU
dt-bindings: display/msm/gmu: Add Adreno X2-85 GMU
drm/msm/a8xx: Add UBWC v6 support
.../devicetree/bindings/display/msm/gmu.yaml | 60 +-
.../devicetree/bindings/iommu/arm,smmu.yaml | 2 +
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/drm/msm/adreno/a2xx_catalog.c | 7 +-
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 50 +-
drivers/gpu/drm/msm/adreno/a2xx_gpu.h | 2 +
drivers/gpu/drm/msm/adreno/a3xx_catalog.c | 13 +-
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 52 +-
drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 2 +
drivers/gpu/drm/msm/adreno/a4xx_catalog.c | 7 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 54 +-
drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 2 +
drivers/gpu/drm/msm/adreno/a5xx_catalog.c | 17 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 61 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 +
drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 371 +++-
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 287 ++-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 25 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 399 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 31 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 74 +-
drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 53 +
drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 17 +
drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 1205 ++++++++++++
drivers/gpu/drm/msm/adreno/adreno_device.c | 4 +-
.../gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h | 420 ++---
.../gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h | 332 ++--
.../gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h | 470 ++---
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 38 +-
drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 1954 +++++++++++++++-----
.../gpu/drm/msm/registers/adreno/a6xx_enums.xml | 2 +-
drivers/gpu/drm/msm/registers/adreno/a6xx_gmu.xml | 283 +--
.../gpu/drm/msm/registers/adreno/a7xx_enums.xml | 7 -
.../drm/msm/registers/adreno/a8xx_descriptors.xml | 120 ++
.../gpu/drm/msm/registers/adreno/a8xx_enums.xml | 289 +++
.../gpu/drm/msm/registers/adreno/adreno_common.xml | 12 +
37 files changed, 5043 insertions(+), 1684 deletions(-)
---
base-commit: 50a0b122cfc8a7dc35009ef9bf33cf6034c7bd69
change-id: 20250929-kaana-gpu-support-11d21c8fa1dc
prerequisite-message-id: <20250930-kaana-gpu-support-v1-1-73530b0700ed(a)oss.qualcomm.com>
prerequisite-patch-id: f15bd99b078d228da892fb1224e10cac31f4a5c2
prerequisite-patch-id: 5b3d152595fbcce7c118d42c00f89160bbf03d41
prerequisite-patch-id: 4387aff0073a3217132ae5da358e5d4b2cb23cb3
prerequisite-patch-id: e047a6ea27db881db0089923af688c38729a7dad
prerequisite-patch-id: e686f7f592194f7d5e943858ce4dab49da6f4d18
prerequisite-patch-id: 638bc6f946cb2c1a2c68c3713a1ce7e6839c3465
prerequisite-patch-id: a85a264e87f79e9ac34dc22124153b050f97dded
prerequisite-patch-id: 8bba83cdb88cb7a8851978590cb24033d95c21de
prerequisite-patch-id: 9f08bcf9e33501478a2312e7a317f730f167652d
prerequisite-patch-id: 65a2884909f6f0e3f111412388fde0c18a4a3334
prerequisite-patch-id: 3e9a011409f3461e3de7b1a8a4e99de6fbf02abf
prerequisite-patch-id: 0ae4c8dc17fd54c84d903badccdf7a2018ec5606
prerequisite-patch-id: 6e0829024fb62bfc4510ef4c5472392dc76efcbf
prerequisite-patch-id: 5e5e177cb37fd1c0151568744565483809f357ba
prerequisite-patch-id: c2236f76a9fda88c41ea535708be1b51fd4d444c
prerequisite-patch-id: 6e26922186365d994987026b674baa66f9ac0139
prerequisite-patch-id: 784df303a9e75f062c1e069d2bdb88578a76ba0e
Best regards,
--
Akhil P Oommen <akhilpo(a)oss.qualcomm.com>