From joe at perches.com Mon Jun 8 11:29:16 2026 From: joe at perches.com (Joe Perches) Date: Mon, 08 Jun 2026 08:29:16 -0700 Subject: [PATCH] get_maintainer: add recipients to output of script In-Reply-To: <20260608152242.61223-2-manuelebner@mailbox.org> References: <20260608152242.61223-2-manuelebner@mailbox.org> Message-ID: <14198ef7adde6d0e24535edf64266201b7036fed.camel@perches.com> 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? From joe at perches.com Mon Jun 8 11:52:00 2026 From: joe at perches.com (Joe Perches) Date: Mon, 08 Jun 2026 08:52:00 -0700 Subject: [PATCH] get_maintainer: add recipients to output of script In-Reply-To: <85761322b578c87381553baf479491a55a5b8b24.camel@mailbox.org> References: <20260608152242.61223-2-manuelebner@mailbox.org> <14198ef7adde6d0e24535edf64266201b7036fed.camel@perches.com> <85761322b578c87381553baf479491a55a5b8b24.camel@mailbox.org> Message-ID: 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. From joe at perches.com Mon Jun 8 12:00:33 2026 From: joe at perches.com (Joe Perches) Date: Mon, 08 Jun 2026 09:00:33 -0700 Subject: [PATCH] get_maintainer: add recipients to output of script In-Reply-To: References: <20260608152242.61223-2-manuelebner@mailbox.org> <14198ef7adde6d0e24535edf64266201b7036fed.camel@perches.com> <85761322b578c87381553baf479491a55a5b8b24.camel@mailbox.org> Message-ID: <4ae343e93c146218515676bba385286ded59e1c2.camel@perches.com> 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. From code at agatha.dev Mon Jun 8 12:50:19 2026 From: code at agatha.dev (Agatha Isabelle Moreira) Date: Mon, 8 Jun 2026 13:50:19 -0300 Subject: [PATCH] get_maintainer: add recipients to output of script In-Reply-To: References: <20260608152242.61223-2-manuelebner@mailbox.org> <14198ef7adde6d0e24535edf64266201b7036fed.camel@perches.com> <85761322b578c87381553baf479491a55a5b8b24.camel@mailbox.org> Message-ID: On Mon, Jun 08, 2026 at 08:52:00AM -0700, Joe Perches wrote: > 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. > Is the original message outside the kernelnewbies list? I do not see the original message in the kernelnewbies list, and neither I see Manuel's messages, so I'm lacking context here. -- Agatha Isabelle Moreira C Developer | agatha.dev Sourcehut: https://sr.ht/~devlavender/ From code at agatha.dev Mon Jun 8 15:32:20 2026 From: code at agatha.dev (Agatha Isabelle Moreira) Date: Mon, 8 Jun 2026 16:32:20 -0300 Subject: [PATCH] get_maintainer: add recipients to output of script In-Reply-To: <20260608163411.70226-2-manuelebner@mailbox.org> References: <14198ef7adde6d0e24535edf64266201b7036fed.camel@perches.com> <20260608163411.70226-2-manuelebner@mailbox.org> Message-ID: 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/ From code at agatha.dev Fri Jun 12 00:04:40 2026 From: code at agatha.dev (Agatha Isabelle Moreira) Date: Fri, 12 Jun 2026 01:04:40 -0300 Subject: Stack Sizes Message-ID: 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 From chambilkethakur at gmail.com Fri Jun 12 05:11:28 2026 From: chambilkethakur at gmail.com (Anuz Pratap Singh Tomar) Date: Fri, 12 Jun 2026 10:11:28 +0100 Subject: Stack Sizes In-Reply-To: References: Message-ID: This question might be worth asking in kernel Janitor mailing list. They also use a few tools for static code checking. On Fri, Jun 12, 2026 at 5:05?AM Agatha Isabelle Moreira wrote: > 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 > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Thank you Warm Regards Anuz -------------- next part -------------- An HTML attachment was scrubbed... URL: From code at agatha.dev Sun Jun 14 18:17:00 2026 From: code at agatha.dev (Agatha Isabelle Moreira) Date: Sun, 14 Jun 2026 19:17:00 -0300 Subject: Stack Sizes In-Reply-To: References: Message-ID: On Fri, Jun 12, 2026 at 10:11:28AM +0100, Anuz Pratap Singh Tomar wrote: > This question might be worth asking in kernel Janitor mailing list. They > also use a few tools for static code checking. Alright, I'm gonna post thare. > -- > Thank you > Warm Regards > Anuz Thanks! -- Agatha Isabelle Moreira Systems Engineer | C From pratikbabshet at gmail.com Fri Jun 19 14:36:32 2026 From: pratikbabshet at gmail.com (Pratik) Date: Fri, 19 Jun 2026 18:36:32 +0000 Subject: [PATCH] docs fix typo 'busses' --> 'buses' in phy.rst Message-ID: <20260619183632.7565-1-pratikbabshet@gmail.com> Signed-off-by: Pratik --- 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 From a.nasrolahi01 at gmail.com Thu Jun 25 10:37:27 2026 From: a.nasrolahi01 at gmail.com (Ali Nasrolahi) Date: Thu, 25 Jun 2026 14:37:27 +0000 Subject: Seeking guidance on detecting mount point inactivity Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: