* linux-next: manual merge of the jc_docs tree with the mm-unstable tree
From: Mark Brown @ 2026-07-14 12:25 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Morton, Linux Kernel Mailing List, Linux Next Mailing List,
Manuel Ebner, Stanislav Kinsburskii
[-- Attachment #1: Type: text/plain, Size: 6834 bytes --]
Hi all,
Today's linux-next merge of the jc_docs tree got a conflict in:
Documentation/mm/hmm.rst
between commit:
d68817e9c3198 ("mm/hmm: add hmm_range_fault_unlocked_timeout() for mmap lock-drop support")
from the mm-unstable tree and commit:
e834ee8e571d5 ("docs/mm: Fix braces")
from the jc_docs 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 Documentation/mm/hmm.rst
index 4e5a750748ae5,54c461e7a143f..0000000000000
--- a/Documentation/mm/hmm.rst
+++ b/Documentation/mm/hmm.rst
@@@ -156,57 -156,42 +156,57 @@@ During the ops->invalidate() callback t
update action to the range (mark range read only, or fully unmap, etc.). The
device must complete the update before the driver callback returns.
-When the device driver wants to populate a range of virtual addresses, it can
-use::
+When the device driver wants to populate a range of virtual addresses, the
+normal interface is::
- int hmm_range_fault(struct hmm_range *range);
+ int hmm_range_fault_unlocked_timeout(struct hmm_range *range,
+ unsigned long timeout);
It will trigger a page fault on missing or read-only entries if write access is
requested (see below). Page faults use the generic mm page fault code path just
-like a CPU page fault. The usage pattern is::
+like a CPU page fault.
+
+The caller must not hold ``mmap_read_lock`` before the call.
+``hmm_range_fault_unlocked_timeout()`` takes the mmap read lock internally and
+allows ``handle_mm_fault()`` to drop it during fault handling. This is required
+for VMAs whose fault handlers may release the mmap lock, for example regions
+managed by ``userfaultfd``.
+
+If the mmap lock is dropped or the range is invalidated, the function refreshes
+``range->notifier_seq`` and restarts the walk internally. ``-EINTR`` is returned
+if mmap lock acquisition is interrupted or a fatal signal is pending during
+retry handling.
+
+The timeout is specified in jiffies; passing ``0`` means retry indefinitely. The
+timeout exists to preserve caller policy for repeated mmu-notifier invalidation
+and is checked between retry attempts. HMM does not interrupt page fault
+handling when the timeout expires, but returns ``-EBUSY`` if the retry budget is
+exhausted before a stable range is obtained.
+
+The usage pattern is::
int driver_populate_range(...)
{
struct hmm_range range;
+ unsigned long timeout;
...
+ timeout = msecs_to_jiffies(HMM_RANGE_DEFAULT_TIMEOUT);
range.notifier = &interval_sub;
range.start = ...;
range.end = ...;
range.hmm_pfns = ...;
- if (!mmget_not_zero(interval_sub->notifier.mm))
+ if (!mmget_not_zero(interval_sub.mm))
return -EFAULT;
again:
- range.notifier_seq = mmu_interval_read_begin(&interval_sub);
- mmap_read_lock(mm);
- ret = hmm_range_fault(&range);
- if (ret) {
- mmap_read_unlock(mm);
- if (ret == -EBUSY)
- goto again;
- return ret;
- }
- mmap_read_unlock(mm);
+ ret = hmm_range_fault_unlocked_timeout(&range, timeout);
+ if (ret)
+ goto out_put;
take_lock(driver->update);
- if (mmu_interval_read_retry(&ni, range.notifier_seq)) {
+ if (mmu_interval_read_retry(&interval_sub, range.notifier_seq)) {
release_lock(driver->update);
goto again;
}
@@@ -215,11 -200,7 +215,11 @@@
* under the update lock */
release_lock(driver->update);
- return 0;
+ ret = 0;
+
+ out_put:
+ mmput(interval_sub.mm);
+ return ret;
}
The driver->update lock is the same lock that the driver takes inside its
@@@ -227,19 -208,6 +227,19 @@@ invalidate() callback. That lock must b
mmu_interval_read_retry() to avoid any race with a concurrent CPU page table
update.
+Holding the mmap lock across HMM faults
+=======================================
+
+Most callers should use ``hmm_range_fault_unlocked_timeout()``. If a driver
+really needs to hold the mmap lock across work outside HMM, it can use::
+
+ int hmm_range_fault(struct hmm_range *range);
+
+The mmap lock must be held by the caller and will remain held on return. This
+interface cannot support VMAs whose fault handlers need to drop the mmap lock.
+New callers should prefer ``hmm_range_fault_unlocked_timeout()`` unless they
+have a specific requirement to keep the mmap lock held across the call.
+
Leverage default_flags and pfn_flags_mask
=========================================
@@@ -253,8 -221,8 +253,8 @@@ permission, it sets:
range->default_flags = HMM_PFN_REQ_FAULT;
range->pfn_flags_mask = 0;
-and calls hmm_range_fault() as described above. This will fill fault all pages
-in the range with at least read permission.
+and calls the HMM range fault helper as described above. This will fault
+all pages in the range with at least read permission.
Now let's say the driver wants to do the same except for one page in the range for
which it wants to have write permission. Now driver set::
@@@ -268,9 -236,9 +268,9 @@@ address == range->start + (index_of_wri
write permission i.e., if the CPU pte does not have write permission set then HMM
will call handle_mm_fault().
-After hmm_range_fault completes the flag bits are set to the current state of
-the page tables, ie HMM_PFN_VALID | HMM_PFN_WRITE will be set if the page is
-writable.
+After the HMM range fault helper completes the flag bits are set to the
+current state of the page tables, ie HMM_PFN_VALID | HMM_PFN_WRITE will be
+set if the page is writable.
Represent and manage device memory from core kernel point of view
@@@ -348,7 -316,7 +348,7 @@@ between device driver specific code an
system memory and device private memory.
One of the first steps migrate_vma_setup() does is to invalidate other
- device's MMUs with the ``mmu_notifier_invalidate_range_start(()`` and
+ device's MMUs with the ``mmu_notifier_invalidate_range_start()`` and
``mmu_notifier_invalidate_range_end()`` calls around the page table
walks to fill in the ``args->src`` array with PFNs to be migrated.
The ``invalidate_range_start()`` callback is passed a
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the mm-nonmm-unstable tree with the risc-v-fixes tree
From: Mark Brown @ 2026-07-14 11:47 UTC (permalink / raw)
To: Andrew Morton
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Paul Walmsley,
Vivian Wang
[-- Attachment #1: Type: text/plain, Size: 3604 bytes --]
Hi all,
Today's linux-next merge of the mm-nonmm-unstable tree got a conflict in:
mm/sparse-vmemmap.c
between commit:
4edd70ee6a7d0 ("mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap")
from the risc-v-fixes tree and commit:
7605044cea4d2 ("riscv: mm: avoid spurious fault after hotplugging vmemmap")
from the mm-nonmm-unstable tree. These appear to be two versions of the
same fix, it looks like one needs to be chosen - I did the conflict
resolution picking based on taste but left the non-conflicting bits of
both changes.
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 mm/sparse-vmemmap.c
index 5a2469fb1838c,290cafcfd7230..0000000000000
--- a/mm/sparse-vmemmap.c
+++ b/mm/sparse-vmemmap.c
@@@ -41,8 -41,6 +41,8 @@@
#define VMEMMAP_POPULATE_PAGEREF 0x0001
#include "internal.h"
+#include "mm_init.h"
+#include "sparse.h"
/*
* Allocate a block of memory to be used to back the virtual memory map
@@@ -344,8 -342,8 +344,8 @@@ static __meminit struct page *vmemmap_g
*
* Any initialization done here will be overwritten by memmap_init().
*
- * hugetlb_vmemmap_init() will take care of initialization after
- * memmap_init().
+ * hugetlb_bootmem_struct_page_init() will take care of initialization
+ * after memmap_init().
*/
p = vmemmap_alloc_block_zero(PAGE_SIZE, node);
@@@ -546,6 -544,12 +546,12 @@@ static int __meminit vmemmap_populate_c
#endif
+ #ifndef vmemmap_populate_finalize
+ static void __meminit vmemmap_populate_finalize(void)
+ {
+ }
+ #endif
+
struct page * __meminit __populate_section_memmap(unsigned long pfn,
unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
struct dev_pagemap *pgmap)
@@@ -566,7 -570,7 +572,7 @@@
if (r < 0)
return NULL;
- flush_cache_vmap(start, end);
+ vmemmap_populate_finalize();
return pfn_to_page(pfn);
}
@@@ -583,6 -587,17 +589,6 @@@ void __init sparse_vmemmap_init_nid_ear
{
hugetlb_vmemmap_init_early(nid);
}
-
-/*
- * This is called just before the initialization of page structures
- * through memmap_init. Zones are now initialized, so any work that
- * needs to be done that needs zone information can be done from
- * here.
- */
-void __init sparse_vmemmap_init_nid_late(int nid)
-{
- hugetlb_vmemmap_init_late(nid);
-}
#endif
static void subsection_mask_set(unsigned long *map, unsigned long pfn,
@@@ -594,7 -609,7 +600,7 @@@
bitmap_set(map, idx, end - idx + 1);
}
-void __init sparse_init_subsection_map(unsigned long pfn, unsigned long nr_pages)
+static void __init sparse_init_subsection_map_range(unsigned long pfn, unsigned long nr_pages)
{
int end_sec_nr = pfn_to_section_nr(pfn + nr_pages - 1);
unsigned long nr, start_sec_nr = pfn_to_section_nr(pfn);
@@@ -617,15 -632,6 +623,15 @@@
}
}
+void __init sparse_init_subsection_map(void)
+{
+ int i, nid;
+ unsigned long start, end;
+
+ for_each_mem_pfn_range(i, MAX_NUMNODES, &start, &end, &nid)
+ sparse_init_subsection_map_range(start, end - start);
+}
+
#ifdef CONFIG_MEMORY_HOTPLUG
/* Mark all memory sections within the pfn range as online */
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the powerpc-fixes tree
From: Mark Brown @ 2026-07-14 11:47 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, PowerPC; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
In commit
1034785975914 ("powerpc/85xx: Add fsl,ifc to common device ids")
Fixes tag
Fixes: 0bf51cc9e9e5 ("powerpc: dts: mpc85xx: remove simple-bus compatible from ifc node")
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
* Fixes tags need work in the powerpc-fixes tree
From: Mark Brown @ 2026-07-14 11:46 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, PowerPC; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
In commit
19dbc55d400b8 ("powerpc/vtime: Initialize starttime at boot for native accounting")
Fixes tag
Fixes: cf9efce0ce31 ("powerpc: Account time using timebase rather than PURR")
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
* linux-next: Tree for Jul 13
From: Mark Brown @ 2026-07-14 10:56 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]
Hi all,
Changes since 20260710:
The fsl tree lost it's build failure.
The driver-core tree acquired a conflict with the origin tree.
The char-misc tree acquired a conflict with the origin tree.
The sound-asoc tree acquired a build failure which I fixed.
The tty tree acquired a build failure, I used the version from
next-20260710 instead.
The scsi-mkp tree acquired a conflict with the scsi-fixes tree.
The scsi-mkp tree acquired a conflict with the origin tree.
The scsi-mkp tree acquired a build failure in the final build so I
merged the version from next-20260710 instead.
The usb tree also acquired a build failure in the final build,
potentially due to a change in another tree, which I ignored for today.
Non-merge commits (relative to Linus' tree): 5209
5201 files changed, 210814 insertions(+), 86997 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 427 trees (counting Linus' and 132 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: linux-next: build failure after merge of the tty tree
From: Mark Brown @ 2026-07-14 10:26 UTC (permalink / raw)
To: Greg KH; +Cc: Praveen Talari, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <2026071417-fritter-mahogany-bb97@gregkh>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Tue, Jul 14, 2026 at 08:45:54AM +0200, Greg KH wrote:
> On Tue, Jul 14, 2026 at 11:36:44AM +0530, Praveen Talari wrote:
> > I don't see these errors in my local build. Is there any specific way to
> > build to see these errors?
> Nope, I can't duplicate this either on my side just by building this
> branch. Is this coming from a change somewhere else that modifies
> PM_RUNTIME_ACQUIRE_IF_ENABLED()?
It's something clang reports.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the tty tree
From: Greg KH @ 2026-07-14 6:45 UTC (permalink / raw)
To: Praveen Talari
Cc: Mark Brown, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <12e1f767-d126-4f36-ab95-caf3252a5728@oss.qualcomm.com>
On Tue, Jul 14, 2026 at 11:36:44AM +0530, Praveen Talari wrote:
> Hi Mark,
>
> On 13-07-2026 20:12, Mark Brown wrote:
> > Hi all,
> >
> > After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1925:4: error:
> > cannot jump from this goto statement to its label
> > 1925 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1916:3: error:
> > cannot jump from this goto statement to its label
> > 1916 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1911:3: error:
> > cannot jump from this goto statement to its label
> > 1911 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1887:3: error:
> > cannot jump from this goto statement to its label
> > 1887 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1881:3: error:
> > cannot jump from this goto statement to its label
> > 1881 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1872:4: error:
> > cannot jump from this goto statement to its label
> > 1872 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1864:4: error:
> > cannot jump from this goto statement to its label
> > 1864 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1848:3: error:
> > cannot jump from this goto statement to its label
> > 1848 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > 8 errors generated.
>
> I don't see these errors in my local build. Is there any specific way to
> build to see these errors?
Nope, I can't duplicate this either on my side just by building this
branch. Is this coming from a change somewhere else that modifies
PM_RUNTIME_ACQUIRE_IF_ENABLED()?
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: build failure after merge of the tty tree
From: Greg KH @ 2026-07-14 6:34 UTC (permalink / raw)
To: Praveen Talari
Cc: Mark Brown, Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <12e1f767-d126-4f36-ab95-caf3252a5728@oss.qualcomm.com>
On Tue, Jul 14, 2026 at 11:36:44AM +0530, Praveen Talari wrote:
> Hi Mark,
>
> On 13-07-2026 20:12, Mark Brown wrote:
> > Hi all,
> >
> > After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1925:4: error:
> > cannot jump from this goto statement to its label
> > 1925 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1916:3: error:
> > cannot jump from this goto statement to its label
> > 1916 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1911:3: error:
> > cannot jump from this goto statement to its label
> > 1911 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1887:3: error:
> > cannot jump from this goto statement to its label
> > 1887 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1881:3: error:
> > cannot jump from this goto statement to its label
> > 1881 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1872:4: error:
> > cannot jump from this goto statement to its label
> > 1872 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1864:4: error:
> > cannot jump from this goto statement to its label
> > 1864 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1848:3: error:
> > cannot jump from this goto statement to its label
> > 1848 | goto error;
> > | ^
> > /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> > jump bypasses initialization of variable with __attribute__((cleanup))
> > 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> > | ^
> > 8 errors generated.
>
> I don't see these errors in my local build. Is there any specific way to
> build to see these errors?
Have you tried 'allmodconfig'? I'll go do that now too...
thanks,
greg k-h
^ permalink raw reply
* Re: linux-next: build failure after merge of the tty tree
From: Praveen Talari @ 2026-07-14 6:06 UTC (permalink / raw)
To: Mark Brown, Greg KH; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <alT5UdRqcfFmadZT@sirena.org.uk>
Hi Mark,
On 13-07-2026 20:12, Mark Brown wrote:
> Hi all,
>
> After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1925:4: error:
> cannot jump from this goto statement to its label
> 1925 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1916:3: error:
> cannot jump from this goto statement to its label
> 1916 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1911:3: error:
> cannot jump from this goto statement to its label
> 1911 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1887:3: error:
> cannot jump from this goto statement to its label
> 1887 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1881:3: error:
> cannot jump from this goto statement to its label
> 1881 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1872:4: error:
> cannot jump from this goto statement to its label
> 1872 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1864:4: error:
> cannot jump from this goto statement to its label
> 1864 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1848:3: error:
> cannot jump from this goto statement to its label
> 1848 | goto error;
> | ^
> /tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
> jump bypasses initialization of variable with __attribute__((cleanup))
> 1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
> | ^
> 8 errors generated.
I don't see these errors in my local build. Is there any specific way to
build to see these errors?
Thanks,
Praveen Talari
>
> Caused by commit
>
> 3d71f8d7eeb37 (serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown)
>
> I have used the tree from next-20260710 instead.
^ permalink raw reply
* [STATUS] next/master - 49362394dad7df66c274c867a271394c10ca2bb8
From: KernelCI bot @ 2026-07-14 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: linux-next
Hello,
Status summary for next/master
Dashboard:
https://d.kernelci.org/c/next/master/49362394dad7df66c274c867a271394c10ca2bb8/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 49362394dad7df66c274c867a271394c10ca2bb8
origin: maestro
test start time: 2026-07-13 18:04:34.745000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 109 ✅ 1 ❌ 0 ⚠️
Tests: 29725 ✅ 5410 ❌ 6310 ⚠️
### POSSIBLE REGRESSIONS
Hardware: qcs6490-rb3gen2
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a553b4a18a4add1353b3469
history: > ✅ > ❌ > ❌ > ❌
Hardware: bcm2711-rpi-4-b
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a556a0d18a4add1353d0133
history: > ✅ > ❌
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a5550e618a4add1353c5af8
history: > ✅ > ❌
Hardware: sun50i-a64-pine64-plus
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.kvm.shardfile-kvm
last run: https://d.kernelci.org/test/maestro:6a55459918a4add1353c0c88
history: > ✅ > ❌
Hardware: mt8183-kukui-jacuzzi-juniper-sku16
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dma-controller0_14001000
last run: https://d.kernelci.org/test/maestro:6a553a6818a4add1353b2d0d
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_dsi_14014000
last run: https://d.kernelci.org/test/maestro:6a553a6818a4add1353b2d09
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58
last run: https://d.kernelci.org/test/maestro:6a553a6818a4add1353b2d01
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_i2c_11008000_anx7625_58_aux-bus_panel
last run: https://d.kernelci.org/test/maestro:6a553a6818a4add1353b2d00
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14008000
last run: https://d.kernelci.org/test/maestro:6a553a6718a4add1353b2ce4
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_14009000
last run: https://d.kernelci.org/test/maestro:6a553a6718a4add1353b2ce3
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_ovl_1400a000
last run: https://d.kernelci.org/test/maestro:6a553a6718a4add1353b2ce2
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400b000
last run: https://d.kernelci.org/test/maestro:6a553a6718a4add1353b2cd7
history: > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_soc_rdma_1400c000
last run: https://d.kernelci.org/test/maestro:6a553a6818a4add1353b2d57
history: > ✅ > ❌
Hardware: sc7180-trogdor-kingoftown
> Config: defconfig+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_4080000
last run: https://d.kernelci.org/test/maestro:6a5536de18a4add1353afbd3
history: > ✅ > ❌
### FIXED REGRESSIONS
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_iommu_3da0000
last run: https://d.kernelci.org/test/maestro:6a55465518a4add1353c15ef
history: > ❌ > ✅ > ✅ > ✅
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.device_error_logs
last run: https://d.kernelci.org/test/maestro:6a55370e18a4add1353b0ad5
history: > ❌ > ✅ > ✅
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a5546d218a4add1353c1791
history: > ❌ > ✅ > ✅
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a55464c18a4add1353c11e7
history: > ❌ > ✅ > ✅
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a55464c18a4add1353c11f5
history: > ❌ > ✅ > ✅
### UNSTABLE TESTS
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a5536e018a4add1353afec9
history: > ❌ > ✅ > ❌ > ❌
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_pcm-test
last run: https://d.kernelci.org/test/maestro:6a55464c18a4add1353c0f8d
history: > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_sound-wm8960
last run: https://d.kernelci.org/test/maestro:6a5549c818a4add1353c4b81
history: > ✅ > ❌ > ✅
This branch has 1 pre-existing build issues. See details in the dashboard.
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* Re: linux-next: build failure in final build
From: Tyrel Datwyler @ 2026-07-13 18:46 UTC (permalink / raw)
To: Mark Brown, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <alUWw0b334Y1AiRa@sirena.org.uk>
On 7/13/26 9:48 AM, Mark Brown wrote:
> Hi all,
>
> After merging the kthread tree, today's linux-next build
> (powerpc pseries_le_defconfig) failed like this:
>
> ERROR: modpost: "nvme_fc_rescan_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
> ERROR: modpost: "nvme_fc_unregister_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
> ERROR: modpost: "nvme_fc_unregister_localport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
> ERROR: modpost: "nvme_fc_register_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
> ERROR: modpost: "nvme_fc_register_localport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
>
> Caused by commit
>
> ddbcf78e8d230 (scsi: ibmvfc: Process NVMe/FC rports in work thread)
>
> I have used the version from next-20260710 instead (equivalent to
> dropping the tree since everything seems to be new today).
This is from the NVMf ibmvfc patch series. I've asked Martin to drop it from
scsi-staging as I already had a respin in process to send out, plus I clearly
forgot to gate the NVMf functionality on NVMf support being configured.
-Tyrel
^ permalink raw reply
* -next status as at v7.2-rc3
From: Mark Brown @ 2026-07-13 18:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 919 bytes --]
Hi Linus,
Things are starting to pick up a bit with a bunch of fun new breaks
and fun conflicts today but still relatively normal apart from the fact
that we're seeing an unusual number of breaks in the final build.
Trees being held at old versions:
scsi-mkp next-20260710 (powerpc driver badly broken)
tty next-20260710 (goto interactions)
plus a USB build break in the final build that I didn't investigate
properly yet and may be due to some other tree.
No trees have signoff problems (arm-soc will tomorrow due to a rebase
unless they fix it overnight).
Non-merge commits relative to Linus' tree: 5209
5201 files changed, 210814 insertions(+), 86997 deletions(-)
Top trees adding commits to -next:
1081 drm
340 mm-unstable
312 qcom
184 net-next
183 tip
159 sound-asoc
133 iio
124 staging
120 nfsd
117 vfs-brauner
Thanks,
Mark
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure in the final build
From: Mark Brown @ 2026-07-13 17:48 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 4478 bytes --]
Hi all,
In the final builds, today's linux-next build (arm64 allyesconfig)
failed like this:
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:105:5: error: no previous
prototype for 'write_ulpi' [-Werror=missing-prototypes]
105 | int write_ulpi(u8 addr, u8 data)
| ^~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:118:6: error: no previous
prototype for 'fsl_otg_chrg_vbus' [-Werror=missing-prototypes]
118 | void fsl_otg_chrg_vbus(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:136:6: error: no previous
prototype for 'fsl_otg_dischrg_vbus' [-Werror=missing-prototypes]
136 | void fsl_otg_dischrg_vbus(int on)
| ^~~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:154:6: error: no previous
prototype for 'fsl_otg_drv_vbus' [-Werror=missing-prototypes]
154 | void fsl_otg_drv_vbus(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:172:6: error: no previous
prototype for 'fsl_otg_loc_conn' [-Werror=missing-prototypes]
172 | void fsl_otg_loc_conn(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:191:6: error: no previous
prototype for 'fsl_otg_loc_sof' [-Werror=missing-prototypes]
191 | void fsl_otg_loc_sof(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:206:6: error: no previous
prototype for 'fsl_otg_start_pulse' [-Werror=missing-prototypes]
206 | void fsl_otg_start_pulse(struct otg_fsm *fsm)
| ^~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:222:6: error: no previous
prototype for 'b_data_pulse_end' [-Werror=missing-prototypes]
222 | void b_data_pulse_end(unsigned long foo)
| ^~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:241:6: error: no previous
prototype for 'b_vbus_pulse_end' [-Werror=missing-prototypes]
241 | void b_vbus_pulse_end(unsigned long foo)
| ^~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:254:6: error: no previous
prototype for 'b_srp_end' [-Werror=missing-prototypes]
254 | void b_srp_end(unsigned long foo)
| ^~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:269:6: error: no previous
prototype for 'a_wait_enum' [-Werror=missing-prototypes]
269 | void a_wait_enum(unsigned long foo)
| ^~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:279:6: error: no previous
prototype for 'set_tmout' [-Werror=missing-prototypes]
279 | void set_tmout(unsigned long indicator)
| ^~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:285:5: error: no previous
prototype for 'fsl_otg_init_timers' [-Werror=missing-prototypes]
285 | int fsl_otg_init_timers(struct otg_fsm *fsm)
| ^~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:342:6: error: no previous
prototype for 'fsl_otg_uninit_timers' [-Werror=missing-prototypes]
342 | void fsl_otg_uninit_timers(void)
| ^~~~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:446:6: error: no previous
prototype for 'otg_reset_controller' [-Werror=missing-prototypes]
446 | void otg_reset_controller(void)
| ^~~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:458:5: error: no previous
prototype for 'fsl_otg_start_host' [-Werror=missing-prototypes]
458 | int fsl_otg_start_host(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:525:5: error: no previous
prototype for 'fsl_otg_start_gadget' [-Werror=missing-prototypes]
525 | int fsl_otg_start_gadget(struct otg_fsm *fsm, int on)
| ^~~~~~~~~~~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:707:13: error: no previous
prototype for 'fsl_otg_isr' [-Werror=missing-prototypes]
707 | irqreturn_t fsl_otg_isr(int irq, void *dev_id)
| ^~~~~~~~~~~
/tmp/next/build/drivers/usb/phy/phy-fsl-usb.c:833:5: error: no previous
prototype for 'usb_otg_start' [-Werror=missing-prototypes]
833 | int usb_otg_start(struct platform_device *pdev)
| ^~~~~~~~~~~~~
cc1: all warnings being treated as errors make[6]:
It looks like this is a change in dependencies which has allowed this to
be built from today, I didn't isolate exactly what - it looks like the
issue is missing statics on all these function definitions, making them
global. I have ignored this for today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Missing signoff in the arm-soc tree
From: Mark Brown @ 2026-07-13 17:38 UTC (permalink / raw)
To: Arnd Bergmann, soc; +Cc: linux-kernel, linux-next
In-Reply-To: <alUh--gXbJNcbmuV@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
On Mon, Jul 13, 2026 at 06:35:55PM +0100, Mark Brown wrote:
> Commits
>
> 923588dd861ba ("ARM: mark mv78xx0 support as deprecated")
> are missing a Signed-off-by from their committers
Alexandre, you did a rebase which makes you the committer of all the
commits you rebased - you need to add a signoff (git rebase --signoff
might help).
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Missing signoff in the arm-soc tree
From: Mark Brown @ 2026-07-13 17:35 UTC (permalink / raw)
To: Arnd Bergmann, soc; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]
Commits
923588dd861ba ("ARM: mark mv78xx0 support as deprecated")
3a09d8c6b3688 ("ARM: mark axxia platform as deprecated")
fa431f73cc18a ("ARM: mark Cortex-M3/M4/M7 based boards as deprecated")
fd0148ccd1d8f ("ARM: mark footbridge as deprecated")
faae50ff70799 ("ARM: mark RiscPC as deprecated")
25592ecf80a17 ("ARM: mark mach-sa1100 as deprecated")
7a9d2a5cb68f4 ("ARM: orion5x: mark all board files as deprecated")
a28d72f93f209 ("ARM: PXA: mark remaining board files as deprecated")
bb09fdba36e19 ("ARM: mark ARCH_DOVE as deprecated")
337de957c1166 ("ARM: mark IWMMXT as deprecated")
09b6757da5976 ("ARM: update FPE_NWFPE help text")
8b0e28c2792ec ("ARM: s3c64xx: extend deprecation schedule")
ef53a06103114 ("ARM: update DEPRECATED_PARAM_STRUCT removal timeline")
ed1dab5e08938 ("ARM: mark CPU_ENDIAN_BE8 as deprecated")
4d9226b820c16 ("ARM: turn CONFIG_ATAGS off by default")
e61f27ee54497 ("ARM: deprecate support for ARM1136r0")
07c06fe4622bb ("ARM: rework ARM11 CPU selection logic")
a82f541ab97f0 ("ARM: limit OABI support to StrongARM CPUs")
4122589d5488c ("ARM: use CONFIG_AEABI by default everywhere")
are missing a Signed-off-by from their committers
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure in final build
From: Mark Brown @ 2026-07-13 16:48 UTC (permalink / raw)
To: Tyrel Datwyler, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
Hi all,
After merging the kthread tree, today's linux-next build
(powerpc pseries_le_defconfig) failed like this:
ERROR: modpost: "nvme_fc_rescan_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
ERROR: modpost: "nvme_fc_unregister_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
ERROR: modpost: "nvme_fc_unregister_localport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
ERROR: modpost: "nvme_fc_register_remoteport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
ERROR: modpost: "nvme_fc_register_localport" [drivers/scsi/ibmvscsi/ibmvfc.ko] undefined!
Caused by commit
ddbcf78e8d230 (scsi: ibmvfc: Process NVMe/FC rports in work thread)
I have used the version from next-20260710 instead (equivalent to
dropping the tree since everything seems to be new today).
[-- 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 origin tree
From: Uwe Kleine-König @ 2026-07-13 15:15 UTC (permalink / raw)
To: Mark Brown
Cc: Greg KH, Danilo Krummrich, Rafael J. Wysocki, Bartosz Golaszewski,
Greg Kroah-Hartman, Linux Kernel Mailing List,
Linux Next Mailing List
In-Reply-To: <alTxJTV0crJ8DNar@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
Hello,
On Mon, Jul 13, 2026 at 03:07:33PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the driver-core tree got a conflict in:
>
> include/linux/platform_device.h
>
> between commit:
>
> 00cd8fc630e06 ("driver core: platform: Include header for struct platform_device_id")
>
> from the origin tree and commits:
>
> 714cfe9e143fe ("driver core: platform: provide platform_device_set_of_node()")
> 8877c06885ce4 ("driver core: platform: provide platform_device_set_fwnode()")
>
> 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 include/linux/platform_device.h
> index 8c566f09d04ef,94b8d2b46e913..0000000000000
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@@ -19,6 -18,9 +19,8 @@@
> struct irq_affinity;
> struct mfd_cell;
> struct property_entry;
> -struct platform_device_id;
> + struct device_node;
> + struct fwnode_handle;
>
> struct platform_device {
> const char *name;
That looks right, thank you
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the scsi-mkp tree with the origin tree
From: Mark Brown @ 2026-07-13 15:13 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List,
Uwe Kleine-König
[-- Attachment #1: Type: text/plain, Size: 1478 bytes --]
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
include/linux/mod_devicetable.h
between commit:
ad428f5811bd7 ("mod_devicetable.h: Split into per subsystem headers")
from the origin tree and commit:
e73ba3d6ed03b ("scsi: zorro: Simplify storing pointers in device id struct")
from the scsi-mkp 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 include/linux/mod_devicetable.h
index a397213bedace,2673a1bd82c45..0000000000000
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
diff --git a/include/linux/device-id/zorro.h b/include/linux/device-id/zorro.h
index 5fdac81689839..26827b9b90b67 100644
--- a/include/linux/device-id/zorro.h
+++ b/include/linux/device-id/zorro.h
@@ -13,7 +13,11 @@ typedef unsigned long kernel_ulong_t;
struct zorro_device_id {
__u32 id; /* Device ID or ZORRO_WILDCARD */
- kernel_ulong_t driver_data; /* Data private to the driver */
+ union {
+ /* Data private to the driver */
+ kernel_ulong_t driver_data;
+ const void *driver_data_ptr;
+ };
};
#endif /* ifndef LINUX_DEVICE_ID_ZORRO_H */
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the scsi-mkp tree with the scsi-fixes tree
From: Mark Brown @ 2026-07-13 15:13 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Brian Bunker, Catalin Iacob, Krishna Kant,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1823 bytes --]
Hi all,
Today's linux-next merge of the scsi-mkp tree got a conflict in:
include/scsi/scsi_device.h
between commit:
e81f1079f9000 ("scsi: core: Remove export for scsi_device_from_queue()")
from the scsi-fixes tree and commit:
ddd0eb9bcebeb ("scsi: core: Add scsi_update_inquiry_data() for updating INQUIRY data")
from the scsi-mkp 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 include/scsi/scsi_device.h
index 8694eeadd753e,7c8c06e60a911..0000000000000
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@@ -408,6 -408,20 +408,19 @@@ void scsi_attach_vpd(struct scsi_devic
void scsi_cdl_check(struct scsi_device *sdev);
int scsi_cdl_enable(struct scsi_device *sdev, bool enable);
+ /**
+ * enum scsi_inq_update_result - Return values for scsi_update_inquiry_data()
+ * @SCSI_INQ_UNCHANGED: INQUIRY data updated, no reprobe needed
+ * @SCSI_INQ_REPROBE_NEEDED: INQUIRY data updated, standard INQUIRY data changed
+ */
+ enum scsi_inq_update_result {
+ SCSI_INQ_UNCHANGED = 0,
+ SCSI_INQ_REPROBE_NEEDED = 1,
+ };
+
+ int scsi_update_inquiry_data(struct scsi_device *sdev,
+ unsigned char *inq_result, size_t inq_len);
+
-extern struct scsi_device *scsi_device_from_queue(struct request_queue *q);
extern int __must_check scsi_device_get(struct scsi_device *);
extern void scsi_device_put(struct scsi_device *);
extern struct scsi_device *scsi_device_lookup(struct Scsi_Host *,
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the tty tree
From: Mark Brown @ 2026-07-13 14:42 UTC (permalink / raw)
To: Praveen Talari, Greg KH
Cc: Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3885 bytes --]
Hi all,
After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1925:4: error:
cannot jump from this goto statement to its label
1925 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1916:3: error:
cannot jump from this goto statement to its label
1916 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1911:3: error:
cannot jump from this goto statement to its label
1911 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1887:3: error:
cannot jump from this goto statement to its label
1887 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1881:3: error:
cannot jump from this goto statement to its label
1881 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1872:4: error:
cannot jump from this goto statement to its label
1872 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1864:4: error:
cannot jump from this goto statement to its label
1864 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1848:3: error:
cannot jump from this goto statement to its label
1848 | goto error;
| ^
/tmp/next/build/drivers/tty/serial/qcom_geni_serial.c:1931:44: note:
jump bypasses initialization of variable with __attribute__((cleanup))
1931 | PM_RUNTIME_ACQUIRE_IF_ENABLED(uport->dev, pm);
| ^
8 errors generated.
Caused by commit
3d71f8d7eeb37 (serial: qcom-geni: remove .pm callback, use runtime PM in startup/shutdown)
I have used the tree from next-20260710 instead.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* linux-next: manual merge of the char-misc tree with the origin tree
From: Mark Brown @ 2026-07-13 14:08 UTC (permalink / raw)
To: Greg KH, Arnd Bergmann
Cc: Alice Ryhl, Greg Kroah-Hartman, Miguel Ojeda, Keshav Verma,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 16109 bytes --]
Hi all,
Today's linux-next merge of the char-misc tree got conflicts in:
drivers/android/binder/node.rs
drivers/android/binder/process.rs
between commits:
6849cabfd30fb ("rust_binder: reject context manager self-transaction")
bc4a982889787 ("rust_binder: clear freeze listener on node removal")
from the origin tree and commits:
b9d17aa74ddd7 ("rust_binder: avoid allocating under node_refs for freeze listeners")
521eae8326a18 ("rust_binder: avoid dropping NodeRef in update_ref() under lock")
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.
I am really not at all confident in this merge.
diff --combined drivers/android/binder/node.rs
index c10148e9069f3,fb57c0b20888f..0000000000000
--- a/drivers/android/binder/node.rs
+++ b/drivers/android/binder/node.rs
@@@ -9,6 -9,7 +9,7 @@@ use kernel::
seq_print,
sync::lock::{spinlock::SpinLockBackend, Guard},
sync::{Arc, LockedBy, SpinLock},
+ uapi,
};
use crate::{
@@@ -21,6 -22,7 +22,7 @@@
};
use core::mem;
+ use core::ptr;
mod wrapper;
pub(crate) use self::wrapper::CritIncrWrapper;
@@@ -321,7 -323,7 +323,7 @@@ impl Node
/// An id that is unique across all binder nodes on the system. Used as the key in the
/// `by_node` map.
pub(crate) fn global_id(&self) -> usize {
- self as *const Node as usize
+ ptr::from_ref(self).addr()
}
pub(crate) fn get_id(&self) -> (u64, u64) {
@@@ -464,7 -466,7 +466,7 @@@
owner_inner: &mut ProcessInner,
) -> Option<DLArc<dyn DeliverToRead>> {
match self.incr_refcount_allow_zero2one(strong, owner_inner) {
- Ok(Some(node)) => Some(node as _),
+ Ok(Some(node)) => Some(node as DLArc<dyn DeliverToRead>),
Ok(None) => None,
Err(CouldNotDeliverCriticalIncrement) => {
assert!(strong);
@@@ -489,8 -491,8 +491,8 @@@
guard: &Guard<'_, ProcessInner, SpinLockBackend>,
) {
let inner = self.inner.access(guard);
- out.strong_count = inner.strong.count as _;
- out.weak_count = inner.weak.count as _;
+ out.strong_count = inner.strong.count as u32;
+ out.weak_count = inner.weak.count as u32;
}
pub(crate) fn populate_debug_info(
@@@ -498,8 -500,8 +500,8 @@@
out: &mut BinderNodeDebugInfo,
guard: &Guard<'_, ProcessInner, SpinLockBackend>,
) {
- out.ptr = self.ptr as _;
- out.cookie = self.cookie as _;
+ out.ptr = self.ptr as uapi::binder_uintptr_t;
+ out.cookie = self.cookie as uapi::binder_uintptr_t;
let inner = self.inner.access(guard);
if inner.strong.has_count {
out.has_strong_ref = 1;
@@@ -657,44 -659,41 +659,43 @@@
pub(crate) fn add_freeze_listener(
&self,
process: &Arc<Process>,
- flags: kernel::alloc::Flags,
- ) -> Result {
- let mut vec_alloc = KVVec::<Arc<Process>>::new();
- loop {
- let mut guard = self.owner.inner.lock();
- // Do not check for `guard.dead`. The `dead` flag that matters here is the owner of the
- // listener, no the target.
- let inner = self.inner.access_mut(&mut guard);
- let len = inner.freeze_list.len();
- if len >= inner.freeze_list.capacity() {
- if len >= vec_alloc.capacity() {
- drop(guard);
- vec_alloc = KVVec::with_capacity((1 + len).next_power_of_two(), flags)?;
- continue;
- }
- mem::swap(&mut inner.freeze_list, &mut vec_alloc);
- for elem in vec_alloc.drain_all() {
- inner.freeze_list.push_within_capacity(elem)?;
- }
+ // If the vector needs to be resized, it's done via this argument.
+ vec_alloc: &mut KVVec<Arc<Process>>,
+ ) -> Result<Result<(), usize>> {
+ let mut guard = self.owner.inner.lock();
+ // Do not check for `guard.dead`. The `dead` flag that matters here is the owner of the
+ // listener, not the target.
+ let inner = self.inner.access_mut(&mut guard);
+ let len = inner.freeze_list.len();
+ if len == inner.freeze_list.capacity() {
+ if len >= vec_alloc.capacity() {
+ // Request the caller to reallocate.
+ return Ok(Err((1 + len).next_power_of_two()));
+ }
+ mem::swap(&mut inner.freeze_list, vec_alloc);
+ for elem in vec_alloc.drain_all() {
+ inner.freeze_list.push_within_capacity(elem)?;
}
- inner.freeze_list.push_within_capacity(process.clone())?;
- return Ok(());
}
+ inner.freeze_list.push_within_capacity(process.clone())?;
+ Ok(Ok(()))
}
- pub(crate) fn remove_freeze_listener(&self, p: &Arc<Process>) -> KVVec<Arc<Process>> {
+ pub(crate) fn remove_freeze_listener(&self, p: &Process) -> KVVec<Arc<Process>> {
let mut guard = self.owner.inner.lock();
let inner = self.inner.access_mut(&mut guard);
let len = inner.freeze_list.len();
- inner.freeze_list.retain(|proc| !Arc::ptr_eq(proc, p));
+ inner
+ .freeze_list
+ .retain(|proc| !core::ptr::eq::<Process>(&**proc, p));
if len == inner.freeze_list.len() {
pr_warn!(
"Could not remove freeze listener for {}\n",
p.pid_in_current_ns()
);
}
+ // If the vector is empty it needs to be freed. However, we can't free it here because that
+ // might sleep, so return it to the caller.
if inner.freeze_list.is_empty() {
return mem::take(&mut inner.freeze_list);
}
diff --combined drivers/android/binder/process.rs
index cdd1a90797266,1abeb83684e41..0000000000000
--- a/drivers/android/binder/process.rs
+++ b/drivers/android/binder/process.rs
@@@ -30,9 -30,9 +30,9 @@@ use kernel::
sync::{
aref::ARef,
lock::{spinlock::SpinLockBackend, Guard},
- Arc, ArcBorrow, CondVar, CondVarTimeoutResult, Mutex, SpinLock, UniqueArc,
+ Arc, ArcBorrow, CondVar, CondVarTimeoutResult, SpinLock, UniqueArc,
},
- task::Task,
+ task::{Pid, Task},
uaccess::{UserSlice, UserSliceReader},
uapi,
workqueue::{self, Work},
@@@ -259,7 -259,7 +259,7 @@@ impl ProcessInner
let push = match wrapper {
None => node
.incr_refcount_allow_zero2one(strong, self)?
- .map(|node| node as _),
+ .map(|node| node as DLArc<dyn DeliverToRead>),
Some(wrapper) => node.incr_refcount_allow_zero2one_with_wrapper(strong, wrapper, self),
};
if let Some(node) = push {
@@@ -455,7 -455,7 +455,7 @@@ pub(crate) struct Process
// Node references are in a different lock to avoid recursive acquisition when
// incrementing/decrementing a node in another process.
#[pin]
- node_refs: Mutex<ProcessNodeRefs>,
+ node_refs: SpinLock<ProcessNodeRefs>,
// Work node for deferred work item.
#[pin]
@@@ -510,7 -510,7 +510,7 @@@ impl Process
cred,
inner <- kernel::new_spinlock!(ProcessInner::new(), "Process::inner"),
pages <- ShrinkablePageRange::new(&super::BINDER_SHRINKER),
- node_refs <- kernel::new_mutex!(ProcessNodeRefs::new(), "Process::node_refs"),
+ node_refs <- kernel::new_spinlock!(ProcessNodeRefs::new(), "Process::node_refs"),
freeze_wait <- kernel::new_condvar!("Process::freeze_wait"),
task: current.group_leader().into(),
defer_work <- kernel::new_work!("Process::defer_work"),
@@@ -741,7 -741,7 +741,7 @@@
} else {
(0, 0, 0)
};
- let node_ref = self.get_node(ptr, cookie, flags as _, true, thread)?;
+ let node_ref = self.get_node(ptr, cookie, flags, true, thread)?;
let node = node_ref.node.clone();
self.ctx.set_manager_node(node_ref)?;
self.inner.lock().is_manager = true;
@@@ -861,14 -861,17 +861,17 @@@
let handle = unused_id.as_u32();
// Do a lookup again as node may have been inserted before the lock was reacquired.
- if let Some(handle_ref) = refs.by_node.get(&node_ref.node.global_id()) {
- let handle = *handle_ref;
- let info = refs.by_handle.get_mut(&handle).unwrap();
- info.node_ref().absorb(node_ref);
- return Ok(handle);
- }
+ let by_node_slot = match refs.by_node.entry(node_ref.node.global_id()) {
+ rbtree::Entry::Vacant(by_node_slot) => by_node_slot,
+ rbtree::Entry::Occupied(handle_ref) => {
+ // The node was inserted by another thread while we didn't hold the lock.
+ let handle = handle_ref.get();
+ let info = refs.by_handle.get_mut(handle).unwrap();
+ info.node_ref().absorb(node_ref);
+ return Ok(*handle);
+ }
+ };
- let gid = node_ref.node.global_id();
let (info_proc, info_node) = {
let info_init = NodeRefInfo::new(node_ref, handle, self.into());
match info.pin_init_with(info_init) {
@@@ -884,6 -887,9 +887,9 @@@
// first thing in `deferred_release`, process cleanup will not miss the items inserted into
// `refs` below.
if self.inner.lock().is_dead {
+ // Explicitly drop the lock so that `info_proc` and `info_node` are dropped outside of
+ // the lock.
+ drop(refs_lock);
return Err(ESRCH);
}
@@@ -891,7 -897,7 +897,7 @@@
// `info_node` into the right node's `refs` list.
unsafe { info_proc.node_ref2().node.insert_node_info(info_node) };
- refs.by_node.insert(reserve1.into_node(gid, handle));
+ by_node_slot.insert(handle, reserve1);
by_handle_slot.insert(info_proc, reserve2);
unused_id.acquire();
Ok(handle)
@@@ -900,11 -906,7 +906,11 @@@
pub(crate) fn get_transaction_node(&self, handle: u32) -> BinderResult<NodeRef> {
// When handle is zero, try to get the context manager.
if handle == 0 {
- Ok(self.ctx.get_manager_node(true)?)
+ let node_ref = self.ctx.get_manager_node(true)?;
+ if core::ptr::eq(self, &*node_ref.node.owner) {
+ return Err(EINVAL.into());
+ }
+ Ok(node_ref)
} else {
Ok(self.get_node_from_handle(handle, true)?)
}
@@@ -946,15 -948,17 +952,17 @@@
// To preserve original binder behaviour, we only fail requests where the manager tries to
// increment references on itself.
- let _to_free_freeze_listener;
- let _to_free_freeze_listener_cleanup;
+ let _to_free_by_handle;
+ let _to_free_by_node;
let mut refs = self.node_refs.lock();
if let Some(info) = refs.by_handle.get_mut(&handle) {
if info.node_ref().update(inc, strong) {
// Clean up death if there is one attached to this node reference.
- if let Some(death) = info.death().take() {
+ //
+ // We remove the entire `info` below, so no need to remove `death` from `info`.
+ if let Some(death) = info.death().as_ref() {
death.set_cleared(true);
- self.remove_from_delivered_deaths(&death);
+ self.remove_from_delivered_deaths(death);
}
// Remove reference from process tables, and from the node's `refs` list.
@@@ -963,16 -967,8 +971,8 @@@
unsafe { info.node_ref2().node.remove_node_info(info) };
let id = info.node_ref().node.global_id();
-
- if let Some(freeze) = *info.freeze() {
- if let Some(fl) = refs.freeze_listeners.remove(&freeze) {
- _to_free_freeze_listener_cleanup = fl.on_process_cleanup(&self);
- _to_free_freeze_listener = fl;
- }
- }
-
- refs.by_handle.remove(&handle);
- refs.by_node.remove(&id);
+ _to_free_by_handle = refs.by_handle.remove_node(&handle);
+ _to_free_by_node = refs.by_node.remove_node(&id);
refs.handle_is_present.release_id(handle as usize);
if let Some(shrink) = refs.handle_is_present.shrink_request() {
@@@ -1299,7 -1295,10 +1299,10 @@@
// Update state and determine if we need to queue a work item. We only need to do it when
// the node is not dead or if the user already completed the death notification.
- if death.set_cleared(false) {
+ let should_schedule = death.set_cleared(false);
+ drop(refs);
+
+ if should_schedule {
if let Some(death) = ListArc::try_from_arc_or_drop(death) {
let _ = thread.push_work_if_looper(death);
}
@@@ -1382,19 -1381,17 +1385,17 @@@
// SAFETY: We are removing the `NodeRefInfo` from the right node.
unsafe { info.node_ref2().node.remove_node_info(info) };
- // Remove all death notifications from the nodes (that belong to a different process).
- let death = if let Some(existing) = info.death().take() {
- existing
- } else {
- continue;
- };
- death.set_cleared(false);
+ // Clear death notifications from the nodes (that belong to a different process).
+ // No need to remove them from `info` as we clear info below.
+ if let Some(death) = info.death().as_ref() {
+ death.set_cleared(false);
+ }
}
// Clean up freeze listeners.
let freeze_listeners = take(&mut self.node_refs.lock().freeze_listeners);
for listener in freeze_listeners.values() {
- listener.on_process_exit(&self);
+ listener.on_process_cleanup(&self);
}
drop(freeze_listeners);
@@@ -1536,13 -1533,13 +1537,13 @@@ fn get_frozen_status(data: UserSlice) -
for ctx in crate::context::get_all_contexts()? {
ctx.for_each_proc(|proc| {
- if proc.task.pid() == info.pid as _ {
+ if proc.task.pid() == info.pid as Pid {
found = true;
let inner = proc.inner.lock();
let txns_pending = inner.txns_pending_locked();
- info.async_recv |= inner.async_recv as u32;
- info.sync_recv |= inner.sync_recv as u32;
- info.sync_recv |= (txns_pending as u32) << 1;
+ info.async_recv |= u32::from(inner.async_recv);
+ info.sync_recv |= u32::from(inner.sync_recv);
+ info.sync_recv |= u32::from(txns_pending) << 1;
}
});
}
[-- 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 origin tree
From: Mark Brown @ 2026-07-13 14:07 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,
Uwe Kleine-König
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
Hi all,
Today's linux-next merge of the driver-core tree got a conflict in:
include/linux/platform_device.h
between commit:
00cd8fc630e06 ("driver core: platform: Include header for struct platform_device_id")
from the origin tree and commits:
714cfe9e143fe ("driver core: platform: provide platform_device_set_of_node()")
8877c06885ce4 ("driver core: platform: provide platform_device_set_fwnode()")
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 include/linux/platform_device.h
index 8c566f09d04ef,94b8d2b46e913..0000000000000
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@@ -19,6 -18,9 +19,8 @@@
struct irq_affinity;
struct mfd_cell;
struct property_entry;
-struct platform_device_id;
+ struct device_node;
+ struct fwnode_handle;
struct platform_device {
const char *name;
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the drm-msm-fixes tree
From: Mark Brown @ 2026-07-13 14:07 UTC (permalink / raw)
To: Rob Clark, Sean Paul; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
In commit
6cd33b6f4155e ("drm/msm/dsi: round 6G byte clock rate to the PLL-achievable value")
Fixes tag
Fixes: 6b16f05aa39f ("drm/msm/dsi: Split clk rate setting and enable")
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
* Fixes tags need work in the crypto-current tree
From: Mark Brown @ 2026-07-13 14:07 UTC (permalink / raw)
To: Herbert Xu, Linux Crypto List; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 290 bytes --]
In commit
196b052cbc5bb ("rhashtable: clear stale iter->p on table restart")
Fixes tag
Fixes: 5d240a8936f6 ("rhashtable: improve rhashtable_walk stability when
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading but no trailing quotes
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Fixes tags need work in the rpmsg tree
From: Mark Brown @ 2026-07-13 13:31 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier; +Cc: linux-kernel, linux-next
[-- Attachment #1: Type: text/plain, Size: 336 bytes --]
In commit
3dbc90b9c22ea ("remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3")
Fixes tag
Fixes: 65991ea8a6d1 ("remoteproc: qcom_wcnss: Handle platforms with only single power domain")
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
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