Re: [PATCH] MAINTAINERS: add Josh Law as reviewer for library code

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
> On Fri, Mar 13, 2026 at 04:00:38PM +0100, Christian Brauner wrote:
> > On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
> > > Add myself as a designated reviewer for the library code to help review
> > > incoming patches and improvements.
> > > 
> > > Signed-off-by: Josh Law <objecting@objecting.org>
> > > ---
> > >  MAINTAINERS | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 96e97d25e1c2..8fd03ab9c657 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -14613,6 +14613,7 @@ F:	tools/testing/nvdimm/
> > >  
> > >  LIBRARY CODE
> > >  M:	Andrew Morton <akpm@linux-foundation.org>
> > > +R:	Josh Law <objecting@objecting.org>
> > >  L:	linux-kernel@vger.kernel.org
> > >  S:	Supported
> > >  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> > > -- 
> > > 2.43.0
> > > 
> > 
> > On Fri, Mar 13, 2026 at 10:17:53AM +0000, Lorenzo Stoakes (Oracle) wrote:
> > > On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
> > > > Add myself as a designated reviewer for the library code to help review
> > > > incoming patches and improvements.
> > > >
> > > > Signed-off-by: Josh Law <objecting@objecting.org>
> > > 
> > > Sorry but NAK, I appreciate your enthusiasm but this is literally _all_
> > > library code, and you don't have a long track history in the kernel.
> > > 
> > > Also in [0], [1], etc. you aren't demonstrating a great deal of maturity,
> > > so I don't think it's appropriate for you to be added at this time.
> > > 
> > > I really don't think a 'catch all' category should be getting arbitrary
> > > extra reviewers in any case.
> > > 
> > > Please take some time to contribute to the kernel, establish yourself, and
> > > then look to reviewership for a specific category.
> > > 
> > > Thanks, Lorenzo
> > > 
> > > > ---
> > > >  MAINTAINERS | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 96e97d25e1c2..8fd03ab9c657 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -14613,6 +14613,7 @@ F:	tools/testing/nvdimm/
> > > >
> > > >  LIBRARY CODE
> > > >  M:	Andrew Morton <akpm@linux-foundation.org>
> > > > +R:	Josh Law <objecting@objecting.org>
> > > >  L:	linux-kernel@vger.kernel.org
> > > >  S:	Supported
> > > >  T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-nonmm-unstable
> > > > --
> > > > 2.43.0
> > > >
> > > >
> > > 
> > > [0]:https://lore.kernel.org/all/c41dbb9d-b8a5-4b5f-9f71-3fe1bed210b6@gmail.com/
> > > [1]:https://lore.kernel.org/linux-mm/40767ecf-7e25-48f5-a604-c43b835b6b66@gmail.com/
> > 
> > On Fri, Mar 13, 2026 at 11:49:03AM +0100, Vlastimil Babka wrote:
> > > On 3/13/26 11:17, Lorenzo Stoakes (Oracle) wrote:
> > > > On Sat, Mar 07, 2026 at 10:19:31PM +0000, Josh Law wrote:
> > > >> Add myself as a designated reviewer for the library code to help review
> > > >> incoming patches and improvements.
> > > >>
> > > >> Signed-off-by: Josh Law <objecting@objecting.org>
> > > > 
> > > > Sorry but NAK, I appreciate your enthusiasm but this is literally _all_
> > > > library code, and you don't have a long track history in the kernel.
> > > 
> > > Agreed, just a week after first appearance on lists is really quite too soon.
> > > 
> > > Yes, getting Cc'd thanks to R: entry is one thing, but that can be achieved
> > > with lei as well. The other aspect of R: is giving weigh in replies to
> > > (potentially new) contributors and that's why it's not given out rather that
> > > quickly.
> > > 
> > > > Also in [0], [1], etc. you aren't demonstrating a great deal of maturity,
> > > > so I don't think it's appropriate for you to be added at this time.
> > > > 
> > > > I really don't think a 'catch all' category should be getting arbitrary
> > > > extra reviewers in any case.
> > > 
> > > Agreed. Many of the files under lib/ are listed in other sections with their
> > > own maintainers. They were not cc'd on this MAINTAINERS update and yet it
> > > would affect all patches to their files too, so they could at least have a
> > > say. It's unfortunate that it's how this catch-all works. Maybe X: entries
> > > could be used by the specific maintainers in the catch-all section, although
> > > it's somewhat tedious.
> > 
> > Agreed. I'm sorry but there is no meaningful track record that would
> > justify this addition. lib/ encompasses locking.c, iov_iter.c,
> > rhashtable.c and a ton of other stuff that is consumed by literally the
> > whole kernel from core to drivers. If this was something innocous I
> > wouldn't care but there's a lot of really gnarly but important stuff in
> > there.
> > 
> > And yes, all of the externally maintained files should be dropped from
> > the generic lib/ catch-all ideally.
> 
> Ok, so let's look at this for a minute:
> 
> - first patch Feb 28 under pseudonym "techyguyperplexable", switched to "Josh Law" only when Andrew required a real name
>   in https://lore.kernel.org/all/20260228114939.de7d44de38d907a9b6632480@linux-foundation.org
> - 142+ emails in ~2 weeks — 37 patches in a single day (Mar 1)
> - All trivial/cosmetic — SPDX headers, comment grammar, spacing, const qualifiers. Zero bug fixes, zero new functionality
> - Carpet-bombed multiple subsystems — lib/, arm64/, staging/, input/, etc.
> - within 1 week of first-ever patch, submitted MAINTAINERS: add Josh Law as reviewer for library code covering all of lib/ (locking.c, iov_iter.c, rhashtable.c, etc.)
> - Email identity mismatch — From: hlcj1234567@gmail.com, Signed-off-by: objecting@objecting.org
> - Formatting problems — top-posting, line length violations, patches not applying cleanly
> 
> So I mean, one week to Reviewer. Even if we're being very generous here,
> we need to do a lot more due diligence going forward. We can't just hand
> out core components like this and risking our reputation and security
> posture.

/me sees "Lmao you and your test cases" in [1] and responds with "LMAO
NAK".  If you're not serious about helping everyone to test your changes
to library code such that you respond that dismissively to longtime
maintainers, you shouldn't be working on operating system kernels.

--D