* linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mark Brown @ 2026-07-26 21:33 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Lorenzo Stoakes, Mike Rapoport
[-- Attachment #1: Type: text/plain, Size: 2907 bytes --]
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/x86/mm/pat/set_memory.c
between commits:
7a7c16a2d2b4d ("x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF")
25a54f65ccbaf ("x86/mm/pat: allocate split page tables as kernel page tables")
from the mm-hotfixes-unstable tree and commit:
5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
from the tip tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc arch/x86/mm/pat/set_memory.c
index 422ce7fba00c6,1f2a2ba9ce57d..0000000000000
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@@ -440,30 -441,12 +443,32 @@@ static void __cpa_collapse_large_pages(
list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
list_del(&ptdesc->pt_list);
- pagetable_free(ptdesc);
+ /*
+ * Only early alloc'd direct map should not be flagged PG_table
+ * here and those shouldn't be collapsed. However be abundantly
+ * cautious and handle the !PG_table case too.
+ */
+ if (PageTable((ptdesc_page(ptdesc))))
+ pagetable_dtor_free(ptdesc);
+ else
+ pagetable_free(ptdesc);
}
+
+ spin_unlock(&cpa_lock);
}
+static void cpa_collapse_large_pages(struct cpa_data *cpa)
+{
+ /*
+ * Take the mmap write lock on init_mm to:
+ * - Avoid a use-after-free if raced by ptdump (which takes its own
+ * write lock on init_mm).
+ * - Serialise concurrent CPA walkers.
+ */
+ scoped_guard(mmap_write_lock, &init_mm)
+ __cpa_collapse_large_pages(cpa);
+}
+
static void cpa_flush(struct cpa_data *cpa, int cache)
{
unsigned int i;
@@@ -1254,22 -1237,16 +1258,20 @@@ __split_large_page(struct cpa_data *cpa
static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
unsigned long address)
{
- struct ptdesc *ptdesc;
+ pte_t *pte;
- if (!debug_pagealloc_enabled())
- spin_unlock(&cpa_lock);
+ spin_unlock(&cpa_lock);
- ptdesc = pagetable_alloc(GFP_KERNEL, 0);
+ if (cpa->init_mm_read_locked)
+ mmap_read_unlock(&init_mm);
+ pte = pte_alloc_one_kernel(&init_mm);
+ if (cpa->init_mm_read_locked)
+ mmap_read_lock(&init_mm);
- if (!debug_pagealloc_enabled())
- spin_lock(&cpa_lock);
+ spin_lock(&cpa_lock);
- if (!ptdesc)
+ if (!pte)
return -ENOMEM;
- if (__split_large_page(cpa, kpte, address, ptdesc))
- pagetable_free(ptdesc);
+ if (__split_large_page(cpa, kpte, address, pte))
+ pte_free_kernel(&init_mm, pte);
return 0;
}
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: duplicate patch in the liveupdate tree
From: Mark Brown @ 2026-07-26 21:34 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton, Pasha Tatashin, Pratyush Yadav
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
Hi all,
The following commit is also in the liveupdate-fixes tree as a different
commit (but the same patch):
05cf3d87a0bf2 ("liveupdate: reject nonzero reserved value for SESSION_FINISH")
36882f3392395 ("liveupdate: Reference count outgoing FLB data")
5c4a03afcb217 ("liveupdate: Remember FLB retrieve() status")
797fe91e50d69 ("kho: align kho_scratch to MAX_ORDER_NR_PAGES pages")
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the liveupdate tree with the liveupdate-fixes tree
From: Mark Brown @ 2026-07-26 21:34 UTC (permalink / raw)
To: Mike Rapoport, Andrew Morton, Pasha Tatashin, Pratyush Yadav
Cc: David Matlack, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2715 bytes --]
Hi all,
Today's linux-next merge of the liveupdate tree got a conflict in:
include/linux/liveupdate.h
between commit:
459873adf5e90 ("liveupdate: Reference count outgoing FLB data")
from the liveupdate-fixes tree and commit:
36882f3392395 ("liveupdate: Reference count outgoing FLB data")
from the liveupdate tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --combined include/linux/liveupdate.h
index 63ea5417de849,6051abc0612ce..0000000000000
--- a/include/linux/liveupdate.h
+++ b/include/linux/liveupdate.h
@@@ -25,6 -25,7 +25,7 @@@ struct file
/**
* struct liveupdate_file_op_args - Arguments for file operation callbacks.
* @handler: The file handler being called.
+ * @session: The session this file belongs to.
* @retrieve_status: The retrieve status for the 'can_finish / finish'
* operation. A value of 0 means the retrieve has not been
* attempted, a positive value means the retrieve was
@@@ -45,6 -46,7 +46,7 @@@
*/
struct liveupdate_file_op_args {
struct liveupdate_file_handler *handler;
+ struct liveupdate_session *session;
int retrieve_status;
struct file *file;
u64 serialized_data;
@@@ -247,6 -249,14 +249,14 @@@ void liveupdate_flb_put_incoming(struc
int liveupdate_flb_get_outgoing(struct liveupdate_flb *flb, void **objp);
void liveupdate_flb_put_outgoing(struct liveupdate_flb *flb);
+ /* kernel can internally retrieve files */
+ int liveupdate_get_file_incoming(struct liveupdate_session *s, u64 token,
+ struct file **filep);
+
+ /* Get a token for an outgoing file, or -ENOENT if file is not preserved */
+ int liveupdate_get_token_outgoing(struct liveupdate_session *s,
+ struct file *file, u64 *tokenp);
+
#else /* CONFIG_LIVEUPDATE */
static inline bool liveupdate_enabled(void)
@@@ -299,5 -309,17 +309,17 @@@ static inline void liveupdate_flb_put_o
{
}
+ static inline int liveupdate_get_file_incoming(struct liveupdate_session *s,
+ u64 token, struct file **filep)
+ {
+ return -EOPNOTSUPP;
+ }
+
+ static inline int liveupdate_get_token_outgoing(struct liveupdate_session *s,
+ struct file *file, u64 *tokenp)
+ {
+ return -EOPNOTSUPP;
+ }
+
#endif /* CONFIG_LIVEUPDATE */
#endif /* _LINUX_LIVEUPDATE_H */
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the driver-core tree with the drm-xe tree
From: Mark Brown @ 2026-07-26 21:56 UTC (permalink / raw)
To: Greg KH, Danilo Krummrich, Rafael J. Wysocki
Cc: Bartosz Golaszewski, Greg Kroah-Hartman,
Linux Kernel Mailing List, Linux Next Mailing List, Matt Roper,
Michal Wajdeczko, Raag Jadav, Thomas Hellström
[-- Attachment #1: Type: text/plain, Size: 2079 bytes --]
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/gpu/drm/xe/xe_i2c.c
between commits:
5d8ed6b64220a ("drm/xe/i2c: Allow per domain unique id")
9420abf8dbc2e ("drm/xe/i2c: Drop manual VF check")
from the drm-xe tree and commits:
e766abbc5191b ("drm/xe/i2c: use platform_device_set_fwnode()")
0f485f88656af ("drm/xe/i2c: use device_create_managed_software_node()")
from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/gpu/drm/xe/xe_i2c.c
index a26c38bb17a15,5b0026bdb1c60..0000000000000
--- a/drivers/gpu/drm/xe/xe_i2c.c
+++ b/drivers/gpu/drm/xe/xe_i2c.c
@@@ -93,15 -93,7 +93,10 @@@ static int xe_i2c_register_adapter(stru
{
struct pci_dev *pci = to_pci_dev(i2c->drm_dev);
struct platform_device *pdev;
- struct fwnode_handle *fwnode;
int ret;
+ u32 id;
+
- fwnode = fwnode_create_software_node(xe_i2c_adapter_properties, NULL);
- if (IS_ERR(fwnode))
- return PTR_ERR(fwnode);
-
+ id = (pci_domain_nr(pci->bus) << 16) | pci_dev_id(pci);
/*
* Not using platform_device_register_full() here because we don't have
@@@ -109,11 -101,15 +104,15 @@@
* uses that handle, but it may be called before
* platform_device_register_full() is done.
*/
- pdev = platform_device_alloc(adapter_name, pci_dev_id(pci));
+ pdev = platform_device_alloc(adapter_name, id);
- if (!pdev) {
- ret = -ENOMEM;
- goto err_fwnode_remove;
- }
+ if (!pdev)
+ return -ENOMEM;
+
+ ret = device_create_managed_software_node(&pdev->dev,
+ xe_i2c_adapter_properties,
+ NULL);
+ if (ret)
+ goto err_pdev_put;
if (i2c->adapter_irq) {
struct resource res;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the driver-core tree with the drm-rust tree
From: Mark Brown @ 2026-07-26 21:57 UTC (permalink / raw)
To: Greg KH, Danilo Krummrich, Rafael J. Wysocki
Cc: Alexandre Courbot, Gary Guo, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
drivers/gpu/nova-core/gpu.rs
between commit:
f1aab4b1ab829 ("gpu: nova-core: avoid repeated calls to pci::Device::as_ref")
from the drm-rust tree and commit:
f7acb19abcd86 ("rust: device: make lifetime on `Core` and `CoreInternal` invariant")
from the driver-core tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/gpu/nova-core/gpu.rs
index 42a4cd7971fa1,b603b0bd2692b..0000000000000
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@@ -277,61 -284,15 +277,61 @@@ struct GspResources<'gpu>
unload_bundle: Option<gsp::UnloadBundle>,
}
+/// Structure holding the resources required to operate the GPU.
+#[pin_data]
+pub(crate) struct Gpu<'gpu> {
+ spec: Spec,
+ /// Static GPU information as provided by the GSP.
+ gsp_static_info: GetGspStaticInfoReply,
+ /// GSP and its resources.
+ #[pin]
+ gsp_resources: GspResources<'gpu>,
+ /// System memory page required for flushing all pending GPU-side memory writes done through
+ /// PCIE into system memory, via sysmembar (A GPU-initiated HW memory-barrier operation).
+ ///
+ /// Must be kept declared *after* `gsp_resources`, as the latter's `PinnedDrop` implementation
+ /// requires the sysmem flush page to be in place.
+ sysmem_flush: SysmemFlush<'gpu>,
+}
+
+#[pinned_drop]
+impl PinnedDrop for GspResources<'_> {
+ fn drop(self: Pin<&mut Self>) {
+ let this = self.project();
+ let device = *this.device;
+ let bar = *this.bar;
+ let bundle = this.unload_bundle.take();
+
+ let _ = this
+ .gsp
+ .as_ref()
+ .get_ref()
+ .unload(
+ GspBootContext {
+ pdev: device,
+ bar,
+ chipset: this.spec.chipset,
+ gsp_falcon: &*this.gsp_falcon,
+ sec2_falcon: &*this.sec2_falcon,
+ fsp: this.fsp.as_mut(),
+ vgpu: &*this.vgpu,
+ },
+ bundle,
+ )
+ .inspect_err(|e| dev_err!(device, "failed to unload GSP: {:?}\n", e));
+ }
+}
+
impl<'gpu> Gpu<'gpu> {
- pub(crate) fn new(
- pdev: &'gpu pci::Device<device::Core<'_>>,
+ pub(crate) fn new<'a>(
+ pdev: &'gpu pci::Device<device::Core<'a>>,
bar: Bar0<'gpu>,
- ) -> impl PinInit<Self, Error> + 'gpu {
+ ) -> impl PinInit<Self, Error> + use<'gpu, 'a> {
+ let dev = pdev.as_ref();
+
try_pin_init!(Self {
- device: pdev.as_ref(),
- spec: Spec::new(pdev.as_ref(), bar).inspect(|spec| {
- dev_info!(pdev,"NVIDIA ({})\n", spec);
+ spec: Spec::new(dev, bar).inspect(|spec| {
+ dev_info!(dev,"NVIDIA ({})\n", spec);
})?,
// We must wait for GFW_BOOT completion before doing any significant setup on the GPU.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the driver-core tree with the drm-rust tree
From: Danilo Krummrich @ 2026-07-26 22:30 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Rafael J. Wysocki, Alexandre Courbot, Gary Guo,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amaCtUBUZZ400yf3@sirena.org.uk>
On Sun Jul 26, 2026 at 11:57 PM CEST, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> drivers/gpu/nova-core/gpu.rs
>
> between commit:
>
> f1aab4b1ab829 ("gpu: nova-core: avoid repeated calls to pci::Device::as_ref")
>
> from the drm-rust tree and commit:
>
> f7acb19abcd86 ("rust: device: make lifetime on `Core` and `CoreInternal` invariant")
>
> from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
LGTM, thanks!
^ permalink raw reply
* Re: linux-next: manual merge of the driver-core tree with the drm-xe tree
From: Danilo Krummrich @ 2026-07-26 22:33 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Rafael J. Wysocki, Bartosz Golaszewski,
Greg Kroah-Hartman, Linux Kernel Mailing List,
Linux Next Mailing List, Matt Roper, Michal Wajdeczko, Raag Jadav,
Thomas Hellström
In-Reply-To: <amaCqZUpvgKLe9gC@sirena.org.uk>
On Sun Jul 26, 2026 at 11:56 PM CEST, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> drivers/gpu/drm/xe/xe_i2c.c
>
> between commits:
>
> 5d8ed6b64220a ("drm/xe/i2c: Allow per domain unique id")
> 9420abf8dbc2e ("drm/xe/i2c: Drop manual VF check")
>
> from the drm-xe tree and commits:
>
> e766abbc5191b ("drm/xe/i2c: use platform_device_set_fwnode()")
> 0f485f88656af ("drm/xe/i2c: use device_create_managed_software_node()")
>
> from the driver-core tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
LGTM, thanks!
^ permalink raw reply
* linux-next: build failure after merge of the fastrpc tree
From: Mark Brown @ 2026-07-26 22:42 UTC (permalink / raw)
To: Srini Kandagatla, Ekansh Gupta
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3078 bytes --]
Hi all,
After merging the fastrpc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
/tmp/next/build/drivers/misc/fastrpc.c:599:29: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
599 | idr_remove(&cctx->ctx_idr, FIELD_GET(FASTRPC_CTXID_MASK, ctx->ctxid));
| ^
/tmp/next/build/drivers/misc/fastrpc.c:737:15: error: call to undeclared function 'FIELD_PREP'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
737 | ctx->ctxid = FIELD_PREP(FASTRPC_CTXID_MASK, ret) |
| ^
/tmp/next/build/drivers/misc/fastrpc.c:2711:10: error: call to undeclared function 'FIELD_GET'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
2711 | ctxid = FIELD_GET(FASTRPC_CTXID_MASK, rsp->ctx);
| ^
/tmp/next/build/drivers/misc/fastrpc.c:2735:4: error: format specifies type 'unsigned long long' but the argument has type 'int' [-Werror,-Wformat]
2733 | "Stale glink response ctx 0x%llx (expected seq 0x%llx), dropping\n",
| ~~~~
| %x
2734 | rsp->ctx,
2735 | FIELD_GET(FASTRPC_CTXID_SEQ_MASK, ctx->ctxid));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/include/linux/dev_printk.h:165:39: note: expanded from macro 'dev_dbg'
165 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:285:19: note: expanded from macro 'dynamic_dev_dbg'
285 | dev, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:261:59: note: expanded from macro '_dynamic_func_call'
261 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, ##__VA_ARGS__)
| ^~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:259:65: note: expanded from macro '_dynamic_func_call_cls'
259 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, ##__VA_ARGS__)
| ^~~~~~~~~~~
/tmp/next/build/include/linux/dynamic_debug.h:231:15: note: expanded from macro '__dynamic_func_call_cls'
231 | func(&id, ##__VA_ARGS__); \
| ^~~~~~~~~~~
4 errors generated.
Caused by commit
10555ba6126ed (misc: fastrpc: Replace hardcoded ctxid mask with GENMASK)
(and one of the subsequent ones that also uses those macros). I have
use the tree from next-20260723 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in next-20260722
From: Bert Karwatzki @ 2026-07-26 22:52 UTC (permalink / raw)
To: linux-kernel, Rafal Ostrowski
Cc: linux-next, linux-rt-devel, amd-gfx, Alex Deucher,
Mario Limonciello, Sebastian Andrzej Siewior, Thomas Gleixner,
spasswolf
In-Reply-To: <6e0b713cffd64b3c30eb4ff04e50721bac9cf8ca.camel@web.de>
Am Sonntag, dem 26.07.2026 um 20:47 +0200 schrieb Bert Karwatzki:
> Am Sonntag, dem 26.07.2026 um 01:16 +0200 schrieb Bert Karwatzki:
>
>
> Now I've run a test with
> commit 8bf0cb97edb ("drm/amd/display: Move dml2_destroy to non-FPU compilation unit")
> with the following debugging patch:
>
As I had no better idea I started throwing printk()s into the general
direction of the bug, and found this after some attempts:
/*******************************************************************************
* Public functions
******************************************************************************/
struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
{
printk(KERN_INFO "%s %d: preempt_count = %d\n", __func__, __LINE__, preempt_count());
struct dc_plane_state *plane_state = kvzalloc_obj(*plane_state,
GFP_ATOMIC);
printk(KERN_INFO "%s %d\n", __func__, __LINE__);
if (NULL == plane_state)
return NULL;
kref_init(&plane_state->refcount);
dc_plane_construct(dc->ctx, plane_state);
return plane_state;
}
In the error case this prints "preempt_count = 2"! (only if dc_create_plane_state()
is called from dc_state_create_phantom_plane()).
If I combine this with the "solution" from above
diff --git a/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c b/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
index cb93bfbe9e9e..7a90098ec118 100644
--- a/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
+++ b/drivers/gpu/drm/amd/display/dc/resource/dcn401/dcn401_resource.c
@@ -1693,11 +1693,9 @@ enum dc_status dcn401_validate_bandwidth(struct dc *dc,
}
if (dc->debug.using_dml2) {
- DC_FP_START();
status = dml2_validate(dc, context,
context->power_source == DC_POWER_SOURCE_DC ? context->bw_ctx.dml2_dc_power_source : context->bw_ctx.dml2,
validate_mode) ? DC_OK : DC_FAIL_BANDWIDTH_VALIDATE;
- DC_FP_END();
}
if (validate_mode == DC_VALIDATE_MODE_AND_PROGRAMMING && status == DC_OK && dc_state_is_subvp_in_use(context)) {
@@ -1718,11 +1716,9 @@ enum dc_status dcn401_validate_bandwidth(struct dc *dc,
if (validate_mode == DC_VALIDATE_MODE_AND_PROGRAMMING && status == DC_FAIL_HW_CURSOR_SUPPORT) {
/* attempt to validate again with subvp disabled due to cursor */
if (dc->debug.using_dml2) {
- DC_FP_START();
status = dml2_validate(dc, context,
context->power_source == DC_POWER_SOURCE_DC ? context->bw_ctx.dml2_dc_power_source : context->bw_ctx.dml2,
validate_mode) ? DC_OK : DC_FAIL_BANDWIDTH_VALIDATE;
- DC_FP_END();
}
}
I get in all cases "preempt_count = 0" again.
I also monitored the preempt_count with this patch applied
on top of commit
02c3060ee303 ("drm/amdgpu: add support to query vram info from firmware")
(this is the last commit before the problematic patchset
32c1c35b6d8b drm/amd/display: Move FPU Guards From DML To DC - Part 3
4bb2f0721ed8 drm/amd/display: Move FPU Guards From DML To DC - Part 2
3539437f354b drm/amd/display: Move FPU Guards From DML To DC - Part 1)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
index 5f12dcca7f71..29f45b556371 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
@@ -85,6 +85,7 @@ uint8_t dc_plane_get_pipe_mask(struct dc_state *dc_state, const struct dc_plane
******************************************************************************/
struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
{
+ printk(KERN_INFO "%s 0: preempt_count = %d\n", __func__, preempt_count());
struct dc_plane_state *plane_state = kvzalloc_obj(*plane_state,
GFP_ATOMIC);
Again I get only 0 for the preempt_count.
Bert Karwatzki
^ permalink raw reply related
* linux-next: Tree for Jul 26
From: Mark Brown @ 2026-07-26 23:19 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2108 bytes --]
Hi all,
Changes since 20260723:
The vfs-brauner tree acquired a build failure, I used the version from
next-20260723 instead.
The amdgpu tree acquired a conflict with the drm-fixes tree.
The tip tree acquired a conflict with the mm-hotfixes-unstable tree.
The liveupdate tree acquired a conflict with the liveupdate-fixes tree.
The char-misc tree acquired a conflict with the drm-xe tree.
The char-misc tree acquired a conflict with the drm-rust tree.
The fastrpc tree acquired a build failure, I used the version from
next-20260723 instead.
Non-merge commits (relative to Linus' tree): 8374
7774 files changed, 386851 insertions(+), 121366 deletions(-)
----------------------------------------------------------------------------
I have created today's linux-next tree at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at https://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There is also the merge.log file in the Next
directory. Between each merge, the tree was built with a defconfig
for arm64, an allmodconfig for x86_64, a multi_v7_defconfig for arm,
an arm64 build of various kselftests, a KUnit build and run on arm64,
and a native build of tools/perf. After the final fixups (if any), I do
an x86_64 modules_install followed by builds for x86_64 allnoconfig,
arm64 allyesconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig and pseries_le_defconfig and i386, s390, sparc and
sparc64 defconfig and htmldocs.
Below is a summary of the state of the merge.
I am currently merging 429 trees (counting Linus' and 133 trees of bug
fix patches pending for the current release).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Thanks to Paul Gortmaker for triage and bug fixes.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-27 3:56 UTC (permalink / raw)
To: Mark Brown
Cc: Tetsuo Handa, Miguel Ojeda, Alexander Potapenko,
Christoph Hellwig, Aleksandr Nogikh, Boqun Feng, Gary Guo,
linux-next, linux-kernel, Miguel Ojeda, Linus Torvalds, peterz,
will, longman, mingo, gregkh
In-Reply-To: <0e5ea495-07a2-4f83-8fd7-c90563bc12c4@sirena.org.uk>
On Sun, Jul 26, 2026 at 06:49:44PM -0500, Mark Brown wrote:
> The other side of this is that the reason people are noticing that you
> have added these patches is that you are causing breakage and disruption
> for them that catches them by surprise, a lot of what's coming through
> here is that you need to work actively with other people.
I will note that the last person who attempted to push changes to
other subsystems via their own tree was Kent Overstreet. That was
considered **extremely** anti-social, and after people complained
Linus agreed to reject any pull request that had changes outside of
bcachefs.
This is slightly different, in that it is pushing broken patches into
linux-next, instead of Linus's tree, but I think there is a similar
precedent. If someone is doing something abusive, it doesn't matter
whether it's because they think they are doing something where the
means justify the ends (whether it's "I fix syzbot bugs" or "I make a
file system which doesn't eat your data"). If you do things in an
antisocial way, Maintainers are *not* obligated to work with you, and
while you can appeal to Linus, you might not like the resolution....
- Ted
^ permalink raw reply
* Re: linux-next: duplicate patch in the liveupdate tree
From: Mike Rapoport @ 2026-07-27 5:35 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Morton, Pasha Tatashin, Pratyush Yadav,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amZ9TMnWRcvjlsOH@sirena.org.uk>
On Sun, Jul 26, 2026 at 10:34:04PM +0100, Mark Brown wrote:
> Hi all,
>
> The following commit is also in the liveupdate-fixes tree as a different
> commit (but the same patch):
>
> 05cf3d87a0bf2 ("liveupdate: reject nonzero reserved value for SESSION_FINISH")
> 36882f3392395 ("liveupdate: Reference count outgoing FLB data")
> 5c4a03afcb217 ("liveupdate: Remember FLB retrieve() status")
> 797fe91e50d69 ("kho: align kho_scratch to MAX_ORDER_NR_PAGES pages")
Argh, looks like I forgot to push fixes after trailers update :/
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mike Rapoport @ 2026-07-27 5:48 UTC (permalink / raw)
To: Mark Brown
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Lorenzo Stoakes
In-Reply-To: <amZ9QR_9NYqq6JMy@sirena.org.uk>
Hi Mark,
On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
> arch/x86/mm/pat/set_memory.c
>
> between commits:
>
> 7a7c16a2d2b4d ("x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF")
> 25a54f65ccbaf ("x86/mm/pat: allocate split page tables as kernel page tables")
>
> from the mm-hotfixes-unstable tree and commit:
>
> 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
>
> from the tip tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --cc arch/x86/mm/pat/set_memory.c
> index 422ce7fba00c6,1f2a2ba9ce57d..0000000000000
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@@ -440,30 -441,12 +443,32 @@@ static void __cpa_collapse_large_pages(
>
> list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> list_del(&ptdesc->pt_list);
> - pagetable_free(ptdesc);
> + /*
> + * Only early alloc'd direct map should not be flagged PG_table
> + * here and those shouldn't be collapsed. However be abundantly
> + * cautious and handle the !PG_table case too.
> + */
> + if (PageTable((ptdesc_page(ptdesc))))
> + pagetable_dtor_free(ptdesc);
> + else
> + pagetable_free(ptdesc);
> }
> +
> + spin_unlock(&cpa_lock);
> }
>
> +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> +{
> + /*
> + * Take the mmap write lock on init_mm to:
> + * - Avoid a use-after-free if raced by ptdump (which takes its own
> + * write lock on init_mm).
> + * - Serialise concurrent CPA walkers.
> + */
> + scoped_guard(mmap_write_lock, &init_mm)
> + __cpa_collapse_large_pages(cpa);
> +}
> +
> static void cpa_flush(struct cpa_data *cpa, int cache)
> {
> unsigned int i;
> @@@ -1254,22 -1237,16 +1258,20 @@@ __split_large_page(struct cpa_data *cpa
> static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
> unsigned long address)
> {
> - struct ptdesc *ptdesc;
> + pte_t *pte;
>
> - if (!debug_pagealloc_enabled())
> - spin_unlock(&cpa_lock);
> + spin_unlock(&cpa_lock);
This should be
if (!debug_pagealloc_enabled())
spin_unlock(&cpa_lock);
> - ptdesc = pagetable_alloc(GFP_KERNEL, 0);
> + if (cpa->init_mm_read_locked)
> + mmap_read_unlock(&init_mm);
> + pte = pte_alloc_one_kernel(&init_mm);
> + if (cpa->init_mm_read_locked)
> + mmap_read_lock(&init_mm);
> - if (!debug_pagealloc_enabled())
> - spin_lock(&cpa_lock);
> + spin_lock(&cpa_lock);
And this
if (!debug_pagealloc_enabled())
spin_lock(&cpa_lock);
> - if (!ptdesc)
> + if (!pte)
> return -ENOMEM;
>
> - if (__split_large_page(cpa, kpte, address, ptdesc))
> - pagetable_free(ptdesc);
> + if (__split_large_page(cpa, kpte, address, pte))
> + pte_free_kernel(&init_mm, pte);
>
> return 0;
> }
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in v7.1+ with PREEMPT_RT
From: Bert Karwatzki @ 2026-07-27 10:06 UTC (permalink / raw)
To: linux-kernel, Rafal Ostrowski
Cc: linux-next, linux-rt-devel, amd-gfx, Alex Deucher,
Mario Limonciello, Sebastian Andrzej Siewior, Thomas Gleixner,
spasswolf
In-Reply-To: <f012ef660c71e5d85bd746caab2f6a6e456671de.camel@web.de>
This can be fixed like this
struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
{
struct dc_plane_state *plane_state;
DC_RUN_WITH_PREEMPTION_ENABLED(plane_state = kvzalloc_obj(*plane_state, GFP_ATOMIC));
if (NULL == plane_state)
return NULL;
kref_init(&plane_state->refcount);
dc_plane_construct(dc->ctx, plane_state);
return plane_state;
}
I also found missing DC_RUN_WITH_PREEMPTION_ENABLED in an error path, I'm preparing
a patch for next-20260721 (next-20260722+ have broken reboot due to the mt7925 issue
mentioned above).
Also, is preempt_{disable,enable}() really necessary in DC_FPU_{BEGIN,END}?
Could migrate_{disable,enable}() be enough instead? This way we wouldn't need
DC_RUN_WITH_PREEMPTION_ENABLED at all(?).
Bert Karwatzki
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in v7.1+ with PREEMPT_RT
From: Ostrowski, Rafal @ 2026-07-27 10:35 UTC (permalink / raw)
To: Bert Karwatzki, linux-kernel@vger.kernel.org
Cc: linux-next@vger.kernel.org, linux-rt-devel@lists.linux.dev,
amd-gfx@lists.freedesktop.org, Deucher, Alexander,
Limonciello, Mario, Sebastian Andrzej Siewior, Thomas Gleixner
In-Reply-To: <5b5559e0fcc162bb0a2b7ab9764b8040c981c1d5.camel@web.de>
> This can be fixed like this
>
> struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
> {
> struct dc_plane_state *plane_state;
> DC_RUN_WITH_PREEMPTION_ENABLED(plane_state = kvzalloc_obj(*plane_state, GFP_ATOMIC));
>
> if (NULL == plane_state)
> return NULL;
>
> kref_init(&plane_state->refcount);
> dc_plane_construct(dc->ctx, plane_state);
>
> return plane_state;
> }
>
> I also found missing DC_RUN_WITH_PREEMPTION_ENABLED in an error path, I'm preparing
> a patch for next-20260721 (next-20260722+ have broken reboot due to the mt7925 issue
> mentioned above).
> Also, is preempt_{disable,enable}() really necessary in DC_FPU_{BEGIN,END}?
> Could migrate_{disable,enable}() be enough instead? This way we wouldn't need
> DC_RUN_WITH_PREEMPTION_ENABLED at all(?).
>
> Bert Karwatzki
Hi Bert,
Sorry for the trouble these changes caused on your setup. It reproduces deterministically on PREEMPT_RT — that's the key condition here. On RT the page allocator always takes a sleeping rt_spin_lock, so any allocation inside the FPU-protected region is illegal, whereas on non-RT kernels the same allocation usually stays on the fast path and doesn't sleep, which is why this hasn't been widely reported.
Some context on how the FPU handling is meant to work:
DC_FP_START/END (DC_FPU_BEGIN/END): these require a non-preemptible context. The kernel needs exclusive use of the FPU while we run FP code, so preemption must be disabled around it. Note that kernel_fpu_begin() itself does preempt_disable() (via fpregs_lock()) unconditionally — on PREEMPT_RT as well. That directly answers your migrate_disable() question: swapping the preempt_disable/enable in dc_fpu_begin/end for migrate_disable/enable would not make the region preemptible, because kernel_fpu_begin() disables preemption on its own regardless. migrate_disable() would only pin us to the CPU (enough to protect the per-CPU recursion counter), but the region would still be atomic, so it wouldn't remove the need for DC_RUN_WITH_PREEMPTION_ENABLED. The only thing that actually re-enables preemption is leaving the FPU (kernel_fpu_end()), which is exactly what that macro does.
DML layer: the whole DML layer is compiled as FPU code (see the FP compilation flags in the makefile), with only a few wrapper/exception units. As a result, any function that calls into DML must wrap the call in a DC_FP_START()/DC_FP_END() block.
DC_RUN_WITH_PREEMPTION_ENABLED: this is the workaround for the cases where we must allocate or sleep while inside an FPU region. The important rule is that this macro must always live in a non-FPU translation unit (a DC file or a DML wrapper/exception file) — never in pure FPU-compiled DML code, since it manipulates the FPU guard itself. With that in mind there are effectively two cases:
DC → DC_FP_START → call DML → no allocation/sleep in the DML path → back to DC → DC_FP_END. Clean case, no macro needed.
DC → DC_FP_START → call DML → DML calls back into a DC (or wrapper) function that allocates/sleeps → wrap the affected code (allocation, sleep) in DC_RUN_WITH_PREEMPTION_ENABLED in that DC function → back to DML → back to DC → DC_FP_END.
The phantom-plane allocation is the second case: DML calls back into dc_create_plane_state(), which is a DC function, so the wrap belongs there.
About the fix:
DC_RUN_WITH_PREEMPTION_ENABLED(plane_state = kvzalloc_obj(*plane_state, GFP_ATOMIC));
This fix looks correct to me.
Kind Regards,
Rafal
^ permalink raw reply
* [PATCH] drm/amd/display: fix usage of DC_FPU_{BEGIN,END} with PREEMPT_RT
From: Bert Karwatzki @ 2026-07-27 10:50 UTC (permalink / raw)
To: linux-kernel
Cc: Bert Karwatzki, linux-next, linux-rt-devel, amd-gfx, # = v7 . 1,
Alex Deucher, Rafal Ostrowski, Mario Limonciello,
Sebastian Andrzej Siewior, Thomas Gleixner
In-Reply-To: <DS7PR12MB5838D278341AE35E0383B951F8CC2@DS7PR12MB5838.namprd12.prod.outlook.com>
On PREEMPT_RT kernels kvzalloc_obj() can sleep because spin_lock is
converted to rt_mutex. dc_create_plane_state() can be called while
inside an FPU-guarded region, resuling in "scheduling while atomic"
errors on PREEMPT_RT kernels.
Fix this by calling kvzalloc_obj() with DC_RUN_WITH_PREEMPTION_ENABLED().
Also fix the error path in dc_create_stream_for_sink().
Fixes: 3539437f354b ("drm/amd/display: Move FPU Guards From DML To DC - Part 1")
Link: https://lore.kernel.org/lkml/20260723123449.6494-1-spasswolf@web.de/
Signed-off-by: Bert Karwatzki <spasswolf@web.de>
---
drivers/gpu/drm/amd/display/dc/core/dc_stream.c | 5 +++--
drivers/gpu/drm/amd/display/dc/core/dc_surface.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
index dbc12640b01c..4ac835777b58 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_stream.c
@@ -233,8 +233,9 @@ struct dc_stream_state *dc_create_stream_for_sink(
fail:
if (stream) {
- kfree(stream->update_scratch);
- kfree(stream);
+ if (stream->update_scratch)
+ DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream->update_scratch));
+ DC_RUN_WITH_PREEMPTION_ENABLED(kfree(stream));
}
return NULL;
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
index 88e825a6582c..d5c6427796b6 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_surface.c
@@ -85,8 +85,8 @@ uint8_t dc_plane_get_pipe_mask(struct dc_state *dc_state, const struct dc_plane
******************************************************************************/
struct dc_plane_state *dc_create_plane_state(const struct dc *dc)
{
- struct dc_plane_state *plane_state = kvzalloc_obj(*plane_state,
- GFP_ATOMIC);
+ struct dc_plane_state *plane_state;
+ DC_RUN_WITH_PREEMPTION_ENABLED(plane_state = kvzalloc_obj(*plane_state, GFP_ATOMIC));
if (NULL == plane_state)
return NULL;
--
2.53.0
^ permalink raw reply related
* Fixes tags need work in the ceph tree
From: Mark Brown @ 2026-07-27 11:28 UTC (permalink / raw)
To: Jeff Layton, Ilya Dryomov; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
In commit
591569339cb56 ("ceph: fix MDS random selection readiness predicate")
Fixes tag
Fixes: b38c9eb4757d ("ceph: allow choose random mds")
has these problem(s):
- Subject does not match target commit subject
Just use
git log -1 --format='Fixes: %h ("%s")'
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Unexpected files in the drm tree
From: Mark Brown @ 2026-07-27 11:29 UTC (permalink / raw)
To: Dave Airlie, DRI; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 154 bytes --]
Commit
ac3baea883dab ("drm/panel: find_panel_by_fwnode() return a counted reference")
added this unexpected file:
drivers/gpu/drm/drm_panel.c.orig
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Lorenzo Stoakes (ARM) @ 2026-07-27 11:33 UTC (permalink / raw)
To: Mike Rapoport
Cc: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Andrew Morton, Dave Hansen,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <ambxL-NxiYZ3vmpu@kernel.org>
On Mon, Jul 27, 2026 at 08:48:31AM +0300, Mike Rapoport wrote:
> Hi Mark,
>
> On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
> > Hi all,
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > arch/x86/mm/pat/set_memory.c
> >
> > between commits:
> >
> > 7a7c16a2d2b4d ("x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF")
> > 25a54f65ccbaf ("x86/mm/pat: allocate split page tables as kernel page tables")
> >
> > from the mm-hotfixes-unstable tree and commit:
> >
> > 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
> >
> > from the tip tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > diff --cc arch/x86/mm/pat/set_memory.c
> > index 422ce7fba00c6,1f2a2ba9ce57d..0000000000000
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@@ -440,30 -441,12 +443,32 @@@ static void __cpa_collapse_large_pages(
> >
> > list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> > list_del(&ptdesc->pt_list);
> > - pagetable_free(ptdesc);
> > + /*
> > + * Only early alloc'd direct map should not be flagged PG_table
> > + * here and those shouldn't be collapsed. However be abundantly
> > + * cautious and handle the !PG_table case too.
> > + */
> > + if (PageTable((ptdesc_page(ptdesc))))
> > + pagetable_dtor_free(ptdesc);
> > + else
> > + pagetable_free(ptdesc);
> > }
> > +
> > + spin_unlock(&cpa_lock);
> > }
> >
> > +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> > +{
> > + /*
> > + * Take the mmap write lock on init_mm to:
> > + * - Avoid a use-after-free if raced by ptdump (which takes its own
> > + * write lock on init_mm).
> > + * - Serialise concurrent CPA walkers.
> > + */
> > + scoped_guard(mmap_write_lock, &init_mm)
> > + __cpa_collapse_large_pages(cpa);
> > +}
> > +
> > static void cpa_flush(struct cpa_data *cpa, int cache)
> > {
> > unsigned int i;
> > @@@ -1254,22 -1237,16 +1258,20 @@@ __split_large_page(struct cpa_data *cpa
> > static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
> > unsigned long address)
> > {
> > - struct ptdesc *ptdesc;
> > + pte_t *pte;
> >
> > - if (!debug_pagealloc_enabled())
> > - spin_unlock(&cpa_lock);
> > + spin_unlock(&cpa_lock);
>
> This should be
>
> if (!debug_pagealloc_enabled())
> spin_unlock(&cpa_lock);
>
> > - ptdesc = pagetable_alloc(GFP_KERNEL, 0);
> > + if (cpa->init_mm_read_locked)
> > + mmap_read_unlock(&init_mm);
> > + pte = pte_alloc_one_kernel(&init_mm);
> > + if (cpa->init_mm_read_locked)
> > + mmap_read_lock(&init_mm);
> > - if (!debug_pagealloc_enabled())
> > - spin_lock(&cpa_lock);
> > + spin_lock(&cpa_lock);
>
> And this
>
> if (!debug_pagealloc_enabled())
> spin_lock(&cpa_lock);
>
> > - if (!ptdesc)
> > + if (!pte)
> > return -ENOMEM;
> >
> > - if (__split_large_page(cpa, kpte, address, ptdesc))
> > - pagetable_free(ptdesc);
> > + if (__split_large_page(cpa, kpte, address, pte))
> > + pte_free_kernel(&init_mm, pte);
> >
> > return 0;
> > }
>
>
>
> --
> Sincerely yours,
> Mike.
Hmm, what's the status of the x86/mm trees on this though? AFAICT Denis's
patch is still as-is and the spin_lock() vs. spin_[un]lock_irq*() issue
raised in [0] is unaddressed?
So is this fixup actually representative of what's going upstream?
Thanks, Lorenzo
[0]:https://lore.kernel.org/all/al-MrKyIafA8QR_8@lucifer/
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mark Brown @ 2026-07-27 11:38 UTC (permalink / raw)
To: Mike Rapoport
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
Andrew Morton, Dave Hansen, Linux Kernel Mailing List,
Linux Next Mailing List, Lorenzo Stoakes
In-Reply-To: <ambxL-NxiYZ3vmpu@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
On Mon, Jul 27, 2026 at 08:48:31AM +0300, Mike Rapoport wrote:
> On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
> > from the mm-hotfixes-unstable tree and commit:
> > 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
> > from the tip tree.
> > - if (!debug_pagealloc_enabled())
> > - spin_unlock(&cpa_lock);
> > + spin_unlock(&cpa_lock);
>
> This should be
> if (!debug_pagealloc_enabled())
> spin_unlock(&cpa_lock);
So essentially dropping the changes from the above commit from the tip
tree? Should that commit be there?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Fixes tags need work in the ceph tree
From: Ilya Dryomov @ 2026-07-27 11:41 UTC (permalink / raw)
To: Mark Brown; +Cc: Jeff Layton, linux-kernel, linux-next
In-Reply-To: <amdA9Kuh6idkytKa@sirena.org.uk>
On Mon, Jul 27, 2026 at 1:28 PM Mark Brown <broonie@kernel.org> wrote:
>
> In commit
>
> 591569339cb56 ("ceph: fix MDS random selection readiness predicate")
>
> Fixes tag
>
> Fixes: b38c9eb4757d ("ceph: allow choose random mds")
>
> has these problem(s):
>
> - Subject does not match target commit subject
> Just use
> git log -1 --format='Fixes: %h ("%s")'
Hi Mark,
Sorry, the patch was taken from the list and I didn't verify the Fixes
tag. I'll fix it and get into habit of double checking these going
forward.
Thanks,
Ilya
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the char-misc.current tree
From: Greg KH @ 2026-07-27 12:18 UTC (permalink / raw)
To: Alice Ryhl
Cc: Mark Brown, Arnd Bergmann, Jahnavi MN, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <al8tlTE4KgeZ92PQ@google.com>
On Tue, Jul 21, 2026 at 08:28:05AM +0000, Alice Ryhl wrote:
> On Mon, Jul 20, 2026 at 03:44:42PM +0100, Mark Brown wrote:
> > Hi all,
> >
> > Today's linux-next merge of the char-misc tree got a conflict in:
> >
> > drivers/android/binder/thread.rs
> >
> > between commit:
> >
> > bb66b1a345253 ("rust_binder: only print failure if error has source")
> >
> > from the char-misc.current tree and commit:
> >
> > c61f3ad2213cf ("rust_binder: Implement BINDER_DEBUG_FAILED_TRANSACTION")
> >
> > from the char-misc tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > diff --cc drivers/android/binder/thread.rs
> > index bc0ef8927905c,a51821dde0adf..0000000000000
> > --- a/drivers/android/binder/thread.rs
> > +++ b/drivers/android/binder/thread.rs
> > @@@ -1273,14 -1295,25 +1295,24 @@@ impl Thread
> > inner.extended_error =
> > ExtendedError::new(info.debug_id as u32, err.reply, source.to_errno());
> > }
> > - }
> >
> > - pr_warn!(
> > - "{}:{} transaction to {} failed: {err:?}",
> > - info.from_pid,
> > - info.from_tid,
> > - info.to_pid
> > - binder_debug!(
> > - FailedTransaction,
> > - "transaction {} to {}:{} failed {:?}, code {} size {}-{}",
> > - if info.is_reply {
> > - "reply"
> > - } else if info.is_oneway() {
> > - "async"
> > - } else {
> > - "call"
> > - },
> > - info.to_pid,
> > - info.to_tid,
> > - err,
> > - info.code,
> > - info.data_size,
> > - info.offsets_size
> > - );
> > ++ binder_debug!(
> > ++ FailedTransaction,
> > ++ "transaction {} to {}:{} failed {:?}, code {} size {}-{}",
> > ++ if info.is_reply {
> > ++ "reply"
> > ++ } else if info.is_oneway() {
> > ++ "async"
> > ++ } else {
> > ++ "call"
> > ++ },
> > ++ info.to_pid,
> > ++ info.to_tid,
> > ++ err,
> > ++ info.code,
> > ++ info.data_size,
> > ++ info.offsets_size
> > + );
> > - }
> > }
> > }
>
> I think you're missing a closing } after the binder_debug! call.
> Otherwise LGTM.
>
> error: this file contains an unclosed delimiter
> --> drivers/android/binder/thread.rs:1743:3
> |
> 453 | impl Thread {
> | - unclosed delimiter
> ...
> 1290 | if let Some(source) = &err.source {
> | - this delimiter might not be properly closed...
> ...
> 1316 | }
> | - ...as it matches this but it has different indentation
> ...
> 1743 | }
> | ^
>
> error: aborting due to 1 previous error
That trailing ) on the same indent line just looks odd to me, which is
why I can see it's going to be easy to make this type of merge
mistake...
I've done this now in my tree so all should be good going forward,
thanks!
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the char-misc tree with the char-misc.current tree
From: Greg KH @ 2026-07-27 12:18 UTC (permalink / raw)
To: Mark Brown
Cc: Arnd Bergmann, Linux Kernel Mailing List, Linux Next Mailing List,
Runyu Xiao, Vu Nguyen Anh Khoa
In-Reply-To: <al40xMdxeEHvedyh@sirena.org.uk>
On Mon, Jul 20, 2026 at 03:46:28PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/misc/nsm.c
>
> between commit:
>
> ce1fed11d18e1 ("misc: nsm: only unlock nsm_dev on post-lock error paths")
>
> from the char-misc.current tree and commit:
>
> 937cd823bb2c9 ("misc: nsm: do not unlock mutex before locking it")
>
> from the char-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> diff --combined drivers/misc/nsm.c
> index 3960506eb7ab3,bb254ee65b840..0000000000000
> --- a/drivers/misc/nsm.c
> +++ b/drivers/misc/nsm.c
> @@@ -243,7 -243,7 +243,7 @@@ static int nsm_sendrecv_msg_locked(stru
> goto cleanup;
> }
>
> - msg->resp.len = len;
> + msg->resp.len = min_t(unsigned int, len, sizeof(msg->resp.data));
>
> rc = 0;
>
> @@@ -365,9 -365,8 +365,8 @@@ static long nsm_dev_ioctl(struct file *
> return -EINVAL;
>
> /* Copy user argument struct to kernel argument struct */
> - r = -EFAULT;
> if (copy_from_user(&raw, argp, _IOC_SIZE(cmd)))
> - return r;
> + return -EFAULT;
>
> mutex_lock(&nsm->lock);
>
> @@@ -413,7 -412,6 +412,7 @@@ static int nsm_device_init_vq(struct vi
> }
>
> static const struct file_operations nsm_dev_fops = {
> + .owner = THIS_MODULE,
> .unlocked_ioctl = nsm_dev_ioctl,
> .compat_ioctl = compat_ptr_ioctl,
> };
Thanks, looks good, this is now done in my tree too.
greg k-h
^ permalink raw reply
* Re: linux-next: manual merge of the tip tree with the mm-hotfixes-unstable tree
From: Mike Rapoport @ 2026-07-27 13:03 UTC (permalink / raw)
To: Lorenzo Stoakes (ARM)
Cc: Mark Brown, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
Peter Zijlstra, Andrew Morton, Dave Hansen,
Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amdA05gNFyzg4Uwc@lucifer>
On Mon, Jul 27, 2026 at 12:33:30PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Mon, Jul 27, 2026 at 08:48:31AM +0300, Mike Rapoport wrote:
> > Hi Mark,
> >
> > On Sun, Jul 26, 2026 at 10:33:53PM +0100, Mark Brown wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > > arch/x86/mm/pat/set_memory.c
> > >
> > > between commits:
> > >
> > > 7a7c16a2d2b4d ("x86/mm/pat: acquire init_mm read lock on attribute change to avoid UAF")
> > > 25a54f65ccbaf ("x86/mm/pat: allocate split page tables as kernel page tables")
> > >
> > > from the mm-hotfixes-unstable tree and commit:
> > >
> > > 5fce67641a3ed ("x86/mm/pat: Don't gate cpa_lock on debug_pagealloc_enabled()")
> > >
> > > from the tip tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging. You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> > >
> > > diff --cc arch/x86/mm/pat/set_memory.c
> > > index 422ce7fba00c6,1f2a2ba9ce57d..0000000000000
> > > --- a/arch/x86/mm/pat/set_memory.c
> > > +++ b/arch/x86/mm/pat/set_memory.c
> > > @@@ -440,30 -441,12 +443,32 @@@ static void __cpa_collapse_large_pages(
> > >
> > > list_for_each_entry_safe(ptdesc, tmp, &pgtables, pt_list) {
> > > list_del(&ptdesc->pt_list);
> > > - pagetable_free(ptdesc);
> > > + /*
> > > + * Only early alloc'd direct map should not be flagged PG_table
> > > + * here and those shouldn't be collapsed. However be abundantly
> > > + * cautious and handle the !PG_table case too.
> > > + */
> > > + if (PageTable((ptdesc_page(ptdesc))))
> > > + pagetable_dtor_free(ptdesc);
> > > + else
> > > + pagetable_free(ptdesc);
> > > }
> > > +
> > > + spin_unlock(&cpa_lock);
> > > }
> > >
> > > +static void cpa_collapse_large_pages(struct cpa_data *cpa)
> > > +{
> > > + /*
> > > + * Take the mmap write lock on init_mm to:
> > > + * - Avoid a use-after-free if raced by ptdump (which takes its own
> > > + * write lock on init_mm).
> > > + * - Serialise concurrent CPA walkers.
> > > + */
> > > + scoped_guard(mmap_write_lock, &init_mm)
> > > + __cpa_collapse_large_pages(cpa);
> > > +}
> > > +
> > > static void cpa_flush(struct cpa_data *cpa, int cache)
> > > {
> > > unsigned int i;
> > > @@@ -1254,22 -1237,16 +1258,20 @@@ __split_large_page(struct cpa_data *cpa
> > > static int split_large_page(struct cpa_data *cpa, pte_t *kpte,
> > > unsigned long address)
> > > {
> > > - struct ptdesc *ptdesc;
> > > + pte_t *pte;
> > >
> > > - if (!debug_pagealloc_enabled())
> > > - spin_unlock(&cpa_lock);
> > > + spin_unlock(&cpa_lock);
> >
> > This should be
> >
> > if (!debug_pagealloc_enabled())
> > spin_unlock(&cpa_lock);
> >
> > > - ptdesc = pagetable_alloc(GFP_KERNEL, 0);
> > > + if (cpa->init_mm_read_locked)
> > > + mmap_read_unlock(&init_mm);
> > > + pte = pte_alloc_one_kernel(&init_mm);
> > > + if (cpa->init_mm_read_locked)
> > > + mmap_read_lock(&init_mm);
> > > - if (!debug_pagealloc_enabled())
> > > - spin_lock(&cpa_lock);
> > > + spin_lock(&cpa_lock);
> >
> > And this
> >
> > if (!debug_pagealloc_enabled())
> > spin_lock(&cpa_lock);
> >
> > > - if (!ptdesc)
> > > + if (!pte)
> > > return -ENOMEM;
> > >
> > > - if (__split_large_page(cpa, kpte, address, ptdesc))
> > > - pagetable_free(ptdesc);
> > > + if (__split_large_page(cpa, kpte, address, pte))
> > > + pte_free_kernel(&init_mm, pte);
> > >
> > > return 0;
> > > }
> >
> >
> >
> > --
> > Sincerely yours,
> > Mike.
>
> Hmm, what's the status of the x86/mm trees on this though? AFAICT Denis's
> patch is still as-is and the spin_lock() vs. spin_[un]lock_irq*() issue
> raised in [0] is unaddressed?
Maybe it's best to take x86 cpa fixes via x86 tree in the end.
I collected them on top of the current tip/x86/mm:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=cpa-fixes
Can you please take a look and check I didn't miss anything? I'd like to
test it a bit more before sending out.
If we route your x86 fixes via x86 tree rather than mm tree there will be a
trivial conflict in definition of the new guards for mmap_lock, but other
than that they should merge nicely with generic and arm64 part of your UAF
set.
> Thanks, Lorenzo
>
> [0]:https://lore.kernel.org/all/al-MrKyIafA8QR_8@lucifer/
--
Sincerely yours,
Mike.
^ permalink raw reply
* linux-next: manual merge of the qcom tree with the origin tree
From: Mark Brown @ 2026-07-27 13:04 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Andy Gross
Cc: Konrad Dybcio, Linux Kernel Mailing List, Linux Next Mailing List,
Qiang Yu, Uwe Kleine-König
[-- Attachment #1: Type: text/plain, Size: 1215 bytes --]
Hi all,
Today's linux-next merge of the qcom tree got a conflict in:
drivers/clk/qcom/tcsrcc-glymur.c
between commit:
995832b2cebe6 ("Replace <linux/mod_devicetable.h> by more specific <linux/device-id/*.h> (c files)")
from the origin tree and commit:
0753091abc4b4 ("clk: qcom: tcsrcc-glymur: Add regulator supplies and migrate to clk_ref helper")
from the qcom tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc drivers/clk/qcom/tcsrcc-glymur.c
index b44fccb795c6b,3388c1c3a2aaa..0000000000000
--- a/drivers/clk/qcom/tcsrcc-glymur.c
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@@ -4,7 -4,10 +4,9 @@@
*/
#include <linux/clk-provider.h>
+ #include <linux/clk/qcom.h>
-#include <linux/mod_devicetable.h>
#include <linux/module.h>
+ #include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox