* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-18 17:19 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Krzysztof Kozlowski, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
Miguel Ojeda, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <DIL2P8CHKVZD.2WVQQRN0FM28N@kernel.org>
> On May 17, 2026, at 8:56 AM, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Sat May 16, 2026 at 9:15 PM CEST, Roman Gushchin wrote:
>> I agree, it’s sometimes gets tricky when a patchset is sent to multiple
>> mailing lists, which policy to apply. I have some improvements in my plans,
>> but it’s not always possible to say how it should be handled.
>
> Which improvements do you have in mind?
If a patchset is sent to multiple mailing lists now Sashiko is using the superset of
email policies. But in many cases it’s possible to determine the “main” mailing list/subsystem
and prefer it’s configuration. Not always.
>
>> It’s not fundamentally new: landing changes touching multiple subsystems is
>> always harder exactly because maintainers might have different and sometimes
>> conflicting views.
>
> It can also be relevant in cases where only a single subsystem is touched.
>
> For instance, in the case of Rust, the rust-for-linux list serves two purposes
> -- when it is a Rust subsystem change and when Rust code of any other subsystem
> is touched, i.e. the rust-for-linux list has more of a LKML character and also
> receives patches for subsystems whose maintainers may not have opted in to
> sashiko email delivery.
>
> That said, I personally don't mind too much, I really like sashiko, which is
> also why I asked for adding the driver-core list. My experience has been that it
> does a very decent job in providing feedback for C code; my feeling is that
> feedback for Rust code is not quite on par yet, but of course it also highly
> depends on the complexity and scope of the corresponding changes.
This is super interesting. An obvious idea is that the training set is relatively limited,
if we’re talking rust for kernel code. Did you notice any common topics or patterns?
Does it produce more false positives or worse in finding actual bugs in comparison
to the c code?
> However, I still have the same concern I raised previously when it comes to
> email delivery: I think that when sashiko sends feedback to contributors
> (without Cc'ing the mailing list and all other recipients), it should actively
> ask the contributor to raise things on the list with all other recipients,
> reviewers and maintainers before acting on them, such that changes subsequent to
> the first submission on the list are aligned.
I personally think that it’s always better to cc some mailing list and/or maintainers,
so there is a second pair of eyes. I totally agree that replying just to the author is less effective.
Of course, we can add the text you’re proposing, but why not simply configure sashiko
to cc the mailing list?
Thanks!
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-18 17:24 UTC (permalink / raw)
To: Peter Zijlstra, Arnd Bergmann, Ethan Nelson-Moore, Dinh Nguyen
Cc: linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260518105735.GW3126523@noisy.programming.kicks-ass.net>
Hi Ethan, Arnd, Peter and Dinh,
On Mon, May 18, 2026 at 11:29:48AM +0200, Arnd Bergmann wrote:
> We last discussed this a year ago when Simon Schuster mentioned[1]
> that Siemens Energy is still using NIOS-2 in production and would
> prefer to have this still included in Linux for at least another
> few years until the obligation for kernel updates ends.
First off, thank you, Arnd, for remembering us as this patch series came
up and also to Dinh for his maintenance of the architecture!
Regarding our status in relation to nios2, Arnd's response already gives
you the gist:
We are well aware that the architecture was deprecated by Intel and are
therefore phasing it out in favour of more contemporary hardware.
I'm also fully aware of the uncertain future of 32-bit architectures as
a whole [0] and that this fate will come to nios2 sooner or later.
But as of now, the mainline support is still in very good shape.
On Mon, May 18, 2026 at 12:57:35PM +0200, Peter Zijlstra wrote:
> Isn't that what we have LTS branches for?
Unfortunately, as we are an infrastructure provider for civil energy
infrastructure, the refurbishment cycle is a bit slower than for
traditional consumer systems. This implies that the traditional LTS
support duration (max. Dec 2028 as of writing [1]) is rather short, and
we would be glad if we could keep the architecture in mainline for at
least 5 years and only then "decay" to LTS.
On Mon, May 18, 2026 at 11:29:48AM +0200, Arnd Bergmann wrote:
> My feeling is that the maintenance burden of keeping nios2 is
> relatively low. On the other hand, maintaining it out of tree
> as a patch set is also something that should not be all that
> hard if it does get removed.
Judging from the architecture's git history, it seems that it's
currently mainly touched by treewide refactors, which are extremely
helpful as we therefore do not have to piece these changes together
downstream. In other respects, we try to be good citizens and contribute
bugfixes as well as required cleanups (such as implementing clone3 [2]
and fixing its flag behaviour on 32-bit architectures) as they come up.
If desired, we also would be happy to intensify our support regarding
reviews or testing to share the maintnance burden if it helps to keep
nios2 in mainline a bit longer.
Best regards,
Simon
0: https://lwn.net/Articles/1035727/
1: https://www.kernel.org/category/releases.html
2: https://lore.kernel.org/lkml/20250821-nios2-implement-clone3-v1-0-1bb24017376a@siemens-energy.com/
^ permalink raw reply
* Re: Stop false review statements
From: Mauro Carvalho Chehab @ 2026-05-18 19:40 UTC (permalink / raw)
To: Theodore Tso
Cc: Jani Nikula, Roman Gushchin, Krzysztof Kozlowski, debarbos,
Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <20260518121601.GA87957@macsyma-wired.lan>
On Mon, 18 May 2026 08:16:01 -0400
"Theodore Tso" <tytso@mit.edu> wrote:
> On Mon, May 18, 2026 at 11:04:29AM +0300, Jani Nikula wrote:
> > > Sashiko is supporting various LLMs, including open models - it’s just a practical
> > > choice: to my knowledge the quality of open models is not on par with frontier closed
> > > models and it would require a non-trivial amount of hardware and infrastructure to run
> > > an open model at the required scale.
> >
> > In the context of the "Reviewed-by: Sashiko" discussion, this actually
> > makes it really hard to assess the quality of those reviews.
>
> Agreed. There's a reason why the coding-assistants.rst specifies the
> model which is used:
>
> Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> The problem is that (as Jon has pointed out) coding-assistants.rst was
> intended for use when the tool was beging used to help create the code
> --- that is, "Coding Assistants". What we're doing here is more of a
> reviewer assistance. Something like:
>
> Scanned-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> Would be more interesting, but it doesn't actually tell us anything
> about what the results were of the scan.
I don't like scanned-by, even for a tool that would always get the
same results like checkpatch. For LLM, this is even worse, as two runs
may give different results for the same code.
IMO what makes much more sense is to add information there when
a change was done due avoid a problem detected by sashiko, and what
was the fixed issue, e.g. a textual description like:
Changed locking schema after Sashiko's report report about
XXX race condition.
Also, except if 100% of the
> One of the problems here is that there is a distinction between the
> infrastructure and review prompts in the Sashiko github repository,
> and the reviews that are being published by Sashiko the web service
> being run by Google that is being lost by some folks. So I wonder if
> for now, we should just do something like:
>
> Link: https://sashiko.dev/#/patchset/20260515091829.194810-1-me%40linux.beauty
Adding a link makes sense to me. It doesn't need to be to the
sashiko's email though: it can be to the entire thread.
> Or just have a link to lore where the review has responded to the
> Sashiko review stating where the Sashiko review reported a
> pre-existing condition (perhaps one that we don't care about because
> races in readahead logic is really Not A Big Deal, etc.) We go for
> this strategy, it would actually be better for the Shashiko.dev review
> to get cc'ed to the mailing list.
>
> Personally, I think that's probably be best way to go. We already
> don't insert into the git commit an explanation of why some bullsh*t
> review by some wannabe human reviewer should be ignored, or why a
> discussion of some problem discovered by a human review in the source
> of the review would be handled in a future patch set. That's what the
> discussion on lore.kernel.org is for. And we shouldn't treat AI
> reviews any different from how we deal with human reviews. So if we
> want to give credit to an AI review, then let's go with the
> Scanned-by.
If the entire content of a Sashiko review is ignored, I don't think
it is worth adding anything. Just like we do with humans, IMO the
best is to just mention what changed due to some feedback received
by a human or by a bot, mentioning who/what bot helped to identify
the issue.
> Or we can just let people look at the mailing list, and
> if people want to have statistics, we can ask people to use a script
> running against public inbox to figure things out.
>
> - Ted
>
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Wolfram Sang @ 2026-05-18 20:46 UTC (permalink / raw)
To: Simon Schuster
Cc: Peter Zijlstra, Arnd Bergmann, Ethan Nelson-Moore, Dinh Nguyen,
linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260518172444.zyd47mcagrcwu7wt@dev-vm-schuster>
Hi Simon,
> downstream. In other respects, we try to be good citizens and contribute
> bugfixes as well as required cleanups (such as implementing clone3 [2]
> and fixing its flag behaviour on 32-bit architectures) as they come up.
Well, this is definitely 'good citizen'...
> If desired, we also would be happy to intensify our support regarding
> reviews or testing to share the maintnance burden if it helps to keep
> nios2 in mainline a bit longer.
... but given this, you might want to get added in MAINTAINERS as
reviewer (or even maintainer) for nios2? Besides that your efforts are
already worth it in my book, it would also ensure you get CCed on
patches like this. Then, you are not depending on people like Arnd
putting you in the loop manually.
Happy hacking,
Wolfram
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Ethan Nelson-Moore @ 2026-05-19 0:13 UTC (permalink / raw)
To: Simon Schuster
Cc: Peter Zijlstra, Arnd Bergmann, Dinh Nguyen, linux-doc, devicetree,
workflows, Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev,
linux-pci, linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <20260518172444.zyd47mcagrcwu7wt@dev-vm-schuster>
Hi, Simon,
Thank you for notifying us of your continued use of the Nios II architecture.
On Mon, May 18, 2026 at 10:24 AM Simon Schuster
<schuster.simon@siemens-energy.com> wrote:
> Unfortunately, as we are an infrastructure provider for civil energy
> infrastructure, the refurbishment cycle is a bit slower than for
> traditional consumer systems. This implies that the traditional LTS
> support duration (max. Dec 2028 as of writing [1]) is rather short, and
> we would be glad if we could keep the architecture in mainline for at
> least 5 years and only then "decay" to LTS.
Your reasoning makes complete sense. However, there is an alternative
to maintaining the architecture in mainline.
The Civil Infrastructure Platform project maintains super-LTS kernels
(and a set of base Debian packages) for 10 years. They are intended to
be used for exactly these kinds of devices.
See here: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership
and here: https://cip-project.org/about/linux-kernel-core-packages
CIP will maintain kernel 6.12 until 2035. Is this long enough for your
lifecycle? What kernel are you currently using? If it's newer than
6.12, we can easily wait until the next CIP SLTS release to remove
Nios II support to avoid a downgrade.
One important thing to note is that the default CIP kernel branches
are not equivalent to standard LTS branches and include new hardware
support, which has a higher likelihood of introducing regressions.
However, the -st branches do not include these changes and follow the
same patch acceptance rules as standard LTS, so they are likely a
better fit for your use case.
Also, CIP focuses on architectures used by CIP members - currently I
think they are x86 (32 and 64-bit), ARM (32 and 64-bit) and RISC-V.
Since Siemens is already a CIP member, you can simply ask them to add
Nios II to the list, and you can assist them with testing and directly
submit patches to them once the standard 6.12 LTS period ends.
I hope this information helps you decide on the best course of action.
Ethan
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: David Laight @ 2026-05-19 8:48 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, devicetree, workflows, linux-arch, dmaengine,
linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260518042833.272221-1-enelsonmoore@gmail.com>
On Sun, 17 May 2026 21:28:33 -0700
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> The Nios II architecture is a soft-core architecture developed by
> Altera (since acquired by Intel) and intended to run on their FPGAs.
>
> Licenses for the architecture have not been available for purchase
> since 2024 [1],
Except I think they got 'beaten up' by some telcos.
The Nios II gets used inside fpga for small cpu doing things that it would
be far to difficult to do in VHDL.
(I believe some mobile base stations fgpa embed a lot of them.)
These will have a small amount of code (maybe 4k - 64k) and a similarly
small amount of data memory along with access to fpga peripheral registers
and (optionally) host memory vie PCIe. No MMU, no cache (or rather the code/data
is in the cache memory but it isn't backed by anything), no branch predictor
(guaranteed cycle times), etc.
Intel suggested that RISCV could be used instead, but it isn't the same beast.
They didn't document the instruction timings nor how to add custom instructions.
The company I used to work for used 4 NIOS II inside an fpga.
The instruction timing for one is pretty critical, it has some code that
has to complete in 122 clocks (worst case).
Our solution was to spend a few man-weeks writing a compatible cpu!
I think it came out with fewer pipeline stalls (in particular it 'lost'
the one for a (predicted) taken branch).
The maximum clock frequency might be lower; but it is ok at 62.5MHz and the
higher 125MHz in just impossible for all sorts of reasons.
OTOH I really wouldn't run Linux on it!
-- David
> and support for it has been removed from GCC 15 [2],
> Buildroot [3], and QEMU [4].
>
> Given all of these factors, it is time to remove Nios II support from
> the kernel. The maintainer stated in 2024 that they were planning to do
> so soon [5], but this did not come to pass.
>
> Remove Nios II support from the kernel and move the former maintainer
> to CREDITS. Thank you, Dinh Nguyen, for maintaining Nios II support!
>
> References:
> [1] https://docs.altera.com/v/u/docs/781327/is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip
> [2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e876acab6cdd84bb2b32c98fc69fb0ba29c81153
> [3] https://github.com/buildroot/buildroot/commit/6775ccc5a199d574ad70b5f79ec58cce97a07c6f
> [4] https://github.com/qemu/qemu/commit/6c3014858c4c0024dd0560f08a6eda0f92f658d6
> [5] https://sourceware.org/pipermail/newlib/2024/021083.html
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Geert Uytterhoeven @ 2026-05-19 9:43 UTC (permalink / raw)
To: David Laight
Cc: Ethan Nelson-Moore, linux-doc, devicetree, workflows, linux-arch,
dmaengine, linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260519094820.1f05ab8e@pumpkin>
Hi David,
On Tue, 19 May 2026 at 10:55, David Laight <david.laight.linux@gmail.com> wrote:
> The company I used to work for used 4 NIOS II inside an fpga.
> The instruction timing for one is pretty critical, it has some code that
> has to complete in 122 clocks (worst case).
> Our solution was to spend a few man-weeks writing a compatible cpu!
> I think it came out with fewer pipeline stalls (in particular it 'lost'
> the one for a (predicted) taken branch).
> The maximum clock frequency might be lower; but it is ok at 62.5MHz and the
> higher 125MHz in just impossible for all sorts of reasons.
>
> OTOH I really wouldn't run Linux on it!
Sounds similar to what CoreSemi is doing with J2 (nommu, also for
predictable latency), but their products do run Linux.
See the video from the LPC session at
https://lpc.events/event/19/contributions/2097/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-19 10:30 UTC (permalink / raw)
To: Ethan Nelson-Moore, Wolfram Sang
Cc: Peter Zijlstra, Arnd Bergmann, Dinh Nguyen, linux-doc, devicetree,
workflows, Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev,
linux-pci, linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <CADkSEUjhq6HSdg4ignzbuJiN5uXATsTdxFbRJ3BMxs5=WUWLDg@mail.gmail.com>
Hi Ethan, hi Wolfram,
Thank you for your thoughtful responses.
On Mon, May 18, 2026 at 05:13:58PM -0700, Ethan Nelson-Moore wrote:
> Your reasoning makes complete sense. However, there is an alternative
> to maintaining the architecture in mainline.
>
> The Civil Infrastructure Platform project maintains super-LTS kernels
> (and a set of base Debian packages) for 10 years. They are intended to
> be used for exactly these kinds of devices.
> See here: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start#kernel_maintainership
> and here: https://cip-project.org/about/linux-kernel-core-packages
>
> CIP will maintain kernel 6.12 until 2035. Is this long enough for your
> lifecycle? What kernel are you currently using? If it's newer than
> 6.12, we can easily wait until the next CIP SLTS release to remove
> Nios II support to avoid a downgrade.
This depends. For released/maintained firmware revisions we already
track CIP SLTS versions (candidates) to be prepared, the majority of which
is currently still running 6.1.x with 6.12.x up-and-coming.
But for the reasons outlined by you regarding architectural and feature
support in CIP SLTS, we do not, however, use the extended support duration
SLTS releases in production, and instead upgrade with the kernel.org LTS
branch release schedule and track these internally alongside mainline
to prevent major obstacles during version jumps.
2035 is still a rather tight timeframe for our typical support/phase-out
period (we would hope to get close to 2040 with the SLTS extensions),
which is also the reason for our targeted 'lifetime extension' for the
nios2 architecture for approximately 5 years, or more precisely ~2-3
SLTS kernels assuming the usual cadence of 2 years between SLTS versions
(+ some safety margin).
> Also, CIP focuses on architectures used by CIP members - currently I
> think they are x86 (32 and 64-bit), ARM (32 and 64-bit) and RISC-V.
> Since Siemens is already a CIP member, you can simply ask them to add
> Nios II to the list, and you can assist them with testing and directly
> submit patches to them once the standard 6.12 LTS period ends.
We have already been in contact with the CIP team (even though the
contact has unfortunately lapsed a bit, mostly our fault), but adding an
additional architecture seemed to be a more substantial effort.
N.B.: Due to past circumstances, we are a completely distinct business
entity from Siemens AG that merely shares the trademark and a common
history; but of course this should not hinder us from getting directly
involved in CIP (quite the opposite!). But this also requires some setup
time.
On Mon, May 18, 2026 at 10:46:55PM +0200, Wolfram Sang wrote:
> > If desired, we also would be happy to intensify our support regarding
> > reviews or testing to share the maintnance burden if it helps to keep
> > nios2 in mainline a bit longer.
>
> ... but given this, you might want to get added in MAINTAINERS as
> reviewer (or even maintainer) for nios2? Besides that your efforts are
> already worth it in my book, it would also ensure you get CCed on
> patches like this. Then, you are not depending on people like Arnd
> putting you in the loop manually.
Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
unsure about the netiquette (can I simply do so by self-proclamation? At
least the git history seems to suggest so...).
Best regards,
Simon
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Wolfram Sang @ 2026-05-19 10:55 UTC (permalink / raw)
To: Simon Schuster
Cc: Ethan Nelson-Moore, Peter Zijlstra, Arnd Bergmann, Dinh Nguyen,
linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster>
Hi Simon,
> > ... but given this, you might want to get added in MAINTAINERS as
> > reviewer (or even maintainer) for nios2? Besides that your efforts are
> > already worth it in my book, it would also ensure you get CCed on
> > patches like this. Then, you are not depending on people like Arnd
> > putting you in the loop manually.
>
> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> unsure about the netiquette (can I simply do so by self-proclamation? At
> least the git history seems to suggest so...).
In your case, you can do so, I'd say. You explained your very reasonable
interest in the architecture and have already shown efforts to keep it,
as we can see from the git history. The final call will be done by Dinh
Nguyen obviously with whom you probably need to sort out details. But I
can't imagine your offer for help will be rejected, quite the contrary.
Happy hacking,
Wolfram
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Miguel Ojeda @ 2026-05-19 11:07 UTC (permalink / raw)
To: Simon Schuster
Cc: Ethan Nelson-Moore, Wolfram Sang, Peter Zijlstra, Arnd Bergmann,
Dinh Nguyen, linux-doc, devicetree, workflows, Linux-Arch,
dmaengine, linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster>
On Tue, May 19, 2026 at 12:41 PM Simon Schuster
<schuster.simon@siemens-energy.com> wrote:
>
> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> unsure about the netiquette (can I simply do so by self-proclamation? At
> least the git history seems to suggest so...).
Up to the existing maintainer, in general.
I would also suggest changing the support level to "Supported",
instead of "Maintained" -- that would help justify keeping it in
mainline.
I hope that helps a bit...
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Dinh Nguyen @ 2026-05-19 11:40 UTC (permalink / raw)
To: Wolfram Sang, Simon Schuster
Cc: Ethan Nelson-Moore, Peter Zijlstra, Arnd Bergmann, linux-doc,
devicetree, workflows, Linux-Arch, dmaengine, linux-i2c,
linux-iio, Netdev, linux-pci, linux-pwm, linux-hardening,
linux-kbuild, linux-csky@vger.kernel.org, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov, Will Deacon,
Aneesh Kumar K.V (Arm), Andrew Morton, Nicholas Piggin,
Vinod Koul, Frank Li, Dave Penkler, Andi Shyti, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lorenzo Pieralisi, Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <agxBqd-ubOL2_i-j@shikoro>
Hi Simon,
On 5/19/26 05:55, Wolfram Sang wrote:
> Hi Simon,
>
>>> ... but given this, you might want to get added in MAINTAINERS as
>>> reviewer (or even maintainer) for nios2? Besides that your efforts are
>>> already worth it in my book, it would also ensure you get CCed on
>>> patches like this. Then, you are not depending on people like Arnd
>>> putting you in the loop manually.
>>
>> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
>> unsure about the netiquette (can I simply do so by self-proclamation? At
>> least the git history seems to suggest so...).
>
> In your case, you can do so, I'd say. You explained your very reasonable
> interest in the architecture and have already shown efforts to keep it,
> as we can see from the git history. The final call will be done by Dinh
> Nguyen obviously with whom you probably need to sort out details. But I
> can't imagine your offer for help will be rejected, quite the contrary.
>
I 100% support adding you as a maintainer. Please send a patch.
Thanks,
Dinh
^ permalink raw reply
* Re: Stop false review statements
From: Danilo Krummrich @ 2026-05-19 12:23 UTC (permalink / raw)
To: Roman Gushchin
Cc: Krzysztof Kozlowski, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
Miguel Ojeda, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <C16C14F1-4D2F-4701-88CC-114F5233980D@linux.dev>
On Mon May 18, 2026 at 7:19 PM CEST, Roman Gushchin wrote:
>
>> On May 17, 2026, at 8:56 AM, Danilo Krummrich <dakr@kernel.org> wrote:
>> That said, I personally don't mind too much, I really like sashiko, which is
>> also why I asked for adding the driver-core list. My experience has been that it
>> does a very decent job in providing feedback for C code; my feeling is that
>> feedback for Rust code is not quite on par yet, but of course it also highly
>> depends on the complexity and scope of the corresponding changes.
>
> This is super interesting. An obvious idea is that the training set is
> relatively limited, if we’re talking rust for kernel code. Did you notice any
> common topics or patterns?
My experience is - and that's probably not surprising as it may tie back to the
relatively limited training set you mention above - that it sometimes loses
context at the FFI boundary, where it has to consider the semantics of the C and
the Rust APIs.
I think the difficult part is not necessarily that there is a language boundary
by itself, but rather that it can be difficult for LLMs to capture the semantic
layer that a Rust API puts on top of a C API in order to derive a safe API.
This also has been my experience in other LLM contexts; the most significant
improvements I saw in output quality have been by providing more semantic
context for the abstraction design.
Probably easy to look up, but does Sashiko consider cover letters already?
> Does it produce more false positives or worse in finding actual bugs in
> comparison to the c code?
I'd say both, and I think the reason is probably the same for both. But to be
fair, this is probably also biased by the class of changes I deal with on the C
and on the Rust side too.
It is also fair to say that in Rust we (almost) don't have whole classes of bugs
that we have on the C side; and the class of memory safety issues makes a huge
proportion of bugs on the C side.
If the model is particularly good at finding memory safety issues (and I think
it is), it of course also messes with the statistics of false positives
comparing C with Rust.
> I personally think that it’s always better to cc some mailing list and/or
> maintainers, so there is a second pair of eyes. I totally agree that replying
> just to the author is less effective. Of course, we can add the text you’re
> proposing, but why not simply configure sashiko to cc the mailing list?
I'm not sure it addresses much of this concern, as I prefer to keep everyone the
patch (series) has been sent to explicitly in the loop.
Of course everyone has a different workflow, but I think it is fair to assume
that most people who are addressed directly follow along through their inbox and
not through the mailing list.
So, I think the real alternative is "reply all", which for multiple reasons I'm
not convinced is the right general call to make yet.
(I do consider it for one of the components I maintain though.)
Thanks,
Danilo
^ permalink raw reply
* Re: [PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat
From: Manuel Ebner @ 2026-05-19 14:10 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
In-Reply-To: <20260514160719.105084-3-manuelebner@mailbox.org>
Hello
i'll ditch this series - it's just not the time yet.
Manuel
On Thu, 2026-05-14 at 18:07 +0200, Manuel Ebner wrote:
> Thanks for all the feedback. I tried to incorporate it in this version.
>
> The goal of this series is to facilitate the transition away from strlcat()
>
> [v2]
> add recipants
> add remarks to strlcat definition in
> lib/string.c
> tools/include/nolibc/string.h
> -> [3/3]
>
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Arnd Bergmann @ 2026-05-20 7:06 UTC (permalink / raw)
To: schuster.simon@siemens-energy.com, Ethan Nelson-Moore,
Wolfram Sang
Cc: Peter Zijlstra, Dinh Nguyen, linux-doc, devicetree, workflows,
Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev, linux-pci,
linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof Wilczyński, Andreas Oetken
In-Reply-To: <20260519103012.blot4bssgiqfer6p@dev-vm-schuster>
On Tue, May 19, 2026, at 12:30, Simon Schuster wrote:
> On Mon, May 18, 2026 at 05:13:58PM -0700, Ethan Nelson-Moore wrote:
>
> 2035 is still a rather tight timeframe for our typical support/phase-out
> period (we would hope to get close to 2040 with the SLTS extensions),
> which is also the reason for our targeted 'lifetime extension' for the
> nios2 architecture for approximately 5 years, or more precisely ~2-3
> SLTS kernels assuming the usual cadence of 2 years between SLTS versions
> (+ some safety margin).
I think that is a reasonable target. We have a bunch of embedded
architectures that have a similarly small user base and I expect
that we will want to remove most of them at some point, as we did
for seven architectures in linux-4.17.
As long as there is a maintainer for nios2 and it's not actively
getting in the way of a specific treewide change, I don't see any
reason to remove this any earlier than the other ones.
Obviously at some point nios2 will have to get removed because
of the limit to gcc-14 or older, but that should not be a problem
for the next few LTS releases.
> Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> unsure about the netiquette (can I simply do so by self-proclamation? At
> least the git history seems to suggest so...).
Dinh already replied that he welcomes the help, and I also suggested
the same thing a year ago. As the only known user that has contributed
patches in a long time, you are obviously qualified.
Sending a patch for the MAINTAINERS file to Dinh is the first step,
once he has sent that upstream, you can (optionally) apply for
kernel.org account that would let you host a git tree on kernel.org
or have a tree that you both have access to.
Arnd
^ permalink raw reply
* [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Willy Tarreau, Greg KH, Leon Romanovsky, Jonathan Corbet,
Sasha Levin, security, workflows, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Willy Tarreau <w@1wt.eu>
[ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.
Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260509094755.2838-2-w@1wt.eu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `Documentation/process/security-bugs`; action verb
`do not`; intent is to update security bug reporting instructions so
reporters do not always Cc the security team.
Record 1.2: Tags present: `Cc: Greg KH <gregkh@linuxfoundation.org>`,
`Cc: Leon Romanovsky <leon@kernel.org>`, `Reviewed-by: Leon Romanovsky
<leon@kernel.org>`, `Reviewed-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>`, `Signed-off-by: Willy Tarreau
<w@1wt.eu>`, `Signed-off-by: Jonathan Corbet <corbet@lwn.net>`,
`Message-ID: <20260509094755.2838-2-w@1wt.eu>`. No `Fixes:`, no
`Reported-by:`, no `Tested-by:`, no `Cc: stable`.
Record 1.3: The body describes a process/documentation problem:
increased automated reports create more mail to the security team than
needed. Symptom is excess security-team involvement, not a kernel
runtime crash or data corruption. No affected kernel versions are named.
Record 1.4: This is not a hidden code bug fix. It is an explicit
documentation/process update that corrects now-overbroad guidance.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/process/security-bugs.rst`,
9 insertions and 1 deletion in the submitted patch. No functions are
modified. Scope is single-file documentation-only.
Record 2.2: Before: reports “must” be sent to maintainers with the
security team in Cc. After: reports still go to maintainers, but
security-team Cc is mandatory only for two-or-fewer recipients, advised
for early reports or specific help, and no longer necessary for
comfortable reporters sending to large teams.
Record 2.3: Bug category is documentation/process correctness. No
resource leak, race, memory safety, refcount, initialization, endian, or
hardware quirk mechanism exists.
Record 2.4: Fix quality is high for its scope: small, reviewed,
documentation-only, no runtime behavior. Regression risk is limited to
possibly changing reporter behavior; no kernel runtime regression is
possible from the diff itself.
## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the replaced sentence was introduced by
`a72b832a482372` (“Documentation: explain how to find maintainers
addresses for security reports”), first contained by `v7.0-rc7~8^2~2`.
Record 3.2: No `Fixes:` tag is present, so there is no Fixes target to
follow.
Record 3.3: Recent history of `Documentation/process/security-bugs.rst`
shows a series of security-reporting documentation updates by Willy
Tarreau, including contact/process clarifications and typo fixes. This
patch is standalone at the diff level but part of a three-patch
documentation series.
Record 3.4: The author has multiple recent commits in
`Documentation/process/security-bugs.rst`. Maintainer lookup identifies
`Security Officers <security@kernel.org>` and `Jonathan Corbet
<corbet@lwn.net>` for this file.
Record 3.5: No code dependencies or functions exist. The exact patch
depends on the newer rewritten security-bugs document layout present in
`7.0.y`; older stable branches do not contain `a72b832a482372`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c` could not be used because no candidate commit
SHA was available locally or in the prompt, and local `master`, `docs-
next`, and `all-next` searches did not find the commit object. Using the
supplied Message-ID, `b4 am` found the original submission at
`https://patch.msgid.link/20260509094755.2838-1-w@1wt.eu`.
Record 4.2: `b4 am` and the mbox show v3 of a 3-patch series, 33 thread
messages, sent to Greg KH, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
`security@kernel.org`, `workflows@vger.kernel.org`, `linux-
doc@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.
Record 4.3: No bug report link, syzbot report, Bugzilla report, or user
crash report exists. Lore WebFetch was blocked by Anubis, but `b4`
successfully fetched the mbox.
Record 4.4: Series context: patch 1/3 is this Cc guidance change; patch
2/3 adds security-bug/threat-model documentation; patch 3/3 clarifies
AI-assisted reports. Cover letter says v2 reworded the “when to Cc” part
based on Greg’s feedback; v3 included wording/structure feedback and
added reviews.
Record 4.5: I found no stable-specific discussion or stable nomination
in the fetched thread. Jonathan Corbet said he applied the series to
`docs-fixes` after short linux-next exposure.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation only.
Record 5.2: No callers; affected audience is readers of
`Documentation/process/security-bugs.rst`.
Record 5.3: No callees or side effects.
Record 5.4: Reachability is not runtime reachability. The path is
“reporter reads stable-tree documentation and follows reporting
instructions.”
Record 5.5: `rg` found the old mandatory-Cc sentence only in
`Documentation/process/security-bugs.rst`; related security-team
references remain elsewhere in the same document.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Record 6.1: `a72b832a482372` is an ancestor of `stable/linux-7.0.y` but
not of local `stable/linux-5.15.y`, `stable/linux-6.1.y`,
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, or
`stable/linux-6.19.y`. So this exact buggy/obsolete sentence is
confirmed in `7.0.y`; older local stable trees have older document
layouts.
Record 6.2: `b4` reports the series base applies cleanly to the current
tree, which is `stable/linux-7.0.y`. Older stable trees would need a
different documentation backport if maintainers wanted equivalent
guidance there.
Record 6.3: No related stable fix for this exact wording was found in
local history.
## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is documentation/process, specifically security
bug reporting. Criticality is process-important, not runtime
core/driver/filesystem criticality.
Record 7.2: The file has active recent development, with several
2025-2026 security-reporting documentation updates.
## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population is documentation readers: security bug
reporters, maintainers, and the kernel security team. No running kernel
users are directly affected.
Record 8.2: Trigger is following the stable tree’s security-bug
reporting documentation. This can be done by any reporter, but it is not
a syscall or kernel execution path.
Record 8.3: Failure mode severity is low for runtime stability, but
medium for security-process efficiency: the old wording can
unnecessarily add the private security team to large-team reports.
Record 8.4: Benefit is moderate for keeping security reporting guidance
current and reducing unnecessary private-list traffic. Risk is very low
because the patch is documentation-only and reviewed.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: documentation-only; zero runtime
regression risk; corrects overbroad/obsolete reporting guidance;
reviewed by Leon Romanovsky and Greg Kroah-Hartman; applied by
documentation maintainer Jonathan Corbet; relevant to security reporting
workflow; clean for `7.0.y`.
Evidence against: it does not fix a kernel runtime bug, crash, security
vulnerability, corruption, or deadlock; older stable trees do not
contain the exact rewritten section, so this exact patch is mainly
applicable to `7.0.y`.
Unresolved: I could not run `b4 dig -c` without a commit SHA, and
WebFetch of lore was blocked by Anubis. The `b4` Message-ID fetch
supplied the needed thread content.
Record 9.2: Stable rules: obviously correct and reviewed: yes. Fixes
real user-visible runtime bug: no. Important
crash/security/corruption/deadlock: no. Small and contained: yes, one
documentation file. No new feature/API: yes. Applies to stable: yes for
`7.0.y`; older branches need separate handling.
Record 9.3: Exception category: documentation fix/update. This is the
reason it qualifies despite not being a runtime bug.
Record 9.4: Decision: backport where the affected documentation exists,
especially `7.0.y`. The runtime benefit is nonexistent, but the risk is
also nonexistent, and stable policy exceptions allow documentation fixes
that correct obsolete guidance.
## Verification
- Phase 1: Parsed supplied commit tags and b4 patch headers; confirmed
no `Fixes:`, `Reported-by:`, `Tested-by`, or `Cc: stable`.
- Phase 2: Read supplied diff and b4 patch; confirmed one documentation
file, 9 insertions/1 deletion, no code.
- Phase 3: Ran `git blame -L 148,152 -- Documentation/process/security-
bugs.rst`; old sentence introduced by `a72b832a482372`.
- Phase 3: Ran `git describe --contains a72b832a482372`; first contained
around `v7.0-rc7~8^2~2`.
- Phase 3: Ran file and author history commands; confirmed recent
related docs updates by Willy Tarreau.
- Phase 4: Local `git log` searches on current history, `master`, `docs-
next`, and `all-next` did not find the candidate commit object.
- Phase 4: `b4 am -o /tmp/security-bugs-b4
20260509094755.2838-2-w@1wt.eu` found a v3 3-patch series, 33
messages, and reported clean apply to current tree.
- Phase 4: `b4 mbox` saved the thread mbox; `rg` found no stable
nomination or NAK for this patch.
- Phase 4: WebFetch of lore URLs was blocked by Anubis; not used for the
final decision.
- Phase 5: `rg` over `Documentation` confirmed the exact mandatory-Cc
sentence appears in `Documentation/process/security-bugs.rst`.
- Phase 6: `git merge-base --is-ancestor a72b832a482372
stable/linux-7.0.y` returned true; checks for `5.15.y`, `6.1.y`,
`6.6.y`, `6.12.y`, `6.18.y`, and `6.19.y` returned false.
- Phase 7: `./scripts/get_maintainer.pl` identified Security Officers
and Jonathan Corbet for the file; `MAINTAINERS` confirms
`DOCUMENTATION PROCESS`, `SECURITY CONTACT`, and `STABLE BRANCH`
entries.
- Phase 8: Failure mode verified from commit text and diff only:
documentation/process burden, not runtime failure.
**YES**
Documentation/process/security-bugs.rst | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers. If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with. For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team
From: Jonathan Corbet @ 2026-05-20 13:07 UTC (permalink / raw)
To: Sasha Levin, patches, stable
Cc: Willy Tarreau, Greg KH, Leon Romanovsky, Sasha Levin, security,
workflows, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-63-sashal@kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> From: Willy Tarreau <w@1wt.eu>
>
> [ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
>
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.
You'll want, at a minimum, f2e65e4e5b4b4b9ecf43f03c3fdbe8c9a8a43a9e to
go with this, or you'll add a broken reference with this commit.
Thanks,
jon
^ permalink raw reply
* [PATCH v2] docs: submitting-patches: Clarify that "reviewer" is a person
From: Krzysztof Kozlowski @ 2026-05-20 15:48 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Greg Kroah-Hartman, Vlastimil Babka,
Andrew Morton, David Hildenbrand, Linus Torvalds, Randy Dunlap,
Mark Brown
Common understanding of word "Reviewer" is: a person performing a review
work [1]. Tools are not persons, thus cannot be reviewers in this term.
Also tools cannot make statements and cannot take responsibility for the
review.
Our docs already clearly mark that "Reviewed-by" must come from a
person:
- "By offering my Reviewed-by: tag, I state that:"
Usage of first person "I" and word "state"
- "A Reviewed-by tag is *a statement of opinion* that the patch is an
appropriate modification of the kernel without any remaining serious"
Only a person can make a statement of opinion.
- "Any interested reviewer (who has done the work) can offer a
Reviewed-by"
A person can offer a tag thus above does not grant the tool
permission to offer a tag.
However this might not be enough, so let's clarify that only a person
with a known identity can state the "Reviewer's statement of oversight".
Link: https://en.wiktionary.org/wiki/reviewer [1]
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Add tags
2. Rephrase/simplify a bit commit msg. Rephrase title - drop "in
English".
3. Add "with known identity", suggested by David Hildenbrand. I retained
previous tags, assuming this change is within spirit of previous
version and there were no objections on the list.
---
Documentation/process/submitting-patches.rst | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index d7290e208e72..cc6a1f73d7f2 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -581,12 +581,12 @@ By offering my Reviewed-by: tag, I state that:
A Reviewed-by tag is a statement of opinion that the patch is an
appropriate modification of the kernel without any remaining serious
-technical issues. Any interested reviewer (who has done the work) can
-offer a Reviewed-by tag for a patch. This tag serves to give credit to
-reviewers and to inform maintainers of the degree of review which has been
-done on the patch. Reviewed-by: tags, when supplied by reviewers known to
-understand the subject area and to perform thorough reviews, will normally
-increase the likelihood of your patch getting into the kernel.
+technical issues. Any interested reviewer (who has done the work and is a
+person with known identity) can offer a Reviewed-by tag for a patch. This tag
+serves to give credit to reviewers and to inform maintainers of the degree of
+review which has been done on the patch. Reviewed-by: tags, when supplied by
+reviewers known to understand the subject area and to perform thorough reviews,
+will normally increase the likelihood of your patch getting into the kernel.
Both Tested-by and Reviewed-by tags, once received on mailing list from tester
or reviewer, should be added by author to the applicable patches when sending
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] docs: submitting-patches: Clarify that "reviewer" is a person
From: Mauro Carvalho Chehab @ 2026-05-21 5:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel,
Greg Kroah-Hartman, Vlastimil Babka, Andrew Morton,
David Hildenbrand, Linus Torvalds, Randy Dunlap, Mark Brown
In-Reply-To: <20260520154846.162170-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, 20 May 2026 17:48:47 +0200
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> wrote:
> Common understanding of word "Reviewer" is: a person performing a review
> work [1]. Tools are not persons, thus cannot be reviewers in this term.
> Also tools cannot make statements and cannot take responsibility for the
> review.
>
> Our docs already clearly mark that "Reviewed-by" must come from a
> person:
>
> - "By offering my Reviewed-by: tag, I state that:"
>
> Usage of first person "I" and word "state"
>
> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
> appropriate modification of the kernel without any remaining serious"
>
> Only a person can make a statement of opinion.
>
> - "Any interested reviewer (who has done the work) can offer a
> Reviewed-by"
>
> A person can offer a tag thus above does not grant the tool
> permission to offer a tag.
>
> However this might not be enough, so let's clarify that only a person
> with a known identity can state the "Reviewer's statement of oversight".
>
> Link: https://en.wiktionary.org/wiki/reviewer [1]
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Makes sense to me.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
>
> Changes in v2:
> 1. Add tags
> 2. Rephrase/simplify a bit commit msg. Rephrase title - drop "in
> English".
> 3. Add "with known identity", suggested by David Hildenbrand. I retained
> previous tags, assuming this change is within spirit of previous
> version and there were no objections on the list.
> ---
> Documentation/process/submitting-patches.rst | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index d7290e208e72..cc6a1f73d7f2 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -581,12 +581,12 @@ By offering my Reviewed-by: tag, I state that:
>
> A Reviewed-by tag is a statement of opinion that the patch is an
> appropriate modification of the kernel without any remaining serious
> -technical issues. Any interested reviewer (who has done the work) can
> -offer a Reviewed-by tag for a patch. This tag serves to give credit to
> -reviewers and to inform maintainers of the degree of review which has been
> -done on the patch. Reviewed-by: tags, when supplied by reviewers known to
> -understand the subject area and to perform thorough reviews, will normally
> -increase the likelihood of your patch getting into the kernel.
> +technical issues. Any interested reviewer (who has done the work and is a
> +person with known identity) can offer a Reviewed-by tag for a patch. This tag
> +serves to give credit to reviewers and to inform maintainers of the degree of
> +review which has been done on the patch. Reviewed-by: tags, when supplied by
> +reviewers known to understand the subject area and to perform thorough reviews,
> +will normally increase the likelihood of your patch getting into the kernel.
>
> Both Tested-by and Reviewed-by tags, once received on mailing list from tester
> or reviewer, should be added by author to the applicable patches when sending
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 00/25] Introduce meminspect
From: Mukesh Ojha @ 2026-05-21 12:20 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jonathan Corbet, Shuah Khan, Eugen Hristev, Arnd Bergmann,
Dennis Zhou, Tejun Heo, Christoph Lameter, Andrew Morton,
Thomas Gleixner, Peter Zijlstra, Anna-Maria Behnsen,
Frederic Weisbecker, Ingo Molnar, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Valentin Schneider, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Kees Cook, Brendan Jackman,
Johannes Weiner, Zi Yan, Chris Li, Kairui Song, Kemeng Shi,
Nhat Pham, Baoquan He, Barry Song, Youngjun Park, Petr Mladek,
John Ogness, Sergey Senozhatsky, Mathieu Poirier, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Saravana Kannan,
workflows, linux-doc, linux-kernel, linux-arch, linux-mm,
linux-arm-msm, linux-remoteproc, devicetree
In-Reply-To: <abtlUQqMOxj5PwGB@baldur>
On Wed, Mar 18, 2026 at 09:55:29PM -0500, Bjorn Andersson wrote:
> On Mon, Mar 16, 2026 at 11:46:47PM +0530, Mukesh Ojha wrote:
> > On Sun, Mar 15, 2026 at 09:24:39PM -0500, Bjorn Andersson wrote:
> > > On Wed, Mar 11, 2026 at 01:45:44AM +0530, Mukesh Ojha wrote:
> [..]
> > > >, to get all the regions as
> > > > separate files. The tool from the host computer will list the regions
> > > > in the order they were downloaded.
> > > >
> > > > Once you have all the files simply use `cat` to put them all together,
> > > > in the order of the indexes. For my kernel config and setup, here is my
> > > > cat command : (you can use a script or something, I haven't done that so
> > > > far):
> > >
> > > So these need to be sorted in numerical order, by that number at the end
> > > of the file name?
> > >
> > > Do you manually punch these in? How do we make this user friendly?
> >
> > Yes, manually.. but I think we can do better. We could make
> > this more user‑friendly by using the section header and string table in
> > the md_KELF binary both of which existed in the earlier implementation.
> > Then, we can write an upstream‑friendly script that reads this KELF
> > metadata file, checks whether a binary with the registered name is
> > present, and stitches everything together to form a complete ELF that
> > the crash tool can consume. Let me know if you have any suggestion..
> >
>
> Can we somehow identify that these regions belong to the minidump and
> teach QDL to build the ELF for us?
Raised PR for the QDL https://github.com/linux-msm/qdl/pull/243 which
does not use numerating order and we can completely drop.
With that PR, QDL will be generating minidump.elf .
And I checked the latest crash tool with no extra patching and just the
--minimal option (as we do not have everything in the minidump) and just
dmesg.
$ ./crash --minimal minidump/vmlinux ./minidump/minidump.elf
crash 9.0.2++
Copyright (C) 2002-2026 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter "help copying" to see the conditions.
This program has absolutely no warranty. Enter "help warranty" for details.
GNU gdb (GDB) 16.2
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=aarch64-elf-linux".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
NOTE: minimal mode commands: log, dis, rd, sym, eval, set, extend and exit
crash> log
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x512f0030]
[ 0.000000] Linux version 7.1.0-rc2-next-20260504-00228-g2595b97d6061 (@f134cd6ce783) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #11 SMP PREEMPT Fri May 15 09:34:41 UTC 2026
[ 0.000000] KASLR disabled on command line
[ 0.000000] random: crng init done
[ 0.000000] Machine model: Qualcomm Technologies, Inc. XXXX
[ 0.000000] earlycon: qcom_geni0 at MMIO 0x0000000000a9c000 (options '')
[ 0.000000] printk: legacy bootconsole [qcom_geni0] enabled
[ 0.000000] efi: UEFI not found.
...
..
[ 48.488296] sysrq: Trigger a crash
[ 48.492004] Kernel panic - not syncing: sysrq triggered crash
[ 48.497944] CPU: 3 UID: 0 PID: 363 Comm: sh Tainted: G W 7.1.0-rc2-next-20260504-00228-g2595b97d6061 #11 PREEMPT
[ 48.510055] Tainted: [W]=WARN
[ 48.513140] Hardware name: Qualcomm Technologies, Inc. XXXX
[ 48.519699] Call trace:
[ 48.522276] show_stack+0x18/0x24 (C)
[ 48.526089] dump_stack_lvl+0x34/0x8c
[ 48.529903] dump_stack+0x18/0x24
[ 48.533366] vpanic+0x47c/0x4dc
[ 48.536646] do_panic_on_target_cpu+0x0/0x1c
[ 48.541078] sysrq_reset_seq_param_set+0x0/0x94
[ 48.545788] __handle_sysrq+0xd4/0x1b8
[ 48.549679] write_sysrq_trigger+0xc0/0xd0
[ 48.553930] proc_reg_write+0x9c/0xf0
[ 48.557737] vfs_write+0xd4/0x358
[ 48.561187] ksys_write+0x6c/0x104
[ 48.564724] __arm64_sys_write+0x1c/0x28
[ 48.568809] invoke_syscall+0x54/0x10c
[ 48.572704] el0_svc_common.constprop.0+0xc0/0xe0
[ 48.577578] do_el0_svc+0x1c/0x28
[ 48.581025] el0_svc+0x38/0x138
[ 48.584317] el0t_64_sync_handler+0xa0/0xe4
[ 48.588660] el0t_64_sync+0x198/0x19c
[ 48.592474] SMP: stopping secondary CPUs
[ 48.796761] Kernel Offset: disabled
[ 48.806510] Memory Limit: none
crash>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-21 15:37 UTC (permalink / raw)
To: Arnd Bergmann, Dinh Nguyen, Wolfram Sang, Miguel Ojeda
Cc: Ethan Nelson-Moore, Peter Zijlstra, linux-doc, devicetree,
workflows, Linux-Arch, dmaengine, linux-i2c, linux-iio, Netdev,
linux-pci, linux-pwm, linux-hardening, linux-kbuild,
linux-csky@vger.kernel.org, Jonathan Corbet, Shuah Khan,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Alex Shi, Yanteng Si, Dongliang Mu, Hu Haowen,
Kees Cook, Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm),
Andrew Morton, Nicholas Piggin, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof WilczyDski, Andreas Oetken
In-Reply-To: <76af64fa-7820-4d92-8aa9-826c3bd812a1@app.fastmail.com>
Hi Arnd, Dinh, Wolfram, and Miguel,
thank you for your explanations and encouragement; I've now sent my
application for co-maintainership for arch/nios2 to you, Dinh.
On Wed, May 20, 2026 at 09:06:33AM +0200, Arnd Bergmann wrote:
> I think that is a reasonable target. We have a bunch of embedded
> architectures that have a similarly small user base and I expect
> that we will want to remove most of them at some point, as we did
> for seven architectures in linux-4.17.
>
> As long as there is a maintainer for nios2 and it's not actively
> getting in the way of a specific treewide change, I don't see any
> reason to remove this any earlier than the other ones.
>
> Obviously at some point nios2 will have to get removed because
> of the limit to gcc-14 or older, but that should not be a problem
> for the next few LTS releases.
This all sounds quite reasonable, including the toolchain
considerations. Thank you for the offer to keep it around a bit.
If any issues arise with tree-wide changes I'd be happy to look into
what can be done on the arch/nios2 side; now that the issues should
reliably reach me via mail.
> > Sure, I'd be glad to do so, but so far I refrained from it as I was a bit
> > unsure about the netiquette (can I simply do so by self-proclamation? At
> > least the git history seems to suggest so...).
>
> Dinh already replied that he welcomes the help, and I also suggested
> the same thing a year ago. As the only known user that has contributed
> patches in a long time, you are obviously qualified.
>
> Sending a patch for the MAINTAINERS file to Dinh is the first step,
> once he has sent that upstream, you can (optionally) apply for
> kernel.org account that would let you host a git tree on kernel.org
> or have a tree that you both have access to.
I've sent the patch, I'm sure we can work everything else out from
there.
Best regards,
Simon
^ permalink raw reply
* Re: [PATCH v2] docs: submitting-patches: Clarify that "reviewer" is a person
From: Jonathan Corbet @ 2026-05-25 20:05 UTC (permalink / raw)
To: Krzysztof Kozlowski, Shuah Khan, workflows, linux-doc,
linux-kernel
Cc: Krzysztof Kozlowski, Greg Kroah-Hartman, Vlastimil Babka,
Andrew Morton, David Hildenbrand, Linus Torvalds, Randy Dunlap,
Mark Brown
In-Reply-To: <20260520154846.162170-2-krzysztof.kozlowski@oss.qualcomm.com>
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> writes:
> Common understanding of word "Reviewer" is: a person performing a review
> work [1]. Tools are not persons, thus cannot be reviewers in this term.
> Also tools cannot make statements and cannot take responsibility for the
> review.
>
> Our docs already clearly mark that "Reviewed-by" must come from a
> person:
>
> - "By offering my Reviewed-by: tag, I state that:"
>
> Usage of first person "I" and word "state"
>
> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
> appropriate modification of the kernel without any remaining serious"
>
> Only a person can make a statement of opinion.
>
> - "Any interested reviewer (who has done the work) can offer a
> Reviewed-by"
>
> A person can offer a tag thus above does not grant the tool
> permission to offer a tag.
>
> However this might not be enough, so let's clarify that only a person
> with a known identity can state the "Reviewer's statement of oversight".
>
> Link: https://en.wiktionary.org/wiki/reviewer [1]
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Acked-by: Randy Dunlap <rdunlap@infradead.org>
> Reviewed-by: Mark Brown <broonie@kernel.org>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>
> Changes in v2:
> 1. Add tags
> 2. Rephrase/simplify a bit commit msg. Rephrase title - drop "in
> English".
> 3. Add "with known identity", suggested by David Hildenbrand. I retained
> previous tags, assuming this change is within spirit of previous
> version and there were no objections on the list.
> ---
> Documentation/process/submitting-patches.rst | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: threat-model: add missing closing parenthesis
From: Jonathan Corbet @ 2026-05-25 20:19 UTC (permalink / raw)
To: Willy Tarreau, Baruch Siach
Cc: Shuah Khan, workflows, linux-doc, Konstantin Ryabitsev
In-Reply-To: <agnm9A9SFsmvIFZg@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
> On Sun, May 17, 2026 at 06:41:41PM +0300, Baruch Siach wrote:
>> Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug")
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>
> Thank you, and sorry for this mistake!
>
> Obviously: Acked-by: Willy Tarreau <w@1wt.eu>
Amusingly, b4 turned that line into:
Obviously: Willy Tarreau <w@1wt.eu>
I was tempted to leave it that way, but decided to fix it up :)
Applied, thanks,
jon
^ permalink raw reply
* Re: [PATCH] docs: threat-model: add missing closing parenthesis
From: Willy Tarreau @ 2026-05-25 20:26 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Baruch Siach, Shuah Khan, workflows, linux-doc,
Konstantin Ryabitsev
In-Reply-To: <878q971but.fsf@trenco.lwn.net>
On Mon, May 25, 2026 at 02:19:06PM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > On Sun, May 17, 2026 at 06:41:41PM +0300, Baruch Siach wrote:
> >> Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug")
> >> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
> >
> > Thank you, and sorry for this mistake!
> >
> > Obviously: Acked-by: Willy Tarreau <w@1wt.eu>
>
> Amusingly, b4 turned that line into:
>
> Obviously: Willy Tarreau <w@1wt.eu>
Ah funny I didn't think about it! Re-reading it with this in mind makes
my reponse a bit surprising.
> I was tempted to leave it that way, but decided to fix it up :)
>
> Applied, thanks,
Thank you ;-)
willy
^ permalink raw reply
* Re: [PATCH] docs: threat-model: add missing closing parenthesis
From: Konstantin Ryabitsev @ 2026-05-25 21:33 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Willy Tarreau, Baruch Siach, Shuah Khan, workflows, linux-doc
In-Reply-To: <878q971but.fsf@trenco.lwn.net>
On Mon, May 25, 2026 at 02:19:06PM -0600, Jonathan Corbet wrote:
> Amusingly, b4 turned that line into:
>
> Obviously: Willy Tarreau <w@1wt.eu>
>
> I was tempted to leave it that way, but decided to fix it up :)
Obviously, you should have left it as-is. ;)
-K
^ permalink raw reply
* [PATCH] docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)
From: Zhan Xusheng @ 2026-05-26 2:20 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Shuah Khan, workflows, linux-doc, linux-kernel, Zhan Xusheng
Commit 9edd04c4189e ("docs: Raise minimum pahole version to 1.26 for
KF_IMPLICIT_ARGS kfuncs") raised the minimum required pahole version
from 1.22 to 1.26 in the requirements table and added a paragraph
explaining the failure mode for distributions still shipping pahole
v1.25 (e.g. Ubuntu 24.04 LTS).
The next day, commit ece7e57afd51 ("docs: changes.rst and ver_linux:
sort the lists") came through a different tree (docs vs sched_ext) and
re-flowed the table alphabetically, but its base did not include
9edd04c4189e. When the two commits met in mainline, the textual rewrite
of the table won and the version bump was lost. The added "Since Linux
7.0..." paragraph also disappeared.
The result is that changes.rst on master (v7.1-rc5) lists pahole 1.22
again, even though sched_ext kfuncs annotated with KF_IMPLICIT_ARGS
genuinely require v1.26 to produce a correct vmlinux BTF. Users on
distributions with pahole v1.25 hit "func_proto incompatible with
vmlinux" when loading any sched_ext BPF program (scx_simple,
scx_qmap, ...) and have no documentation pointing them at the version
gap.
Restore both changes from 9edd04c4189e.
Fixes: ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists")
Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
---
Documentation/process/changes.rst | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 9a99037270ff..a4db8f7b3afb 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -53,7 +53,7 @@ mcelog 0.6 mcelog --version
mkimage (optional) 2017.01 mkimage --version
nfs-utils 1.0.5 showmount --version
openssl & libcrypto 1.0.0 openssl version
-pahole 1.22 pahole --version
+pahole 1.26 pahole --version
pcmciautils 004 pccardctl -V
PPP 2.4.0 pppd --version
procps 3.2.0 ps --version
@@ -147,6 +147,11 @@ Since Linux 5.2, if CONFIG_DEBUG_INFO_BTF is selected, the build system
generates BTF (BPF Type Format) from DWARF in vmlinux, a bit later from kernel
modules as well. This requires pahole v1.22 or later.
+Since Linux 7.0, kfuncs annotated with KF_IMPLICIT_ARGS require pahole v1.26
+or later. Without it, such kfuncs will have incorrect BTF prototypes in
+vmlinux, causing BPF programs to fail to load with a "func_proto incompatible
+with vmlinux" error. Many sched_ext kfuncs are affected.
+
It is found in the 'dwarves' or 'pahole' distro packages or from
https://fedorapeople.org/~acme/dwarves/.
--
2.43.0
^ permalink raw reply related
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