- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

SOFTIRQ Stacks and Virtual Memory
by Richard Sept. 2, 2026

Sept. 2, 2026

Hi all, Why does this doc: https://www.kernel.org/doc/Documentation/x86/x86_64/mm.txt not contain entries for the IRQ and SOFTIRQ stack? Are those stacks dynamically allocated in one of the areas in this table? Or is the doc just outdated? Would it be valuable to update it? Best, -- Richard

2 1

Runtime ownership and driver binding for SPI-NOR shared with FPGA
by Patryk July 15, 2026

July 15, 2026

Hi I've been working on a baseboard where I have an SoC running Linux and FPGA that uses external flash as a bitstream storage. This flash is in fact shared between Linux and FPGA but not simultaneously. It is "muxed" so that it can only be accessible either by Linux or FPGA at once. This is designed so that the flash can be updated from Linux. When the platform is booting, the mux is always switched so that the FPGA can access the flash and load its bitstream. Whenever I want to update the flash I need to make it accessible physically (need to change the mux config) for Linux as well as "logically" - meaning that the appropriate driver has to be loaded. Once the update is done, Linux should release the flash and no longer use it unless the update has to be repeated so the update sequence is roughly like this: - change mux config - bind driver - write flash - unbind driver - change mux config again I am trying to determine the correct way to model and implement this. I could implement most of the sequence in userspace, but the SPI device still needs platform-specific information such as the SPI controller, chip select, maximum clock frequency, and possibly a GPIO-based chip select provided by a GPIO expander. One possible approach would be to describe the flash normally in the Device Tree with "okay" status. The initial spi-nor probe would fail because the flash is connected to the FPGA during boot. Later, when an update is required, userspace could switch the mux and retry probing the existing SPI device: - change mux - echo spi0.2 > /sys/bus/spi/drivers_probe or echo spi0.2 > /sys/bus/spi/drivers/spi-nor/bind - update flash - echo spi0.2 > /sys/bus/spi/drivers/spi-nor/unbind - change mux again but is this really a good option? I feel that I'm leaking hardware specific information to userspace, I'll have to hardcode some paths, driver names in flashing script / prepare separate script for each device (if there are differences between platforms) or carry platform hardware description config file so that the flashing tool could stay generic and read necessary info from config. Is there any better way? Would be grateful for any suggestion Best regards Patryk

1 0

Seeking guidance on detecting mount point inactivity
by Ali Nasrolahi July 6, 2026

July 6, 2026

Hello everyone, I am working on a problem involving managing some number of filesystem mounts (~1000+) and determining when a mount becomes inactive to do some maintenance. To be specific, the goal is to detect when a mounted filesystem has no remaining active file usage, and after it remains inactive for some period (e.g. 10 seconds), transition it into a state where new file opens are blocked so that maintenance operations can safely proceed. It must handle concurrent access from arbitrary applications, so correctness under races is quite challenging. I have looked into userspace based approaches and tools for observing file usage, but they seem difficult to make fully correct in edge cases such as process forking and descriptor inheritance, which makes it hard to reliably implement the “last reference + grace period + safe transition”. At this point I suspect this problem should be tied to kernel-level mount lifecycle semantics rather than something that can be reliably done in userspace alone. However, I am not sure which mailing-list (if any) is appropriate to present this kind of problem/question. So, I am mainly looking for guidance on where to take this discussion to seek some sort of advice. Thanks a lot, Ali

3 6

[PATCH] docs fix typo 'busses' --> 'buses' in phy.rst
by Pratik June 19, 2026

June 19, 2026

Signed-off-by: Pratik <pratikbabshet(a)gmail.com> --- Documentation/networking/phy.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 0170c9d4d..9bcaacc5c 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -19,8 +19,8 @@ amounts of redundant code. Also, on embedded systems with multiple (and sometimes quite different) ethernet controllers connected to the same management bus, it is difficult to ensure safe use of the bus. -Since the PHYs are devices, and the management busses through which they are -accessed are, in fact, busses, the PHY Abstraction Layer (PAL) treats them as such. +Since the PHYs are devices, and the management buses through which they are +accessed are, in fact, buses, the PHY Abstraction Layer (PAL) treats them as such. In doing so, it has these goals: #. Increase code-reuse @@ -35,7 +35,7 @@ The MDIO bus ============ Most network devices are connected to a PHY by means of a management bus. -Different devices use different busses (though some share common interfaces). +Different devices use different buses (though some share common interfaces). In order to take advantage of the PAL, each bus interface needs to be registered as a distinct device. -- 2.43.0

1 0

Stack Sizes
by Agatha Isabelle Moreira June 14, 2026

June 14, 2026

Hi, The kernel documentation says that any function that uses more than 512 bytes on the stack is a candidate for change. However, it doesn't say under what conditions (what config options). I found 193 functions matching, some with stacks quite larger than that. I suspect this could be the result of some config options, maybe. What would you recommend me checking? -- Agatha Isabelle Moreira Systems Engineer | C

2 2

Re: [PATCH] get_maintainer: add recipients to output of script
by Agatha Isabelle Moreira June 8, 2026

June 8, 2026

On Mon, Jun 08, 2026 at 06:34:12PM +0200, Manuel Ebner wrote: > Add all people tagged in all the mentioned commits to the output of this script. > This is done to give credit to people who inspired the current commit or to get > feedback from people who know the subject. Some things to notice: 1) Cc someone in the message is not the way of giving credit, the tags are already for that. 2) The way get_maintainer.pl works today already copies the relevant people, you should state why your addition matters to that. 3) You are supposed to send the message again with `[PATCH v2]` in the subject if you want your message to be tracked as a new version of the patch. In that case you must include a changelog stating your changes. See: https://docs.kernel.org/process/submitting-patches.html 4) I'm not sure why people in the mentioned patches should necessarily be copied in a patch. I mean, if they are active contributors to that part of the code they are likely already included in the regular `get_maintainer.pl` output, they will either be listed in the `MAINTAINERS` file or at least be fetched through git. Keep in mind that `get_maintainer.pl` is not intended to be used to spam people, but to get where to send your patches and who to copy. > index 16b80a700d4a..8c44b14391f9 100755 > --- a/scripts/get_maintainer.pl > +++ b/scripts/get_maintainer.pl > @@ -30,6 +30,7 @@ my $email_usename = 1; > my $email_maintainer = 1; > my $email_reviewer = 1; > my $email_fixes = 1; > +my $email_mentioned = 0; > my $email_list = 1; > my $email_moderated_list = 1; > my $email_subscriber_list = 0; > @@ -78,6 +79,7 @@ my $exit = 0; > > my @files = (); > my @fixes = (); # If a patch description includes Fixes: lines > +my @mentioned = (); # If a patch description mentiones a patch > my @range = (); > my @keyword_tvi = (); > my @file_emails = (); > @@ -264,6 +266,7 @@ if (!GetOptions( > 'n!' => \$email_usename, > 'l!' => \$email_list, > 'fixes!' => \$email_fixes, > + 'mentioned!' => \$email_mentioned, > 'moderated!' => \$email_moderated_list, > 's!' => \$email_subscriber_list, > 'multiline!' => \$output_multiline, > @@ -606,6 +609,8 @@ foreach my $file (@ARGV) { > push(@files, $filename2); > } elsif (m/^Fixes:\s+([0-9a-fA-F]{6,40})/) { > push(@fixes, $1) if ($email_fixes); > + } elsif (m/\s+([0-9a-fA-F]{6,40})/) { > + push(@mentioned, $1) if ($email_mentioned); If you still wanna submit this patch anyway, besides explaining the reason to be accepted, I think you should check if your regex isn't matching anything other than commit messages. For instance, I can easily imagine this regex matching a regular hash that's not a commit id or a memory address. Imagine you have a kernel panic log in the commit message, for instance. I think your script would likely misinterpret register values as commit messages. Really need to work on that. Though I would recommend that you discuss with the list first and try to get people to understand why this might be important first so you don't waste time fixing something that might not get accepted. Unless you wanna use it for yourself locally. -- Agatha Isabelle Moreira C Developer | agatha.dev Sourcehut: https://sr.ht/~devlavender/

1 0

Re: [PATCH] get_maintainer: add recipients to output of script
by Joe Perches June 8, 2026

June 8, 2026

On Mon, 2026-06-08 at 17:46 +0200, Manuel Ebner wrote: > On Mon, 2026-06-08 at 08:29 -0700, Joe Perches wrote: > On Mon, 2026-06-08 at 17:22 +0200, Manuel Ebner wrote: > Add all people tagged in all the mentioned commits to the output of this script. > > Why? > > Because sometimes there is a reason to add them. Doing so with get_maintainer > spares the manual copying and pasting. Please specify this reason in the changelog.

2 1

Re: [PATCH] get_maintainer: add recipients to output of script
by Joe Perches June 8, 2026

June 8, 2026

On Mon, 2026-06-08 at 17:56 +0200, Manuel Ebner wrote: > Is it ok to have this on by default or should I turn it off? Has to be off. Otherwise all the 'cc:' lines would be used. And fyi: I doubt the utility of this new mechanism.

1 0

Re: [PATCH] get_maintainer: add recipients to output of script
by Joe Perches June 8, 2026

June 8, 2026

On Mon, 2026-06-08 at 17:22 +0200, Manuel Ebner wrote: > Add all people tagged in all the mentioned commits to the output of this script. Why?

1 0

why don't unlock_buffer call directly clear_and_wake_up_bit?
by shuo chen May 19, 2026

May 19, 2026

The unlock_buffer and clear_and_wake_up_bit call same the three function in the same sequence: 1.clear_bit_unlock 2.smp_mb__after_atomic 3.wake_up_bit So why don't unlock_buffer write the fllowing: void unlock_buffer(struct buffer_head *bh) { clear_and_wake_up_bit(BH_Lock,&bh->b_state); }

2 2