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

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

[Christian Brauner]

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.

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

[Christian Brauner]

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.

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

[Lorenzo Stoakes (Oracle)]

+cc David for mention

On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
> - 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.

Thanks! Agree absolutely that we need to be careful about this. Jia Tan should
be instructive.

Josh - there's nothing personal here to be clear, this is a question of
procedure and caution.

More broadly I think we should avoid assigning new people to catch-all
categories anyway unless they are well established enough to be involved with
_everything_ the catch-all covers.

For instance adding people to the mm/* other than perhaps... David ;) would be
crazy.

Also - Andrew - I think for cases where you are the only maintainer but it
impacts others, you should seek acks proportional to the scope the MAINTAINERS
entry spans - in this case that'd be a _lot_ of people - but that only
underlines that we shouldn't be updating such entries anyway.

In fact - can we just do away with catch-all's and just make sure MAINTAINERS
entries are established for everything?

I have ground to stand on for this as I personally did it for mm, although we do
still have a catch-all (not sure if necessary any more?)

In the case of lib/ a quick fix could be to figure out which files are not
covered by other MAINTAINERS entries and adding them all to what is currently
the catch-all?

Cheers, Lorenzo

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

[Josh Law]

13 Mar 2026 15:48:32 Lorenzo Stoakes (Oracle) <ljs@kernel.org>:

> +cc David for mention
>
> On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
>> - 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.
>
> Thanks! Agree absolutely that we need to be careful about this. Jia Tan should
> be instructive.
>
> Josh - there's nothing personal here to be clear, this is a question of
> procedure and caution.
>
> More broadly I think we should avoid assigning new people to catch-all
> categories anyway unless they are well established enough to be involved with
> _everything_ the catch-all covers.
>
> For instance adding people to the mm/* other than perhaps... David ;) would be
> crazy.
>
> Also - Andrew - I think for cases where you are the only maintainer but it
> impacts others, you should seek acks proportional to the scope the MAINTAINERS
> entry spans - in this case that'd be a _lot_ of people - but that only
> underlines that we shouldn't be updating such entries anyway.
>
> In fact - can we just do away with catch-all's and just make sure MAINTAINERS
> entries are established for everything?
>
> I have ground to stand on for this as I personally did it for mm, although we do
> still have a catch-all (not sure if necessary any more?)
>
> In the case of lib/ a quick fix could be to figure out which files are not
> covered by other MAINTAINERS entries and adding them all to what is currently
> the catch-all?
>
> Cheers, Lorenzo

Well, it's already been merged into linux-next, I will keep constantly trying to prove myself as a trusted figure in the community, and I am learning new things every day about the rules, and when you talk about me making "trivial" patches, I also made some medium sized bug fixes, yeah my start was just "janitor" code, but I will try to prove myself,


V/R


Josh Law

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

[Lorenzo Stoakes (Oracle)]

On Fri, Mar 13, 2026 at 03:51:24PM +0000, Josh Law wrote:
> Well, it's already been merged into linux-next, I will keep constantly trying to prove myself as a trusted figure in the community, and I am learning new things every day about the rules, and when you talk about me making "trivial" patches, I also made some medium sized bug fixes, yeah my start was just "janitor" code, but I will try to prove myself,

The patch is not being taken.

As I said, it's nothing personal, you shouldn't be seeking this 1 week into
contributing to the kernel.

Keep contributing and get to learn the rules and etiquette, and only think of
MAINTAINERS say a year or so afterwards.

I started contributing in ~2014 and was added to MAINTAINERS in 2023 I think?

There's no rush :)

Thanks, Lorenzo

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

[Jens Axboe]

On 3/13/26 9:51 AM, Josh Law wrote:
> 13 Mar 2026 15:48:32 Lorenzo Stoakes (Oracle) <ljs@kernel.org>:
> 
>> +cc David for mention
>>
>> On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
>>> - 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.
>>
>> Thanks! Agree absolutely that we need to be careful about this. Jia Tan should
>> be instructive.
>>
>> Josh - there's nothing personal here to be clear, this is a question of
>> procedure and caution.
>>
>> More broadly I think we should avoid assigning new people to catch-all
>> categories anyway unless they are well established enough to be involved with
>> _everything_ the catch-all covers.
>>
>> For instance adding people to the mm/* other than perhaps... David ;) would be
>> crazy.
>>
>> Also - Andrew - I think for cases where you are the only maintainer but it
>> impacts others, you should seek acks proportional to the scope the MAINTAINERS
>> entry spans - in this case that'd be a _lot_ of people - but that only
>> underlines that we shouldn't be updating such entries anyway.
>>
>> In fact - can we just do away with catch-all's and just make sure MAINTAINERS
>> entries are established for everything?
>>
>> I have ground to stand on for this as I personally did it for mm, although we do
>> still have a catch-all (not sure if necessary any more?)
>>
>> In the case of lib/ a quick fix could be to figure out which files are not
>> covered by other MAINTAINERS entries and adding them all to what is currently
>> the catch-all?
>>
>> Cheers, Lorenzo
> 
> Well, it's already been merged into linux-next, I will keep constantly

That doesn't matter, lots of things end up temporarily in -next and
disappear before it ever sees upstream.

> trying to prove myself as a trusted figure in the community, and I am
> learning new things every day about the rules, and when you talk about
> me making "trivial" patches, I also made some medium sized bug fixes,
> yeah my start was just "janitor" code, but I will try to prove myself,

I have to agree with Christian/Lorenzo/et al here. This is not how it
works. You prove yourself by doing quality work, and then and only then
does it become official. Adding someone after 1 week of a bunch of
trivial patches is literally crazy, imho.

-- 
Jens Axboe

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

[Josh Law]

13 Mar 2026 15:57:04 Jens Axboe <axboe@kernel.dk>:

> On 3/13/26 9:51 AM, Josh Law wrote:
>> 13 Mar 2026 15:48:32 Lorenzo Stoakes (Oracle) <ljs@kernel.org>:
>>
>>> +cc David for mention
>>>
>>> On Fri, Mar 13, 2026 at 04:33:49PM +0100, Christian Brauner wrote:
>>>> - 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.
>>>
>>> Thanks! Agree absolutely that we need to be careful about this. Jia Tan should
>>> be instructive.
>>>
>>> Josh - there's nothing personal here to be clear, this is a question of
>>> procedure and caution.
>>>
>>> More broadly I think we should avoid assigning new people to catch-all
>>> categories anyway unless they are well established enough to be involved with
>>> _everything_ the catch-all covers.
>>>
>>> For instance adding people to the mm/* other than perhaps... David ;) would be
>>> crazy.
>>>
>>> Also - Andrew - I think for cases where you are the only maintainer but it
>>> impacts others, you should seek acks proportional to the scope the MAINTAINERS
>>> entry spans - in this case that'd be a _lot_ of people - but that only
>>> underlines that we shouldn't be updating such entries anyway.
>>>
>>> In fact - can we just do away with catch-all's and just make sure MAINTAINERS
>>> entries are established for everything?
>>>
>>> I have ground to stand on for this as I personally did it for mm, although we do
>>> still have a catch-all (not sure if necessary any more?)
>>>
>>> In the case of lib/ a quick fix could be to figure out which files are not
>>> covered by other MAINTAINERS entries and adding them all to what is currently
>>> the catch-all?
>>>
>>> Cheers, Lorenzo
>>
>> Well, it's already been merged into linux-next, I will keep constantly
>
> That doesn't matter, lots of things end up temporarily in -next and
> disappear before it ever sees upstream.
>
>> trying to prove myself as a trusted figure in the community, and I am
>> learning new things every day about the rules, and when you talk about
>> me making "trivial" patches, I also made some medium sized bug fixes,
>> yeah my start was just "janitor" code, but I will try to prove myself,
>
> I have to agree with Christian/Lorenzo/et al here. This is not how it
> works. You prove yourself by doing quality work, and then and only then
> does it become official. Adding someone after 1 week of a bunch of
> trivial patches is literally crazy, imho.
>
> --
> Jens Axboe

Thank you guys for the context and the history. I understand now
why my request was premature and how it looks from a security and procedural
standpoint. I appreciate you taking the time to explain the 'Jia Tan'
caution, it makes total sense why the bar is so high.

I'm going to take the 'no rush' advice to heart. I'll focus on the technical
work, learn the etiquette, and prove myself through quality contributions over
time. Thank you for not being super mad


V/R


Josh Law

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

[Jens Axboe]

On 3/13/26 10:00 AM, Josh Law wrote:
> Thank you guys for the context and the history. I understand now why
> my request was premature and how it looks from a security and
> procedural standpoint. I appreciate you taking the time to explain the
> 'Jia Tan' caution, it makes total sense why the bar is so high.
> 
> I'm going to take the 'no rush' advice to heart. I'll focus on the
> technical work, learn the etiquette, and prove myself through quality
> contributions over time. Thank you for not being super mad

That is the way! Just keep at it, it's a long road.

-- 
Jens Axboe

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

[Darrick J. Wong]

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

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

[Josh Law]

13 Mar 2026 15:52:54 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:
>>>>>> …
>>>>>
>>>>> 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

I apologize unreservedly to the maintainers and the community. The
comment I made was incredibly disrespectful and immature. I realize now that
testing is foundational to kernel development, especially in library
code, and my dismissive response was a massive failure on my part.

I have a lot to learn about the technical requirements of the kernel,
but clearly, I have even more to learn about the professional
standards of this community. I accept the NAK and will step back to
re-evaluate my approach and conduct. I am sorry for wasting your time.


V/R


Josh Law