* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-24 21:05 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <7250a5ad-ec2d-4852-af56-9c1c653d24c7@I-love.SAKURA.ne.jp>
On Sat, Jul 25, 2026 at 12:29:27AM -0500, Tetsuo Handa wrote:
> The problem is that a maintainer who has the permission to
> accept/reject patches tends to become defunctional when syzbot is
> involved. What actions can the Linux kernel community take in order
> to address this problem (instead of just ignoring developers who are
> trying to fix bugs)?
Fundamentally, not all bugs are worth fixing. And if you believe that
all bugs are worth fixing, you need to convince companies to **fund**
that work, and not leave it as unfunded mandate. If you give me some
minions who can be dedicated to help fix bugs, I'm certainly willing
to provide technical direction. But there's no such thing as a free
lunch --- and the business case is not as clear cut as you seem to be
assuming.
In essence, this is a cost allocation problem. When you ask for help
from other maintainers to fix something that you care about, if it's
not important to them or their company / management chain, you are
dumping costs from you to them. This can work if you can also help
them in turn in other areas. This happens all the time, actually, and
it's what makes Open Source work.
So I think the way we solve this problem is by finding ways to
allocate the costs to those companies or organizations that think it
is a good fit for their business, and to reduce the burden on those
whose company (or management chain) doesn't think the business case is
sufficiently compelling.
Other solutions might include finding some AI solution which can
filter the low-priority quality Syzbot reports from the high-quality
ones. If some companies or some departments may have different
priorities, perhaps they can use different filuters, so they can work
on those bugs that they think are important.
Perhaps AI's can do a better job at proposing some patches that
resolve the problem, or creating reliable reproducers that don't
require thousands of VM hours of testing.
One of the reasons why I am personally more supportive about Sashiko
than syzbot is because Sashiko is a technology which is reducing *my*
workload. It does transfer more work to the contributor, but if they
are trying to get code into the kernel and if their company think
there is a business case for that new feature, it seems right that we
require that pay the development costs of submitting high-quality
code.
Cheeres,
- Ted
^ permalink raw reply
* Re: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Matthew Brost @ 2026-07-24 19:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Mark Brown, Andrew Morton, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Usama Arif, linux-mm, dri-devel, linux-next
In-Reply-To: <20260724194808.GA1461047@ax162>
On Fri, Jul 24, 2026 at 12:48:08PM -0700, Nathan Chancellor wrote:
> On Fri, Jul 24, 2026 at 01:13:42AM +0100, Mark Brown wrote:
> > On Thu, Jul 23, 2026 at 04:11:48PM -0700, Matthew Brost wrote:
> > > On Thu, Jul 23, 2026 at 04:09:42PM -0700, Andrew Morton wrote:
> >
> > > > I'm fine the drm people changing things ;)
> >
> > > I'll jump make a DRM change so this is all worked out when it gets to
> > > Linus.
> >
> > So should I drop Nathan's fixup then?
>
> As you may or may not have seen yet, the drm commit has been reverted in
> the drm-misc-fixes branch, so my change should no longer apply.
Yes, I asked to drm-misc-fixes maintainer to revert the change to avoid
sending to Linus and will post a non-conflicting follow up drm shortly.
Matt
>
> --
> Cheers,
> Nathan
^ permalink raw reply
* Re: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Nathan Chancellor @ 2026-07-24 19:48 UTC (permalink / raw)
To: Mark Brown
Cc: Matthew Brost, Andrew Morton, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Usama Arif, linux-mm, dri-devel, linux-next
In-Reply-To: <93289e91-ef9f-4786-bf49-e93d91afc1ad@sirena.org.uk>
On Fri, Jul 24, 2026 at 01:13:42AM +0100, Mark Brown wrote:
> On Thu, Jul 23, 2026 at 04:11:48PM -0700, Matthew Brost wrote:
> > On Thu, Jul 23, 2026 at 04:09:42PM -0700, Andrew Morton wrote:
>
> > > I'm fine the drm people changing things ;)
>
> > I'll jump make a DRM change so this is all worked out when it gets to
> > Linus.
>
> So should I drop Nathan's fixup then?
As you may or may not have seen yet, the drm commit has been reverted in
the drm-misc-fixes branch, so my change should no longer apply.
--
Cheers,
Nathan
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Miguel Ojeda @ 2026-07-24 17:49 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Theodore Tso, Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh
In-Reply-To: <58689827-9211-4f26-9777-51c0b5e1eebb@I-love.SAKURA.ne.jp>
On Fri, Jul 24, 2026 at 4:35 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> Those who hate my attempts (i.e. sending patches to linux-next without
> being reviewed/acked by maintainers) are expecting that any patch is
> reviewed/acked by maintainers. But some maintainers are considering bugs
It is not "hate", it is just the linux-next rules:
"
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
"
That is why nobody is expecting random patches to appear there --
because every maintainer receives those rules when they add their tree
to linux-next.
And those rules make sense -- adding patches that are not ready or
unexpected can confuse others, break the build, add conflicts or,
worse of all, silently invalidate testing of normal patches going to
Linus.
Now, again, exceptions are definitely possible (e.g. I asked for one
to add Rust many months before it was finally merged), but one needs
to be quite careful and for something treewide like what you are
asking, it will always be tricky...
E.g. even if you always managed to perfectly place the changes behind
a `CONFIG_`, subsystems should probably still be warned, and Mark
would probably need to drop your side if there are conflicts to be
safe unless you coordinated the resolution beforehand with the
maintainers etc.
Cheers,
Miguel
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-24 15:29 UTC (permalink / raw)
To: Theodore Tso
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <amN5Gu2J5mILKs_j@mit.edu>
On 2026/07/24 23:51, Theodore Tso wrote:
>> In other words, the interest (by the upstream Linux kernel community) on
>> fixing kernel bugs which syzbot found are decreasing. This is a deadlock
>> situation, and just saying "Not my business." is not helpful.
>
> Perhaps if Syzbot could be improved so we can be more selective about
> which bugs are worth fixing, it might actually be better for the
> kernel's quality.
One non-critical bug in some module can prevent other critical bugs in
different modules from being discovered. We can't expect that syzbot can
find only critical bugs, without an effort to fix non-critical bugs.
>
> But if the goal is to get ourselves to zero bugs, or zero syzbot
> reported issues, that's not a goal I can get behind. It certainly
> isn't something my management chain isn't willing to support that
> goal, and it's NOT going to happen out of my own personal time.
https://www.youtube.com/watch?v=qrBVXxZDVQY or
https://events19.linuxfoundation.org/wp-content/uploads/2017/11/Syzbot-and-the-Tale-of-Thousand-Kernel-Bugs-Dmitry-Vyukov-Google.pdf
says that the goal is "Reduce bugs/release 100x: 20'000 -> 200".
I know that individual maintainer cannot afford looking into all patches
that involve syzbot. A maintainer has the permission to accept/reject
patches on an area he/she maintains. The problem is that a maintainer
who has the permission to accept/reject patches tends to become defunctional
when syzbot is involved. What actions can the Linux kernel community take
in order to address this problem (instead of just ignoring developers
who are trying to fix bugs)?
^ permalink raw reply
* hang during shutdown in next-20260722+ with MT7925
From: Bert Karwatzki @ 2026-07-24 15:14 UTC (permalink / raw)
To: Nicolas Cavallari
Cc: Bert Karwatzki, linux-kernel, linux-next, linux-wireless,
Felix Fietkau, ryder.lee, lorenzo, legale.legale, sean.wang,
shayne.chen
In-Reply-To: <20260708144615.24092-1-nicolas.cavallari@green-communications.fr>
Since next-20260722 my debian sid system hangs when shutting down or
rebooting (No error message when monitoring the shutdown process via
netconsole). I bisected the error to commit
13b7e6a96a00 ("wifi: mt76: Disable napi when removing device")
and reverting this commit in next-20260723 makes shutting down or
rebooting work normally again.
Wifi device:
09:00.0 Network controller [0280]: MEDIATEK Corp. MT7925 802.11be 160MHz 2x2 PCIe Wireless Network Adapter [Filogic 360] [14c3:7925]
Cpu:
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 26
model : 68
model name : AMD Ryzen 9 9950X 16-Core Processor
stepping : 0
microcode : 0xb404035
cpu MHz : 624.194
cache size : 1024 KB
physical id : 0
siblings : 32
core id : 0
cpu cores : 16
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local user_shstk avx_vnni avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid bus_lock_detect movdiri movdir64b overflow_recov succor smca fsrm avx512_vp2intersect flush_l1d amd_lbr_pmc_freeze
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso spectre_v2_user vmscape
bogomips : 8599.52
TLB size : 192 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
Other pci hardware:
$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Root Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge GPP Bridge
00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Dummy Host Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Internal GPP Bridge to Bus [C:A]
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 71)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 0
00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 1
00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 2
00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 3
00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 4
00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 5
00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 6
00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge Data Fabric; Function 7
01:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Upstream Port of PCI Express Switch (rev 25)
02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] Navi 10 XL Downstream Port of PCI Express Switch (rev 25)
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 44 [Radeon RX 9060 XT] (rev c0)
03:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Navi 48 HDMI/DP Audio Controller
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD 9100 PRO [PM9E1]
05:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Upstream Port (rev 01)
06:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:06.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:07.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:08.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:0c.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
06:0d.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset PCIe Switch Downstream Port (rev 01)
08:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 06)
09:00.0 Network controller: MEDIATEK Corp. MT7925 802.11be 160MHz 2x2 PCIe Wireless Network Adapter [Filogic 360]
0b:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 800 Series Chipset USB 3.x XHCI Controller (rev 01)
0c:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] 600 Series Chipset SATA Controller (rev 01)
0d:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge PCIe Dummy Function (rev c1)
0d:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 19h PSP/CCP
0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 3.1 xHCI
0d:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 3.1 xHCI
0e:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Raphael/Granite Ridge USB 2.0 xHCI
Bert Karwatzki
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in next-20260722
From: Bert Karwatzki @ 2026-07-24 15:08 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: <4d7c2dd588cd77d1d112da473f2a262d22051d57.camel@web.de>
Am Freitag, dem 24.07.2026 um 00:51 +0200 schrieb Bert Karwatzki:
> Am Donnerstag, dem 23.07.2026 um 18:17 +0200 schrieb Bert Karwatzki:
> > Am Donnerstag, dem 23.07.2026 um 15:23 +0200 schrieb Bert Karwatzki:
> > > Am Donnerstag, dem 23.07.2026 um 15:10 +0200 schrieb Bert Karwatzki:
> > > > I was able to gather the panic error message from a failed shutdown via netconsole,
> > > > this time the kernel used was v7.2-rc3:
> > > > #
> > > > Bert Karwatzki
> > >
> > > Unfortunatetly I can now reproduce these kernel panics in v7.1:
> > >
> > >
> > > So now I'm going to use memtest86+ on my machine and then look at the changes I had in
> > > my userspace as the first error occured on 22.7.2026. Let's hope this does not escalate ...
> > >
> > > Bert Karwatzki
> >
> >
> > But I found out an exciting thing:
> > I can only reproduce the crashes in v7.2-rc4 when watching the reboot via netconsole,
> > without netconsole no crash occurs!(This also explains why I had not seen this crashes before ...)
> >
> Actually this is not cause by netconsole, but by rebooting right after a crash. Some
> broken state seems to be preserved across reboots. Switching off the power supply after
> a crash or even a ~30s wait after switching off the crashed machine seems to be enough
> to get around this.
> Also the hang when rebooting next-20260722 also occurs when compiling without PREEMPT_RT.
>
> Bert Karwatzki
There are actually several errors here:
1) The shutdown hang wich occurs in next-20260722+ (PREMPT_RT or not)
This error is caused by (I'll open a separate thread for this):
commit 13b7e6a96a005c656d38f3da51581deaf9866375
Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Wed Jul 8 16:43:47 2026 +0200
wifi: mt76: Disable napi when removing device
Unloading the mt7915e module with a MT7916 triggers multiples WARN in
__netif_napi_del_locked() and in page_pool_disable_direct_recycling()
because the driver does not disable the napi before destroying it.
This is troublesome since on MT7916 it is required to unload the module
and reinsert it with a different enable_6ghz parameter to change the
frequency. The system generally becomes unstable after reinserting the
module.
Fix it by disabling napi before deleting it. Also, do not delete napi
on WED queues since napi is neither used nor initialized on them.
Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Link: https://patch.msgid.link/20260708144615.24092-1-nicolas.cavallari@green-communications.fr
Signed-off-by: Felix Fietkau <nbd@nbd.name>
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index f8c2fe5f2f58..322041859217 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -1189,7 +1189,10 @@ void mt76_dma_cleanup(struct mt76_dev *dev)
mt76_for_each_q_rx(dev, i) {
struct mt76_queue *q = &dev->q_rx[i];
- netif_napi_del(&dev->napi[i]);
+ if (!mt76_queue_is_wed_rro(q)) {
+ napi_disable(&dev->napi[i]);
+ netif_napi_del(&dev->napi[i]);
+ }
mt76_dma_rx_cleanup(dev, q);
page_pool_destroy(q->page_pool);
2) The "scheduling while atomic" errors which occur in v7.2-rc4 and earlier, once I figure out
these I'll contiue here (v6.19 is free from these errors)
Bert Karwatzki
^ permalink raw reply related
* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-24 14:51 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <58689827-9211-4f26-9777-51c0b5e1eebb@I-love.SAKURA.ne.jp>
On Fri, Jul 24, 2026 at 11:35:36PM -0500, Tetsuo Handa wrote:
> I wonder whether it is appropriate to call "syzbot issues". syzbot is
> finding bugs in upstream git trees. Unless the cause of a bug is either
> syzbot is doing a stupid thing or compiler/toolchain is broken, it is
> "an upstream kernel issue".
I know that people have different experiences of Syzbot reported
issues, but the bugs I see require root privileges, modifying a file
system while it is mounted, maliciously corrupting file system images
and then mounting it without first running fsck, mucking with the loop
device (which requires root privileges) while it is in use by a file
system.
I do agree that if you mount a file system without running fsck, and
it has been maliciously corrupted, it woud be nice(tm) if it didn't
result in a crash or a WARN_ON. If someone wants to fund the
engineering work to make this be true, so long as it doesn't
compromise long-term code maintainability or performance, patches
would be welcome. So perhaps this is a P2 bug. But it's not
something I'm going to consider high priority, because it's not in any
threat model that I or the people who manage the budget and head count
authorizations, care about.
Since that's the *vast* majority of the issues reported by syzbot, I
tend to use "syzbot bug" as a shorthand.
I can't speak to whether the syzbot bugs you are chasing fall into
this category or not. But if it requires *vast* amount of VM time, it
makes me suspect that it falls into that category.
> Those who hate my attempts (i.e. sending patches to linux-next without
> being reviewed/acked by maintainers) are expecting that any patch is
> reviewed/acked by maintainers. But some maintainers are considering bugs
> reported by syzbot as "not worth looking into". Therefore, not only
> debug printk() patches (for bugs found by syzbot) but also bug fix patches
> (which syzbot has found) are getting ignored.
Yep, and I've explained above why that's the case. I've tried to make
the case that if there was a way that we could easily separate out
those bugs which are signal from noise (at leat as defined by those
people who refuse to fund this development work), it might be good for
improving syzbot's reputation. But I'm so busy that I don't have time
to go through all of the syzbot reported issues to see if any of them
are actually ones that should be considered high priority.
> In other words, the interest (by the upstream Linux kernel community) on
> fixing kernel bugs which syzbot found are decreasing. This is a deadlock
> situation, and just saying "Not my business." is not helpful.
Perhaps if Syzbot could be improved so we can be more selective about
which bugs are worth fixing, it might actually be better for the
kernel's quality.
But if the goal is to get ourselves to zero bugs, or zero syzbot
reported issues, that's not a goal I can get behind. It certainly
isn't something my management chain isn't willing to support that
goal, and it's NOT going to happen out of my own personal time.
Cheers,
- Ted
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-24 14:35 UTC (permalink / raw)
To: Theodore Tso
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <amNsDFyTbsyAASjt@mit.edu>
On 2026/07/24 22:50, Theodore Tso wrote:
> On Fri, Jul 24, 2026 at 09:11:27PM -0500, Tetsuo Handa wrote:
>>
>> What is happening is that I am using tomoyo git tree as a hook for
>> executing debug printk() (using linux-next git tree) in order to debug
>> problems which syzbot has found but nobody can afford looking into.
>>
>> Individual git tree is not served as a hook for applying debug patches
>> like "quilt push"; one of reasons is that "git" (compared to "quilt") is
>> not intended for removing a patch when that patch became no longer
>> necessary (due to problem being fixed).
>
> Ah. In that case, what if you simply have a separate tree which just
> has these debugging patches, and then either Mark Brown or the Syzbot
> team could create a new git tree / branch which takes linux-next and
> then merges this debug tree on top of the latest linux-net?
Yes, how to apply debug printk() patch will be solved if there were git
trees which applies debug patches on top of linux.git , linux-next.git ,
net.git etc.
But there is a potential problem. Developers might not try to look into
downstream git trees. How many developers would "git clone" when syzbot
reports an issue found in git trees with debug patches applied?
> The only question then is how much does the Syzbot team is willing pay
> to help provide the resources you need to resolve those syzbot issues.
I wonder whether it is appropriate to call "syzbot issues". syzbot is
finding bugs in upstream git trees. Unless the cause of a bug is either
syzbot is doing a stupid thing or compiler/toolchain is broken, it is
"an upstream kernel issue".
> I will say that *my* particular management chain at $WORK has
> authorized ignoring a whole class of syzbot bugs because they are
> utterly irrelevant for our production environment, and so it's not so
> much a "can't afford", but "has insufficient business value relative
> to our budget / head count authorization".
Yes, that is the biggest issue.
Those who hate my attempts (i.e. sending patches to linux-next without
being reviewed/acked by maintainers) are expecting that any patch is
reviewed/acked by maintainers. But some maintainers are considering bugs
reported by syzbot as "not worth looking into". Therefore, not only
debug printk() patches (for bugs found by syzbot) but also bug fix patches
(which syzbot has found) are getting ignored.
There are many patches which are not promptly applied into relevant git
trees. For example, syzbot is still using linux-next-20260714
( https://syzkaller.appspot.com/upstream/manager/ci-upstream-linux-next-kasan-gce-root )
despite the latest linux-next tree is linux-next-20260723 because e.g.
https://lore.kernel.org/all/al1pElMQZsDfpAYI@michalis-linux/T/ is not yet
applied. There is little effort in the community that "we try to make it
possible to continue fuzzing the linux-next.git tree in order to find new
bugs as early as possible and fix new bugs before it reaches linux.git tree".
In other words, the interest (by the upstream Linux kernel community) on
fixing kernel bugs which syzbot found are decreasing. This is a deadlock
situation, and just saying "Not my business." is not helpful.
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Theodore Tso @ 2026-07-24 13:50 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <2c903636-532f-47b5-9894-00470f235682@I-love.SAKURA.ne.jp>
On Fri, Jul 24, 2026 at 09:11:27PM -0500, Tetsuo Handa wrote:
>
> What is happening is that I am using tomoyo git tree as a hook for
> executing debug printk() (using linux-next git tree) in order to debug
> problems which syzbot has found but nobody can afford looking into.
>
> Individual git tree is not served as a hook for applying debug patches
> like "quilt push"; one of reasons is that "git" (compared to "quilt") is
> not intended for removing a patch when that patch became no longer
> necessary (due to problem being fixed).
Ah. In that case, what if you simply have a separate tree which just
has these debugging patches, and then either Mark Brown or the Syzbot
team could create a new git tree / branch which takes linux-next and
then merges this debug tree on top of the latest linux-net?
The advantages of this is that the patches never hit linux-next, but
this new tree, call it linux-next-syz-debug. And since it is a new
tree, you wouldn't need a new magic KConfig CONFIG #ifdef, so no code
changes would be needed in syzbot.
The only question then is how much does the Syzbot team is willing pay
to help provide the resources you need to resolve those syzbot issues.
I will say that *my* particular management chain at $WORK has
authorized ignoring a whole class of syzbot bugs because they are
utterly irrelevant for our production environment, and so it's not so
much a "can't afford", but "has insufficient business value relative
to our budget / head count authorization". (And personally, I refuse
to work on those bugs after midnight or on weekends; I have higher
priority personal priorities.) But perhaps the Syzbot team has a
different set of priorities....
- Ted
^ permalink raw reply
* No tree for 24th July
From: Mark Brown @ 2026-07-24 12:40 UTC (permalink / raw)
To: linux-next, linux-kernel
Hi,
Due to a mess up on my part there will be no -next release today, I will
do one on the 26th instead. Apologies for the disruption.
Thanks,
Mark
^ permalink raw reply
* Re: Policy regarding linux-next only changes
From: Tetsuo Handa @ 2026-07-24 12:11 UTC (permalink / raw)
To: Theodore Tso
Cc: Alexander Potapenko, Mark Brown, Christoph Hellwig,
Aleksandr Nogikh, Boqun Feng, Gary Guo, linux-next, linux-kernel,
Miguel Ojeda, Linus Torvalds, peterz, will, longman, mingo,
gregkh, Miguel Ojeda
In-Reply-To: <amEAzMTbA9R9HgN7@mit.edu>
On 2026/07/23 2:47, Theodore Tso wrote:
> On Thu, Jul 23, 2026 at 12:07:44AM -0500, Tetsuo Handa wrote:
>> The procedural problem is that developers / maintainers are too busy
>> to respond to my debug patches. Since I am debugging difficult bugs
>> where nobody else are willing to spend resources, this is an
>> expected result. I am OK to post my debug patches to ML. But without
>> responses / interests from developers / maintainers, this problem
>> won't be able to make progress.
>>
>> Just saying "Not my business." is not helpful.
>
> Is what is happening that when your security LSM (Tomoyo) is enabled,
> this causes lockdep or warnings or other issues in other subsystems?
No. Problems are not related to tomoyo.
What is happening is that I am using tomoyo git tree as a hook for
executing debug printk() (using linux-next git tree) in order to debug
problems which syzbot has found but nobody can afford looking into.
Individual git tree is not served as a hook for applying debug patches
like "quilt push"; one of reasons is that "git" (compared to "quilt") is
not intended for removing a patch when that patch became no longer
necessary (due to problem being fixed).
^ permalink raw reply
* Re: linux-next: manual merge of the nfc tree with the nfc-fixes tree
From: Zhou, Yun @ 2026-07-24 3:18 UTC (permalink / raw)
To: Mark Brown, David Heidelberg
Cc: Linux Kernel Mailing List, Linux Next Mailing List, Samuel Page,
horms
In-Reply-To: <akJv3Ajqh0ALyEk4@sirena.org.uk>
Hi Mark, David,
My patch (1d5fcb66b07a3) [1] was applied to the nfc tree on Jun 2,
nearly a month before Samuel's (075f88b7d3b5c, Jun 24) [2] . They fix
the same bug.
But Samuel's v2 still has issues that I addressed during my v1 [3] -->
v3 iteration:
1. Error response handling: his patch requires sizeof(*rsp_1) before
reading the status field. A valid NCI error response may only contain
a 1-byte status — his code returns SYNTAX_ERROR instead of propagating
the device's actual error code. I fixed this in v2 [4] by checking 1
byte first, then requiring the full header only after status == OK.
2. ndev state corruption: Simon flagged that if the length check fails
after ndev fields are partially updated, it leaves ndev in an
inconsistent state. My v3 defers all ndev updates until after
validation passes.
[1]
https://lore.kernel.org/all/20260527052625.3309581-1-yun.zhou@windriver.com/T/
[2] https://lore.kernel.org/all/20260624224455.999374-1-sam@bynar.io/
[3]
https://lore.kernel.org/all/20260519013042.3459906-1-yun.zhou@windriver.com/T/
[4]
https://lore.kernel.org/all/20260522021326.1164807-1-yun.zhou@windriver.com/T/
Was there something wrong with my version, or was it just a mechanical
conflict resolution?
Thanks,
Yun
On 6/29/2026 9:15 PM, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the nfc tree got a conflict in:
>
> net/nfc/nci/rsp.c
>
> between commit:
>
> 075f88b7d3b5c ("nfc: nci: fix uninit-value in nci_core_init_rsp_packet()")
>
> from the nfc-fixes tree and commit:
>
> 1d5fcb66b07a3 ("nfc: nci: fix use of uninitialized memory in CORE_INIT_RSP parsing")
>
> from the nfc 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 net/nfc/nci/rsp.c
> index 6b2fa6bdbd14b,85c3ff2b78cd9..0000000000000
> --- a/net/nfc/nci/rsp.c
> +++ b/net/nfc/nci/rsp.c
> @@@ -50,7 -50,8 +50,8 @@@ static u8 nci_core_init_rsp_packet_v1(s
> const struct nci_core_init_rsp_1 *rsp_1 = (void *)skb->data;
> const struct nci_core_init_rsp_2 *rsp_2;
>
> + /* Ensure that the status field can be accessed. */
> - if (skb_headlen(skb) < 1)
> + if (skb->len < sizeof(*rsp_1))
> return NCI_STATUS_SYNTAX_ERROR;
>
> pr_debug("status 0x%x\n", rsp_1->status);
^ permalink raw reply
* [STATUS] next/master - 9eebf259d5352b87080d67758f483583d9e763d7
From: KernelCI bot @ 2026-07-24 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/9eebf259d5352b87080d67758f483583d9e763d7/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
branch: master
commit hash: 9eebf259d5352b87080d67758f483583d9e763d7
origin: maestro
test start time: 2026-07-23 16:24:54.439000+00:00
Builds: 72 ✅ 2 ❌ 0 ⚠️
Boots: 156 ✅ 2 ❌ 0 ⚠️
Tests: 26416 ✅ 2052 ❌ 4606 ⚠️
### POSSIBLE REGRESSIONS
Hardware: bcm2837-rpi-3-b-plus
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625680798ea6c1ef60ab4f
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a626653798ea6c1ef617b6b
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a626653798ea6c1ef617b6a
history: > ✅ > ✅ > ✅ > ❌
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa
last run: https://d.kernelci.org/test/maestro:6a62563e798ea6c1ef60a8c4
history: > ✅ > ❌ > ❌
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_59
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4c2
history: > ✅ > ❌
- kselftest.alsa.alsa_mixer-test_event_spurious_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4d7
history: > ✅ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625687798ea6c1ef60ab73
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a625ed8798ea6c1ef614846
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a625ed8798ea6c1ef614845
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625686798ea6c1ef60ab6e
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a625b0f798ea6c1ef610828
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a625b0f798ea6c1ef610827
history: > ✅ > ✅ > ✅ > ✅ > ❌
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a62560e798ea6c1ef60a6d3
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a626947798ea6c1ef61872f
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a625655798ea6c1ef60a97a
history: > ✅ > ❌ > ❌ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625688798ea6c1ef60ab7d
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a626e44798ea6c1ef61e0eb
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a626e44798ea6c1ef61e0ea
history: > ✅ > ✅ > ✅ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625683798ea6c1ef60ab5e
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-001
last run: https://d.kernelci.org/test/maestro:6a625b83798ea6c1ef613313
history: > ✅ > ✅ > ✅ > ❌
- kselftest.proc.proc_proc-self-map-files-002
last run: https://d.kernelci.org/test/maestro:6a625b83798ea6c1ef613312
history: > ✅ > ✅ > ✅ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.clone3
last run: https://d.kernelci.org/test/maestro:6a625fae798ea6c1ef614957
history: > ✅ > ✅ > ✅ > ✅ > ❌
- kselftest.proc
last run: https://d.kernelci.org/test/maestro:6a625684798ea6c1ef60ab64
history: > ✅ > ✅ > ✅ > ✅ > ❌
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.efivars
last run: https://d.kernelci.org/test/maestro:6a6248ff75cb84fb218a8935
history: > ✅ > ❌ > ❌ > ❌ > ❌
### FIXED REGRESSIONS
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_61
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4d5
history: > ❌ > ✅
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_62
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4dc
history: > ❌ > ✅
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_63
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4e3
history: > ❌ > ✅
- kselftest.alsa.alsa_mixer-test_name_wm8960audio_64
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e4ea
history: > ❌ > ✅
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e513
history: > ❌ > ✅
- kselftest.alsa.alsa_mixer-test_write_default_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e521
history: > ❌ > ✅
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a625679798ea6c1ef60ab06
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a625e39798ea6c1ef6144b9
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a625e39798ea6c1ef6144ba
history: > ❌ > ❌ > ✅ > ✅ > ✅
Hardware: meson-gxl-s905x-libretech-cc
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a62567a798ea6c1ef60ab11
history: > ❌ > ❌ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a6282b5798ea6c1ef62393d
history: > ❌ > ❌ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a6282b5798ea6c1ef62393e
history: > ❌ > ❌ > ✅ > ✅
Hardware: sm8750-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a62561b798ea6c1ef60a744
history: > ❌ > ❌ > ✅
- kselftest.breakpoints.breakpoints_step_after_suspend_test
last run: https://d.kernelci.org/test/maestro:6a625800798ea6c1ef60f0ae
history: > ❌ > ❌ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a625678798ea6c1ef60aafe
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a625afb798ea6c1ef6107ac
history: > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a625afb798ea6c1ef6107ad
history: > ❌ > ✅ > ✅ > ✅
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.breakpoints
last run: https://d.kernelci.org/test/maestro:6a62561d798ea6c1ef60a753
history: > ❌ > ❌ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a626d2f798ea6c1ef6199bf
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.timers
last run: https://d.kernelci.org/test/maestro:6a625697798ea6c1ef60abd2
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.timers.timers_posix_timers
last run: https://d.kernelci.org/test/maestro:6a627175798ea6c1ef61e3ec
history: > ❌ > ✅ > ✅ > ✅
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:6a625c56798ea6c1ef613748
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a625674798ea6c1ef60aae7
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a625b46798ea6c1ef6109d2
history: > ❌ > ❌ > ✅ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a625b46798ea6c1ef6109d3
history: > ❌ > ❌ > ✅ > ✅ > ✅
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145a1
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef614560
history: > ❌ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c00000_pcie_0_wifi_0
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61455e
history: > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_pci_1c10000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61455d
history: > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a625e6c798ea6c1ef6144f1
history: > ❌ > ✅ > ✅ > ✅
- kselftest.futex
last run: https://d.kernelci.org/test/maestro:6a625675798ea6c1ef60aaed
history: > ❌ > ❌ > ❌ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_multiple
last run: https://d.kernelci.org/test/maestro:6a625f72798ea6c1ef61491d
history: > ❌ > ❌ > ❌ > ✅ > ✅
- kselftest.futex.futex_run_sh_global_requeue_single
last run: https://d.kernelci.org/test/maestro:6a625f72798ea6c1ef61491e
history: > ❌ > ❌ > ✅ > ✅ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.ring-buffer
last run: https://d.kernelci.org/test/maestro:6a62493f75cb84fb218a8ab8
history: > ❌ > ❌ > ❌ > ❌ > ✅
### UNSTABLE TESTS
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:6a625659798ea6c1ef60a992
history: > ✅ > ❌ > ✅ > ✅
- kselftest.device_error_logs.devices_error_logs_test_device_error_logs_py
last run: https://d.kernelci.org/test/maestro:6a625ea6798ea6c1ef614701
history: > ✅ > ❌ > ✅ > ✅
Hardware: imx8mp-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e50a
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e511
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e518
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_invalid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e51f
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_69
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e50b
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_70
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e512
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_71
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e519
history: > ⚠️ > ✅
- kselftest.alsa.alsa_mixer-test_write_valid_wm8960audio_72
last run: https://d.kernelci.org/test/maestro:6a625757798ea6c1ef60e520
history: > ⚠️ > ✅
Hardware: k3-am625-verdin-wifi-mallow
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.dt
last run: https://d.kernelci.org/test/maestro:6a62566f798ea6c1ef60aaae
history: > ❌ > ❌ > ✅ > ❌ > ❌
Hardware: kaanapali-mtp
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a62560d798ea6c1ef60a6cf
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a625750798ea6c1ef60df8c
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_9800000_dsi_9ac0000_panel_0
last run: https://d.kernelci.org/test/maestro:6a625dbd798ea6c1ef6143be
history: > ✅ > ❌ > ✅ > ✅ > ✅
Hardware: meson-g12b-a311d-khadas-vim3
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a625243798ea6c1ef60991f
history: > ✅ > ❌ > ❌ > ✅ > ✅
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a6252cf798ea6c1ef609ae0
history: > ✅ > ❌ > ❌ > ✅ > ✅
Hardware: mt8395-genio-1200-evk
> Config: defconfig+preempt_rt
- Architecture/compiler: arm64/gcc-14
- rt-tests.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a625245798ea6c1ef609941
history: > ✅ > ❌ > ✅ > ✅ > ✅
- rt-tests.rt-migrate-test.rt-migrate-test
last run: https://d.kernelci.org/test/maestro:6a625791798ea6c1ef60ee0e
history: > ✅ > ❌ > ✅ > ✅ > ✅
Hardware: lemans-evk
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.devices-probe
last run: https://d.kernelci.org/test/maestro:6a625703798ea6c1ef60d6ac
history: > ❌ > ✅ > ❌ > ❌
Hardware: qcs6490-rb3gen2
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.arm64
last run: https://d.kernelci.org/test/maestro:6a625608798ea6c1ef60a6be
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.arm64.arm64_fp-stress
last run: https://d.kernelci.org/test/maestro:6a625755798ea6c1ef60e250
history: > ✅ > ❌ > ✅ > ✅ > ✅
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a625646798ea6c1ef60a919
history: > ❌ > ❌ > ❌ > ✅ > ❌
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a62565a798ea6c1ef60a998
history: > ❌ > ✅ > ✅ > ❌
- kselftest.dt.dt_test_unprobed_devices_sh_reboot-mode
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6137a6
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_edp_aea0000
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef61377f
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef61377c
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_99c000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613760
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_phy_88e8000
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef61373b
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc_3100
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613706
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_adc-tm_3400
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613707
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7000
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613704
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7100
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613703
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7400
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613741
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7c00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613702
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_7d00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613701
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8400
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef613700
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8500
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136ff
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_8600
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136fe
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9800
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136fd
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_nvram_9d00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136fc
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136fb
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_pwrkey
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136fa
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_pon_1300_resin
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136f9
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_0_rtc_6100
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136f8
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_1_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136f5
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_pwm
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136f2
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_2_temp-alarm_a00
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136f1
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_adc_3100
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136ef
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_spmi_c440000_pmic_8_temp-alarm_2400
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136ed
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_usb_a600000
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136cc
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136cb
history: > ✅ > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_wcn6750-pmu
last run: https://d.kernelci.org/test/maestro:6a625c56798ea6c1ef6136c6
history: > ✅ > ✅ > ✅ > ❌ > ✅
> Config: defconfig+arm64-chromebook+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.gpio
last run: https://d.kernelci.org/test/maestro:6a62492075cb84fb218a8a0b
history: > ❌ > ❌ > ✅ > ❌ > ❌
Hardware: qcs8300-ride
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- kselftest.coredump
last run: https://d.kernelci.org/test/maestro:6a625647798ea6c1ef60a91e
history: > ❌ > ✅ > ❌ > ❌ > ✅
- kselftest.device-error-logs
last run: https://d.kernelci.org/test/maestro:6a62565b798ea6c1ef60a99f
history: > ❌ > ✅ > ❌ > ❌
- kselftest.devices-exist
last run: https://d.kernelci.org/test/maestro:6a6256f3798ea6c1ef60d647
history: > ✅ > ❌ > ✅ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145ac
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_display-controller_ae01000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145ab
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_displayport-controller_af54000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145a9
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_dsi_ae94000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145a7
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_ae94400
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145a5
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_display-subsystem_ae00000_phy_aec2a00
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef6145a4
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_ethernet_23040000_mdio_phy_8
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61459f
history: > ⚠️ > ✅ > ⚠️ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_9c0000_serial_988000_bluetooth
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef614585
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_geniqup_ac0000_i2c_a80000_i2c-mux_70_i2c_0_bridge_58
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61457f
history: > ❌ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_gpu_3d00000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61457c
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_20c00000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef61454c
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_remoteproc_26300000
last run: https://d.kernelci.org/test/maestro:6a625e6d798ea6c1ef614547
history: > ✅ > ✅ > ❌ > ✅
- kselftest.dt.dt_test_unprobed_devices_sh_soc_0_video-codec_aa00000
last run: https://d.kernelci.org/test/maestro:6a625e6c798ea6c1ef6144f0
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: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Mark Brown @ 2026-07-24 0:13 UTC (permalink / raw)
To: Matthew Brost
Cc: Andrew Morton, Nathan Chancellor, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Usama Arif, linux-mm, dri-devel,
linux-next
In-Reply-To: <amKftG6NRZy0Ii2/@gsse-cloud1.jf.intel.com>
[-- Attachment #1: Type: text/plain, Size: 297 bytes --]
On Thu, Jul 23, 2026 at 04:11:48PM -0700, Matthew Brost wrote:
> On Thu, Jul 23, 2026 at 04:09:42PM -0700, Andrew Morton wrote:
> > I'm fine the drm people changing things ;)
> I'll jump make a DRM change so this is all worked out when it gets to
> Linus.
So should I drop Nathan's fixup then?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Matthew Brost @ 2026-07-23 23:11 UTC (permalink / raw)
To: Andrew Morton
Cc: Nathan Chancellor, Mark Brown, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Usama Arif, linux-mm, dri-devel, linux-next
In-Reply-To: <20260723160942.b58b065d771401aba117bc77@linux-foundation.org>
On Thu, Jul 23, 2026 at 04:09:42PM -0700, Andrew Morton wrote:
> On Thu, 23 Jul 2026 14:27:24 -0700 Nathan Chancellor <nathan@kernel.org> wrote:
>
> > > So the drm_pagemap.c code could be:
> > >
> > > -#if IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION)
> > > +#if IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES)
> > > #define DRM_PAGEMAP_PMD_ORDER HPAGE_PMD_ORDER
> > > #else
> > > #define DRM_PAGEMAP_PMD_ORDER (-1)
> >
> > Ah yeah, I probably should have looked at the bigger picture there.
> >
> > > This Kconfig has been around since 2024:
> > > git format-patch -1 b979db1611a63
> > >
> > > Would it be better for everyone for me to change this in the DRM branches?
> >
> > I believe that would render this conflict moot and seems like the
> > correct thing to do anyways but you could wait for input from the mm
> > folks.
>
> I'm fine the drm people changing things ;)
>
I'll jump make a DRM change so this is all worked out when it gets to
Linus.
Matt
> Otherwise I can disable "mm: rename ARCH_ENABLE_THP_MIGRATION to
> ARCH_HAS_PMD_SOFTLEAVES" for now and fix&reintroduce it into mm.git
> after drm-misc has merge into Linus. Or something like that.
>
^ permalink raw reply
* Re: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Andrew Morton @ 2026-07-23 23:09 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Matthew Brost, Mark Brown, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Usama Arif, linux-mm, dri-devel, linux-next
In-Reply-To: <20260723212724.GA999236@ax162>
On Thu, 23 Jul 2026 14:27:24 -0700 Nathan Chancellor <nathan@kernel.org> wrote:
> > So the drm_pagemap.c code could be:
> >
> > -#if IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION)
> > +#if IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES)
> > #define DRM_PAGEMAP_PMD_ORDER HPAGE_PMD_ORDER
> > #else
> > #define DRM_PAGEMAP_PMD_ORDER (-1)
>
> Ah yeah, I probably should have looked at the bigger picture there.
>
> > This Kconfig has been around since 2024:
> > git format-patch -1 b979db1611a63
> >
> > Would it be better for everyone for me to change this in the DRM branches?
>
> I believe that would render this conflict moot and seems like the
> correct thing to do anyways but you could wait for input from the mm
> folks.
I'm fine the drm people changing things ;)
Otherwise I can disable "mm: rename ARCH_ENABLE_THP_MIGRATION to
ARCH_HAS_PMD_SOFTLEAVES" for now and fix&reintroduce it into mm.git
after drm-misc has merge into Linus. Or something like that.
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in next-20260722
From: Bert Karwatzki @ 2026-07-23 22:51 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: <1a0800888c2fcd42f1fcd661d8f6f50580ac2fd4.camel@web.de>
Am Donnerstag, dem 23.07.2026 um 18:17 +0200 schrieb Bert Karwatzki:
> Am Donnerstag, dem 23.07.2026 um 15:23 +0200 schrieb Bert Karwatzki:
> > Am Donnerstag, dem 23.07.2026 um 15:10 +0200 schrieb Bert Karwatzki:
> > > I was able to gather the panic error message from a failed shutdown via netconsole,
> > > this time the kernel used was v7.2-rc3:
> > > #
> > > Bert Karwatzki
> >
> > Unfortunatetly I can now reproduce these kernel panics in v7.1:
> >
> >
> > So now I'm going to use memtest86+ on my machine and then look at the changes I had in
> > my userspace as the first error occured on 22.7.2026. Let's hope this does not escalate ...
> >
> > Bert Karwatzki
>
>
> But I found out an exciting thing:
> I can only reproduce the crashes in v7.2-rc4 when watching the reboot via netconsole,
> without netconsole no crash occurs!(This also explains why I had not seen this crashes before ...)
>
Actually this is not cause by netconsole, but by rebooting right after a crash. Some
broken state seems to be preserved across reboots. Switching off the power supply after
a crash or even a ~30s wait after switching off the crashed machine seems to be enough
to get around this.
Also the hang when rebooting next-20260722 also occurs when compiling without PREEMPT_RT.
Bert Karwatzki
^ permalink raw reply
* Re: Semantic conflict between 04b177544a04 in drm-misc-fixes and 0b6b1bb28482 in -mm
From: Nathan Chancellor @ 2026-07-23 21:27 UTC (permalink / raw)
To: Matthew Brost
Cc: Mark Brown, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrew Morton, Usama Arif, linux-mm, dri-devel, linux-next
In-Reply-To: <amFPJc1NQbuYWlSp@gsse-cloud1.jf.intel.com>
On Wed, Jul 22, 2026 at 04:15:49PM -0700, Matthew Brost wrote:
> On Wed, Jul 22, 2026 at 03:56:05PM -0700, Nathan Chancellor wrote:
> > Hi Mark and drm and mm folks,
> >
>
> Typically to get drm_pagemap.c to compile on various configs this is
> what is needed:
>
> 109 #ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES
> 110 #define HPAGE_PMD_SHIFT PMD_SHIFT
> 111 #define HPAGE_PUD_SHIFT PUD_SHIFT
> 112 #else
> 113 #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; })
> 114 #define HPAGE_PUD_SHIFT ({ BUILD_BUG(); 0; })
> 115 #endif
>
> So the drm_pagemap.c code could be:
>
> -#if IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION)
> +#if IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES)
> #define DRM_PAGEMAP_PMD_ORDER HPAGE_PMD_ORDER
> #else
> #define DRM_PAGEMAP_PMD_ORDER (-1)
Ah yeah, I probably should have looked at the bigger picture there.
> This Kconfig has been around since 2024:
> git format-patch -1 b979db1611a63
>
> Would it be better for everyone for me to change this in the DRM branches?
I believe that would render this conflict moot and seems like the
correct thing to do anyways but you could wait for input from the mm
folks.
> > There is a semantic conflict between commit 04b177544a04 ("drm/pagemap:
> > Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATION") in the
> > drm-misc-fixes tree and commit 0b6b1bb28482 ("mm: rename
> > ARCH_ENABLE_THP_MIGRATION to ARCH_HAS_PMD_SOFTLEAVES"), resulting in a
> > lone instance of CONFIG_ARCH_ENABLE_THP_MIGRATION with no way to define
> > it.
> >
> > $ git grep ARCH_ENABLE_THP_MIGRATION
> > Next/merge.log:Merging drm-misc-fixes/for-linux-next-fixes (04b177544a040 drm/pagemap: Guard HPAGE_PMD_ORDER use with CONFIG_ARCH_ENABLE_THP_MIGRATION)
> > drivers/gpu/drm/drm_pagemap.c:#if IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION)
> >
> > This results in an objtool warning (or error with CONFIG_OBJTOOL_WERROR)
> > when building with clang because NR_PAGES(order) results in 1U << -1,
> > which causes clang to stop generating code for
> > drm_pagemap_migrate_to_devmem() when encountering unconditional
> > undefined behavior.
> >
> > drivers/gpu/drm/drm_gpusvm_helper.o: error: objtool: drm_pagemap_migrate_to_devmem() falls through to next function drm_pagemap_zdd_alloc()
> >
> > Mark, could please apply the following diff to the -mm merge to avoid
> > this? Obviously, there will need to be further coordination for
> > resolving this upstream when the time comes but it is only an issue in
> > -next currently.
> >
> > diff --git a/drivers/gpu/drm/drm_pagemap.c b/drivers/gpu/drm/drm_pagemap.c
> > index 4a794544b7dc..f00c27edbfb9 100644
> > --- a/drivers/gpu/drm/drm_pagemap.c
> > +++ b/drivers/gpu/drm/drm_pagemap.c
> > @@ -12,7 +12,7 @@
> > #include <drm/drm_pagemap_util.h>
> > #include <drm/drm_print.h>
> >
> > -#if IS_ENABLED(CONFIG_ARCH_ENABLE_THP_MIGRATION)
> > +#if IS_ENABLED(CONFIG_ARCH_HAS_PMD_SOFTLEAVES)
> > #define DRM_PAGEMAP_PMD_ORDER HPAGE_PMD_ORDER
> > #else
> > #define DRM_PAGEMAP_PMD_ORDER (-1)
> > --
> > Cheers,
> > Nathan
--
Cheers,
Nathan
^ permalink raw reply
* Re: linux-next: manual merge of the wireless-next tree with the origin tree
From: Zhao Li @ 2026-07-23 20:21 UTC (permalink / raw)
To: Mark Brown
Cc: Johannes Berg, linux-wireless, Johannes Berg, linux-kernel,
linux-next, Miri Korenblit, Pagadala Yesu Anjaneyulu
In-Reply-To: <ac48f782-3fbd-4c61-89d0-4dd032ca81b9@sirena.org.uk>
On Thu, Jul 23, 2026 at 7:51 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 22, 2026 at 03:53:59PM -0500, Enderaoe Lyther wrote:
>
> > I noticed one semantic conflict later in ieee80211_rx_mgmt_assoc_resp().
>
> I can't tell which bit of code you are talking about here. I see there
> is a block at line 7274 of -next:
>
> if (elems->aid_resp)
> aid = le16_to_cpu(elems->aid_resp->aid);
> else if (!assoc_data->s1g)
> aid = le16_to_cpu(mgmt->u.assoc_resp.aid);
> else if (status_code == WLAN_STATUS_SUCCESS)
> goto notify_driver;
Sorry about the formatting in my earlier message. I should have quoted the
code inline instead of top-posting.
That last branch was introduced by 035ed430ce6a ("wifi: mac80211: avoid
non-S1G AID fallback for S1G assoc") as:
else if (status_code == WLAN_STATUS_SUCCESS)
goto abandon_assoc;
f13e573ab3f12 ("wifi: mac80211: notify driver before destroying assoc
link") consolidated terminal association cleanup at destroy_assoc_data
and removed abandon_assoc. The conflict resolution retargeted this branch
to notify_driver, but notify_driver only calls drv_mgd_complete_tx()
without destroying the association data.
Since assoc_status is initialized to ASSOC_ABANDON at function entry, the
equivalent target is destroy_assoc_data. A successful S1G association
response with no AID Response element otherwise leaves assoc_data live
instead of abandoning it.
> but that is immediately after another goto notify_driver, there's
> further notify_driver error handling afterwards and all the earlier
> error handling is return statements so it looks at least unclear what's
> supposed to be going on.
Other goto notify_driver targets are intentional:
- "if (!elems) goto notify_driver" is a pre-existing allocation failure
bail-out; so association timeout handles cleanup.
- The comeback path WLAN_STATUS_ASSOC_REJECTED_TEMPORARILY keeps
assoc_data live deliberately for retry.
A successful S1G response without an AID Response element is terminal.
It needs to abandon association immediately, so the target should be
destroy_assoc_data rather than notify_driver.
> Please don't top post, reply in line with needed context.
Understood. Sorry for the unclear top-posted reply.
Zhao
^ permalink raw reply
* linux-next: Tree for Jul 23
From: Mark Brown @ 2026-07-23 18:15 UTC (permalink / raw)
To: Linux Next Mailing List; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
Hi all,
Changes since 20260722:
The pci tree acquired a conflict with the arm64 tree.
The net-next tree acquired a conflict with the net tree.
The bluetooth tree acquired a conflict with the net tree.
The paulmck tree acquired a conflict with the tip-fixes and tip trees.
The kvm-arm tree acquired a conflict with the arm64 tree.
Non-merge commits (relative to Linus' tree): 8135
7669 files changed, 371211 insertions(+), 118647 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: linux-next: manual merge of the net-next tree with the net tree
From: Matthieu Baerts @ 2026-07-23 17:16 UTC (permalink / raw)
To: Mark Brown
Cc: Eric Dumazet, Linux Kernel Mailing List, Linux Next Mailing List,
Michael Bommarito, David Miller, Jakub Kicinski, Paolo Abeni,
Networking
In-Reply-To: <amIaJr3aOQNS_Fvl@sirena.org.uk>
Hi Mark,
On 23/07/2026 15:41, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/amt.c
>
> between commit:
>
> 3656a79f94c47 ("amt: re-read skb header pointers after every pull")
>
> from the net tree and commit:
>
> 586c4dcf28eb6 ("amt: no longer rely on RTNL in amt_fill_info()")
>
> from the net-next 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/net/amt.c
> index b733309b866ff,f8169c5512a59..0000000000000
> --- a/drivers/net/amt.c
> +++ b/drivers/net/amt.c
> @@@ -2811,7 -2775,8 +2814,8 @@@ drop
> static int amt_rcv(struct sock *sk, struct sk_buff *skb)
> {
> struct amt_dev *amt;
> - struct iphdr *iph;
> + __be32 saddr;
> + __be32 remote_ip;
Thank you for the resolution, it looks good to me, except these lines:
in the net subsystem, the local variables are declared following the
reversed Xmas tree order [1]. So I suppose the Net maintainers will
inverse these two lines when resolving this conflict.
[1]
https://docs.kernel.org/process/maintainer-netdev.html#local-variable-ordering-reverse-xmas-tree-rcs
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [Re] kernel panic during shutdown in v7.2-rc{3,4} and next-20260722 with PREEMPT_RT
From: Bert Karwatzki @ 2026-07-23 16:17 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: <d24a136539c5931984f4855ad6596ca7aee8ebe2.camel@web.de>
Am Donnerstag, dem 23.07.2026 um 15:23 +0200 schrieb Bert Karwatzki:
> Am Donnerstag, dem 23.07.2026 um 15:10 +0200 schrieb Bert Karwatzki:
> > I was able to gather the panic error message from a failed shutdown via netconsole,
> > this time the kernel used was v7.2-rc3:
> > #
> > Bert Karwatzki
>
> Unfortunatetly I can now reproduce these kernel panics in v7.1:
>
>
> So now I'm going to use memtest86+ on my machine and then look at the changes I had in
> my userspace as the first error occured on 22.7.2026. Let's hope this does not escalate ...
>
> Bert Karwatzki
So I've run memtest86+ for ~2.5h (2.6 complete runs) and found no error. Even if my memory
contained an error, if it's that hard to trigger it would not cause frequent crashes.
But I found out an exciting thing:
I can only reproduce the crashes in v7.2-rc4 when watching the reboot via netconsole,
without netconsole no crash occurs!(This also explains why I had not seen this crashes before ...)
In next-20260722 the crash is reproducible without netconsole.
So I'm going back to bisecting from v7.2-rc4 to next-20260722. Once I'm finished with
that I'm going to look at the "netconsole triggerred" crashes.
Does anyone have an idea what's going on?
Bert Karwatzki
^ permalink raw reply
* Re: linux-next: duplicate patch in the paulmck tree
From: Paul E. McKenney @ 2026-07-23 16:04 UTC (permalink / raw)
To: Mark Brown; +Cc: Linux Kernel Mailing List, Linux Next Mailing List
In-Reply-To: <amInUXBCvCX4vXUh@sirena.org.uk>
On Thu, Jul 23, 2026 at 03:38:09PM +0100, Mark Brown wrote:
> Hi all,
>
> The following commit is also in the tip-fixes tree as a different commit
> (but the same patch):
>
> fbced06c64fd6 ("smp: Avoid invalid per-CPU CSD lookup with CSD lock debug")
And I have dropped this one as well, thank you!
Thanx, Paul
^ permalink raw reply
* Re: linux-next: manual merge of the paulmck tree with the tip-fixes and tip trees
From: Paul E. McKenney @ 2026-07-23 16:03 UTC (permalink / raw)
To: Mark Brown
Cc: Chuyi Zhou, Linux Kernel Mailing List, Linux Next Mailing List,
Thomas Gleixner, Usama Arif
In-Reply-To: <amInSCxaV5NRRWcT@sirena.org.uk>
On Thu, Jul 23, 2026 at 03:38:00PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the paulmck tree got a conflict in:
>
> kernel/smp.c
>
> between commits:
>
> 35551efb155e3 ("smp: Make CSD lock acquisition atomic for debug mode")
> ec9f57e6fefbc ("smp: Use release stores for csd_lock_record() state")
>
> from the tip-fixes and tip trees and commit:
>
> c2d939be90724 ("smp: Make CSD lock acquisition atomic for debug mode")
>
> from the paulmck 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.
Excellent! I have dropped this from my tree in favor of tip-fixes.
Thanx, Paul
> diff --combined kernel/smp.c
> index b696bcc60c08f,b9448fe3b84ff..0000000000000
> --- a/kernel/smp.c
> +++ b/kernel/smp.c
> @@@ -16,7 -16,6 +16,7 @@@
> #include <linux/init.h>
> #include <linux/interrupt.h>
> #include <linux/gfp.h>
> +#include <linux/slab.h>
> #include <linux/smp.h>
> #include <linux/cpu.h>
> #include <linux/sched.h>
> @@@ -64,14 -63,7 +64,14 @@@ int smpcfd_prepare_cpu(unsigned int cpu
> free_cpumask_var(cfd->cpumask);
> return -ENOMEM;
> }
> - cfd->csd = alloc_percpu(call_single_data_t);
> +
> + /*
> + * Allocate the per-CPU CSD the first time a CPU comes up. It is
> + * not freed when the CPU is offlined, so csd_lock_wait() can access
> + * it even when the CPU was offlined after preemption was re-enabled.
> + */
> + if (!cfd->csd)
> + cfd->csd = alloc_percpu(call_single_data_t);
> if (!cfd->csd) {
> free_cpumask_var(cfd->cpumask);
> free_cpumask_var(cfd->cpumask_ipi);
> @@@ -87,6 -79,7 +87,6 @@@ int smpcfd_dead_cpu(unsigned int cpu
>
> free_cpumask_var(cfd->cpumask);
> free_cpumask_var(cfd->cpumask_ipi);
> - free_percpu(cfd->csd);
> return 0;
> }
>
> @@@ -189,22 -182,16 +189,22 @@@ static atomic_t csd_bug_count = ATOMIC_
> static void __csd_lock_record(call_single_data_t *csd)
> {
> if (!csd) {
> - smp_mb(); /* NULL cur_csd after unlock. */
> - __this_cpu_write(cur_csd, NULL);
> + /*
> + * Pairs with smp_load_acquire() of cur_csd in
> + * csd_lock_wait_toolong(): orders any preceding CSD
> + * callback/unlock before a remote reader observes NULL.
> + */
> + smp_store_release(this_cpu_ptr(&cur_csd), NULL);
> return;
> }
> __this_cpu_write(cur_csd_func, csd->func);
> __this_cpu_write(cur_csd_info, csd->info);
> - smp_wmb(); /* func and info before csd. */
> - __this_cpu_write(cur_csd, csd);
> - smp_mb(); /* Update cur_csd before function call. */
> - /* Or before unlock, as the case may be. */
> + /*
> + * Pairs with smp_load_acquire() of cur_csd in
> + * csd_lock_wait_toolong(): publishes cur_csd_func and
> + * cur_csd_info before the non-NULL pointer becomes visible.
> + */
> + smp_store_release(this_cpu_ptr(&cur_csd), csd);
> }
>
> static __always_inline void csd_lock_record(call_single_data_t *csd)
> @@@ -285,13 -272,7 +285,13 @@@ static bool csd_lock_wait_toolong(call_
> cpux = 0;
> else
> cpux = cpu;
> - cpu_cur_csd = smp_load_acquire(&per_cpu(cur_csd, cpux)); /* Before func and info. */
> + /*
> + * Pairs with smp_store_release() of cur_csd in __csd_lock_record():
> + * a non-NULL cur_csd here implies cur_csd_func and cur_csd_info
> + * are the matching publication; a NULL value is ordered after any
> + * preceding CSD callback/unlock on the remote CPU.
> + */
> + cpu_cur_csd = smp_load_acquire(&per_cpu(cur_csd, cpux));
> /* How long since this CSD lock was stuck. */
> ts_delta = ts2 - ts0;
> pr_alert("csd: %s non-responsive CSD lock (#%d) on CPU#%d, waiting %lld ns for CPU#%02d %pS(%ps).\n",
> @@@ -342,8 -323,6 +342,8 @@@ static void __csd_lock_wait(call_single
> int bug_id = 0;
> u64 ts0, ts1;
>
> + guard(preempt)();
> +
> ts1 = ts0 = ktime_get_mono_fast_ns();
> for (;;) {
> if (csd_lock_wait_toolong(csd, ts0, &ts1, &bug_id, &nmessages))
> @@@ -381,15 -360,14 +381,15 @@@ static __always_inline void csd_lock(ca
> {
> if (IS_ENABLED(CONFIG_CSD_LOCK_WAIT_DEBUG) &&
> static_branch_unlikely(&csdlock_debug_enabled)) {
> - unsigned int flags;
>
> for (;;) {
> + unsigned int flags;
> +
> __csd_lock_wait(csd);
> flags = READ_ONCE(csd->node.u_flags);
> +
> if (!(flags & CSD_FLAG_LOCK) &&
> - try_cmpxchg_acquire(&csd->node.u_flags, &flags,
> - flags | CSD_FLAG_LOCK))
> + try_cmpxchg_acquire(&csd->node.u_flags, &flags, flags | CSD_FLAG_LOCK))
> break;
> }
> } else {
> @@@ -680,9 -658,17 +680,9 @@@ void flush_smp_call_function_queue(void
> local_irq_restore(flags);
> }
>
> -/**
> - * smp_call_function_single - Run a function on a specific CPU
> - * @cpu: Specific target CPU for this function.
> - * @func: The function to run. This must be fast and non-blocking.
> - * @info: An arbitrary pointer to pass to the function.
> - * @wait: If true, wait until function has completed on other CPUs.
> - *
> - * Returns: %0 on success, else a negative status code.
> - */
> -int smp_call_function_single(int cpu, smp_call_func_t func, void *info,
> - int wait)
> +static int __smp_call_function_single(int cpu, smp_call_func_t func,
> + void *info, const struct cpumask *mask,
> + bool wait)
> {
> call_single_data_t *csd;
> call_single_data_t csd_stack = {
> @@@ -699,14 -685,6 +699,14 @@@
> */
> this_cpu = get_cpu();
>
> + if (mask) {
> + /* Try for same CPU (cheapest) */
> + if (!cpumask_test_cpu(this_cpu, mask))
> + cpu = sched_numa_find_nth_cpu(mask, 0, cpu_to_node(this_cpu));
> + else
> + cpu = this_cpu;
> + }
> +
> /*
> * Can deadlock when called with interrupts disabled.
> * We allow cpu's that are not yet online though, as no one else can
> @@@ -739,32 -717,13 +739,32 @@@
>
> err = generic_exec_single(cpu, csd);
>
> + /*
> + * @csd is stack-allocated when @wait is true. No concurrent access
> + * except from the IPI completion path, so we can re-enable preemption
> + * early to reduce latency.
> + */
> + put_cpu();
> +
> if (wait)
> csd_lock_wait(csd);
>
> - put_cpu();
> -
> return err;
> }
> +
> +/**
> + * smp_call_function_single - Run a function on a specific CPU
> + * @cpu: Specific target CPU for this function.
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @wait: If true, wait until function has completed on other CPUs.
> + *
> + * Returns: %0 on success, else a negative status code.
> + */
> +int smp_call_function_single(int cpu, smp_call_func_t func, void *info, bool wait)
> +{
> + return __smp_call_function_single(cpu, func, info, NULL, wait);
> +}
> EXPORT_SYMBOL(smp_call_function_single);
>
> /**
> @@@ -815,10 -774,10 +815,10 @@@ EXPORT_SYMBOL_GPL(smp_call_function_sin
>
> /**
> * smp_call_function_any - Run a function on any of the given cpus
> - * @mask: The mask of cpus it can run on.
> - * @func: The function to run. This must be fast and non-blocking.
> - * @info: An arbitrary pointer to pass to the function.
> - * @wait: If true, wait until function has completed.
> + * @mask: The mask of cpus it can run on.
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @wait: If true, wait until function has completed.
> *
> * Selection preference:
> * 1) current cpu if in @mask
> @@@ -829,54 -788,20 +829,54 @@@
> int smp_call_function_any(const struct cpumask *mask,
> smp_call_func_t func, void *info, int wait)
> {
> - unsigned int cpu;
> - int ret;
> -
> - /* Try for same CPU (cheapest) */
> - cpu = get_cpu();
> - if (!cpumask_test_cpu(cpu, mask))
> - cpu = sched_numa_find_nth_cpu(mask, 0, cpu_to_node(cpu));
> -
> - ret = smp_call_function_single(cpu, func, info, wait);
> - put_cpu();
> - return ret;
> + return __smp_call_function_single(-1, func, info, mask, wait);
> }
> EXPORT_SYMBOL_GPL(smp_call_function_any);
>
> +static DEFINE_STATIC_KEY_FALSE(ipi_mask_inlined);
> +
> +#ifdef CONFIG_PREEMPTION
> +
> +int smp_task_ipi_mask_alloc(struct task_struct *task)
> +{
> + if (static_branch_unlikely(&ipi_mask_inlined))
> + return 0;
> +
> + ACCESS_PRIVATE(task, ipi_mask).ipi_mask_ptr =
> + kmalloc(cpumask_size(), GFP_KERNEL);
> + if (!ACCESS_PRIVATE(task, ipi_mask).ipi_mask_ptr)
> + return -ENOMEM;
> +
> + return 0;
> +}
> +
> +void smp_task_ipi_mask_free(struct task_struct *task)
> +{
> + if (static_branch_unlikely(&ipi_mask_inlined))
> + return;
> +
> + kfree(ACCESS_PRIVATE(task, ipi_mask).ipi_mask_ptr);
> +}
> +
> +static cpumask_t *smp_task_ipi_mask(struct task_struct *cur)
> +{
> + /*
> + * If cpumask_size() is smaller than or equal to the pointer
> + * size, it stashes the cpumask in the pointer itself to
> + * avoid extra memory allocations.
> + */
> + if (static_branch_unlikely(&ipi_mask_inlined))
> + return (cpumask_t *)&ACCESS_PRIVATE(cur, ipi_mask).ipi_mask_val;
> +
> + return ACCESS_PRIVATE(cur, ipi_mask).ipi_mask_ptr;
> +}
> +#else
> +static cpumask_t *smp_task_ipi_mask(struct task_struct *cur)
> +{
> + return NULL;
> +}
> +#endif
> +
> /*
> * Flags to be used as scf_flags argument of smp_call_function_many_cond().
> *
> @@@ -891,20 -816,13 +891,20 @@@ static void smp_call_function_many_cond
> unsigned int scf_flags,
> smp_cond_func_t cond_func)
> {
> - int cpu, last_cpu, this_cpu = smp_processor_id();
> - struct call_function_data *cfd;
> + struct cpumask *cpumask, *task_mask;
> bool wait = scf_flags & SCF_WAIT;
> - int nr_cpus = 0;
> + struct call_function_data *cfd;
> + int cpu, last_cpu, this_cpu;
> bool run_remote = false;
> + int nr_cpus = 0;
>
> - lockdep_assert_preemption_disabled();
> + this_cpu = get_cpu();
> + cfd = this_cpu_ptr(&cfd_data);
> + task_mask = smp_task_ipi_mask(current);
> + if (task_mask)
> + cpumask = task_mask;
> + else
> + cpumask = cfd->cpumask;
>
> /*
> * Can deadlock when called with interrupts disabled.
> @@@ -926,15 -844,16 +926,15 @@@
>
> /* Check if we need remote execution, i.e., any CPU excluding this one. */
> if (cpumask_any_and_but(mask, cpu_online_mask, this_cpu) < nr_cpu_ids) {
> - cfd = this_cpu_ptr(&cfd_data);
> - cpumask_and(cfd->cpumask, mask, cpu_online_mask);
> - __cpumask_clear_cpu(this_cpu, cfd->cpumask);
> + cpumask_and(cpumask, mask, cpu_online_mask);
> + __cpumask_clear_cpu(this_cpu, cpumask);
>
> cpumask_clear(cfd->cpumask_ipi);
> - for_each_cpu(cpu, cfd->cpumask) {
> + for_each_cpu(cpu, cpumask) {
> call_single_data_t *csd = per_cpu_ptr(cfd->csd, cpu);
>
> if (cond_func && !cond_func(cpu, info)) {
> - __cpumask_clear_cpu(cpu, cfd->cpumask);
> + __cpumask_clear_cpu(cpu, cpumask);
> continue;
> }
>
> @@@ -984,18 -903,8 +984,18 @@@
> local_irq_restore(flags);
> }
>
> + /*
> + * The IPI work has been queued and dispatched. On PREEMPT kernels,
> + * tasks created through dup_task_struct() have task-local wait masks.
> + * The boot init_task can fall back to cfd->cpumask when the mask is
> + * not inlined, but other tasks still use task-local masks and cannot
> + * overwrite it. On !PREEMPT kernels, preempt_enable() cannot schedule
> + * another task, so the per-CPU mask remains protected.
> + */
> + put_cpu();
> +
> if (run_remote && wait) {
> - for_each_cpu(cpu, cfd->cpumask) {
> + for_each_cpu(cpu, cpumask) {
> call_single_data_t *csd;
>
> csd = per_cpu_ptr(cfd->csd, cpu);
> @@@ -1006,14 -915,15 +1006,14 @@@
>
> /**
> * smp_call_function_many() - Run a function on a set of CPUs.
> - * @mask: The set of cpus to run on (only runs on online subset).
> - * @func: The function to run. This must be fast and non-blocking.
> - * @info: An arbitrary pointer to pass to the function.
> - * @wait: If true, wait (atomically) until function has completed
> - * on other CPUs.
> + * @mask: The set of cpus to run on (only runs on online subset).
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @wait: If true, wait (atomically) until function has completed
> + * on other CPUs.
> *
> * You must not call this function with disabled interrupts or from a
> - * hardware interrupt handler or from a bottom half handler. Preemption
> - * must be disabled when calling this function.
> + * hardware interrupt handler or from a bottom half handler.
> *
> * @func is not called on the local CPU even if @mask contains it. Consider
> * using on_each_cpu_cond_mask() instead if this is not desirable.
> @@@ -1027,10 -937,10 +1027,10 @@@ EXPORT_SYMBOL(smp_call_function_many)
>
> /**
> * smp_call_function() - Run a function on all other CPUs.
> - * @func: The function to run. This must be fast and non-blocking.
> - * @info: An arbitrary pointer to pass to the function.
> - * @wait: If true, wait (atomically) until function has completed
> - * on other CPUs.
> + * @func: The function to run. This must be fast and non-blocking.
> + * @info: An arbitrary pointer to pass to the function.
> + * @wait: If true, wait (atomically) until function has completed
> + * on other CPUs.
> *
> * If @wait is true, then returns once @func has returned; otherwise
> * it returns just before the target cpu calls @func.
> @@@ -1040,8 -950,9 +1040,8 @@@
> */
> void smp_call_function(smp_call_func_t func, void *info, int wait)
> {
> - preempt_disable();
> - smp_call_function_many(cpu_online_mask, func, info, wait);
> - preempt_enable();
> + smp_call_function_many_cond(cpu_online_mask, func, info,
> + wait ? SCF_WAIT : 0, NULL);
> }
> EXPORT_SYMBOL(smp_call_function);
>
> @@@ -1107,9 -1018,6 +1107,9 @@@ EXPORT_SYMBOL(nr_cpu_ids)
> void __init setup_nr_cpu_ids(void)
> {
> set_nr_cpu_ids(find_last_bit(cpumask_bits(cpu_possible_mask), NR_CPUS) + 1);
> +
> + if (IS_ENABLED(CONFIG_PREEMPTION) && cpumask_size() <= sizeof(unsigned long))
> + static_branch_enable(&ipi_mask_inlined);
> }
>
> /* Called by boot processor to activate the rest. */
> @@@ -1146,14 -1054,12 +1146,14 @@@ void __init smp_init(void
> * @func: The function to run on all applicable CPUs.
> * This must be fast and non-blocking.
> * @info: An arbitrary pointer to pass to both functions.
> - * @wait: If true, wait (atomically) until function has
> - * completed on other CPUs.
> + * @wait: If true, wait until function has completed on other CPUs.
> * @mask: The set of cpus to run on (only runs on online subset).
> *
> - * Preemption is disabled to protect against CPUs going offline but not online.
> - * CPUs going online during the call will not be seen or sent an IPI.
> + * Target CPU selection and work queueing are done with preemption
> + * disabled. This protects against CPUs going offline, but not against
> + * CPUs coming online concurrently; newly online CPUs are not guaranteed
> + * to be seen or sent an IPI. If @wait is true, the final wait for remote
> + * completion happens after that preemption-disabled section.
> *
> * You must not call this function with disabled interrupts or
> * from a hardware interrupt handler or from a bottom half handler.
> @@@ -1166,7 -1072,9 +1166,7 @@@ void on_each_cpu_cond_mask(smp_cond_fun
> if (wait)
> scf_flags |= SCF_WAIT;
>
> - preempt_disable();
> smp_call_function_many_cond(mask, func, info, scf_flags, cond_func);
> - preempt_enable();
> }
> EXPORT_SYMBOL(on_each_cpu_cond_mask);
>
^ 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