ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
@ 2021-04-21 18:35 James Bottomley
  2021-04-21 18:46 ` Christian Borntraeger
                   ` (10 more replies)
  0 siblings, 11 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-21 18:35 UTC (permalink / raw)
  To: ksummit

I've long been on record as not really being a fan of trivial patches
because they can cause merge issues with current patches and introduce
bugs, particularly in older drivers, that don't get detected for a long
while.  However, the recent events with the University of Minnesota:

https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/

Have elevated the risk factor around trivial patches claiming to fix
bugs to the point where it looks like there's no such thing as a truly
trivial patch and they all need reviewing.

Our policy in SCSI for a long time has been no trivial patches accepted
to maintained drivers, and I think that would be a good start if
adopted kernel wide, but I think the next policy should be no trivial
bug fix without a pointer to the actual bug report or report from a
trusted static checker.  This would likely mean we have to create a
list of trusted static checkers ... obviously 0day and coverity but
what else?

James



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
@ 2021-04-21 18:46 ` Christian Borntraeger
  2021-04-21 18:51 ` Alexey Dobriyan
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 153+ messages in thread
From: Christian Borntraeger @ 2021-04-21 18:46 UTC (permalink / raw)
  To: James Bottomley, ksummit



On 21.04.21 20:35, James Bottomley wrote:
> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?

I think we must also accept bugfixes that clearly explain how a bug can happen.
You certainly do not want to wait for somebody to run into a problem if it
is clear how such a bug can happen.
Of course this requires a proper review.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
  2021-04-21 18:46 ` Christian Borntraeger
@ 2021-04-21 18:51 ` Alexey Dobriyan
  2021-04-21 18:53   ` Christian Borntraeger
  2021-04-21 19:06 ` Al Viro
                   ` (8 subsequent siblings)
  10 siblings, 1 reply; 153+ messages in thread
From: Alexey Dobriyan @ 2021-04-21 18:51 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?

How does the list get expanded if new static checker is not on
the list and its patches won't be applied?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:51 ` Alexey Dobriyan
@ 2021-04-21 18:53   ` Christian Borntraeger
  0 siblings, 0 replies; 153+ messages in thread
From: Christian Borntraeger @ 2021-04-21 18:53 UTC (permalink / raw)
  To: Alexey Dobriyan, James Bottomley; +Cc: ksummit



On 21.04.21 20:51, Alexey Dobriyan wrote:
> On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
>> Our policy in SCSI for a long time has been no trivial patches accepted
>> to maintained drivers, and I think that would be a good start if
>> adopted kernel wide, but I think the next policy should be no trivial
>> bug fix without a pointer to the actual bug report or report from a
>> trusted static checker.  This would likely mean we have to create a
>> list of trusted static checkers ... obviously 0day and coverity but
>> what else?
> 
> How does the list get expanded if new static checker is not on
> the list and its patches won't be applied?

I think the answer is common sense. Take James proposal as a guideline
but use your common sense as a maintainer to apply patches nevertheless.
This would also address my concern.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
  2021-04-21 18:46 ` Christian Borntraeger
  2021-04-21 18:51 ` Alexey Dobriyan
@ 2021-04-21 19:06 ` Al Viro
  2021-04-21 19:14 ` James Bottomley
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 153+ messages in thread
From: Al Viro @ 2021-04-21 19:06 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide,

Er...  I'm not sure I understand you correctly; suppose maintainer of a driver
gets what pretends to be an obvious fix, complete with analysis, verifies that
the bug is real and the fix is correct.  What should that maintainer do under
your policy?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (2 preceding siblings ...)
  2021-04-21 19:06 ` Al Viro
@ 2021-04-21 19:14 ` James Bottomley
  2021-04-21 19:22 ` Steven Rostedt
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-21 19:14 UTC (permalink / raw)
  To: ksummit

On Wed, 2021-04-21 at 11:35 -0700, James Bottomley wrote:
> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and
> introduce bugs, particularly in older drivers, that don't get
> detected for a long while.  However, the recent events with the
> University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a
> truly trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches
> accepted to maintained drivers,

Sorry, Viro caught this: that should be "no trivial patches accepted to
*un*maintained driver ..."

James


>  and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?
> 
> James
> 
> 
> 



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (3 preceding siblings ...)
  2021-04-21 19:14 ` James Bottomley
@ 2021-04-21 19:22 ` Steven Rostedt
  2021-04-21 19:26   ` Kees Cook
  2021-04-21 19:32   ` Roland Dreier
  2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
                   ` (5 subsequent siblings)
  10 siblings, 2 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-21 19:22 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, 21 Apr 2021 11:35:36 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?

I take a lot of trivial fixes. I found two that I accepted that were from
umn.edu, and both of them (after a second review) were legitimate fixes.
One was in Greg's revert patch series, which I asked him to not revert, and
the other was me looking at all patches I've received with a Cc to umn.edu
emails, and was from a gmail account (which I'm assuming was someone that
was part of this group).

I have no problem with taking a trivial patch if they are really fixing a
bug. I think what needs to be done here is look at the patches that got in
that were buggy, and see why they got in.

Perhaps the answer is to scrutinize trivial patches more. To me, the only
"trivial" patch is a comment fix, or update to documentation. And even
then, I spend time reviewing it.

If you don't have time to review a patch, then by all means, don't accept
it. Perhaps the answer is simply have a higher bar on what you do accept.

There are a few people that I will accept patches from with out review. But
anyone else, I scrutinize the code before taking it in.


-- Steve


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:22 ` Steven Rostedt
@ 2021-04-21 19:26   ` Kees Cook
  2021-04-21 19:32   ` Roland Dreier
  1 sibling, 0 replies; 153+ messages in thread
From: Kees Cook @ 2021-04-21 19:26 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: James Bottomley, ksummit

On Wed, Apr 21, 2021 at 03:22:09PM -0400, Steven Rostedt wrote:
> On Wed, 21 Apr 2021 11:35:36 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > I've long been on record as not really being a fan of trivial patches
> > because they can cause merge issues with current patches and introduce
> > bugs, particularly in older drivers, that don't get detected for a long
> > while.  However, the recent events with the University of Minnesota:
> > 
> > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > 
> > Have elevated the risk factor around trivial patches claiming to fix
> > bugs to the point where it looks like there's no such thing as a truly
> > trivial patch and they all need reviewing.
> > 
> > Our policy in SCSI for a long time has been no trivial patches accepted
> > to maintained drivers, and I think that would be a good start if
> > adopted kernel wide, but I think the next policy should be no trivial
> > bug fix without a pointer to the actual bug report or report from a
> > trusted static checker.  This would likely mean we have to create a
> > list of trusted static checkers ... obviously 0day and coverity but
> > what else?
> 
> I take a lot of trivial fixes. I found two that I accepted that were from
> umn.edu, and both of them (after a second review) were legitimate fixes.
> One was in Greg's revert patch series, which I asked him to not revert, and
> the other was me looking at all patches I've received with a Cc to umn.edu
> emails, and was from a gmail account (which I'm assuming was someone that
> was part of this group).
> 
> I have no problem with taking a trivial patch if they are really fixing a
> bug. I think what needs to be done here is look at the patches that got in
> that were buggy, and see why they got in.
> 
> Perhaps the answer is to scrutinize trivial patches more. To me, the only
> "trivial" patch is a comment fix, or update to documentation. And even
> then, I spend time reviewing it.
>
> If you don't have time to review a patch, then by all means, don't accept
> it. Perhaps the answer is simply have a higher bar on what you do accept.

Agreed. I and many other folks do trivial patching all over the kernel
(though, yes, we're usually much better at describing tools, methods,
reachability, and impact), but I don't want us to swing too far in the
other direction and allow the UMN situation to have a chilling effect on
legitimate (even if "trivial") improvements.

-- 
Kees Cook

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (4 preceding siblings ...)
  2021-04-21 19:22 ` Steven Rostedt
@ 2021-04-21 19:30 ` Jiri Kosina
  2021-04-21 20:28   ` Jiri Kosina
  2021-04-21 19:47 ` Dan Carpenter
                   ` (4 subsequent siblings)
  10 siblings, 1 reply; 153+ messages in thread
From: Jiri Kosina @ 2021-04-21 19:30 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, 21 Apr 2021, James Bottomley wrote:

> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.

I am all for discussing policy of trivial patches (*), but just to make it 
clear -- I don't think that's really directly related to the University of 
Minnesota issue.

Most of the patches they sent were not really falling into the "trivial" 
category at all -- they were actual substantial functional changes. As 
such, big part of them would never meet the 'trivial' criteria as defined 
in Documentation/process/submitting-patches.rst

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:22 ` Steven Rostedt
  2021-04-21 19:26   ` Kees Cook
@ 2021-04-21 19:32   ` Roland Dreier
  2021-04-21 19:55     ` Julia Lawall
  2021-04-22  5:59     ` Christoph Hellwig
  1 sibling, 2 replies; 153+ messages in thread
From: Roland Dreier @ 2021-04-21 19:32 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: James Bottomley, ksummit

On Wed, Apr 21, 2021 at 12:22 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> I have no problem with taking a trivial patch if they are really fixing a
> bug. I think what needs to be done here is look at the patches that got in
> that were buggy, and see why they got in.
>
> Perhaps the answer is to scrutinize trivial patches more. To me, the only
> "trivial" patch is a comment fix, or update to documentation. And even
> then, I spend time reviewing it.
>
> If you don't have time to review a patch, then by all means, don't accept
> it. Perhaps the answer is simply have a higher bar on what you do accept.
>
> There are a few people that I will accept patches from with out review. But
> anyone else, I scrutinize the code before taking it in.

I agree with this.  And indeed to me perhaps what needs to be
calibrated is our definition of a trivial patch.

If someone sends a patch that changes "speling" to "spelling" in a
comment, then I think that's fine to apply without much scrutiny.  If
someone sends a patch that changes reference counting on an error
path, then that absolutely needs to be looked at to ensure
correctness.  There are enough people sending wrong patches without
even thinking about malicious actors.

I also think there does need to be a strong sanction against this UMN
research group, since we need to make sure there are strong incentives
against wasting everyone's time with stunts like this.  Hopefully on
the academic side it can be made clear that this is not ethical
research - for example, why did IEEE think this was an acceptable
paper?

 - R.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (5 preceding siblings ...)
  2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
@ 2021-04-21 19:47 ` Dan Carpenter
  2021-04-22  9:34   ` Mauro Carvalho Chehab
  2021-04-21 19:49 ` Alexandre Belloni
                   ` (3 subsequent siblings)
  10 siblings, 1 reply; 153+ messages in thread
From: Dan Carpenter @ 2021-04-21 19:47 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

I use my rename_rev.pl script to review trivial patches.  It's kind of
a crap script, but it's useful if someone is re-indenting a whole file
and adds a secret additional line.

https://github.com/error27/rename_rev

Someone who isn't as terrible at Perl could probably re-write it better.

regards,
dan carpenter


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (6 preceding siblings ...)
  2021-04-21 19:47 ` Dan Carpenter
@ 2021-04-21 19:49 ` Alexandre Belloni
  2021-04-22  2:05 ` Martin K. Petersen
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 153+ messages in thread
From: Alexandre Belloni @ 2021-04-21 19:49 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

Hi,

On 21/04/2021 11:35:36-0700, James Bottomley wrote:
> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?
> 

I find it very difficult to trust coverity because it has a tendency of
adding unnecessary checks for return values just because other drivers
are checking for the return value and this adds a lot of bloat in the
kernel for condition that will never happen on real hardware.

Also we have a lot of useless refactoring due to 0day and coccinnelle.
I'm not sure blessing any static checker is really a good option.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:32   ` Roland Dreier
@ 2021-04-21 19:55     ` Julia Lawall
  2021-04-21 20:28       ` Stephen Hemminger
  2021-04-22  5:59     ` Christoph Hellwig
  1 sibling, 1 reply; 153+ messages in thread
From: Julia Lawall @ 2021-04-21 19:55 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Steven Rostedt, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 2492 bytes --]



On Wed, 21 Apr 2021, Roland Dreier wrote:

> On Wed, Apr 21, 2021 at 12:22 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > I have no problem with taking a trivial patch if they are really fixing a
> > bug. I think what needs to be done here is look at the patches that got in
> > that were buggy, and see why they got in.
> >
> > Perhaps the answer is to scrutinize trivial patches more. To me, the only
> > "trivial" patch is a comment fix, or update to documentation. And even
> > then, I spend time reviewing it.
> >
> > If you don't have time to review a patch, then by all means, don't accept
> > it. Perhaps the answer is simply have a higher bar on what you do accept.
> >
> > There are a few people that I will accept patches from with out review. But
> > anyone else, I scrutinize the code before taking it in.
>
> I agree with this.  And indeed to me perhaps what needs to be
> calibrated is our definition of a trivial patch.
>
> If someone sends a patch that changes "speling" to "spelling" in a
> comment, then I think that's fine to apply without much scrutiny.  If
> someone sends a patch that changes reference counting on an error
> path, then that absolutely needs to be looked at to ensure
> correctness.  There are enough people sending wrong patches without
> even thinking about malicious actors.
>
> I also think there does need to be a strong sanction against this UMN
> research group, since we need to make sure there are strong incentives
> against wasting everyone's time with stunts like this.  Hopefully on
> the academic side it can be made clear that this is not ethical
> research - for example, why did IEEE think this was an acceptable
> paper?

The author's web page (https://www-users.cs.umn.edu/~kjlu/) says:

On the Feasibility of Stealthily Introducing Vulnerabilities in
Open-Source Software via Hypocrite Commits
Qiushi Wu, and Kangjie Lu.
To appear in Proceedings of the 42nd IEEE Symposium on Security and
Privacy (Oakland'21). Virtual conference, May 2021.
★ Note: The experiment did not introduce any bug or bug-introducing
commit into OSS. It demonstrated weaknesses in the patching process in a
safe way. No user was affected, and IRB exempt was issued. The experiment
actually fixed three real bugs. Please see the clarifications.
https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

He's on the program committee of the conference for next year...

[I'm just providing information, not implying that I agree with it]

julia

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:55     ` Julia Lawall
@ 2021-04-21 20:28       ` Stephen Hemminger
  2021-04-21 20:37         ` Julia Lawall
  0 siblings, 1 reply; 153+ messages in thread
From: Stephen Hemminger @ 2021-04-21 20:28 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

On Wed, 21 Apr 2021 21:55:09 +0200 (CEST)
Julia Lawall <julia.lawall@inria.fr> wrote:

> On Wed, 21 Apr 2021, Roland Dreier wrote:
> 
> > On Wed, Apr 21, 2021 at 12:22 PM Steven Rostedt <rostedt@goodmis.org> wrote:  
> > > I have no problem with taking a trivial patch if they are really fixing a
> > > bug. I think what needs to be done here is look at the patches that got in
> > > that were buggy, and see why they got in.
> > >
> > > Perhaps the answer is to scrutinize trivial patches more. To me, the only
> > > "trivial" patch is a comment fix, or update to documentation. And even
> > > then, I spend time reviewing it.
> > >
> > > If you don't have time to review a patch, then by all means, don't accept
> > > it. Perhaps the answer is simply have a higher bar on what you do accept.
> > >
> > > There are a few people that I will accept patches from with out review. But
> > > anyone else, I scrutinize the code before taking it in.  
> >
> > I agree with this.  And indeed to me perhaps what needs to be
> > calibrated is our definition of a trivial patch.
> >
> > If someone sends a patch that changes "speling" to "spelling" in a
> > comment, then I think that's fine to apply without much scrutiny.  If
> > someone sends a patch that changes reference counting on an error
> > path, then that absolutely needs to be looked at to ensure
> > correctness.  There are enough people sending wrong patches without
> > even thinking about malicious actors.
> >
> > I also think there does need to be a strong sanction against this UMN
> > research group, since we need to make sure there are strong incentives
> > against wasting everyone's time with stunts like this.  Hopefully on
> > the academic side it can be made clear that this is not ethical
> > research - for example, why did IEEE think this was an acceptable
> > paper?  
> 
> The author's web page (https://www-users.cs.umn.edu/~kjlu/) says:
> 
> On the Feasibility of Stealthily Introducing Vulnerabilities in
> Open-Source Software via Hypocrite Commits
> Qiushi Wu, and Kangjie Lu.
> To appear in Proceedings of the 42nd IEEE Symposium on Security and
> Privacy (Oakland'21). Virtual conference, May 2021.
> ★ Note: The experiment did not introduce any bug or bug-introducing
> commit into OSS. It demonstrated weaknesses in the patching process in a
> safe way. No user was affected, and IRB exempt was issued. The experiment
> actually fixed three real bugs. Please see the clarifications.
> https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf
> 
> He's on the program committee of the conference for next year...
> 
> [I'm just providing information, not implying that I agree with it]
> 
> julia

Did anyone raise the issue that this paper violates the listed disclosure
requirement on the conference website.

Ethical Considerations for Vulnerability Disclosure
Where research identifies a vulnerability (e.g., software vulnerabilities in a given program, design weaknesses in a hardware system, or any other kind of vulnerability in deployed systems), we expect that researchers act in a way that avoids gratuitous harm to affected users and, where possible, affirmatively protects those users. In nearly every case, disclosing the vulnerability to vendors of affected systems, and other stakeholders, will help protect users. It is the committee’s sense that a disclosure window of 45 days https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy to 90 days https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html ahead of publication is consistent with authors’ ethical obligations.

The version of the paper submitted for review must discuss in detail the steps the authors have taken or plan to take to address these vulnerabilities; but, consistent with the timelines above, the authors do not have to disclose vulnerabilities ahead of submission. If a paper raises significant ethical and/or legal concerns, it might be rejected based on these concerns. The PC chairs will be happy to consult with authors about how this policy applies to their submissions.


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
@ 2021-04-21 20:28   ` Jiri Kosina
  2021-04-21 22:18     ` Shuah Khan
  0 siblings, 1 reply; 153+ messages in thread
From: Jiri Kosina @ 2021-04-21 20:28 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, 21 Apr 2021, Jiri Kosina wrote:

> I am all for discussing policy of trivial patches (*), but just to make it 
> clear -- I don't think that's really directly related to the University of 
> Minnesota issue.

(*) saying that as a de-facto maintainer of trivial.git, although that 
    tree has been severely neglected over the past years. Also, as far as 
    I can say, none of the umn.edu patches went in through the trivial 
    tree

Thanks,

-- 
Jiri Kosina
Director, SUSE Labs Core

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:28       ` Stephen Hemminger
@ 2021-04-21 20:37         ` Julia Lawall
  2021-04-21 20:45           ` Steven Rostedt
  2021-04-21 21:37           ` James Morris
  0 siblings, 2 replies; 153+ messages in thread
From: Julia Lawall @ 2021-04-21 20:37 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 4598 bytes --]



On Wed, 21 Apr 2021, Stephen Hemminger wrote:

> On Wed, 21 Apr 2021 21:55:09 +0200 (CEST)
> Julia Lawall <julia.lawall@inria.fr> wrote:
>
> > On Wed, 21 Apr 2021, Roland Dreier wrote:
> >
> > > On Wed, Apr 21, 2021 at 12:22 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > > > I have no problem with taking a trivial patch if they are really fixing a
> > > > bug. I think what needs to be done here is look at the patches that got in
> > > > that were buggy, and see why they got in.
> > > >
> > > > Perhaps the answer is to scrutinize trivial patches more. To me, the only
> > > > "trivial" patch is a comment fix, or update to documentation. And even
> > > > then, I spend time reviewing it.
> > > >
> > > > If you don't have time to review a patch, then by all means, don't accept
> > > > it. Perhaps the answer is simply have a higher bar on what you do accept.
> > > >
> > > > There are a few people that I will accept patches from with out review. But
> > > > anyone else, I scrutinize the code before taking it in.
> > >
> > > I agree with this.  And indeed to me perhaps what needs to be
> > > calibrated is our definition of a trivial patch.
> > >
> > > If someone sends a patch that changes "speling" to "spelling" in a
> > > comment, then I think that's fine to apply without much scrutiny.  If
> > > someone sends a patch that changes reference counting on an error
> > > path, then that absolutely needs to be looked at to ensure
> > > correctness.  There are enough people sending wrong patches without
> > > even thinking about malicious actors.
> > >
> > > I also think there does need to be a strong sanction against this UMN
> > > research group, since we need to make sure there are strong incentives
> > > against wasting everyone's time with stunts like this.  Hopefully on
> > > the academic side it can be made clear that this is not ethical
> > > research - for example, why did IEEE think this was an acceptable
> > > paper?
> >
> > The author's web page (https://www-users.cs.umn.edu/~kjlu/) says:
> >
> > On the Feasibility of Stealthily Introducing Vulnerabilities in
> > Open-Source Software via Hypocrite Commits
> > Qiushi Wu, and Kangjie Lu.
> > To appear in Proceedings of the 42nd IEEE Symposium on Security and
> > Privacy (Oakland'21). Virtual conference, May 2021.
> > ★ Note: The experiment did not introduce any bug or bug-introducing
> > commit into OSS. It demonstrated weaknesses in the patching process in a
> > safe way. No user was affected, and IRB exempt was issued. The experiment
> > actually fixed three real bugs. Please see the clarifications.
> > https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf
> >
> > He's on the program committee of the conference for next year...
> >
> > [I'm just providing information, not implying that I agree with it]
> >
> > julia
>
> Did anyone raise the issue that this paper violates the listed disclosure
> requirement on the conference website.
>
> Ethical Considerations for Vulnerability Disclosure
> Where research identifies a vulnerability (e.g., software vulnerabilities in a given program, design weaknesses in a hardware system, or any other kind of vulnerability in deployed systems), we expect that researchers act in a way that avoids gratuitous harm to affected users and, where possible, affirmatively protects those users. In nearly every case, disclosing the vulnerability to vendors of affected systems, and other stakeholders, will help protect users. It is the committee’s sense that a disclosure window of 45 days https://vuls.cert.org/confluence/display/Wiki/Vulnerability+Disclosure+Policy to 90 days https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-faq.html ahead of publication is consistent with authors’ ethical obligations.
>
> The version of the paper submitted for review must discuss in detail the steps the authors have taken or plan to take to address these vulnerabilities; but, consistent with the timelines above, the authors do not have to disclose vulnerabilities ahead of submission. If a paper raises significant ethical and/or legal concerns, it might be rejected based on these concerns. The PC chairs will be happy to consult with authors about how this policy applies to their submissions.

The apology states that they didn't detect any vulnerabilities.  They
found three non exploitable bugs and submitted incorrect patches for them.
When the patches received some positive feedback, they explained that the
patches were incorrect and provided a proper fix.

So they damaged trust, but not actually the Linux kernel...

julia

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:37         ` Julia Lawall
@ 2021-04-21 20:45           ` Steven Rostedt
  2021-04-21 20:50             ` Julia Lawall
  2021-04-21 21:37           ` James Morris
  1 sibling, 1 reply; 153+ messages in thread
From: Steven Rostedt @ 2021-04-21 20:45 UTC (permalink / raw)
  To: Julia Lawall; +Cc: Stephen Hemminger, Roland Dreier, James Bottomley, ksummit

On Wed, 21 Apr 2021 22:37:55 +0200 (CEST)
Julia Lawall <julia.lawall@inria.fr> wrote:

> The apology states that they didn't detect any vulnerabilities.  They
> found three non exploitable bugs and submitted incorrect patches for them.
> When the patches received some positive feedback, they explained that the
> patches were incorrect and provided a proper fix.
> 
> So they damaged trust, but not actually the Linux kernel...

That's what they stated, but did any patch that they knew was incorrect
actually make it into the kernel? If so, then it's on them.

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:45           ` Steven Rostedt
@ 2021-04-21 20:50             ` Julia Lawall
  2021-04-21 21:03               ` Jiri Kosina
  0 siblings, 1 reply; 153+ messages in thread
From: Julia Lawall @ 2021-04-21 20:50 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Stephen Hemminger, Roland Dreier, James Bottomley, ksummit



On Wed, 21 Apr 2021, Steven Rostedt wrote:

> On Wed, 21 Apr 2021 22:37:55 +0200 (CEST)
> Julia Lawall <julia.lawall@inria.fr> wrote:
>
> > The apology states that they didn't detect any vulnerabilities.  They
> > found three non exploitable bugs and submitted incorrect patches for them.
> > When the patches received some positive feedback, they explained that the
> > patches were incorrect and provided a proper fix.
> >
> > So they damaged trust, but not actually the Linux kernel...
>
> That's what they stated, but did any patch that they knew was incorrect
> actually make it into the kernel? If so, then it's on them.

No idea.  The apology goes to great lengths to say that none did, but who
knows.

julia

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:50             ` Julia Lawall
@ 2021-04-21 21:03               ` Jiri Kosina
  0 siblings, 0 replies; 153+ messages in thread
From: Jiri Kosina @ 2021-04-21 21:03 UTC (permalink / raw)
  To: Julia Lawall
  Cc: Steven Rostedt, Stephen Hemminger, Roland Dreier,
	James Bottomley, ksummit

On Wed, 21 Apr 2021, Julia Lawall wrote:

> > > The apology states that they didn't detect any vulnerabilities.  They
> > > found three non exploitable bugs and submitted incorrect patches for them.
> > > When the patches received some positive feedback, they explained that the
> > > patches were incorrect and provided a proper fix.
> > >
> > > So they damaged trust, but not actually the Linux kernel...
> >
> > That's what they stated, but did any patch that they knew was incorrect
> > actually make it into the kernel? If so, then it's on them.
> 
> No idea.  The apology goes to great lengths to say that none did, but who
> knows.

There are at least two commmits referenced in the LKML thread 
(pci_slot_release() wild dereference and missed unlock in set_fan_div()) 
where new security/stability issue was introduced by the patches.

Of course, under normal circumstances, noone would ever be publicly 
grilled about introducing such an issue in a bugfix by mistake, but this 
is a special case.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:37         ` Julia Lawall
  2021-04-21 20:45           ` Steven Rostedt
@ 2021-04-21 21:37           ` James Morris
  2021-04-22  7:34             ` Geert Uytterhoeven
  1 sibling, 1 reply; 153+ messages in thread
From: James Morris @ 2021-04-21 21:37 UTC (permalink / raw)
  To: Julia Lawall
  Cc: Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Wed, 21 Apr 2021, Julia Lawall wrote:

> The apology states that they didn't detect any vulnerabilities.  They
> found three non exploitable bugs and submitted incorrect patches for them.
> When the patches received some positive feedback, they explained that the
> patches were incorrect and provided a proper fix.
> 
> So they damaged trust, but not actually the Linux kernel...

The issue is that there was no consent and no coordination, so we don't 
know the scope of the experiment and whether it was still continuing. 

We are this not able to trust anything the group said about what they'd
done or not done, until now [1].

In all probability there is nothing further amiss but we would not have 
expected them to use fake gmail accounts to submit bugs to the kernel 
either.

It's now on us to audit all of their known contributions, because we don't 
know the scope of the experiment, which was based on the use of deception, 
and we can't make any assumptions based on what they have said.

We also need the identity of the 'random' gmail accounts they used, 
although this should be handled by a small trusted group in private, as it 
will lead to privacy issues for kernel maintainers who responded to them 
in public.


[1] The UMN CS leadership has made a public statement now that the 
research is now suspended: 
https://twitter.com/UMNComputerSci/status/1384948683821694976


-- 
James Morris
<jmorris@namei.org>


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 20:28   ` Jiri Kosina
@ 2021-04-21 22:18     ` Shuah Khan
  2021-04-21 23:17       ` Guenter Roeck
  0 siblings, 1 reply; 153+ messages in thread
From: Shuah Khan @ 2021-04-21 22:18 UTC (permalink / raw)
  To: Jiri Kosina, James Bottomley; +Cc: ksummit, Shuah Khan

On 4/21/21 2:28 PM, Jiri Kosina wrote:
> On Wed, 21 Apr 2021, Jiri Kosina wrote:
> 
>> I am all for discussing policy of trivial patches (*), but just to make it
>> clear -- I don't think that's really directly related to the University of
>> Minnesota issue.
> 
> (*) saying that as a de-facto maintainer of trivial.git, although that
>      tree has been severely neglected over the past years. Also, as far as
>      I can say, none of the umn.edu patches went in through the trivial
>      tree
> 

I agree. I looked at a few including this one:

8e949363f017e2011464812a714fb29710fb95b4
net: mlx5: Add a missing check on idr_find, free buf

Definitely doesn't fall under trivial category. It is unfortunate
that we are in the situation to not be able to trust patches as we
do get fix patches for syzbot bugs from new developers.

There are no easy solutions other than reviews. Trivial patch focused
policy will not help address this problem.

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 22:18     ` Shuah Khan
@ 2021-04-21 23:17       ` Guenter Roeck
  2021-04-21 23:21         ` Shuah Khan
  0 siblings, 1 reply; 153+ messages in thread
From: Guenter Roeck @ 2021-04-21 23:17 UTC (permalink / raw)
  To: Shuah Khan; +Cc: Jiri Kosina, James Bottomley, ksummit

On Wed, Apr 21, 2021 at 04:18:15PM -0600, Shuah Khan wrote:
> On 4/21/21 2:28 PM, Jiri Kosina wrote:
> > On Wed, 21 Apr 2021, Jiri Kosina wrote:
> > 
> > > I am all for discussing policy of trivial patches (*), but just to make it
> > > clear -- I don't think that's really directly related to the University of
> > > Minnesota issue.
> > 
> > (*) saying that as a de-facto maintainer of trivial.git, although that
> >      tree has been severely neglected over the past years. Also, as far as
> >      I can say, none of the umn.edu patches went in through the trivial
> >      tree
> > 
> 
> I agree. I looked at a few including this one:
> 
> 8e949363f017e2011464812a714fb29710fb95b4
> net: mlx5: Add a missing check on idr_find, free buf
> 

Coincidentally that introduced a UAF (or, rather, made an existing UAF
worse) which was later fixed with commit 31634bf5dcc4. Was that one of
the experiments ?

Guenter

> Definitely doesn't fall under trivial category. It is unfortunate
> that we are in the situation to not be able to trust patches as we
> do get fix patches for syzbot bugs from new developers.
> 
> There are no easy solutions other than reviews. Trivial patch focused
> policy will not help address this problem.
> 
> thanks,
> -- Shuah
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 23:17       ` Guenter Roeck
@ 2021-04-21 23:21         ` Shuah Khan
  0 siblings, 0 replies; 153+ messages in thread
From: Shuah Khan @ 2021-04-21 23:21 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: Jiri Kosina, James Bottomley, ksummit, Shuah Khan

On 4/21/21 5:17 PM, Guenter Roeck wrote:
> On Wed, Apr 21, 2021 at 04:18:15PM -0600, Shuah Khan wrote:
>> On 4/21/21 2:28 PM, Jiri Kosina wrote:
>>> On Wed, 21 Apr 2021, Jiri Kosina wrote:
>>>
>>>> I am all for discussing policy of trivial patches (*), but just to make it
>>>> clear -- I don't think that's really directly related to the University of
>>>> Minnesota issue.
>>>
>>> (*) saying that as a de-facto maintainer of trivial.git, although that
>>>       tree has been severely neglected over the past years. Also, as far as
>>>       I can say, none of the umn.edu patches went in through the trivial
>>>       tree
>>>
>>
>> I agree. I looked at a few including this one:
>>
>> 8e949363f017e2011464812a714fb29710fb95b4
>> net: mlx5: Add a missing check on idr_find, free buf
>>
> 
> Coincidentally that introduced a UAF (or, rather, made an existing UAF
> worse) which was later fixed with commit 31634bf5dcc4. Was that one of
> the experiments ?
> 

Correct. The problem was found and fixed in subsequent commits.

thanks,
-- Shuah


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (7 preceding siblings ...)
  2021-04-21 19:49 ` Alexandre Belloni
@ 2021-04-22  2:05 ` Martin K. Petersen
  2021-04-22  3:04   ` Joe Perches
  2021-04-22  4:21 ` Leon Romanovsky
  2021-04-22 10:35 ` Mauro Carvalho Chehab
  10 siblings, 1 reply; 153+ messages in thread
From: Martin K. Petersen @ 2021-04-22  2:05 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit


James,

> Our policy in SCSI for a long time has been no trivial patches
> accepted to maintained drivers,

I'm afraid that ship sailed years ago. I am merging a ton of trivial
patches in SCSI.

The reality is that not merging trivial patches is a losing battle. The
various static checkers appear to develop defect detection parity and
gcc and LLVM get more picky with every release. Consequently, if I don't
apply a trivial patch, I'll end up having a variant of the same fix show
up in my inbox weekly until the end of time. I have no choice but to
apply.

A compounding problem is that many individual driver developers are
overwhelmed by the constant flurry of trivial patches and therefore
ignore them. So from a practical perspective there is very little
difference between maintained and unmaintained drivers in the trivial
patch department.

Given the ongoing advances in compilers and static analysis I don't
think that simply ignoring these patches is a realistic approach. The
reported defect list will inevitably keep growing. But I do think that
we need a better process and more contributor mentoring. A lot of these
patches are poorly documented, don't apply to my for-next, have been
fixed for weeks, etc.

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  2:05 ` Martin K. Petersen
@ 2021-04-22  3:04   ` Joe Perches
  2021-04-22 10:13     ` Mauro Carvalho Chehab
                       ` (2 more replies)
  0 siblings, 3 replies; 153+ messages in thread
From: Joe Perches @ 2021-04-22  3:04 UTC (permalink / raw)
  To: Martin K. Petersen, James Bottomley; +Cc: ksummit

On Wed, 2021-04-21 at 22:05 -0400, Martin K. Petersen wrote:
> James,
> 
> > Our policy in SCSI for a long time has been no trivial patches
> > accepted to maintained drivers,
> 
> I'm afraid that ship sailed years ago. I am merging a ton of trivial
> patches in SCSI.

True and thank you.

Perhaps the primary thing that James' email shows is that he's not
actively watching drivers/scsi/ git tree changes very much.

And I believe James is referring to whitespace style trivial patches.

> The reality is that not merging trivial patches is a losing battle. The
> various static checkers appear to develop defect detection parity and
> gcc and LLVM get more picky with every release.

True, but perhaps most of the pickiness can be mitigated by moving
various warnings to W=2 or W=3.

> Consequently, if I don't
> apply a trivial patch, I'll end up having a variant of the same fix show
> up in my inbox weekly until the end of time. I have no choice but to
> apply.
> 
> A compounding problem is that many individual driver developers are
> overwhelmed by the constant flurry of trivial patches and therefore
> ignore them.

I believe it's more like some or most individual driver developers
do not actually actively maintain their drivers and the MAINTAINER
section for various drivers are more like vanity or historical lists.

It's true when the driver is first submitted and under review, many
driver developers do take and apply feedback, but the period for
most developers to actively track changes ends when the driver is
accepted into the mainline tree.

> So from a practical perspective there is very little
> difference between maintained and unmaintained drivers in the trivial
> patch department.



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (8 preceding siblings ...)
  2021-04-22  2:05 ` Martin K. Petersen
@ 2021-04-22  4:21 ` Leon Romanovsky
  2021-04-22  4:56   ` Al Viro
                     ` (3 more replies)
  2021-04-22 10:35 ` Mauro Carvalho Chehab
  10 siblings, 4 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22  4:21 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.

While we are talking about policies, I would like to raise another bad
practice that is done by even seasoned developers - sending patches with
carefully crafted and filtered TO and CC.

This practice causes to get out of context patches without ability to
see whole picture and the worse part that it divides feedback to
"islands" without ability to agree or disagree with the feedback.

I'm putting this link as an EXAMPLE where every patch has different CC participants:
https://lore.kernel.org/linux-rdma/CAJX1Ytb=XYKGeYuEN-2tPv9hx3G+=wnGWMzPk893J__JJFyhGQ@mail.gmail.com/T/#mf56c926ec0279a65fe180110b7dcf93fe053b91a

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:21 ` Leon Romanovsky
@ 2021-04-22  4:56   ` Al Viro
  2021-04-22  5:52     ` Leon Romanovsky
  2021-04-22  6:05     ` Christoph Hellwig
  2021-04-22  6:03   ` Christoph Hellwig
                     ` (2 subsequent siblings)
  3 siblings, 2 replies; 153+ messages in thread
From: Al Viro @ 2021-04-22  4:56 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> > I've long been on record as not really being a fan of trivial patches
> > because they can cause merge issues with current patches and introduce
> > bugs, particularly in older drivers, that don't get detected for a long
> > while.  However, the recent events with the University of Minnesota:
> > 
> > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > 
> > Have elevated the risk factor around trivial patches claiming to fix
> > bugs to the point where it looks like there's no such thing as a truly
> > trivial patch and they all need reviewing.
> 
> While we are talking about policies, I would like to raise another bad
> practice that is done by even seasoned developers - sending patches with
> carefully crafted and filtered TO and CC.
> 
> This practice causes to get out of context patches without ability to
> see whole picture and the worse part that it divides feedback to
> "islands" without ability to agree or disagree with the feedback.

Suppose you have a 60-patch series, with 56 in fs/*.c (and related headers
in include/linux) and 4 - in arch/*/include/asm/*; should e.g. MIPS folks
get spammed with the entire thing, just because one patch consolidates
some ifdefs?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:56   ` Al Viro
@ 2021-04-22  5:52     ` Leon Romanovsky
  2021-04-22  6:05     ` Christoph Hellwig
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22  5:52 UTC (permalink / raw)
  To: Al Viro; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 04:56:28AM +0000, Al Viro wrote:
> On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> > > I've long been on record as not really being a fan of trivial patches
> > > because they can cause merge issues with current patches and introduce
> > > bugs, particularly in older drivers, that don't get detected for a long
> > > while.  However, the recent events with the University of Minnesota:
> > > 
> > > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > > 
> > > Have elevated the risk factor around trivial patches claiming to fix
> > > bugs to the point where it looks like there's no such thing as a truly
> > > trivial patch and they all need reviewing.
> > 
> > While we are talking about policies, I would like to raise another bad
> > practice that is done by even seasoned developers - sending patches with
> > carefully crafted and filtered TO and CC.
> > 
> > This practice causes to get out of context patches without ability to
> > see whole picture and the worse part that it divides feedback to
> > "islands" without ability to agree or disagree with the feedback.
> 
> Suppose you have a 60-patch series, with 56 in fs/*.c (and related headers
> in include/linux) and 4 - in arch/*/include/asm/*; should e.g. MIPS folks
> get spammed with the entire thing, just because one patch consolidates
> some ifdefs?

Yes, I still would like to see whole series, because such patch bombs
are not supposed to be too often and if they are, it can hint that the
changed area needs some restructure/changes/e.t.c to make submission
easier.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:32   ` Roland Dreier
  2021-04-21 19:55     ` Julia Lawall
@ 2021-04-22  5:59     ` Christoph Hellwig
  2021-04-22  6:28       ` Tomasz Figa
                         ` (3 more replies)
  1 sibling, 4 replies; 153+ messages in thread
From: Christoph Hellwig @ 2021-04-22  5:59 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Steven Rostedt, James Bottomley, ksummit

On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> I also think there does need to be a strong sanction against this UMN
> research group, since we need to make sure there are strong incentives
> against wasting everyone's time with stunts like this.  Hopefully on
> the academic side it can be made clear that this is not ethical
> research - for example, why did IEEE think this was an acceptable
> paper?

I wholeheartedly disagree.  Demonstrating this kind of "attack" has
been long overdue, and kicked off a very important discussion.  Even
more so as in this area malice is almost indistinguishable from normal
incompetence.  I think they deserve a medel of honor.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:21 ` Leon Romanovsky
  2021-04-22  4:56   ` Al Viro
@ 2021-04-22  6:03   ` Christoph Hellwig
  2021-04-22  6:18     ` Leon Romanovsky
  2021-04-22  9:20   ` Mauro Carvalho Chehab
  2021-04-22 12:40   ` Mark Brown
  3 siblings, 1 reply; 153+ messages in thread
From: Christoph Hellwig @ 2021-04-22  6:03 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> While we are talking about policies, I would like to raise another bad
> practice that is done by even seasoned developers - sending patches with
> carefully crafted and filtered TO and CC.
> 
> This practice causes to get out of context patches without ability to
> see whole picture and the worse part that it divides feedback to
> "islands" without ability to agree or disagree with the feedback.

Yes.  Depending on my mood I'll ask for a proper resend or will just
ignore that kind of crap, as it is completely unreviewable.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:56   ` Al Viro
  2021-04-22  5:52     ` Leon Romanovsky
@ 2021-04-22  6:05     ` Christoph Hellwig
  1 sibling, 0 replies; 153+ messages in thread
From: Christoph Hellwig @ 2021-04-22  6:05 UTC (permalink / raw)
  To: Al Viro; +Cc: Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 04:56:28AM +0000, Al Viro wrote:
> > This practice causes to get out of context patches without ability to
> > see whole picture and the worse part that it divides feedback to
> > "islands" without ability to agree or disagree with the feedback.
> 
> Suppose you have a 60-patch series, with 56 in fs/*.c (and related headers
> in include/linux) and 4 - in arch/*/include/asm/*; should e.g. MIPS folks
> get spammed with the entire thing, just because one patch consolidates
> some ifdefs?

If it is all related: absolutly.  If no just split it into two or more
series.


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  6:03   ` Christoph Hellwig
@ 2021-04-22  6:18     ` Leon Romanovsky
  0 siblings, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22  6:18 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 07:03:39AM +0100, Christoph Hellwig wrote:
> On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > While we are talking about policies, I would like to raise another bad
> > practice that is done by even seasoned developers - sending patches with
> > carefully crafted and filtered TO and CC.
> > 
> > This practice causes to get out of context patches without ability to
> > see whole picture and the worse part that it divides feedback to
> > "islands" without ability to agree or disagree with the feedback.
> 
> Yes.  Depending on my mood I'll ask for a proper resend or will just
> ignore that kind of crap, as it is completely unreviewable.

Such ignore gives false feeling that you are OK with the changes.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  5:59     ` Christoph Hellwig
@ 2021-04-22  6:28       ` Tomasz Figa
  2021-04-22  7:05         ` Al Viro
  2021-04-22  7:06         ` H. Peter Anvin
  2021-04-22  7:05       ` Jiri Kosina
                         ` (2 subsequent siblings)
  3 siblings, 2 replies; 153+ messages in thread
From: Tomasz Figa @ 2021-04-22  6:28 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

2021年4月22日(木) 15:01 Christoph Hellwig <hch@infradead.org>:
>
> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > I also think there does need to be a strong sanction against this UMN
> > research group, since we need to make sure there are strong incentives
> > against wasting everyone's time with stunts like this.  Hopefully on
> > the academic side it can be made clear that this is not ethical
> > research - for example, why did IEEE think this was an acceptable
> > paper?
>
> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> been long overdue, and kicked off a very important discussion.  Even
> more so as in this area malice is almost indistinguishable from normal
> incompetence.  I think they deserve a medel of honor.
>

Agreed with Christoph. We are talking here about a critical piece of
the software that is the foundation of security of the whole system.
That we have a problem with the volume of reviews has been a topic on
various conferences since years and my experience is that it hasn't
really improved. As a part of my Chromium work, I often find upstream
code with issues that make me really concerned about the quality of
the review it received. Not saying it applies to all subsystems of
course, but not limited to single special cases either.

That said, I think UMN should have done this in a more ethical way.
For example, someone from the kernel community could have been
involved as a supervisor, to prevent things from running out of
control and ending up as real exploits and also to facilitate a
clean-up after the experiment ends. Also the fact that they are
denying this now is concerning.

Best regards,
Tomasz

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  6:28       ` Tomasz Figa
@ 2021-04-22  7:05         ` Al Viro
  2021-04-22  7:46           ` Al Viro
  2021-04-22  7:06         ` H. Peter Anvin
  1 sibling, 1 reply; 153+ messages in thread
From: Al Viro @ 2021-04-22  7:05 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: Christoph Hellwig, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 03:28:25PM +0900, Tomasz Figa wrote:
> 2021年4月22日(木) 15:01 Christoph Hellwig <hch@infradead.org>:
> >
> > On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > > I also think there does need to be a strong sanction against this UMN
> > > research group, since we need to make sure there are strong incentives
> > > against wasting everyone's time with stunts like this.  Hopefully on
> > > the academic side it can be made clear that this is not ethical
> > > research - for example, why did IEEE think this was an acceptable
> > > paper?
> >
> > I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> > been long overdue, and kicked off a very important discussion.  Even
> > more so as in this area malice is almost indistinguishable from normal
> > incompetence.  I think they deserve a medel of honor.
> >
> 
> Agreed with Christoph. We are talking here about a critical piece of
> the software that is the foundation of security of the whole system.
> That we have a problem with the volume of reviews has been a topic on
> various conferences since years and my experience is that it hasn't
> really improved. As a part of my Chromium work, I often find upstream
> code with issues that make me really concerned about the quality of
> the review it received. Not saying it applies to all subsystems of
> course, but not limited to single special cases either.
> 
> That said, I think UMN should have done this in a more ethical way.
> For example, someone from the kernel community could have been
> involved as a supervisor, to prevent things from running out of
> control and ending up as real exploits and also to facilitate a
> clean-up after the experiment ends. Also the fact that they are
> denying this now is concerning.

Three words: list of SHA1.  Posted once their experiment had been finished.
AFAICS, they have *not* bothered to publish that, and when a paper mentions
raising awareness, you really want to see the raw data.  Cf. "framing",
"advocacy", "science by press conference", etc.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  5:59     ` Christoph Hellwig
  2021-04-22  6:28       ` Tomasz Figa
@ 2021-04-22  7:05       ` Jiri Kosina
  2021-04-22 16:05       ` Roland Dreier
  2021-04-22 18:03       ` Al Viro
  3 siblings, 0 replies; 153+ messages in thread
From: Jiri Kosina @ 2021-04-22  7:05 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

On Thu, 22 Apr 2021, Christoph Hellwig wrote:

> Demonstrating this kind of "attack" has been long overdue, and kicked 
> off a very important discussion.  Even more so as in this area malice is 
> almost indistinguishable from normal incompetence.  I think they deserve 
> a medel of honor.

I think they just demonstrated the obvious.

I doubt anyone was ever questioning the fact that given enough effort 
investment and creativity, you can sneak malicious code anywhere at least 
for a while; so proving the obvious was just a sort of pointless excercise 
at the cost of a lot of wasted time in my view.

There are interesting things that could be researched here, e.g. how long 
do bugs remain unnoticed before they are eventually fixed by someone 
(perhaps in corelation to the size of the community of the project), etc. 
But that doesn't seem to be what's been researched here.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  6:28       ` Tomasz Figa
  2021-04-22  7:05         ` Al Viro
@ 2021-04-22  7:06         ` H. Peter Anvin
  1 sibling, 0 replies; 153+ messages in thread
From: H. Peter Anvin @ 2021-04-22  7:06 UTC (permalink / raw)
  To: Tomasz Figa, Christoph Hellwig
  Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

And *that* is the fundamental problem here. 
Pen testing without permission is at best unethical, and often illegal.

On April 21, 2021 11:28:25 PM PDT, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>2021年4月22日(木) 15:01 Christoph Hellwig <hch@infradead.org>:
>>
>> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
>> > I also think there does need to be a strong sanction against this
>UMN
>> > research group, since we need to make sure there are strong
>incentives
>> > against wasting everyone's time with stunts like this.  Hopefully
>on
>> > the academic side it can be made clear that this is not ethical
>> > research - for example, why did IEEE think this was an acceptable
>> > paper?
>>
>> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
>> been long overdue, and kicked off a very important discussion.  Even
>> more so as in this area malice is almost indistinguishable from
>normal
>> incompetence.  I think they deserve a medel of honor.
>>
>
>Agreed with Christoph. We are talking here about a critical piece of
>the software that is the foundation of security of the whole system.
>That we have a problem with the volume of reviews has been a topic on
>various conferences since years and my experience is that it hasn't
>really improved. As a part of my Chromium work, I often find upstream
>code with issues that make me really concerned about the quality of
>the review it received. Not saying it applies to all subsystems of
>course, but not limited to single special cases either.
>
>That said, I think UMN should have done this in a more ethical way.
>For example, someone from the kernel community could have been
>involved as a supervisor, to prevent things from running out of
>control and ending up as real exploits and also to facilitate a
>clean-up after the experiment ends. Also the fact that they are
>denying this now is concerning.
>
>Best regards,
>Tomasz

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 21:37           ` James Morris
@ 2021-04-22  7:34             ` Geert Uytterhoeven
  2021-04-22  7:51               ` Mike Rapoport
  2021-04-22  9:55               ` Mauro Carvalho Chehab
  0 siblings, 2 replies; 153+ messages in thread
From: Geert Uytterhoeven @ 2021-04-22  7:34 UTC (permalink / raw)
  To: James Morris
  Cc: Julia Lawall, Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> On Wed, 21 Apr 2021, Julia Lawall wrote:
> > The apology states that they didn't detect any vulnerabilities.  They
> > found three non exploitable bugs and submitted incorrect patches for them.
> > When the patches received some positive feedback, they explained that the
> > patches were incorrect and provided a proper fix.
> >
> > So they damaged trust, but not actually the Linux kernel...
>
> The issue is that there was no consent and no coordination, so we don't
> know the scope of the experiment and whether it was still continuing.
>
> We are this not able to trust anything the group said about what they'd
> done or not done, until now [1].
>
> In all probability there is nothing further amiss but we would not have
> expected them to use fake gmail accounts to submit bugs to the kernel
> either.
>
> It's now on us to audit all of their known contributions, because we don't
> know the scope of the experiment, which was based on the use of deception,
> and we can't make any assumptions based on what they have said.
>
> We also need the identity of the 'random' gmail accounts they used,
> although this should be handled by a small trusted group in private, as it
> will lead to privacy issues for kernel maintainers who responded to them
> in public.

What do we gain by blindly reverting all[1] umn.edu patches, and
ignoring future patches from umn.edu?
I think all of this is moot: other people may be doing the same thing,
or even "in worse faith".  The only thing that helps is making sure
patches get reviewed[2] before being applied.

[1] Judging from the new review comments, many of the 190 patches
    to be reverted were real fixes.
[2] Whether we can trust the reviewers is another question, and might
    become the topic of another research project :-(

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	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  7:05         ` Al Viro
@ 2021-04-22  7:46           ` Al Viro
  0 siblings, 0 replies; 153+ messages in thread
From: Al Viro @ 2021-04-22  7:46 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: Christoph Hellwig, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 07:05:19AM +0000, Al Viro wrote:
> > > I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> > > been long overdue, and kicked off a very important discussion.  Even
> > > more so as in this area malice is almost indistinguishable from normal
> > > incompetence.  I think they deserve a medel of honor.
> > >
> > 
> > Agreed with Christoph. We are talking here about a critical piece of
> > the software that is the foundation of security of the whole system.
> > That we have a problem with the volume of reviews has been a topic on
> > various conferences since years and my experience is that it hasn't
> > really improved. As a part of my Chromium work, I often find upstream
> > code with issues that make me really concerned about the quality of
> > the review it received. Not saying it applies to all subsystems of
> > course, but not limited to single special cases either.
> > 
> > That said, I think UMN should have done this in a more ethical way.
> > For example, someone from the kernel community could have been
> > involved as a supervisor, to prevent things from running out of
> > control and ending up as real exploits and also to facilitate a
> > clean-up after the experiment ends. Also the fact that they are
> > denying this now is concerning.
> 
> Three words: list of SHA1.  Posted once their experiment had been finished.
> AFAICS, they have *not* bothered to publish that, and when a paper mentions
> raising awareness, you really want to see the raw data.  Cf. "framing",
> "advocacy", "science by press conference", etc.

BTW, according to one of the authors, currently "All of the commits sent
by my students are in good faith to fix some bugs."  And apparently that
includes 0c85a7e87465.  OK, we'd all posted embarrassingly dumb patches
and some of those got merged, but normally once that becomes known
what follows is some expression of embarrassment and request to revert
the damn thing (or "here's the fix", but that obviously does not apply
in this case).  Nothing of that kind has happened in public, and if
revert request went straight to Linus, I'd expect that commit to have
been reverted by now.  It is not.

Possibilities:
	* that PhD student currently net.dead and had been since the first
responses appeared (Apr 9).  Contradicts known facts - the guy had net
access at least over the last several days.
	* PhD student in question is honestly unaware that retraction or
correction of known mistake in a publication is expected.  Possible, but
in that case his advisor is not doing him any favours by not informing
him of such expectations.
	* PhD student in question still believes that the patch is
not garbage.  Again, possible, but... with that level of illiteracy
I'd expect him to have run into trouble much earlier.
	* Professor is entirely honest, but the student in question is
not his.
	* Professor is not entirely honest.
	* Something else.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  7:34             ` Geert Uytterhoeven
@ 2021-04-22  7:51               ` Mike Rapoport
  2021-04-22  8:45                 ` Christian Brauner
  2021-04-22  9:39                 ` Mauro Carvalho Chehab
  2021-04-22  9:55               ` Mauro Carvalho Chehab
  1 sibling, 2 replies; 153+ messages in thread
From: Mike Rapoport @ 2021-04-22  7:51 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: James Morris, Julia Lawall, Stephen Hemminger, Roland Dreier,
	Steven Rostedt, James Bottomley, ksummit

Hi,

On Thu, Apr 22, 2021 at 09:34:38AM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> > On Wed, 21 Apr 2021, Julia Lawall wrote:
> > > The apology states that they didn't detect any vulnerabilities.  They
> > > found three non exploitable bugs and submitted incorrect patches for them.
> > > When the patches received some positive feedback, they explained that the
> > > patches were incorrect and provided a proper fix.
> > >
> > > So they damaged trust, but not actually the Linux kernel...
> >
> > The issue is that there was no consent and no coordination, so we don't
> > know the scope of the experiment and whether it was still continuing.
> >
> > We are this not able to trust anything the group said about what they'd
> > done or not done, until now [1].
> >
> > In all probability there is nothing further amiss but we would not have
> > expected them to use fake gmail accounts to submit bugs to the kernel
> > either.
> >
> > It's now on us to audit all of their known contributions, because we don't
> > know the scope of the experiment, which was based on the use of deception,
> > and we can't make any assumptions based on what they have said.
> >
> > We also need the identity of the 'random' gmail accounts they used,
> > although this should be handled by a small trusted group in private, as it
> > will lead to privacy issues for kernel maintainers who responded to them
> > in public.
> 
> What do we gain by blindly reverting all[1] umn.edu patches, and
> ignoring future patches from umn.edu?
> I think all of this is moot: other people may be doing the same thing,
> or even "in worse faith".  The only thing that helps is making sure
> patches get reviewed[2] before being applied.
> 
> [1] Judging from the new review comments, many of the 190 patches
>     to be reverted were real fixes.
> [2] Whether we can trust the reviewers is another question, and might
>     become the topic of another research project :-(

Hopefully such research will require too much effort and won't get funding :)

Now seriously, I agree with Jiri that this research is proving the obvious
that given enough effort somebody can add malicious code to any open source
project. People make mistakes and even rightfully trusted reviewers may
miss some issues during the review.

And since that's given this research only emphasizes the importance of
testing/fuzzing/CI etc.

> 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
> 

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  7:51               ` Mike Rapoport
@ 2021-04-22  8:45                 ` Christian Brauner
  2021-04-22 15:27                   ` Steven Rostedt
  2021-04-22  9:39                 ` Mauro Carvalho Chehab
  1 sibling, 1 reply; 153+ messages in thread
From: Christian Brauner @ 2021-04-22  8:45 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 10:51:12AM +0300, Mike Rapoport wrote:
> Hi,
> 
> On Thu, Apr 22, 2021 at 09:34:38AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> > > On Wed, 21 Apr 2021, Julia Lawall wrote:
> > > > The apology states that they didn't detect any vulnerabilities.  They
> > > > found three non exploitable bugs and submitted incorrect patches for them.
> > > > When the patches received some positive feedback, they explained that the
> > > > patches were incorrect and provided a proper fix.
> > > >
> > > > So they damaged trust, but not actually the Linux kernel...
> > >
> > > The issue is that there was no consent and no coordination, so we don't
> > > know the scope of the experiment and whether it was still continuing.
> > >
> > > We are this not able to trust anything the group said about what they'd
> > > done or not done, until now [1].
> > >
> > > In all probability there is nothing further amiss but we would not have
> > > expected them to use fake gmail accounts to submit bugs to the kernel
> > > either.
> > >
> > > It's now on us to audit all of their known contributions, because we don't
> > > know the scope of the experiment, which was based on the use of deception,
> > > and we can't make any assumptions based on what they have said.
> > >
> > > We also need the identity of the 'random' gmail accounts they used,
> > > although this should be handled by a small trusted group in private, as it
> > > will lead to privacy issues for kernel maintainers who responded to them
> > > in public.
> > 
> > What do we gain by blindly reverting all[1] umn.edu patches, and
> > ignoring future patches from umn.edu?
> > I think all of this is moot: other people may be doing the same thing,
> > or even "in worse faith".  The only thing that helps is making sure
> > patches get reviewed[2] before being applied.
> > 
> > [1] Judging from the new review comments, many of the 190 patches
> >     to be reverted were real fixes.
> > [2] Whether we can trust the reviewers is another question, and might
> >     become the topic of another research project :-(
> 
> Hopefully such research will require too much effort and won't get funding :)
> 
> Now seriously, I agree with Jiri that this research is proving the obvious
> that given enough effort somebody can add malicious code to any open source

Research like this has existed before. They even link to some of it in
their paper. Their "hypocritial commit" concept seems like a classic
example of giving a corner-case its own definition (Which is fine of
course.). They essentially seem to argue that it's different from Trojan
Horse commits that introduce direct vulnerabilities aka the classic
(2003?) if (foo & (__WCLONE | __WALL) && current->uid = 0)
in that they introduce vulnerabilities as side-effects which yeah.
It's good that it triggered a discussion even if the way this is done is
(also academically) suboptimal.
There's a reason why prior research into Trojan Horse contributions
didn't just go out and try to place bugs into existing software on such
a large scale. (The fact that even one buggy commit - accident or not -
from their group made it into the kernel renders the whole research
project ethically questionable.)

Does the possibility of introducing bugs on purpose have to have
immediate global consequences for our review processes is a question I
find particularly hard to answer.
Even with all the consolidation effort over the last (2) years
subsystems are still managed very differently and the review quality and
quantity a patch or patch series will get may be vastly different.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:21 ` Leon Romanovsky
  2021-04-22  4:56   ` Al Viro
  2021-04-22  6:03   ` Christoph Hellwig
@ 2021-04-22  9:20   ` Mauro Carvalho Chehab
  2021-04-22 11:34     ` Leon Romanovsky
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
  2021-04-22 12:40   ` Mark Brown
  3 siblings, 2 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22  9:20 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: James Bottomley, ksummit

Em Thu, 22 Apr 2021 07:21:26 +0300
Leon Romanovsky <leon@kernel.org> escreveu:

> On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> > I've long been on record as not really being a fan of trivial patches
> > because they can cause merge issues with current patches and introduce
> > bugs, particularly in older drivers, that don't get detected for a long
> > while.  However, the recent events with the University of Minnesota:
> > 
> > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > 
> > Have elevated the risk factor around trivial patches claiming to fix
> > bugs to the point where it looks like there's no such thing as a truly
> > trivial patch and they all need reviewing.  
> 
> While we are talking about policies, I would like to raise another bad
> practice that is done by even seasoned developers - sending patches with
> carefully crafted and filtered TO and CC.
> 
> This practice causes to get out of context patches without ability to
> see whole picture and the worse part that it divides feedback to
> "islands" without ability to agree or disagree with the feedback.
> 
> I'm putting this link as an EXAMPLE where every patch has different CC participants:
> https://lore.kernel.org/linux-rdma/CAJX1Ytb=XYKGeYuEN-2tPv9hx3G+=wnGWMzPk893J__JJFyhGQ@mail.gmail.com/T/#mf56c926ec0279a65fe180110b7dcf93fe053b91a

This is not a matter of bad practice. There are a couple of reasons
why each patch on a series will have a different group of Cc, like:

	- driver maintainers for each patch may be different;
	- scripts/get_maintainers.pl will return a different Cc/To;
	- patch series touch different subsystems;
	- sending a patch with too many c/c can make it rejected by
	  mail list servers.

Also, nowadays, with lore and b4, it would be easy to retrieve the
entire patch series, even for those that aren't subscribed on a 
c/c mailing list.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 19:47 ` Dan Carpenter
@ 2021-04-22  9:34   ` Mauro Carvalho Chehab
  2021-04-22  9:59     ` Johannes Berg
  0 siblings, 1 reply; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22  9:34 UTC (permalink / raw)
  To: Dan Carpenter; +Cc: James Bottomley, ksummit

Hi Dan,

Em Wed, 21 Apr 2021 22:47:03 +0300
Dan Carpenter <dan.carpenter@oracle.com> escreveu:

> I use my rename_rev.pl script to review trivial patches.  It's kind of
> a crap script, but it's useful if someone is re-indenting a whole file
> and adds a secret additional line.
> 
> https://github.com/error27/rename_rev
> 
> Someone who isn't as terrible at Perl could probably re-write it better.

Here, I use "wdiff" in order to deal with renames. It has a somewhat
funny dialect, but it helps a lot reviewing renaming patches.


Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  7:51               ` Mike Rapoport
  2021-04-22  8:45                 ` Christian Brauner
@ 2021-04-22  9:39                 ` Mauro Carvalho Chehab
  1 sibling, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22  9:39 UTC (permalink / raw)
  To: Mike Rapoport
  Cc: Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

Em Thu, 22 Apr 2021 10:51:12 +0300
Mike Rapoport <rppt@linux.ibm.com> escreveu:

> Hi,
> 
> On Thu, Apr 22, 2021 at 09:34:38AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:  
> > > On Wed, 21 Apr 2021, Julia Lawall wrote:  
> > > > The apology states that they didn't detect any vulnerabilities.  They
> > > > found three non exploitable bugs and submitted incorrect patches for them.
> > > > When the patches received some positive feedback, they explained that the
> > > > patches were incorrect and provided a proper fix.
> > > >
> > > > So they damaged trust, but not actually the Linux kernel...  
> > >
> > > The issue is that there was no consent and no coordination, so we don't
> > > know the scope of the experiment and whether it was still continuing.
> > >
> > > We are this not able to trust anything the group said about what they'd
> > > done or not done, until now [1].
> > >
> > > In all probability there is nothing further amiss but we would not have
> > > expected them to use fake gmail accounts to submit bugs to the kernel
> > > either.
> > >
> > > It's now on us to audit all of their known contributions, because we don't
> > > know the scope of the experiment, which was based on the use of deception,
> > > and we can't make any assumptions based on what they have said.
> > >
> > > We also need the identity of the 'random' gmail accounts they used,
> > > although this should be handled by a small trusted group in private, as it
> > > will lead to privacy issues for kernel maintainers who responded to them
> > > in public.  
> > 
> > What do we gain by blindly reverting all[1] umn.edu patches, and
> > ignoring future patches from umn.edu?
> > I think all of this is moot: other people may be doing the same thing,
> > or even "in worse faith".  The only thing that helps is making sure
> > patches get reviewed[2] before being applied.
> > 
> > [1] Judging from the new review comments, many of the 190 patches
> >     to be reverted were real fixes.
> > [2] Whether we can trust the reviewers is another question, and might
> >     become the topic of another research project :-(  
> 
> Hopefully such research will require too much effort and won't get funding :)

I suspect, however, that the publicity gained by this attempt will
actually attract hackers that will try to do the same. We need to take
extra care to avoid other similar issues.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  7:34             ` Geert Uytterhoeven
  2021-04-22  7:51               ` Mike Rapoport
@ 2021-04-22  9:55               ` Mauro Carvalho Chehab
  2021-04-22 12:01                 ` Leon Romanovsky
  2021-04-22 12:18                 ` Leon Romanovsky
  1 sibling, 2 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22  9:55 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: James Morris, Julia Lawall, Stephen Hemminger, Roland Dreier,
	Steven Rostedt, James Bottomley, ksummit

Em Thu, 22 Apr 2021 09:34:38 +0200
Geert Uytterhoeven <geert@linux-m68k.org> escreveu:

> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> > On Wed, 21 Apr 2021, Julia Lawall wrote:  
> > > The apology states that they didn't detect any vulnerabilities.  They
> > > found three non exploitable bugs and submitted incorrect patches for them.
> > > When the patches received some positive feedback, they explained that the
> > > patches were incorrect and provided a proper fix.
> > >
> > > So they damaged trust, but not actually the Linux kernel...  
> >
> > The issue is that there was no consent and no coordination, so we don't
> > know the scope of the experiment and whether it was still continuing.
> >
> > We are this not able to trust anything the group said about what they'd
> > done or not done, until now [1].
> >
> > In all probability there is nothing further amiss but we would not have
> > expected them to use fake gmail accounts to submit bugs to the kernel
> > either.
> >
> > It's now on us to audit all of their known contributions, because we don't
> > know the scope of the experiment, which was based on the use of deception,
> > and we can't make any assumptions based on what they have said.
> >
> > We also need the identity of the 'random' gmail accounts they used,
> > although this should be handled by a small trusted group in private, as it
> > will lead to privacy issues for kernel maintainers who responded to them
> > in public.  
> 
> What do we gain by blindly reverting all[1] umn.edu patches, and
> ignoring future patches from umn.edu?
> I think all of this is moot: other people may be doing the same thing,
> or even "in worse faith".  The only thing that helps is making sure
> patches get reviewed[2] before being applied.
> 
> [1] Judging from the new review comments, many of the 190 patches
>     to be reverted were real fixes.

The reverted ones for media (29 patches) didn't contain any malicious code.
One was useless (because the media core already fixes the pointed issue),
but the other ones were valid patches.

> [2] Whether we can trust the reviewers is another question, and might
>     become the topic of another research project :-(

That's the main concern.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:34   ` Mauro Carvalho Chehab
@ 2021-04-22  9:59     ` Johannes Berg
  2021-04-22 10:52       ` Mauro Carvalho Chehab
  2021-04-22 20:15       ` Alexandre Belloni
  0 siblings, 2 replies; 153+ messages in thread
From: Johannes Berg @ 2021-04-22  9:59 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Dan Carpenter; +Cc: James Bottomley, ksummit

On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:
> 
> Here, I use "wdiff" in order to deal with renames. It has a somewhat
> funny dialect, but it helps a lot reviewing renaming patches.

This also helps for casual "git show" etc.:

[core]
	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX

(path may vary, of course)

johannes


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  3:04   ` Joe Perches
@ 2021-04-22 10:13     ` Mauro Carvalho Chehab
  2021-04-22 12:07     ` Mark Brown
  2021-04-22 16:42     ` Bart Van Assche
  2 siblings, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 10:13 UTC (permalink / raw)
  To: Joe Perches; +Cc: Martin K. Petersen, James Bottomley, ksummit

Em Wed, 21 Apr 2021 20:04:17 -0700
Joe Perches <joe@perches.com> escreveu:

> On Wed, 2021-04-21 at 22:05 -0400, Martin K. Petersen wrote:
> > James,
> >   
> > > Our policy in SCSI for a long time has been no trivial patches
> > > accepted to maintained drivers,  
> > 
> > I'm afraid that ship sailed years ago. I am merging a ton of trivial
> > patches in SCSI.  
> 
> True and thank you.
> 
> Perhaps the primary thing that James' email shows is that he's not
> actively watching drivers/scsi/ git tree changes very much.
> 
> And I believe James is referring to whitespace style trivial patches.
> 
> > The reality is that not merging trivial patches is a losing battle. The
> > various static checkers appear to develop defect detection parity and
> > gcc and LLVM get more picky with every release.  
> 
> True, but perhaps most of the pickiness can be mitigated by moving
> various warnings to W=2 or W=3.

Not sure if this would solve anything. Also, it starts showing a lot
of false-positive issues, like those:

	./arch/x86/include/asm/bitops.h:283:28: warning: declaration of ‘ffs’ shadows a built-in function [-Wshadow]
	  283 | static __always_inline int ffs(int x)
	      |                            ^~~

	<stdin>:21: warning: macro "__IGNORE_stat64" is not used [-Wunused-macros]
	<stdin>:22: warning: macro "__IGNORE_lstat64" is not used [-Wunused-macros]
	<stdin>:157: warning: macro "__IGNORE_madvise1" is not used [-Wunused-macros]
	<stdin>:73: warning: macro "__IGNORE_llseek" is not used [-Wunused-macros]


Btw, -Wunused-macros is probably that it probably doesn't make any sense
to have "fixes". Having things like:

	#define SOME_UNUSED_FOO

won't cause any real issue, and attempts to drop those would result
on lots of ifdefs for no good reason, like:

#ifdef CONFIG_FOO
#  define SOMETHING_USED_ONLY_WHEN_CONFIG_FOO
#endif

I would move it to be out of W=2.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
                   ` (9 preceding siblings ...)
  2021-04-22  4:21 ` Leon Romanovsky
@ 2021-04-22 10:35 ` Mauro Carvalho Chehab
  2021-04-22 11:03   ` Sudip Mukherjee
                     ` (3 more replies)
  10 siblings, 4 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 10:35 UTC (permalink / raw)
  To: James Bottomley; +Cc: ksummit

Hi James,

Em Wed, 21 Apr 2021 11:35:36 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:

> I've long been on record as not really being a fan of trivial patches
> because they can cause merge issues with current patches and introduce
> bugs, particularly in older drivers, that don't get detected for a long
> while.  However, the recent events with the University of Minnesota:
> 
> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> 
> Have elevated the risk factor around trivial patches claiming to fix
> bugs to the point where it looks like there's no such thing as a truly
> trivial patch and they all need reviewing.
> 
> Our policy in SCSI for a long time has been no trivial patches accepted
> to maintained drivers, and I think that would be a good start if
> adopted kernel wide, but I think the next policy should be no trivial
> bug fix without a pointer to the actual bug report or report from a
> trusted static checker.  This would likely mean we have to create a
> list of trusted static checkers ... obviously 0day and coverity but
> what else?

I agree that we should have a "Rethinking the acceptance policy" talk
at the Maintainer Summit, but it should cover a scope wider than just
trivial patches. At least the patches I checked, sent from "@unm.edu" 
to media subsystem, they all looked good enough to be merged[1].

The main question is actually what's the degree of confidence a
maintainer can rely on a patch sent from a random contributor.

That's not an easy task.

I mean, usually, each maintainer develops internally a "trust score"
from subsystem's contributors, but such trustee level is usually not
shared with other maintainers.

When a developer reaches a certain level, maintainers are willing
to merge their work faster as they know that the developer is
there for a while and it is not trying to harm the community.

Perhaps one thing that we could add would be a
scripts/get_developer_trustee_status, which would be returning
a set of indicators that would help the maintainer to know
how much it can trust a random contributor, like:

	- how many drivers and patches a contributor has written;
	- how long and how frequent he's sending Kernel patches;
	- what subsystems received patches from him;
	- if the developer isn't on a blacklist/graylist.


Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:59     ` Johannes Berg
@ 2021-04-22 10:52       ` Mauro Carvalho Chehab
  2021-04-22 12:16         ` Mike Rapoport
  2021-04-22 20:15       ` Alexandre Belloni
  1 sibling, 1 reply; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 10:52 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Dan Carpenter, James Bottomley, ksummit

Em Thu, 22 Apr 2021 11:59:38 +0200
Johannes Berg <johannes@sipsolutions.net> escreveu:

> On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:
> > 
> > Here, I use "wdiff" in order to deal with renames. It has a somewhat
> > funny dialect, but it helps a lot reviewing renaming patches.  
> 
> This also helps for casual "git show" etc.:
> 
> [core]
> 	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX
> 
> (path may vary, of course)

Nice!

Yet, at least on Fedora 33, I had to add a small perl script for it to
work (modified from https://github.com/git/git/blob/master/contrib/diff-highlight/diff-highlight.perl),
as git-core-doc-2.28.0-1.fc33.noarch only contains DiffHighlight.pm.

Thanks,
Mauro

#!/usr/bin/perl
BEGIN {push @INC, '/usr/share/doc/git/contrib/diff-highlight/'}
use DiffHighlight;

# Some scripts may not realize that SIGPIPE is being ignored when launching the
# pager--for instance scripts written in Python.
$SIG{PIPE} = 'DEFAULT';

DiffHighlight::highlight_stdin();
exit 0;

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 10:35 ` Mauro Carvalho Chehab
@ 2021-04-22 11:03   ` Sudip Mukherjee
  2021-04-22 14:00     ` Steven Rostedt
  2021-04-22 20:28     ` Andrew Morton
  2021-04-22 12:32   ` Martin K. Petersen
                     ` (2 subsequent siblings)
  3 siblings, 2 replies; 153+ messages in thread
From: Sudip Mukherjee @ 2021-04-22 11:03 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: James Bottomley, ksummit, Jiri Kosina

On Thu, Apr 22, 2021 at 11:37 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Hi James,
>
> Em Wed, 21 Apr 2021 11:35:36 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
>
> > I've long been on record as not really being a fan of trivial patches
> > because they can cause merge issues with current patches and introduce
> > bugs, particularly in older drivers, that don't get detected for a long
> > while.  However, the recent events with the University of Minnesota:
> >
> > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> >
> > Have elevated the risk factor around trivial patches claiming to fix
> > bugs to the point where it looks like there's no such thing as a truly
> > trivial patch and they all need reviewing.
> >
> > Our policy in SCSI for a long time has been no trivial patches accepted
> > to maintained drivers, and I think that would be a good start if
> > adopted kernel wide, but I think the next policy should be no trivial
> > bug fix without a pointer to the actual bug report or report from a
> > trusted static checker.  This would likely mean we have to create a
> > list of trusted static checkers ... obviously 0day and coverity but
> > what else?
>
> I agree that we should have a "Rethinking the acceptance policy" talk
> at the Maintainer Summit, but it should cover a scope wider than just
> trivial patches. At least the patches I checked, sent from "@unm.edu"
> to media subsystem, they all looked good enough to be merged[1].
>

May I suggest that we have a separate tree for trivial patches like
the trivial.git tree that Jiri has and all trivial patches goes
through that tree. There can be a separate set of reviewers for those
patches who can work under the guidance of GregKH or others who are
looking at trivial patches on a daily basis for staging subsystem. But
I guess the question is where do you draw the boundary of a patch
being trivial or not.


-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:20   ` Mauro Carvalho Chehab
@ 2021-04-22 11:34     ` Leon Romanovsky
  2021-04-22 13:22       ` Mark Brown
  2021-04-22 13:29       ` Steven Rostedt
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
  1 sibling, 2 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 11:34 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 07:21:26 +0300
> Leon Romanovsky <leon@kernel.org> escreveu:
> 
> > On Wed, Apr 21, 2021 at 11:35:36AM -0700, James Bottomley wrote:
> > > I've long been on record as not really being a fan of trivial patches
> > > because they can cause merge issues with current patches and introduce
> > > bugs, particularly in older drivers, that don't get detected for a long
> > > while.  However, the recent events with the University of Minnesota:
> > > 
> > > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > > 
> > > Have elevated the risk factor around trivial patches claiming to fix
> > > bugs to the point where it looks like there's no such thing as a truly
> > > trivial patch and they all need reviewing.  
> > 
> > While we are talking about policies, I would like to raise another bad
> > practice that is done by even seasoned developers - sending patches with
> > carefully crafted and filtered TO and CC.
> > 
> > This practice causes to get out of context patches without ability to
> > see whole picture and the worse part that it divides feedback to
> > "islands" without ability to agree or disagree with the feedback.
> > 
> > I'm putting this link as an EXAMPLE where every patch has different CC participants:
> > https://lore.kernel.org/linux-rdma/CAJX1Ytb=XYKGeYuEN-2tPv9hx3G+=wnGWMzPk893J__JJFyhGQ@mail.gmail.com/T/#mf56c926ec0279a65fe180110b7dcf93fe053b91a
> 
> This is not a matter of bad practice. There are a couple of reasons
> why each patch on a series will have a different group of Cc, like:
> 
> 	- driver maintainers for each patch may be different;
> 	- scripts/get_maintainers.pl will return a different Cc/To;
> 	- patch series touch different subsystems;

Like Christoph said, if it is unrelated send the patches as separated
series.

> 	- sending a patch with too many c/c can make it rejected by
> 	  mail list servers.

In such cases, I put in To people who will apply the patches and in CC
only mailing lists.

> 
> Also, nowadays, with lore and b4, it would be easy to retrieve the
> entire patch series, even for those that aren't subscribed on a 
> c/c mailing list.

I'm pretty happy with my email flow and see a little value in reconstruction
of emails thread with b4 just to realize that the series is not important to me.

It also don't solve my "knowledge island" issue.

Thanks

> 
> Thanks,
> Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:55               ` Mauro Carvalho Chehab
@ 2021-04-22 12:01                 ` Leon Romanovsky
  2021-04-22 12:26                   ` Mark Brown
  2021-04-22 12:18                 ` Leon Romanovsky
  1 sibling, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 12:01 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:34:38 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> 
> > On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> > > On Wed, 21 Apr 2021, Julia Lawall wrote:  
> > > > The apology states that they didn't detect any vulnerabilities.  They
> > > > found three non exploitable bugs and submitted incorrect patches for them.
> > > > When the patches received some positive feedback, they explained that the
> > > > patches were incorrect and provided a proper fix.
> > > >
> > > > So they damaged trust, but not actually the Linux kernel...  
> > >
> > > The issue is that there was no consent and no coordination, so we don't
> > > know the scope of the experiment and whether it was still continuing.
> > >
> > > We are this not able to trust anything the group said about what they'd
> > > done or not done, until now [1].
> > >
> > > In all probability there is nothing further amiss but we would not have
> > > expected them to use fake gmail accounts to submit bugs to the kernel
> > > either.
> > >
> > > It's now on us to audit all of their known contributions, because we don't
> > > know the scope of the experiment, which was based on the use of deception,
> > > and we can't make any assumptions based on what they have said.
> > >
> > > We also need the identity of the 'random' gmail accounts they used,
> > > although this should be handled by a small trusted group in private, as it
> > > will lead to privacy issues for kernel maintainers who responded to them
> > > in public.  
> > 
> > What do we gain by blindly reverting all[1] umn.edu patches, and
> > ignoring future patches from umn.edu?
> > I think all of this is moot: other people may be doing the same thing,
> > or even "in worse faith".  The only thing that helps is making sure
> > patches get reviewed[2] before being applied.
> > 
> > [1] Judging from the new review comments, many of the 190 patches
> >     to be reverted were real fixes.
> 
> The reverted ones for media (29 patches) didn't contain any malicious code.
> One was useless (because the media core already fixes the pointed issue),
> but the other ones were valid patches.

And didn't you ask yourself after seeing same 29 patches that the
correct fix should be in another place? pm_runtime_get_sync?

> 
> > [2] Whether we can trust the reviewers is another question, and might
> >     become the topic of another research project :-(
> 
> That's the main concern.
> 
> Thanks,
> Mauro
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  3:04   ` Joe Perches
  2021-04-22 10:13     ` Mauro Carvalho Chehab
@ 2021-04-22 12:07     ` Mark Brown
  2021-04-22 16:42     ` Bart Van Assche
  2 siblings, 0 replies; 153+ messages in thread
From: Mark Brown @ 2021-04-22 12:07 UTC (permalink / raw)
  To: Joe Perches; +Cc: Martin K. Petersen, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

On Wed, Apr 21, 2021 at 08:04:17PM -0700, Joe Perches wrote:

> True, but perhaps most of the pickiness can be mitigated by moving
> various warnings to W=2 or W=3.

There are already people like Arnd actively working on managing what
warnings are at what levels for various compiler versions, but this
isn't just a case of wanting to shut up new warnings - a lot of the
new warnings that get introduced are legitimate and we both want to
fix the existing issues they identify and be able to enable them more
widely to benefit from them.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 10:52       ` Mauro Carvalho Chehab
@ 2021-04-22 12:16         ` Mike Rapoport
  2021-04-22 13:41           ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 153+ messages in thread
From: Mike Rapoport @ 2021-04-22 12:16 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Johannes Berg, Dan Carpenter, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 12:52:33PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 11:59:38 +0200
> Johannes Berg <johannes@sipsolutions.net> escreveu:
> 
> > On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:
> > > 
> > > Here, I use "wdiff" in order to deal with renames. It has a somewhat
> > > funny dialect, but it helps a lot reviewing renaming patches.  
> > 
> > This also helps for casual "git show" etc.:
> > 
> > [core]
> > 	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX
> > 
> > (path may vary, of course)
> 
> Nice!
> 
> Yet, at least on Fedora 33, I had to add a small perl script for it to
> work (modified from https://github.com/git/git/blob/master/contrib/diff-highlight/diff-highlight.perl),
> as git-core-doc-2.28.0-1.fc33.noarch only contains DiffHighlight.pm.

With git 2.29 it works fine on my F33.
 
> Thanks,
> Mauro
> 
> #!/usr/bin/perl
> BEGIN {push @INC, '/usr/share/doc/git/contrib/diff-highlight/'}
> use DiffHighlight;
> 
> # Some scripts may not realize that SIGPIPE is being ignored when launching the
> # pager--for instance scripts written in Python.
> $SIG{PIPE} = 'DEFAULT';
> 
> DiffHighlight::highlight_stdin();
> exit 0;
> 

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:55               ` Mauro Carvalho Chehab
  2021-04-22 12:01                 ` Leon Romanovsky
@ 2021-04-22 12:18                 ` Leon Romanovsky
  2021-04-22 15:38                   ` Shuah Khan
  1 sibling, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 12:18 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:34:38 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> 
> > On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
> > > On Wed, 21 Apr 2021, Julia Lawall wrote:  
> > > > The apology states that they didn't detect any vulnerabilities.  They
> > > > found three non exploitable bugs and submitted incorrect patches for them.
> > > > When the patches received some positive feedback, they explained that the
> > > > patches were incorrect and provided a proper fix.
> > > >
> > > > So they damaged trust, but not actually the Linux kernel...  
> > >
> > > The issue is that there was no consent and no coordination, so we don't
> > > know the scope of the experiment and whether it was still continuing.
> > >
> > > We are this not able to trust anything the group said about what they'd
> > > done or not done, until now [1].
> > >
> > > In all probability there is nothing further amiss but we would not have
> > > expected them to use fake gmail accounts to submit bugs to the kernel
> > > either.
> > >
> > > It's now on us to audit all of their known contributions, because we don't
> > > know the scope of the experiment, which was based on the use of deception,
> > > and we can't make any assumptions based on what they have said.
> > >
> > > We also need the identity of the 'random' gmail accounts they used,
> > > although this should be handled by a small trusted group in private, as it
> > > will lead to privacy issues for kernel maintainers who responded to them
> > > in public.  
> > 
> > What do we gain by blindly reverting all[1] umn.edu patches, and
> > ignoring future patches from umn.edu?
> > I think all of this is moot: other people may be doing the same thing,
> > or even "in worse faith".  The only thing that helps is making sure
> > patches get reviewed[2] before being applied.
> > 
> > [1] Judging from the new review comments, many of the 190 patches
> >     to be reverted were real fixes.
> 
> The reverted ones for media (29 patches) didn't contain any malicious code.
> One was useless (because the media core already fixes the pointed issue),
> but the other ones were valid patches.

I'm sorry that I didn't check all media commits, but this random commit
467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
broke sp8870 (I don't know what is it).

diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
index 8d31cf3f4f07..270a3c559e08 100644
--- a/drivers/media/dvb-frontends/sp8870.c
+++ b/drivers/media/dvb-frontends/sp8870.c
@@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
        sp8870_writereg(state, 0xc05, reg0xc05);

        // read status reg in order to clear pending irqs
-       sp8870_readreg(state, 0x200);
+       err = sp8870_readreg(state, 0x200);
+       if (err)
+               return err;

        // system controller start
        sp8870_microcontroller_start(state);


   67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
   68 {
   69         int ret;
 <...>
   77         if (ret != 2) {
   78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
   79                 return -1;
   80         }
   81
   82         return (b1[0] << 8 | b1[1]);
   83 }

The valid check should be if (err < 0);

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:01                 ` Leon Romanovsky
@ 2021-04-22 12:26                   ` Mark Brown
  2021-04-22 12:35                     ` Leon Romanovsky
  0 siblings, 1 reply; 153+ messages in thread
From: Mark Brown @ 2021-04-22 12:26 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, James Morris,
	Julia Lawall, Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote:
> On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:

> > The reverted ones for media (29 patches) didn't contain any malicious code.
> > One was useless (because the media core already fixes the pointed issue),
> > but the other ones were valid patches.

> And didn't you ask yourself after seeing same 29 patches that the
> correct fix should be in another place? pm_runtime_get_sync?

The runtime PM APIs are for legitimate reasons really fiddly to get
right - there's a bunch of different ways to do things and disabling
runtime PM in Kconfig can cause surprises.  It's been identified as an
issue for years but it's really not trivial to address it at the API
level.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 10:35 ` Mauro Carvalho Chehab
  2021-04-22 11:03   ` Sudip Mukherjee
@ 2021-04-22 12:32   ` Martin K. Petersen
  2021-04-22 15:11     ` Laurent Pinchart
  2021-04-22 15:28     ` James Bottomley
  2021-04-22 13:24   ` Konstantin Ryabitsev
  2021-04-22 15:34   ` Shuah Khan
  3 siblings, 2 replies; 153+ messages in thread
From: Martin K. Petersen @ 2021-04-22 12:32 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: James Bottomley, ksummit


Hi Mauro!

> Perhaps one thing that we could add would be a
> scripts/get_developer_trustee_status, which would be returning
> a set of indicators that would help the maintainer to know
> how much it can trust a random contributor, like:
>
> 	- how many drivers and patches a contributor has written;
> 	- how long and how frequent he's sending Kernel patches;
> 	- what subsystems received patches from him;
> 	- if the developer isn't on a blacklist/graylist.

I do a 'git log --grep' when I see an email address I do not recognize,
sometimes I also Google. It would definitely be nice to automate some of
this.

From past program committee tenures I have a bunch of perl hacks to rank
people based on git history, mailing list posts, etc. But until now I
hadn't really thought of doing something that elaborate in my patch
workflow.

Scraping the list archives was the most painful part but that is now
trivially easy thanks to lore ('git log --author pakki001'). And much
faster too.

I think your proposal is fine as long as it is just printing raw
statistics. I am concerned that if we turn those numbers into a
one-dimensional "trust level", people will instantly start to game the
system to artificially inflate their score.

Another metric that may be worth capturing is how many Fixes: tags refer
to patches authored by this submitter.

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:26                   ` Mark Brown
@ 2021-04-22 12:35                     ` Leon Romanovsky
  2021-04-22 12:52                       ` Hans Verkuil
  2021-04-22 13:33                       ` Mauro Carvalho Chehab
  0 siblings, 2 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 12:35 UTC (permalink / raw)
  To: Mark Brown
  Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, James Morris,
	Julia Lawall, Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 01:26:04PM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote:
> > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
> 
> > > The reverted ones for media (29 patches) didn't contain any malicious code.
> > > One was useless (because the media core already fixes the pointed issue),
> > > but the other ones were valid patches.
> 
> > And didn't you ask yourself after seeing same 29 patches that the
> > correct fix should be in another place? pm_runtime_get_sync?
> 
> The runtime PM APIs are for legitimate reasons really fiddly to get
> right - there's a bunch of different ways to do things and disabling
> runtime PM in Kconfig can cause surprises.  It's been identified as an
> issue for years but it's really not trivial to address it at the API
> level.

There is no need to fix all problems at once, but seeing same mistake
over and over like in commit 57cc666d36ad ("media: st-delta: Fix reference
count leak in delta_run_work") can be fixed very easily (+grep all source
code to remove extra put):

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 18b82427d0cb..d73c967ddb80 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1089,6 +1089,9 @@ int __pm_runtime_resume(struct device *dev, int rpmflags)
        retval = rpm_resume(dev, rpmflags);
        spin_unlock_irqrestore(&dev->power.lock, flags);

+       if (retval && rpmflags & RPM_GET_PUT)
+               atomic_dec(&dev->power.usage_count);
+
        return retval;
 }
 EXPORT_SYMBOL_GPL(__pm_runtime_resume);




^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  4:21 ` Leon Romanovsky
                     ` (2 preceding siblings ...)
  2021-04-22  9:20   ` Mauro Carvalho Chehab
@ 2021-04-22 12:40   ` Mark Brown
  2021-04-22 12:54     ` Mike Rapoport
  3 siblings, 1 reply; 153+ messages in thread
From: Mark Brown @ 2021-04-22 12:40 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 663 bytes --]

On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:

> While we are talking about policies, I would like to raise another bad
> practice that is done by even seasoned developers - sending patches with
> carefully crafted and filtered TO and CC.

> This practice causes to get out of context patches without ability to
> see whole picture and the worse part that it divides feedback to
> "islands" without ability to agree or disagree with the feedback.

The flip side of copying everyone on everything is that especially for
serieses which aren't just repetitive changes this gets really noisy
really quickly and things end up just not getting read.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:35                     ` Leon Romanovsky
@ 2021-04-22 12:52                       ` Hans Verkuil
  2021-04-22 13:33                       ` Mauro Carvalho Chehab
  1 sibling, 0 replies; 153+ messages in thread
From: Hans Verkuil @ 2021-04-22 12:52 UTC (permalink / raw)
  To: Leon Romanovsky, Mark Brown
  Cc: Mauro Carvalho Chehab, Geert Uytterhoeven, James Morris,
	Julia Lawall, Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On 22/04/2021 14:35, Leon Romanovsky wrote:
> On Thu, Apr 22, 2021 at 01:26:04PM +0100, Mark Brown wrote:
>> On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote:
>>> On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
>>
>>>> The reverted ones for media (29 patches) didn't contain any malicious code.
>>>> One was useless (because the media core already fixes the pointed issue),
>>>> but the other ones were valid patches.
>>
>>> And didn't you ask yourself after seeing same 29 patches that the
>>> correct fix should be in another place? pm_runtime_get_sync?

A new function was created that does the correct cleanup:
pm_runtime_resume_and_get().

But these patches predate that addition.

Regards,

	Hans

>>
>> The runtime PM APIs are for legitimate reasons really fiddly to get
>> right - there's a bunch of different ways to do things and disabling
>> runtime PM in Kconfig can cause surprises.  It's been identified as an
>> issue for years but it's really not trivial to address it at the API
>> level.
> 
> There is no need to fix all problems at once, but seeing same mistake
> over and over like in commit 57cc666d36ad ("media: st-delta: Fix reference
> count leak in delta_run_work") can be fixed very easily (+grep all source
> code to remove extra put):
> 
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 18b82427d0cb..d73c967ddb80 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1089,6 +1089,9 @@ int __pm_runtime_resume(struct device *dev, int rpmflags)
>         retval = rpm_resume(dev, rpmflags);
>         spin_unlock_irqrestore(&dev->power.lock, flags);
> 
> +       if (retval && rpmflags & RPM_GET_PUT)
> +               atomic_dec(&dev->power.usage_count);
> +
>         return retval;
>  }
>  EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> 
> 
> 
> 


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:20   ` Mauro Carvalho Chehab
  2021-04-22 11:34     ` Leon Romanovsky
@ 2021-04-22 12:53     ` Konstantin Ryabitsev
  2021-04-22 13:08       ` Leon Romanovsky
                         ` (3 more replies)
  1 sibling, 4 replies; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-22 12:53 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> Also, nowadays, with lore and b4, it would be easy to retrieve the
> entire patch series, even for those that aren't subscribed on a 
> c/c mailing list.

If you're a mutt user, you can set up a keybinding, e.g.:

    macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"

You'll need to adjust it to point at where your maildir lives, of course, but
that's the general idea. With it in place, you can hit "4" in the index view
to get the rest of the thread (without duplicating the messages you already
have).

If you use mbsync, this will also put the thread into your remote imap folder.

-K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:40   ` Mark Brown
@ 2021-04-22 12:54     ` Mike Rapoport
  2021-04-22 13:23       ` Mark Brown
  2021-04-22 14:51       ` Laurent Pinchart
  0 siblings, 2 replies; 153+ messages in thread
From: Mike Rapoport @ 2021-04-22 12:54 UTC (permalink / raw)
  To: Mark Brown; +Cc: Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> 
> > While we are talking about policies, I would like to raise another bad
> > practice that is done by even seasoned developers - sending patches with
> > carefully crafted and filtered TO and CC.
> 
> > This practice causes to get out of context patches without ability to
> > see whole picture and the worse part that it divides feedback to
> > "islands" without ability to agree or disagree with the feedback.
> 
> The flip side of copying everyone on everything is that especially for
> serieses which aren't just repetitive changes this gets really noisy
> really quickly and things end up just not getting read.

I think this is quite subjective and different people have different email
flows.

For me the most annoying is to get several patches from the middle of a
series. IMHO, sending at least cover letter to everyone is the bare minimum
so that people at least can take a look at high level details and request a
repost.

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
@ 2021-04-22 13:08       ` Leon Romanovsky
  2021-04-22 13:27         ` Konstantin Ryabitsev
  2021-04-22 17:56       ` Leon Romanovsky
                         ` (2 subsequent siblings)
  3 siblings, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 13:08 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 08:53:57AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> > Also, nowadays, with lore and b4, it would be easy to retrieve the
> > entire patch series, even for those that aren't subscribed on a 
> > c/c mailing list.
> 
> If you're a mutt user, you can set up a keybinding, e.g.:
> 
>     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"
> 
> You'll need to adjust it to point at where your maildir lives, of course, but
> that's the general idea. With it in place, you can hit "4" in the index view
> to get the rest of the thread (without duplicating the messages you already
> have).

Thanks, I'll try it, however it will fit my flow only partially.

This macro will bring the missing patches only when I'm near computer (mutt),
while in my flow, I'm reading emails from the phone and only for the replies use
the computer.

> 
> If you use mbsync, this will also put the thread into your remote imap folder.
> 
> -K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 11:34     ` Leon Romanovsky
@ 2021-04-22 13:22       ` Mark Brown
  2021-04-22 13:47         ` Leon Romanovsky
  2021-04-22 14:12         ` Mauro Carvalho Chehab
  2021-04-22 13:29       ` Steven Rostedt
  1 sibling, 2 replies; 153+ messages in thread
From: Mark Brown @ 2021-04-22 13:22 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Thu, Apr 22, 2021 at 02:34:53PM +0300, Leon Romanovsky wrote:

> Like Christoph said, if it is unrelated send the patches as separated
> series.

A very common case is for MFDs where you've got a core driver which is
either being newly added or as far as external interfaces go having some
defines added to it and then a bunch of basically unrelated driver
patches.  There is often a build time dependency (not so much with the
newly added stuff) so there is an actual dependency but no meaningful
overlap with reviews.  You get a similar thing with people bringing up
new SoCs where they send a minimal set of drivers in the initial series
so people can usefully test.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:54     ` Mike Rapoport
@ 2021-04-22 13:23       ` Mark Brown
  2021-04-22 15:19         ` Steven Rostedt
  2021-04-22 14:51       ` Laurent Pinchart
  1 sibling, 1 reply; 153+ messages in thread
From: Mark Brown @ 2021-04-22 13:23 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: Leon Romanovsky, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:

> > The flip side of copying everyone on everything is that especially for
> > serieses which aren't just repetitive changes this gets really noisy
> > really quickly and things end up just not getting read.

> I think this is quite subjective and different people have different email
> flows.

Well, it also depends a lot on why the series is going to lots of people
- the MFD/new SoC case is very different to the adding and using a new
API case for example.

> For me the most annoying is to get several patches from the middle of a
> series. IMHO, sending at least cover letter to everyone is the bare minimum
> so that people at least can take a look at high level details and request a
> repost.

Yes, the cover letter should always go to everyone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 10:35 ` Mauro Carvalho Chehab
  2021-04-22 11:03   ` Sudip Mukherjee
  2021-04-22 12:32   ` Martin K. Petersen
@ 2021-04-22 13:24   ` Konstantin Ryabitsev
  2021-04-22 14:31     ` Mauro Carvalho Chehab
  2021-04-22 15:34   ` Shuah Khan
  3 siblings, 1 reply; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-22 13:24 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: James Bottomley, ksummit

On Thu, Apr 22, 2021 at 12:35:59PM +0200, Mauro Carvalho Chehab wrote:
> I mean, usually, each maintainer develops internally a "trust score"
> from subsystem's contributors, but such trustee level is usually not
> shared with other maintainers.
> 
> When a developer reaches a certain level, maintainers are willing
> to merge their work faster as they know that the developer is
> there for a while and it is not trying to harm the community.

> 
> Perhaps one thing that we could add would be a
> scripts/get_developer_trustee_status, which would be returning
> a set of indicators that would help the maintainer to know
> how much it can trust a random contributor, like:
> 
> 	- how many drivers and patches a contributor has written;
> 	- how long and how frequent he's sending Kernel patches;
> 	- what subsystems received patches from him;
> 	- if the developer isn't on a blacklist/graylist.

I must point out that "karma" systems are quite ripe for abuse and can create
negative dynamics within the project. Right now, without an accepted framework
of cryptographic patch attestation, high-karma accounts will be more likely to
be targeted for impersonation -- typo spoofing, account hijacking, "From"
fudging [*], etc.

Even if we do everything right and implement strong cryptographic end-to-end
attestation, we will still always have to assume that the submitter might be
under duress and is submitting intentionally harmful code because someone is
holding their family hostage.

I think karma makes sense within the vertical confines of submaintainer
hierarchy -- X collects patches and sends a pull request to Y; Y verifies the
signature on the pull request, gives it a quick review and submits another
request to Z, etc. Exporting the "karma points" outside of this hierarchy
doesn't really make sense.

-K

[*] A neat trick is where the email message "From" is a random gmail address,
but the in-body "From:" has an address of a trusted contributor. If you review
such patches after running "git am" you will not catch this discrepancy.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:08       ` Leon Romanovsky
@ 2021-04-22 13:27         ` Konstantin Ryabitsev
  2021-04-22 13:41           ` Leon Romanovsky
  2021-04-22 16:28           ` Serge E. Hallyn
  0 siblings, 2 replies; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-22 13:27 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 04:08:47PM +0300, Leon Romanovsky wrote:
> > You'll need to adjust it to point at where your maildir lives, of course, but
> > that's the general idea. With it in place, you can hit "4" in the index view
> > to get the rest of the thread (without duplicating the messages you already
> > have).
> 
> Thanks, I'll try it, however it will fit my flow only partially.
> 
> This macro will bring the missing patches only when I'm near computer (mutt),
> while in my flow, I'm reading emails from the phone and only for the replies use
> the computer.

You may be better served by the upcoming "lei" tool, then. It can identify
threads of interest to you (e.g. those on which you are cc'd), put them
into your local or remote inbox, and continuously update them as new messages
come in. If you run it as a background process, you'll get the workflow you're
wanting.

-K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 11:34     ` Leon Romanovsky
  2021-04-22 13:22       ` Mark Brown
@ 2021-04-22 13:29       ` Steven Rostedt
  2021-04-22 13:58         ` Leon Romanovsky
  2021-04-22 14:20         ` Rob Herring
  1 sibling, 2 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 13:29 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, 22 Apr 2021 14:34:53 +0300
Leon Romanovsky <leon@kernel.org> wrote:

> > This is not a matter of bad practice. There are a couple of reasons
> > why each patch on a series will have a different group of Cc, like:
> > 
> > 	- driver maintainers for each patch may be different;
> > 	- scripts/get_maintainers.pl will return a different Cc/To;
> > 	- patch series touch different subsystems;  
> 
> Like Christoph said, if it is unrelated send the patches as separated
> series.

Since I use quilt to send my patches, my only two choices are all patches,
or individual ones with Cc. Some of my patches will need to touch every
architecture. I'll Cc the maintainers of the architecture code, but not
include them in every architecture patch. And because this code depends on
other patches, I can not send them as individual series.

I use to have issues with this, but now with lore, I can trivially find the
entire thread and read it the whole story. IMO, it is no longer bad
practice to Cc only a single patch is a larger series to a maintainer, for
the one patch that touches their code. It's a "FYI, I'm touching your
code". But because of lore, it's really easy for them to get the full
picture.

I much rather have my INBOX today be only patches that touches my code,
then full series of patches that I really don't care about. Worse yet, I'll
get Cc'd on a full series of 20 patches, where only one patch touches my
code. The sad part is, I'm much more likely to ignore that series, because
I'm added to stuff by get-maintainers for the strangest reason, and
completely miss that there's a single patch in there that really requires
my review.

Please, just Cc me on code that touches something I maintain or listed as
a reviewer (which is still a lot).

> 
> > 	- sending a patch with too many c/c can make it rejected by
> > 	  mail list servers.  
> 
> In such cases, I put in To people who will apply the patches and in CC
> only mailing lists.
> 
> > 
> > Also, nowadays, with lore and b4, it would be easy to retrieve the
> > entire patch series, even for those that aren't subscribed on a 
> > c/c mailing list.  
> 
> I'm pretty happy with my email flow and see a little value in reconstruction
> of emails thread with b4 just to realize that the series is not important to me.

It's not b4 you need. I seldom use that (but perhaps I should start). But
lore is really easy. My email client, by default, shows the message id of
the email I'm looking at. If I want to know more, I copy that message id,
open a browser, and type:

 lore.kernel.org/r/<message-id>

Hit enter, and boom! the entire thread is there!

Try it!

> 
> It also don't solve my "knowledge island" issue.

I believe lore does.

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:35                     ` Leon Romanovsky
  2021-04-22 12:52                       ` Hans Verkuil
@ 2021-04-22 13:33                       ` Mauro Carvalho Chehab
  2021-04-22 13:42                         ` Leon Romanovsky
  1 sibling, 1 reply; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 13:33 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Mark Brown, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

Em Thu, 22 Apr 2021 15:35:11 +0300
Leon Romanovsky <leon@kernel.org> escreveu:

> On Thu, Apr 22, 2021 at 01:26:04PM +0100, Mark Brown wrote:
> > On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote:  
> > > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:  
> >   
> > > > The reverted ones for media (29 patches) didn't contain any malicious code.
> > > > One was useless (because the media core already fixes the pointed issue),
> > > > but the other ones were valid patches.  
> >   
> > > And didn't you ask yourself after seeing same 29 patches that the
> > > correct fix should be in another place? pm_runtime_get_sync?  
> > 
> > The runtime PM APIs are for legitimate reasons really fiddly to get
> > right - there's a bunch of different ways to do things and disabling
> > runtime PM in Kconfig can cause surprises.  It's been identified as an
> > issue for years but it's really not trivial to address it at the API
> > level.  
> 
> There is no need to fix all problems at once, but seeing same mistake
> over and over like in commit 57cc666d36ad ("media: st-delta: Fix reference
> count leak in delta_run_work") can be fixed very easily (+grep all source
> code to remove extra put):
> 
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 18b82427d0cb..d73c967ddb80 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1089,6 +1089,9 @@ int __pm_runtime_resume(struct device *dev, int rpmflags)
>         retval = rpm_resume(dev, rpmflags);
>         spin_unlock_irqrestore(&dev->power.lock, flags);
> 
> +       if (retval && rpmflags & RPM_GET_PUT)
> +               atomic_dec(&dev->power.usage_count);
> +
>         return retval;
>  }
>  EXPORT_SYMBOL_GPL(__pm_runtime_resume);

This would break existing code that would try to do a _put_ themselves. 

> A new function was created that does the correct cleanup:
> pm_runtime_resume_and_get().
> 
> But these patches predate that addition.

Yeah, a patch changing the logic to use pm_runtime_resume_and_get()
would equally solve, but, as Hans pointed, this new function
is brand new:

	commit dd8088d5a8969dc2b42f71d7bc01c25c61a78066
	Author: Zhang Qilong <zhangqilong3@huawei.com>
	Date:   Tue Nov 10 17:29:32 2020 +0800
	
	    PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter
	
Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:16         ` Mike Rapoport
@ 2021-04-22 13:41           ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 13:41 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: Johannes Berg, Dan Carpenter, James Bottomley, ksummit

Em Thu, 22 Apr 2021 15:16:39 +0300
Mike Rapoport <rppt@linux.ibm.com> escreveu:

> On Thu, Apr 22, 2021 at 12:52:33PM +0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 22 Apr 2021 11:59:38 +0200
> > Johannes Berg <johannes@sipsolutions.net> escreveu:
> >   
> > > On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:  
> > > > 
> > > > Here, I use "wdiff" in order to deal with renames. It has a somewhat
> > > > funny dialect, but it helps a lot reviewing renaming patches.    
> > > 
> > > This also helps for casual "git show" etc.:
> > > 
> > > [core]
> > > 	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX
> > > 
> > > (path may vary, of course)  
> > 
> > Nice!
> > 
> > Yet, at least on Fedora 33, I had to add a small perl script for it to
> > work (modified from https://github.com/git/git/blob/master/contrib/diff-highlight/diff-highlight.perl),
> > as git-core-doc-2.28.0-1.fc33.noarch only contains DiffHighlight.pm.  
> 
> With git 2.29 it works fine on my F33.

Didn't test 2.29. I had to downgrade yesterday from 2.30, due to this
issue:

	https://bugzilla.redhat.com/show_bug.cgi?id=1952030


Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:27         ` Konstantin Ryabitsev
@ 2021-04-22 13:41           ` Leon Romanovsky
  2021-04-22 16:28           ` Serge E. Hallyn
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 13:41 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 09:27:36AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 04:08:47PM +0300, Leon Romanovsky wrote:
> > > You'll need to adjust it to point at where your maildir lives, of course, but
> > > that's the general idea. With it in place, you can hit "4" in the index view
> > > to get the rest of the thread (without duplicating the messages you already
> > > have).
> > 
> > Thanks, I'll try it, however it will fit my flow only partially.
> > 
> > This macro will bring the missing patches only when I'm near computer (mutt),
> > while in my flow, I'm reading emails from the phone and only for the replies use
> > the computer.
> 
> You may be better served by the upcoming "lei" tool, then. It can identify
> threads of interest to you (e.g. those on which you are cc'd), put them
> into your local or remote inbox, and continuously update them as new messages
> come in. If you run it as a background process, you'll get the workflow you're
> wanting.

I'm less optimistic than you, for example it is unclear where and how
will I run this background process when I want to read emails during the
trips :).

Thanks

> 
> -K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:33                       ` Mauro Carvalho Chehab
@ 2021-04-22 13:42                         ` Leon Romanovsky
  0 siblings, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 13:42 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Mark Brown, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 03:33:49PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 15:35:11 +0300
> Leon Romanovsky <leon@kernel.org> escreveu:
> 
> > On Thu, Apr 22, 2021 at 01:26:04PM +0100, Mark Brown wrote:
> > > On Thu, Apr 22, 2021 at 03:01:39PM +0300, Leon Romanovsky wrote:  
> > > > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:  
> > >   
> > > > > The reverted ones for media (29 patches) didn't contain any malicious code.
> > > > > One was useless (because the media core already fixes the pointed issue),
> > > > > but the other ones were valid patches.  
> > >   
> > > > And didn't you ask yourself after seeing same 29 patches that the
> > > > correct fix should be in another place? pm_runtime_get_sync?  
> > > 
> > > The runtime PM APIs are for legitimate reasons really fiddly to get
> > > right - there's a bunch of different ways to do things and disabling
> > > runtime PM in Kconfig can cause surprises.  It's been identified as an
> > > issue for years but it's really not trivial to address it at the API
> > > level.  
> > 
> > There is no need to fix all problems at once, but seeing same mistake
> > over and over like in commit 57cc666d36ad ("media: st-delta: Fix reference
> > count leak in delta_run_work") can be fixed very easily (+grep all source
> > code to remove extra put):
> > 
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 18b82427d0cb..d73c967ddb80 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -1089,6 +1089,9 @@ int __pm_runtime_resume(struct device *dev, int rpmflags)
> >         retval = rpm_resume(dev, rpmflags);
> >         spin_unlock_irqrestore(&dev->power.lock, flags);
> > 
> > +       if (retval && rpmflags & RPM_GET_PUT)
> > +               atomic_dec(&dev->power.usage_count);
> > +
> >         return retval;
> >  }
> >  EXPORT_SYMBOL_GPL(__pm_runtime_resume);
> 
> This would break existing code that would try to do a _put_ themselves. 

I'll cite myself from the line above: "(+grep all source code to remove extra put)"

It doesn't matter.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:22       ` Mark Brown
@ 2021-04-22 13:47         ` Leon Romanovsky
  2021-04-22 13:51           ` Mark Brown
  2021-04-22 14:12         ` Mauro Carvalho Chehab
  1 sibling, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 13:47 UTC (permalink / raw)
  To: Mark Brown; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 02:22:02PM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2021 at 02:34:53PM +0300, Leon Romanovsky wrote:
> 
> > Like Christoph said, if it is unrelated send the patches as separated
> > series.
> 
> A very common case is for MFDs where you've got a core driver which is
> either being newly added or as far as external interfaces go having some
> defines added to it and then a bunch of basically unrelated driver
> patches.  There is often a build time dependency (not so much with the
> newly added stuff) so there is an actual dependency but no meaningful
> overlap with reviews.  You get a similar thing with people bringing up
> new SoCs where they send a minimal set of drivers in the initial series
> so people can usefully test.

I don't know anything about MFD subsystem, but for the subsystems (netdev, RDMA, PCI and MM)
which I'm following, is important to get whole series.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:47         ` Leon Romanovsky
@ 2021-04-22 13:51           ` Mark Brown
  0 siblings, 0 replies; 153+ messages in thread
From: Mark Brown @ 2021-04-22 13:51 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Thu, Apr 22, 2021 at 04:47:56PM +0300, Leon Romanovsky wrote:
> On Thu, Apr 22, 2021 at 02:22:02PM +0100, Mark Brown wrote:

> > A very common case is for MFDs where you've got a core driver which is
> > either being newly added or as far as external interfaces go having some

> I don't know anything about MFD subsystem, but for the subsystems (netdev, RDMA, PCI and MM)
> which I'm following, is important to get whole series.

These are chips where there's one device which has drivers in multiple
subsystems which are basically separate IPs that happen to be in the
same package (PMICs are a common case) - the drivers are generally
unrelated to each other in any meaningful sense, they're grouped as a
result of physical packaging and manufacturing concerns.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:29       ` Steven Rostedt
@ 2021-04-22 13:58         ` Leon Romanovsky
  2021-04-22 14:20         ` Rob Herring
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 13:58 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 09:29:16AM -0400, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 14:34:53 +0300
> Leon Romanovsky <leon@kernel.org> wrote:
> 
> > > This is not a matter of bad practice. There are a couple of reasons
> > > why each patch on a series will have a different group of Cc, like:
> > > 
> > > 	- driver maintainers for each patch may be different;
> > > 	- scripts/get_maintainers.pl will return a different Cc/To;
> > > 	- patch series touch different subsystems;  
> > 
> > Like Christoph said, if it is unrelated send the patches as separated
> > series.

<...>

> Please, just Cc me on code that touches something I maintain or listed as
> a reviewer (which is still a lot).

Actually, we are drifting into another interesting topic to discuss.
"How to make life of patch submitters easy?" The difference in
maintainer's preferences, mailing list rules, e.t.c makes submission
process unbelievably painful.

<...>

> > I'm pretty happy with my email flow and see a little value in reconstruction
> > of emails thread with b4 just to realize that the series is not important to me.
> 
> It's not b4 you need. I seldom use that (but perhaps I should start). But
> lore is really easy. My email client, by default, shows the message id of
> the email I'm looking at. If I want to know more, I copy that message id,
> open a browser, and type:
> 
>  lore.kernel.org/r/<message-id>
> 
> Hit enter, and boom! the entire thread is there!
> 
> Try it!

I'm using lorifier on daily basis.

> 
> > 
> > It also don't solve my "knowledge island" issue.
> 
> I believe lore does.

Did you try to follow netdev and MM with lore only?

Thanks

> 
> -- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 11:03   ` Sudip Mukherjee
@ 2021-04-22 14:00     ` Steven Rostedt
  2021-04-22 14:07       ` Jiri Kosina
  2021-04-22 20:28     ` Andrew Morton
  1 sibling, 1 reply; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 14:00 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: Mauro Carvalho Chehab, James Bottomley, ksummit, Jiri Kosina

On Thu, 22 Apr 2021 12:03:24 +0100
Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> May I suggest that we have a separate tree for trivial patches like
> the trivial.git tree that Jiri has and all trivial patches goes

Funny that you suggest something that we already have and you mention. Yes
Jiri had the trivial tree, but because it ends up being a lot of work, and
if the maintainer of that tree doesn't have the time to maintain it, it
becomes a dead end for those patches.

It requires someone with a good enough reputation to maintain it, and that
means most people who have that reputation do not have the time to maintain
it ;-)

> through that tree. There can be a separate set of reviewers for those
> patches who can work under the guidance of GregKH or others who are
> looking at trivial patches on a daily basis for staging subsystem. But
> I guess the question is where do you draw the boundary of a patch
> being trivial or not.

The way it use to work was that if a patch was deemed trivial by the
maintainer, they could simply Cc the trivial email and say, trivial patch.
And then the trivial maintainer (use to be Jiri) would pull it in. It was
nice, as I didn't have to worry about putting those patches into my full 13
hour test suite ;-)

-- Steve


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 14:00     ` Steven Rostedt
@ 2021-04-22 14:07       ` Jiri Kosina
  2021-04-22 15:31         ` Sudip Mukherjee
  0 siblings, 1 reply; 153+ messages in thread
From: Jiri Kosina @ 2021-04-22 14:07 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Sudip Mukherjee, Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, 22 Apr 2021, Steven Rostedt wrote:

> > May I suggest that we have a separate tree for trivial patches like 
> > the trivial.git tree that Jiri has and all trivial patches goes
> 
> Funny that you suggest something that we already have and you mention. Yes
> Jiri had the trivial tree, but because it ends up being a lot of work, and
> if the maintainer of that tree doesn't have the time to maintain it, it
> becomes a dead end for those patches.
> 
> It requires someone with a good enough reputation to maintain it, and that
> means most people who have that reputation do not have the time to maintain
> it ;-)

Yeah, amen to that :)

That tree still sort of exists, I am collecting the patches that are sent 
there every now and then in big batches, and those which are still 
relevant by then I send to Linus afterwards.

The problem with that aproach of course is that it implicitly assumes 

	trivial -> non-urgent

which is a dubious asumption to take. But so far, it has actually worked 
reasonably well in that mode of operation, because the trivial && urgent 
ones are picked up by maintainers normally anyway by their own interest 
(and usually people are reasonable enough to send the urgent ones the 
proper route anyway).

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:22       ` Mark Brown
  2021-04-22 13:47         ` Leon Romanovsky
@ 2021-04-22 14:12         ` Mauro Carvalho Chehab
  2021-04-22 14:51           ` Leon Romanovsky
  1 sibling, 1 reply; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 14:12 UTC (permalink / raw)
  To: Mark Brown; +Cc: Leon Romanovsky, James Bottomley, ksummit

Em Thu, 22 Apr 2021 14:22:02 +0100
Mark Brown <broonie@kernel.org> escreveu:

> On Thu, Apr 22, 2021 at 02:34:53PM +0300, Leon Romanovsky wrote:
> 
> > Like Christoph said, if it is unrelated send the patches as separated
> > series.  
> 
> A very common case is for MFDs where you've got a core driver which is
> either being newly added or as far as external interfaces go having some
> defines added to it and then a bunch of basically unrelated driver
> patches.  There is often a build time dependency (not so much with the
> newly added stuff) so there is an actual dependency but no meaningful
> overlap with reviews.  You get a similar thing with people bringing up
> new SoCs where they send a minimal set of drivers in the initial series
> so people can usefully test.

Another common case are patches changing a kAPI that it is used on
other subsystems. They should be grouped as a hole, and applied
altogether, but each subsystem maintainer should ack/review only the
stuff related to the subsystem's scope.

Btw, one such example is the /190 patch series from the UNM reverts
that actually generated this thread: it doesn't make any sense to
bother all subsystem maintainers for patches that are completely
unrelated to their work.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:29       ` Steven Rostedt
  2021-04-22 13:58         ` Leon Romanovsky
@ 2021-04-22 14:20         ` Rob Herring
  2021-04-23  6:04           ` Mauro Carvalho Chehab
  1 sibling, 1 reply; 153+ messages in thread
From: Rob Herring @ 2021-04-22 14:20 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Leon Romanovsky, Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 8:30 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 22 Apr 2021 14:34:53 +0300
> Leon Romanovsky <leon@kernel.org> wrote:
>
> > > This is not a matter of bad practice. There are a couple of reasons
> > > why each patch on a series will have a different group of Cc, like:
> > >
> > >     - driver maintainers for each patch may be different;
> > >     - scripts/get_maintainers.pl will return a different Cc/To;
> > >     - patch series touch different subsystems;
> >
> > Like Christoph said, if it is unrelated send the patches as separated
> > series.
>
> Since I use quilt to send my patches, my only two choices are all patches,
> or individual ones with Cc. Some of my patches will need to touch every
> architecture. I'll Cc the maintainers of the architecture code, but not
> include them in every architecture patch. And because this code depends on
> other patches, I can not send them as individual series.
>
> I use to have issues with this, but now with lore, I can trivially find the
> entire thread and read it the whole story. IMO, it is no longer bad
> practice to Cc only a single patch is a larger series to a maintainer, for
> the one patch that touches their code. It's a "FYI, I'm touching your
> code". But because of lore, it's really easy for them to get the full
> picture.
>
> I much rather have my INBOX today be only patches that touches my code,
> then full series of patches that I really don't care about. Worse yet, I'll
> get Cc'd on a full series of 20 patches, where only one patch touches my
> code. The sad part is, I'm much more likely to ignore that series, because
> I'm added to stuff by get-maintainers for the strangest reason, and
> completely miss that there's a single patch in there that really requires
> my review.
>
> Please, just Cc me on code that touches something I maintain or listed as
> a reviewer (which is still a lot).

Unless the process of who to Cc or not is completely automated,
relying on submitters to do the right thing to give you the subset of
emails you want to see is never going to work. I have frequent
problems with folks not Cc'ing the DT list for DT patches, how hard is
that? I think the answer is making where patches are sent less
important and better/easier filtering from lore (which is coming).

Rob

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:24   ` Konstantin Ryabitsev
@ 2021-04-22 14:31     ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-22 14:31 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: James Bottomley, ksummit

Em Thu, 22 Apr 2021 09:24:01 -0400
Konstantin Ryabitsev <konstantin@linuxfoundation.org> escreveu:

> On Thu, Apr 22, 2021 at 12:35:59PM +0200, Mauro Carvalho Chehab wrote:
> > I mean, usually, each maintainer develops internally a "trust score"
> > from subsystem's contributors, but such trustee level is usually not
> > shared with other maintainers.
> > 
> > When a developer reaches a certain level, maintainers are willing
> > to merge their work faster as they know that the developer is
> > there for a while and it is not trying to harm the community.  
> 
> > 
> > Perhaps one thing that we could add would be a
> > scripts/get_developer_trustee_status, which would be returning
> > a set of indicators that would help the maintainer to know
> > how much it can trust a random contributor, like:
> > 
> > 	- how many drivers and patches a contributor has written;
> > 	- how long and how frequent he's sending Kernel patches;
> > 	- what subsystems received patches from him;
> > 	- if the developer isn't on a blacklist/graylist.  
> 
> I must point out that "karma" systems are quite ripe for abuse and can create
> negative dynamics within the project. Right now, without an accepted framework
> of cryptographic patch attestation, high-karma accounts will be more likely to
> be targeted for impersonation -- typo spoofing, account hijacking, "From"
> fudging [*], etc.

Good point.

> Even if we do everything right and implement strong cryptographic end-to-end
> attestation,

IMO, it makes sense to improve our workflow towards having gpg-signed patches
that are cross-signed by Kernel maintainers from developers that are regular
contributors.

Of course, a change like that takes time.

> I think karma makes sense within the vertical confines of submaintainer
> hierarchy -- X collects patches and sends a pull request to Y; Y verifies the
> signature on the pull request, gives it a quick review and submits another
> request to Z, etc. Exporting the "karma points" outside of this hierarchy
> doesn't really make sense.

Yeah, it makes a lot sense vertically, but it also makes sense horizontally:
the karma from a long time subsystem maintainer is higher than a random
contributor, even when contributing to a different subsystem. The reason is
that it is unlikely that such contributor would just disappear in the thin
air if something bad comes up from merging his patch.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:54     ` Mike Rapoport
  2021-04-22 13:23       ` Mark Brown
@ 2021-04-22 14:51       ` Laurent Pinchart
  2021-04-22 15:14         ` Mike Rapoport
  1 sibling, 1 reply; 153+ messages in thread
From: Laurent Pinchart @ 2021-04-22 14:51 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: Mark Brown, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
> > On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > 
> > > While we are talking about policies, I would like to raise another bad
> > > practice that is done by even seasoned developers - sending patches with
> > > carefully crafted and filtered TO and CC.
> > 
> > > This practice causes to get out of context patches without ability to
> > > see whole picture and the worse part that it divides feedback to
> > > "islands" without ability to agree or disagree with the feedback.
> > 
> > The flip side of copying everyone on everything is that especially for
> > serieses which aren't just repetitive changes this gets really noisy
> > really quickly and things end up just not getting read.
> 
> I think this is quite subjective and different people have different email
> flows.
> 
> For me the most annoying is to get several patches from the middle of a
> series. IMHO, sending at least cover letter to everyone is the bare minimum
> so that people at least can take a look at high level details and request a
> repost.

Could tooling based on lore and b4 help here ? The prospect of getting
more patches in my inbox isn't exactly enticing, but the ability to
quickly get the full context of a patch series is certainly useful (I've
had to look up parts I wasn't CC'ed on previously).

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 14:12         ` Mauro Carvalho Chehab
@ 2021-04-22 14:51           ` Leon Romanovsky
  0 siblings, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 14:51 UTC (permalink / raw)
  To: Mauro Carvalho Chehab; +Cc: Mark Brown, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 04:12:07PM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 14:22:02 +0100
> Mark Brown <broonie@kernel.org> escreveu:
> 
> > On Thu, Apr 22, 2021 at 02:34:53PM +0300, Leon Romanovsky wrote:
> > 
> > > Like Christoph said, if it is unrelated send the patches as separated
> > > series.  
> > 
> > A very common case is for MFDs where you've got a core driver which is
> > either being newly added or as far as external interfaces go having some
> > defines added to it and then a bunch of basically unrelated driver
> > patches.  There is often a build time dependency (not so much with the
> > newly added stuff) so there is an actual dependency but no meaningful
> > overlap with reviews.  You get a similar thing with people bringing up
> > new SoCs where they send a minimal set of drivers in the initial series
> > so people can usefully test.
> 
> Another common case are patches changing a kAPI that it is used on
> other subsystems. They should be grouped as a hole, and applied
> altogether, but each subsystem maintainer should ack/review only the
> stuff related to the subsystem's scope.

This is exactly when I want to see all relevant mailing lists to be CCed.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:32   ` Martin K. Petersen
@ 2021-04-22 15:11     ` Laurent Pinchart
  2021-04-22 15:28     ` James Bottomley
  1 sibling, 0 replies; 153+ messages in thread
From: Laurent Pinchart @ 2021-04-22 15:11 UTC (permalink / raw)
  To: Martin K. Petersen; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 08:32:11AM -0400, Martin K. Petersen wrote:
> 
> Hi Mauro!
> 
> > Perhaps one thing that we could add would be a
> > scripts/get_developer_trustee_status, which would be returning
> > a set of indicators that would help the maintainer to know
> > how much it can trust a random contributor, like:
> >
> > 	- how many drivers and patches a contributor has written;
> > 	- how long and how frequent he's sending Kernel patches;
> > 	- what subsystems received patches from him;
> > 	- if the developer isn't on a blacklist/graylist.
> 
> I do a 'git log --grep' when I see an email address I do not recognize,
> sometimes I also Google. It would definitely be nice to automate some of
> this.
> 
> From past program committee tenures I have a bunch of perl hacks to rank
> people based on git history, mailing list posts, etc. But until now I
> hadn't really thought of doing something that elaborate in my patch
> workflow.
> 
> Scraping the list archives was the most painful part but that is now
> trivially easy thanks to lore ('git log --author pakki001'). And much
> faster too.
> 
> I think your proposal is fine as long as it is just printing raw
> statistics. I am concerned that if we turn those numbers into a
> one-dimensional "trust level", people will instantly start to game the
> system to artificially inflate their score.
> 
> Another metric that may be worth capturing is how many Fixes: tags refer
> to patches authored by this submitter.

Looking forward to the resulting discussions on when to add a Fixes: tag
:-) If Fixes: becomes a negative ranking tool, developers will lobby to
not get their patches blamed, and we'll lose part of the value of
Fixes:.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 14:51       ` Laurent Pinchart
@ 2021-04-22 15:14         ` Mike Rapoport
  2021-04-22 15:17           ` Laurent Pinchart
  2021-04-22 15:32           ` Shuah Khan
  0 siblings, 2 replies; 153+ messages in thread
From: Mike Rapoport @ 2021-04-22 15:14 UTC (permalink / raw)
  To: Laurent Pinchart; +Cc: Mark Brown, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 05:51:23PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
> > On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
> > > On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > > 
> > > > While we are talking about policies, I would like to raise another bad
> > > > practice that is done by even seasoned developers - sending patches with
> > > > carefully crafted and filtered TO and CC.
> > > 
> > > > This practice causes to get out of context patches without ability to
> > > > see whole picture and the worse part that it divides feedback to
> > > > "islands" without ability to agree or disagree with the feedback.
> > > 
> > > The flip side of copying everyone on everything is that especially for
> > > serieses which aren't just repetitive changes this gets really noisy
> > > really quickly and things end up just not getting read.
> > 
> > I think this is quite subjective and different people have different email
> > flows.
> > 
> > For me the most annoying is to get several patches from the middle of a
> > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > so that people at least can take a look at high level details and request a
> > repost.
> 
> Could tooling based on lore and b4 help here ? The prospect of getting
> more patches in my inbox isn't exactly enticing, but the ability to
> quickly get the full context of a patch series is certainly useful (I've
> had to look up parts I wasn't CC'ed on previously).

lore definitely helps, but still requires an extra step. I think having the
cover letter in your inbox helps to decide if you want to do that extra
step.

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:14         ` Mike Rapoport
@ 2021-04-22 15:17           ` Laurent Pinchart
  2021-04-22 15:35             ` Al Viro
  2021-04-22 15:32           ` Shuah Khan
  1 sibling, 1 reply; 153+ messages in thread
From: Laurent Pinchart @ 2021-04-22 15:17 UTC (permalink / raw)
  To: Mike Rapoport; +Cc: Mark Brown, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 06:14:39PM +0300, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 05:51:23PM +0300, Laurent Pinchart wrote:
> > On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
> > > On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
> > > > On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > > > 
> > > > > While we are talking about policies, I would like to raise another bad
> > > > > practice that is done by even seasoned developers - sending patches with
> > > > > carefully crafted and filtered TO and CC.
> > > > >
> > > > > This practice causes to get out of context patches without ability to
> > > > > see whole picture and the worse part that it divides feedback to
> > > > > "islands" without ability to agree or disagree with the feedback.
> > > > 
> > > > The flip side of copying everyone on everything is that especially for
> > > > serieses which aren't just repetitive changes this gets really noisy
> > > > really quickly and things end up just not getting read.
> > > 
> > > I think this is quite subjective and different people have different email
> > > flows.
> > > 
> > > For me the most annoying is to get several patches from the middle of a
> > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > so that people at least can take a look at high level details and request a
> > > repost.
> > 
> > Could tooling based on lore and b4 help here ? The prospect of getting
> > more patches in my inbox isn't exactly enticing, but the ability to
> > quickly get the full context of a patch series is certainly useful (I've
> > had to look up parts I wasn't CC'ed on previously).
> 
> lore definitely helps, but still requires an extra step. I think having the
> cover letter in your inbox helps to decide if you want to do that extra
> step.

Agree about the cover letter, if there's something that needs to be sent
to all recipients it's that one.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:23       ` Mark Brown
@ 2021-04-22 15:19         ` Steven Rostedt
  2021-04-22 21:19           ` Thomas Gleixner
  2021-04-23  6:15           ` Greg KH
  0 siblings, 2 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 15:19 UTC (permalink / raw)
  To: Mark Brown; +Cc: Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Thu, 22 Apr 2021 14:23:39 +0100
Mark Brown <broonie@kernel.org> wrote:

> > For me the most annoying is to get several patches from the middle of a
> > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > so that people at least can take a look at high level details and request a
> > repost.  
> 
> Yes, the cover letter should always go to everyone.

And that's still the one thing that quilt send-mail does not support :-p

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  8:45                 ` Christian Brauner
@ 2021-04-22 15:27                   ` Steven Rostedt
  0 siblings, 0 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 15:27 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Mike Rapoport, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, James Bottomley, ksummit

On Thu, 22 Apr 2021 10:45:27 +0200
Christian Brauner <christian.brauner@ubuntu.com> wrote:

> There's a reason why prior research into Trojan Horse contributions
> didn't just go out and try to place bugs into existing software on such
> a large scale. (The fact that even one buggy commit - accident or not -
> from their group made it into the kernel renders the whole research
> project ethically questionable.)

Perhaps this professor should publish a followup paper describing what
happens when you push malicious code and get caught. Write about the
devastation it has on one's reputation as well as the reputation of your
company. ;-)

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:32   ` Martin K. Petersen
  2021-04-22 15:11     ` Laurent Pinchart
@ 2021-04-22 15:28     ` James Bottomley
  2021-04-22 15:35       ` Johannes Berg
  2021-04-22 15:36       ` Mark Brown
  1 sibling, 2 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-22 15:28 UTC (permalink / raw)
  To: Martin K. Petersen, Mauro Carvalho Chehab; +Cc: ksummit

On Thu, 2021-04-22 at 08:32 -0400, Martin K. Petersen wrote:
> Another metric that may be worth capturing is how many Fixes: tags
> refer to patches authored by this submitter.

Or perhaps invert it: no bug fix without a Fixes: tag.  Some of the
human handlers of robot based finders, like Dan's smatch, do go back
and figure out where the bug came from, but if we encourage the rule
that if you're fixing a bug you must identify the origin and explain
the bug it may help weed out some bogus fixes.

There seem to be two strands here: how to gain trust in the submitter
and a process which makes it easy to identify for someone familiar with
the subsystem to identify the actual bug, but I think improving our bug
process would yield immediate benefits.  Trust is a more difficult
thing to quantify.

James



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 14:07       ` Jiri Kosina
@ 2021-04-22 15:31         ` Sudip Mukherjee
  2021-04-22 21:33           ` Thomas Gleixner
  0 siblings, 1 reply; 153+ messages in thread
From: Sudip Mukherjee @ 2021-04-22 15:31 UTC (permalink / raw)
  To: Jiri Kosina
  Cc: Steven Rostedt, Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 3:07 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 22 Apr 2021, Steven Rostedt wrote:
>
> > > May I suggest that we have a separate tree for trivial patches like
> > > the trivial.git tree that Jiri has and all trivial patches goes
> >
> > Funny that you suggest something that we already have and you mention. Yes
> > Jiri had the trivial tree, but because it ends up being a lot of work, and
> > if the maintainer of that tree doesn't have the time to maintain it, it
> > becomes a dead end for those patches.
> >
> > It requires someone with a good enough reputation to maintain it, and that
> > means most people who have that reputation do not have the time to maintain
> > it ;-)
>
> Yeah, amen to that :)

I know, shortage of maintainers and reviewers.
I guess my suggestion was that all trivial patches goes via the
trivial tree and to have a group of interested people reviewing
patches which are submitted to trivial.

>
> That tree still sort of exists, I am collecting the patches that are sent
> there every now and then in big batches, and those which are still
> relevant by then I send to Linus afterwards.

I think this is a big blocker. Unless patches are applied to the tree
soon and added to linux-next, anyone creating patches based on that
tree and sending the patch might/will see the patch irrelevant.


-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:14         ` Mike Rapoport
  2021-04-22 15:17           ` Laurent Pinchart
@ 2021-04-22 15:32           ` Shuah Khan
  1 sibling, 0 replies; 153+ messages in thread
From: Shuah Khan @ 2021-04-22 15:32 UTC (permalink / raw)
  To: Mike Rapoport, Laurent Pinchart
  Cc: Mark Brown, Leon Romanovsky, James Bottomley, ksummit, Shuah Khan

On 4/22/21 9:14 AM, Mike Rapoport wrote:
> On Thu, Apr 22, 2021 at 05:51:23PM +0300, Laurent Pinchart wrote:
>> On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
>>> On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
>>>> On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
>>>>
>>>>> While we are talking about policies, I would like to raise another bad
>>>>> practice that is done by even seasoned developers - sending patches with
>>>>> carefully crafted and filtered TO and CC.
>>>>
>>>>> This practice causes to get out of context patches without ability to
>>>>> see whole picture and the worse part that it divides feedback to
>>>>> "islands" without ability to agree or disagree with the feedback.
>>>>
>>>> The flip side of copying everyone on everything is that especially for
>>>> serieses which aren't just repetitive changes this gets really noisy
>>>> really quickly and things end up just not getting read.
>>>
>>> I think this is quite subjective and different people have different email
>>> flows.
>>>
>>> For me the most annoying is to get several patches from the middle of a
>>> series. IMHO, sending at least cover letter to everyone is the bare minimum
>>> so that people at least can take a look at high level details and request a
>>> repost.
>>
>> Could tooling based on lore and b4 help here ? The prospect of getting
>> more patches in my inbox isn't exactly enticing, but the ability to
>> quickly get the full context of a patch series is certainly useful (I've
>> had to look up parts I wasn't CC'ed on previously).
> 
> lore definitely helps, but still requires an extra step. I think having the
> cover letter in your inbox helps to decide if you want to do that extra
> step.
> 

+1 on cover letter. I like to see the cover letter for the series in my
Inbox to give me the context and scope of the change. It helps with
reviewing the change in my code.

thanks,
-- Shuah



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 10:35 ` Mauro Carvalho Chehab
                     ` (2 preceding siblings ...)
  2021-04-22 13:24   ` Konstantin Ryabitsev
@ 2021-04-22 15:34   ` Shuah Khan
  2021-04-22 15:42     ` James Bottomley
  3 siblings, 1 reply; 153+ messages in thread
From: Shuah Khan @ 2021-04-22 15:34 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, James Bottomley; +Cc: ksummit, Shuah Khan

On 4/22/21 4:35 AM, Mauro Carvalho Chehab wrote:
> Hi James,
> 
> Em Wed, 21 Apr 2021 11:35:36 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> 
>> I've long been on record as not really being a fan of trivial patches
>> because they can cause merge issues with current patches and introduce
>> bugs, particularly in older drivers, that don't get detected for a long
>> while.  However, the recent events with the University of Minnesota:
>>
>> https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
>>
>> Have elevated the risk factor around trivial patches claiming to fix
>> bugs to the point where it looks like there's no such thing as a truly
>> trivial patch and they all need reviewing.
>>
>> Our policy in SCSI for a long time has been no trivial patches accepted
>> to maintained drivers, and I think that would be a good start if
>> adopted kernel wide, but I think the next policy should be no trivial
>> bug fix without a pointer to the actual bug report or report from a
>> trusted static checker.  This would likely mean we have to create a
>> list of trusted static checkers ... obviously 0day and coverity but
>> what else?
> 
> I agree that we should have a "Rethinking the acceptance policy" talk
> at the Maintainer Summit, but it should cover a scope wider than just
> trivial patches. At least the patches I checked, sent from "@unm.edu"
> to media subsystem, they all looked good enough to be merged[1].
> 
> The main question is actually what's the degree of confidence a
> maintainer can rely on a patch sent from a random contributor.
> 
> That's not an easy task.
> 
> I mean, usually, each maintainer develops internally a "trust score"
> from subsystem's contributors, but such trustee level is usually not
> shared with other maintainers.
> 
> When a developer reaches a certain level, maintainers are willing
> to merge their work faster as they know that the developer is
> there for a while and it is not trying to harm the community.
> 
> Perhaps one thing that we could add would be a
> scripts/get_developer_trustee_status, which would be returning
> a set of indicators that would help the maintainer to know
> how much it can trust a random contributor, like:
> 
> 	- how many drivers and patches a contributor has written;
> 	- how long and how frequent he's sending Kernel patches;
> 	- what subsystems received patches from him;
> 	- if the developer isn't on a blacklist/graylist.
> 
> 

This will put new developers at disadvantage. Let's think this through
before adding barriers for entry.

thanks,
-- Shuah


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:17           ` Laurent Pinchart
@ 2021-04-22 15:35             ` Al Viro
  0 siblings, 0 replies; 153+ messages in thread
From: Al Viro @ 2021-04-22 15:35 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Mike Rapoport, Mark Brown, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 06:17:12PM +0300, Laurent Pinchart wrote:
> On Thu, Apr 22, 2021 at 06:14:39PM +0300, Mike Rapoport wrote:
> > On Thu, Apr 22, 2021 at 05:51:23PM +0300, Laurent Pinchart wrote:
> > > On Thu, Apr 22, 2021 at 03:54:22PM +0300, Mike Rapoport wrote:
> > > > On Thu, Apr 22, 2021 at 01:40:23PM +0100, Mark Brown wrote:
> > > > > On Thu, Apr 22, 2021 at 07:21:26AM +0300, Leon Romanovsky wrote:
> > > > > 
> > > > > > While we are talking about policies, I would like to raise another bad
> > > > > > practice that is done by even seasoned developers - sending patches with
> > > > > > carefully crafted and filtered TO and CC.
> > > > > >
> > > > > > This practice causes to get out of context patches without ability to
> > > > > > see whole picture and the worse part that it divides feedback to
> > > > > > "islands" without ability to agree or disagree with the feedback.
> > > > > 
> > > > > The flip side of copying everyone on everything is that especially for
> > > > > serieses which aren't just repetitive changes this gets really noisy
> > > > > really quickly and things end up just not getting read.
> > > > 
> > > > I think this is quite subjective and different people have different email
> > > > flows.
> > > > 
> > > > For me the most annoying is to get several patches from the middle of a
> > > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > > so that people at least can take a look at high level details and request a
> > > > repost.
> > > 
> > > Could tooling based on lore and b4 help here ? The prospect of getting
> > > more patches in my inbox isn't exactly enticing, but the ability to
> > > quickly get the full context of a patch series is certainly useful (I've
> > > had to look up parts I wasn't CC'ed on previously).
> > 
> > lore definitely helps, but still requires an extra step. I think having the
> > cover letter in your inbox helps to decide if you want to do that extra
> > step.
> 
> Agree about the cover letter, if there's something that needs to be sent
> to all recipients it's that one.

Agreed, especially combined with "the cover latter ought to contain a reference
to git branch, if such exists".

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:28     ` James Bottomley
@ 2021-04-22 15:35       ` Johannes Berg
  2021-04-22 15:36       ` Mark Brown
  1 sibling, 0 replies; 153+ messages in thread
From: Johannes Berg @ 2021-04-22 15:35 UTC (permalink / raw)
  To: James Bottomley, Martin K. Petersen, Mauro Carvalho Chehab; +Cc: ksummit

On Thu, 2021-04-22 at 08:28 -0700, James Bottomley wrote:
> On Thu, 2021-04-22 at 08:32 -0400, Martin K. Petersen wrote:
> > Another metric that may be worth capturing is how many Fixes: tags
> > refer to patches authored by this submitter.
> 
> Or perhaps invert it: no bug fix without a Fixes: tag.

We do this internally on our driver (it also helps see if release
branches need a certain fix or not), but even then you sometimes just
have to give up and say "unknown". Which is still useful to an extent as
long as the developer did the work and didn't just blindly say
"unknown", though the maintainer(s) usually will see and challenge that.

johannes


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:28     ` James Bottomley
  2021-04-22 15:35       ` Johannes Berg
@ 2021-04-22 15:36       ` Mark Brown
  2021-04-22 15:40         ` James Bottomley
  2021-04-23  9:27         ` Dan Carpenter
  1 sibling, 2 replies; 153+ messages in thread
From: Mark Brown @ 2021-04-22 15:36 UTC (permalink / raw)
  To: James Bottomley; +Cc: Martin K. Petersen, Mauro Carvalho Chehab, ksummit

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Thu, Apr 22, 2021 at 08:28:00AM -0700, James Bottomley wrote:
> On Thu, 2021-04-22 at 08:32 -0400, Martin K. Petersen wrote:
> > Another metric that may be worth capturing is how many Fixes: tags
> > refer to patches authored by this submitter.

> Or perhaps invert it: no bug fix without a Fixes: tag.  Some of the
> human handlers of robot based finders, like Dan's smatch, do go back
> and figure out where the bug came from, but if we encourage the rule
> that if you're fixing a bug you must identify the origin and explain
> the bug it may help weed out some bogus fixes.

Script that use git blame to generate a commit to put in the Fixes: tag
incoming...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:18                 ` Leon Romanovsky
@ 2021-04-22 15:38                   ` Shuah Khan
  2021-04-23  9:06                     ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 153+ messages in thread
From: Shuah Khan @ 2021-04-22 15:38 UTC (permalink / raw)
  To: Leon Romanovsky, Mauro Carvalho Chehab
  Cc: Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit, Shuah Khan

On 4/22/21 6:18 AM, Leon Romanovsky wrote:
> On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
>> Em Thu, 22 Apr 2021 09:34:38 +0200
>> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
>>
>>> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 21 Apr 2021, Julia Lawall wrote:
>>>>> The apology states that they didn't detect any vulnerabilities.  They
>>>>> found three non exploitable bugs and submitted incorrect patches for them.
>>>>> When the patches received some positive feedback, they explained that the
>>>>> patches were incorrect and provided a proper fix.
>>>>>
>>>>> So they damaged trust, but not actually the Linux kernel...
>>>>
>>>> The issue is that there was no consent and no coordination, so we don't
>>>> know the scope of the experiment and whether it was still continuing.
>>>>
>>>> We are this not able to trust anything the group said about what they'd
>>>> done or not done, until now [1].
>>>>
>>>> In all probability there is nothing further amiss but we would not have
>>>> expected them to use fake gmail accounts to submit bugs to the kernel
>>>> either.
>>>>
>>>> It's now on us to audit all of their known contributions, because we don't
>>>> know the scope of the experiment, which was based on the use of deception,
>>>> and we can't make any assumptions based on what they have said.
>>>>
>>>> We also need the identity of the 'random' gmail accounts they used,
>>>> although this should be handled by a small trusted group in private, as it
>>>> will lead to privacy issues for kernel maintainers who responded to them
>>>> in public.
>>>
>>> What do we gain by blindly reverting all[1] umn.edu patches, and
>>> ignoring future patches from umn.edu?
>>> I think all of this is moot: other people may be doing the same thing,
>>> or even "in worse faith".  The only thing that helps is making sure
>>> patches get reviewed[2] before being applied.
>>>
>>> [1] Judging from the new review comments, many of the 190 patches
>>>      to be reverted were real fixes.
>>
>> The reverted ones for media (29 patches) didn't contain any malicious code.
>> One was useless (because the media core already fixes the pointed issue),
>> but the other ones were valid patches.
> 
> I'm sorry that I didn't check all media commits, but this random commit
> 467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
> broke sp8870 (I don't know what is it).
> 
> diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
> index 8d31cf3f4f07..270a3c559e08 100644
> --- a/drivers/media/dvb-frontends/sp8870.c
> +++ b/drivers/media/dvb-frontends/sp8870.c
> @@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
>          sp8870_writereg(state, 0xc05, reg0xc05);
> 
>          // read status reg in order to clear pending irqs
> -       sp8870_readreg(state, 0x200);
> +       err = sp8870_readreg(state, 0x200);
> +       if (err)
> +               return err;
> 
>          // system controller start
>          sp8870_microcontroller_start(state);
> 
> 
>     67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
>     68 {
>     69         int ret;
>   <...>
>     77         if (ret != 2) {
>     78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
>     79                 return -1;
>     80         }
>     81
>     82         return (b1[0] << 8 | b1[1]);
>     83 }
> 
> The valid check should be if (err < 0);
> 

Correct. Like all the other callers of sp8870_readreg() do with
its return. Non-zero return is valid for this routine.

thanks,
-- Shuah




^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:36       ` Mark Brown
@ 2021-04-22 15:40         ` James Bottomley
  2021-04-23  9:27         ` Dan Carpenter
  1 sibling, 0 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-22 15:40 UTC (permalink / raw)
  To: Mark Brown; +Cc: Martin K. Petersen, Mauro Carvalho Chehab, ksummit

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Thu, 2021-04-22 at 16:36 +0100, Mark Brown wrote:
> On Thu, Apr 22, 2021 at 08:28:00AM -0700, James Bottomley wrote:
> > On Thu, 2021-04-22 at 08:32 -0400, Martin K. Petersen wrote:
> > > Another metric that may be worth capturing is how many Fixes:
> > > tags refer to patches authored by this submitter.
> >  
> > Or perhaps invert it: no bug fix without a Fixes: tag.  Some of the
> > human handlers of robot based finders, like Dan's smatch, do go
> > back and figure out where the bug came from, but if we encourage
> > the rule that if you're fixing a bug you must identify the origin
> > and explain the bug it may help weed out some bogus fixes.
> 
> Script that use git blame to generate a commit to put in the Fixes:
> tag incoming...

Any system can be gamed, but I was thinking fixes helps ground the
reviewer in where the bug was introduced.  I also wasn't thinking fixes
alone, but fixes: *and* explanation of the bug.

James


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:34   ` Shuah Khan
@ 2021-04-22 15:42     ` James Bottomley
  2021-04-22 15:48       ` James Bottomley
  2021-04-22 16:38       ` Bart Van Assche
  0 siblings, 2 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-22 15:42 UTC (permalink / raw)
  To: Shuah Khan, Mauro Carvalho Chehab; +Cc: ksummit

On Thu, 2021-04-22 at 09:34 -0600, Shuah Khan wrote:
> On 4/22/21 4:35 AM, Mauro Carvalho Chehab wrote:
> > Hi James,
> > 
> > Em Wed, 21 Apr 2021 11:35:36 -0700
> > James Bottomley <James.Bottomley@HansenPartnership.com> escreveu:
> > 
> > > I've long been on record as not really being a fan of trivial
> > > patches
> > > because they can cause merge issues with current patches and
> > > introduce
> > > bugs, particularly in older drivers, that don't get detected for
> > > a long
> > > while.  However, the recent events with the University of
> > > Minnesota:
> > > 
> > > https://lore.kernel.org/lkml/20210421130105.1226686-1-gregkh@linuxfoundation.org/
> > > 
> > > Have elevated the risk factor around trivial patches claiming to
> > > fix
> > > bugs to the point where it looks like there's no such thing as a
> > > truly
> > > trivial patch and they all need reviewing.
> > > 
> > > Our policy in SCSI for a long time has been no trivial patches
> > > accepted
> > > to maintained drivers, and I think that would be a good start if
> > > adopted kernel wide, but I think the next policy should be no
> > > trivial
> > > bug fix without a pointer to the actual bug report or report from
> > > a
> > > trusted static checker.  This would likely mean we have to create
> > > a
> > > list of trusted static checkers ... obviously 0day and coverity
> > > but
> > > what else?
> > 
> > I agree that we should have a "Rethinking the acceptance policy"
> > talk
> > at the Maintainer Summit, but it should cover a scope wider than
> > just
> > trivial patches. At least the patches I checked, sent from
> > "@unm.edu"
> > to media subsystem, they all looked good enough to be merged[1].
> > 
> > The main question is actually what's the degree of confidence a
> > maintainer can rely on a patch sent from a random contributor.
> > 
> > That's not an easy task.
> > 
> > I mean, usually, each maintainer develops internally a "trust
> > score"
> > from subsystem's contributors, but such trustee level is usually
> > not
> > shared with other maintainers.
> > 
> > When a developer reaches a certain level, maintainers are willing
> > to merge their work faster as they know that the developer is
> > there for a while and it is not trying to harm the community.
> > 
> > Perhaps one thing that we could add would be a
> > scripts/get_developer_trustee_status, which would be returning
> > a set of indicators that would help the maintainer to know
> > how much it can trust a random contributor, like:
> > 
> > 	- how many drivers and patches a contributor has written;
> > 	- how long and how frequent he's sending Kernel patches;
> > 	- what subsystems received patches from him;
> > 	- if the developer isn't on a blacklist/graylist.
> > 
> > 
> 
> This will put new developers at disadvantage. Let's think this
> through before adding barriers for entry.

OK, so I think there are several separate topics now:

   1. how trust is generated in the ecosystem.  I think that's a long
      conversation and one of the big dangers is actually not only
      discouraging new entrants but also drive by submitters, who by their
      very nature will not have the necessary trust flag.  I still think
      if you don't know the submitter, you can still trust the code if you
      can clearly see what it's doing and why.
   2. Improving the requirement for bug fixes and large series, like cover
      letters to everyone, adding fixes: tag and clear explanation.
   3. Better handling of "trivial" changes, say via a resurrected trivial
      tree

James



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:42     ` James Bottomley
@ 2021-04-22 15:48       ` James Bottomley
  2021-04-22 15:52         ` Steven Rostedt
  2021-04-22 16:23         ` Konstantin Ryabitsev
  2021-04-22 16:38       ` Bart Van Assche
  1 sibling, 2 replies; 153+ messages in thread
From: James Bottomley @ 2021-04-22 15:48 UTC (permalink / raw)
  To: Shuah Khan, Mauro Carvalho Chehab; +Cc: ksummit

On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
[...]
>    2. Improving the requirement for bug fixes and large series, like
> cover letters to everyone, adding fixes: tag and clear explanation.

Just on this one, can we get the mailing list to help now we're moving
to a new infrastructure?  I was already thinking of asking if it could
reject email with html parts rather than simply losing it, but perhaps
it could reject threaded submissions where the cover letter isn't
correctly cc'd?  I know that's a big ask because there has to be an
easy way to recognize them (heuristics on the PATCH tag?) and a way to
recognize missing cc's (perhaps simply that someone cc'd on the
threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)

James



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:48       ` James Bottomley
@ 2021-04-22 15:52         ` Steven Rostedt
  2021-04-22 16:08           ` Shuah Khan
                             ` (2 more replies)
  2021-04-22 16:23         ` Konstantin Ryabitsev
  1 sibling, 3 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 15:52 UTC (permalink / raw)
  To: James Bottomley; +Cc: Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, 22 Apr 2021 08:48:21 -0700
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> [...]
> >    2. Improving the requirement for bug fixes and large series, like
> > cover letters to everyone, adding fixes: tag and clear explanation.  
> 
> Just on this one, can we get the mailing list to help now we're moving
> to a new infrastructure?  I was already thinking of asking if it could
> reject email with html parts rather than simply losing it, but perhaps
> it could reject threaded submissions where the cover letter isn't
> correctly cc'd?  I know that's a big ask because there has to be an
> easy way to recognize them (heuristics on the PATCH tag?) and a way to
> recognize missing cc's (perhaps simply that someone cc'd on the
> threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)

Unfortunately, this breaks all quilt users, as quilt does not support this.

Which includes myself, perhaps Peter Zijlstra, and I believe Andrew Morton.

I also, don't want to be Cc'd on the cover letter of stable patches, which
also doesn't follow this procedure.

-- Steve


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  5:59     ` Christoph Hellwig
  2021-04-22  6:28       ` Tomasz Figa
  2021-04-22  7:05       ` Jiri Kosina
@ 2021-04-22 16:05       ` Roland Dreier
  2021-04-22 16:24         ` Krzysztof Kozlowski
  2021-04-22 18:03       ` Al Viro
  3 siblings, 1 reply; 153+ messages in thread
From: Roland Dreier @ 2021-04-22 16:05 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Steven Rostedt, James Bottomley, ksummit

On Wed, Apr 21, 2021 at 11:00 PM Christoph Hellwig <hch@infradead.org> wrote:

> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > I also think there does need to be a strong sanction against this UMN
> > research group, since we need to make sure there are strong incentives
> > against wasting everyone's time with stunts like this.  Hopefully on
> > the academic side it can be made clear that this is not ethical
> > research - for example, why did IEEE think this was an acceptable
> > paper?
>
> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> been long overdue, and kicked off a very important discussion.  Even
> more so as in this area malice is almost indistinguishable from normal
> incompetence.  I think they deserve a medel of honor.

I think everyone already knew bad patches could get merged.  I'm not
convinced Greg sending a giant pile of patches, some/most of which
seem to be reverting valid fixes and reintroducing bugs, is
particularly productive either.

In any case, academic researchers have an ethical obligation not to
experiment on people without informing them.  When CS research turns
into social science or psychology research, the researchers need to
follow well-established rules about research on human subjects.

In fact it's not clear what happened here - the UMN group has said
that their research was reviewed and approved by their IRB and was
designed and conducted so that no malicious patches ended up applied
to any git tree.  That may or may not be true but Greg's
(over)reaction seems to have generated a lot of unhelpful noise.

 - R.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:52         ` Steven Rostedt
@ 2021-04-22 16:08           ` Shuah Khan
  2021-04-22 16:13           ` Jan Kara
  2021-04-23  7:58           ` Mauro Carvalho Chehab
  2 siblings, 0 replies; 153+ messages in thread
From: Shuah Khan @ 2021-04-22 16:08 UTC (permalink / raw)
  To: Steven Rostedt, James Bottomley
  Cc: Mauro Carvalho Chehab, ksummit, Shuah Khan

On 4/22/21 9:52 AM, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 08:48:21 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
>> On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
>> [...]
>>>     2. Improving the requirement for bug fixes and large series, like
>>> cover letters to everyone, adding fixes: tag and clear explanation.
>>
>> Just on this one, can we get the mailing list to help now we're moving
>> to a new infrastructure?  I was already thinking of asking if it could
>> reject email with html parts rather than simply losing it, but perhaps
>> it could reject threaded submissions where the cover letter isn't
>> correctly cc'd?  I know that's a big ask because there has to be an
>> easy way to recognize them (heuristics on the PATCH tag?) and a way to
>> recognize missing cc's (perhaps simply that someone cc'd on the
>> threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)
> 

One thing that would be helpful is rejecting patches that aren't cc'ed
to the maintainers. I have had two recent cases where the patches were
delegated to me in patchwork and I had to go find them. I did the
extra work primarily because the patch was sent by a new developer.

It adds extra work for sure.

> Unfortunately, this breaks all quilt users, as quilt does not support this.
> 
> Which includes myself, perhaps Peter Zijlstra, and I believe Andrew Morton.
> 
> I also, don't want to be Cc'd on the cover letter of stable patches, which
> also doesn't follow this procedure.
> 

I didn't realize quilt doesn't support it.

thanks,
-- Shuah



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:52         ` Steven Rostedt
  2021-04-22 16:08           ` Shuah Khan
@ 2021-04-22 16:13           ` Jan Kara
  2021-04-22 17:04             ` Steven Rostedt
  2021-04-22 17:08             ` Martin K. Petersen
  2021-04-23  7:58           ` Mauro Carvalho Chehab
  2 siblings, 2 replies; 153+ messages in thread
From: Jan Kara @ 2021-04-22 16:13 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: James Bottomley, Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu 22-04-21 11:52:35, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 08:48:21 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> > [...]
> > >    2. Improving the requirement for bug fixes and large series, like
> > > cover letters to everyone, adding fixes: tag and clear explanation.  
> > 
> > Just on this one, can we get the mailing list to help now we're moving
> > to a new infrastructure?  I was already thinking of asking if it could
> > reject email with html parts rather than simply losing it, but perhaps
> > it could reject threaded submissions where the cover letter isn't
> > correctly cc'd?  I know that's a big ask because there has to be an
> > easy way to recognize them (heuristics on the PATCH tag?) and a way to
> > recognize missing cc's (perhaps simply that someone cc'd on the
> > threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)
> 
> Unfortunately, this breaks all quilt users, as quilt does not support this.

Is it that hard to improve quilt?

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:48       ` James Bottomley
  2021-04-22 15:52         ` Steven Rostedt
@ 2021-04-22 16:23         ` Konstantin Ryabitsev
  1 sibling, 0 replies; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-22 16:23 UTC (permalink / raw)
  To: James Bottomley; +Cc: Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, Apr 22, 2021 at 08:48:21AM -0700, James Bottomley wrote:
> On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> [...]
> >    2. Improving the requirement for bug fixes and large series, like
> > cover letters to everyone, adding fixes: tag and clear explanation.
> 
> Just on this one, can we get the mailing list to help now we're moving
> to a new infrastructure?  I was already thinking of asking if it could
> reject email with html parts rather than simply losing it

That's the case on the new server -- senders will get a "looks like you tried
to post a HTML message" rejection.

> but perhaps it could reject threaded submissions where the cover letter
> isn't correctly cc'd?  I know that's a big ask because there has to be an
> easy way to recognize them (heuristics on the PATCH tag?) and a way to
> recognize missing cc's (perhaps simply that someone cc'd on the threaded
> [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)

That's not something we can reasonably do, as this requires tracking across
multiple messages and reconstituting threads as opposed to applying logic
based on the contents of a single message.

I think it's better to provide improved submitter tooling than to catch all
possible corner-cases related to series/threads.

-K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:05       ` Roland Dreier
@ 2021-04-22 16:24         ` Krzysztof Kozlowski
  0 siblings, 0 replies; 153+ messages in thread
From: Krzysztof Kozlowski @ 2021-04-22 16:24 UTC (permalink / raw)
  To: Roland Dreier; +Cc: Christoph Hellwig, Steven Rostedt, James Bottomley, ksummit

On Thu, 22 Apr 2021 at 18:06, Roland Dreier <roland@kernel.org> wrote:
> In any case, academic researchers have an ethical obligation not to
> experiment on people without informing them.  When CS research turns
> into social science or psychology research, the researchers need to
> follow well-established rules about research on human subjects.
>
> In fact it's not clear what happened here - the UMN group has said
> that their research was reviewed and approved by their IRB and was
> designed and conducted so that no malicious patches ended up applied
> to any git tree.  That may or may not be true but Greg's
> (over)reaction seems to have generated a lot of unhelpful noise.

There is a statement now from UMN:
https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021
"Leadership in the University of Minnesota Department of Computer
Science & Engineering learned today about the details of research
being conducted..."
so one could question their review and approval process by IRB.

That research supposedly did not commit anything bad but, as was
found, there were buggy commits from uwn.net. Maybe they were part of
other research, maybe not? And now how do you know that research
actually ended or that there is no new research (since it's secret
till not finished)? What assurances do you have that recent commits
were in good faith, if original trust is ruined and benefit of doubt
is gone?

Best regards,
Krzysztof

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 13:27         ` Konstantin Ryabitsev
  2021-04-22 13:41           ` Leon Romanovsky
@ 2021-04-22 16:28           ` Serge E. Hallyn
  1 sibling, 0 replies; 153+ messages in thread
From: Serge E. Hallyn @ 2021-04-22 16:28 UTC (permalink / raw)
  To: Konstantin Ryabitsev
  Cc: Leon Romanovsky, Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 09:27:36AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 04:08:47PM +0300, Leon Romanovsky wrote:
> > > You'll need to adjust it to point at where your maildir lives, of course, but
> > > that's the general idea. With it in place, you can hit "4" in the index view
> > > to get the rest of the thread (without duplicating the messages you already
> > > have).
> > 
> > Thanks, I'll try it, however it will fit my flow only partially.
> > 
> > This macro will bring the missing patches only when I'm near computer (mutt),
> > while in my flow, I'm reading emails from the phone and only for the replies use
> > the computer.
> 
> You may be better served by the upcoming "lei" tool, then. It can identify
> threads of interest to you (e.g. those on which you are cc'd), put them
> into your local or remote inbox, and continuously update them as new messages
> come in. If you run it as a background process, you'll get the workflow you're
> wanting.
> 
> -K

That sounds awesome.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:42     ` James Bottomley
  2021-04-22 15:48       ` James Bottomley
@ 2021-04-22 16:38       ` Bart Van Assche
  2021-04-22 16:57         ` Leon Romanovsky
  2021-04-22 18:03         ` Jiri Kosina
  1 sibling, 2 replies; 153+ messages in thread
From: Bart Van Assche @ 2021-04-22 16:38 UTC (permalink / raw)
  To: James Bottomley, Shuah Khan, Mauro Carvalho Chehab; +Cc: ksummit

On 4/22/21 8:42 AM, James Bottomley wrote:
>    3. Better handling of "trivial" changes, say via a resurrected trivial
>       tree

Why was the trivial tree introduced? I may be missing some history here.

I'm not convinced that sending trivial patches to a separate mailing
list and maintainer helps everyone. As an example, I want to see block
layer patches being posted on the block layer mailing list and I want to
see SCSI patches being posted on the SCSI mailing list. I don't want to
have to follow a separate "trivial" mailing list to verify whether or
not e.g. a patch is posted on that mailing list that changes a correct
comment into an incorrect comment.

Thanks,

Bart.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  3:04   ` Joe Perches
  2021-04-22 10:13     ` Mauro Carvalho Chehab
  2021-04-22 12:07     ` Mark Brown
@ 2021-04-22 16:42     ` Bart Van Assche
  2021-04-22 17:58       ` Jiri Kosina
  2 siblings, 1 reply; 153+ messages in thread
From: Bart Van Assche @ 2021-04-22 16:42 UTC (permalink / raw)
  To: Joe Perches, Martin K. Petersen, James Bottomley; +Cc: ksummit

On 4/21/21 8:04 PM, Joe Perches wrote:
> And I believe James is referring to whitespace style trivial patches.

Maybe it's just me but I don't like patches that only change whitespace
or the coding style. I'm fine with such patches if these are part of a
larger patch series that also fixes bugs but not if such patches are
posted on their own. "git log -p" and "git blame" are important tools to
learn more about why code evolved into its current state.
Whitespace-only patches make it harder to follow how code evolved into
its current state.

Thanks,

Bart.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:38       ` Bart Van Assche
@ 2021-04-22 16:57         ` Leon Romanovsky
  2021-04-22 18:03         ` Jiri Kosina
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 16:57 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: James Bottomley, Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, Apr 22, 2021 at 09:38:32AM -0700, Bart Van Assche wrote:
> On 4/22/21 8:42 AM, James Bottomley wrote:
> >    3. Better handling of "trivial" changes, say via a resurrected trivial
> >       tree
> 
> Why was the trivial tree introduced? I may be missing some history here.
> 
> I'm not convinced that sending trivial patches to a separate mailing
> list and maintainer helps everyone. As an example, I want to see block
> layer patches being posted on the block layer mailing list and I want to
> see SCSI patches being posted on the SCSI mailing list. I don't want to
> have to follow a separate "trivial" mailing list to verify whether or
> not e.g. a patch is posted on that mailing list that changes a correct
> comment into an incorrect comment.

Completely agree, the idea that trivial.git patches don't need review of
relevant maintainer sounds wrong to me. And if the maintainer looks on
them, he/she can apply them directly.

Thanks

> 
> Thanks,
> 
> Bart.
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:13           ` Jan Kara
@ 2021-04-22 17:04             ` Steven Rostedt
  2021-04-22 17:08             ` Martin K. Petersen
  1 sibling, 0 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 17:04 UTC (permalink / raw)
  To: Jan Kara; +Cc: James Bottomley, Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, 22 Apr 2021 18:13:40 +0200
Jan Kara <jack@suse.cz> wrote:

> > Unfortunately, this breaks all quilt users, as quilt does not support this.  
> 
> Is it that hard to improve quilt?

I've toyed with fixing this, and almost had it working once. I just never
had time to get it fully working.

But no, it's not hard. But it does require a good understanding of both
bash script and Perl ;-)

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:13           ` Jan Kara
  2021-04-22 17:04             ` Steven Rostedt
@ 2021-04-22 17:08             ` Martin K. Petersen
  2021-04-23 11:16               ` Jan Kara
  1 sibling, 1 reply; 153+ messages in thread
From: Martin K. Petersen @ 2021-04-22 17:08 UTC (permalink / raw)
  To: Jan Kara
  Cc: Steven Rostedt, James Bottomley, Shuah Khan,
	Mauro Carvalho Chehab, ksummit


Jan,

> Is it that hard to improve quilt?

Now that we have tighter integration between the various components of
our infrastructure, I wonder if we should reconsider the patch
submission process?

Instead of putting the burden on the submitter to pick the right 20
mailing lists to CC: and accommodate 100 developers and maintainers with
individual delivery preferences, why not let the k.org infrastructure
automate that aspect?

Have a patch ingress email address that runs get_maintainer.pl to figure
out who to reach out to. And then everybody with a kernel.org account
can twiddle their preferences wrt. whether to receive the whole series,
only patches that touch files they are responsible for, opt not to
receive individual mails but only the relevant mailing list copy,
whether to receive stable backport notifications, etc.

That would substantially lower the barrier of entry for patch
submitters. More work for Konstantin, obviously. And potentially some
transitional grievances for most of the rest of us based on our
individual workflows and preferences.

Just an idea, I know it's a bit controversial. However, there seems to
be no shortage of problems originating in the patch mail preparation and
sending department. Seems like a bigger barrier for some than developing
the actual patch.

We could even consider supporting receiving and disseminating git
bundles on the ingress. That would help overcome the many problems with
corporate email servers vs. git send-email. A ton of problems are
introduced as developers copy and paste things from their corporate
email to GMail, etc. Seems like our backend tooling could help alleviate
some of those pains without completely wrecking the mail-based flow we
maintainers are comfortable with...

-- 
Martin K. Petersen	Oracle Linux Engineering

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
  2021-04-22 13:08       ` Leon Romanovsky
@ 2021-04-22 17:56       ` Leon Romanovsky
  2021-04-22 18:05         ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
  2021-04-23  7:19       ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
  2021-04-23  7:31       ` Christian Brauner
  3 siblings, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-22 17:56 UTC (permalink / raw)
  To: Konstantin Ryabitsev; +Cc: Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 08:53:57AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> > Also, nowadays, with lore and b4, it would be easy to retrieve the
> > entire patch series, even for those that aren't subscribed on a 
> > c/c mailing list.
> 
> If you're a mutt user, you can set up a keybinding, e.g.:
> 
>     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"
> 
> You'll need to adjust it to point at where your maildir lives, of course, but
> that's the general idea. With it in place, you can hit "4" in the index view
> to get the rest of the thread (without duplicating the messages you already
> have).

Konstantin,

I tried the above and here the obstacles which I encounter.
1. My emails are stored in Maildir. The mb2md script half-worked but ok
for the test.
2. b4 didn't work if I tried to use lore link from the middle of discussion,
which is very common pattern to me.
3. b4 didn't grab the discussions, so I got the patches, but didn't get and
won't get any interesting to me responses.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:42     ` Bart Van Assche
@ 2021-04-22 17:58       ` Jiri Kosina
  0 siblings, 0 replies; 153+ messages in thread
From: Jiri Kosina @ 2021-04-22 17:58 UTC (permalink / raw)
  To: Bart Van Assche; +Cc: Joe Perches, Martin K. Petersen, James Bottomley, ksummit

On Thu, 22 Apr 2021, Bart Van Assche wrote:

> > And I believe James is referring to whitespace style trivial patches.
> 
> Maybe it's just me but I don't like patches that only change whitespace
> or the coding style. I'm fine with such patches if these are part of a
> larger patch series that also fixes bugs but not if such patches are
> posted on their own. "git log -p" and "git blame" are important tools to
> learn more about why code evolved into its current state.
> Whitespace-only patches make it harder to follow how code evolved into
> its current state.

Just to state the (hopefully) obvious -- even on the rare ocasions I am 
actually collecting patches for trivial.git, I am ignoring whitespace-only 
"fixes".

-- 
Jiri Kosina
Director, SUSE Labs Core

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  5:59     ` Christoph Hellwig
                         ` (2 preceding siblings ...)
  2021-04-22 16:05       ` Roland Dreier
@ 2021-04-22 18:03       ` Al Viro
  2021-04-22 22:35         ` Thomas Gleixner
  3 siblings, 1 reply; 153+ messages in thread
From: Al Viro @ 2021-04-22 18:03 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 06:59:48AM +0100, Christoph Hellwig wrote:
> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > I also think there does need to be a strong sanction against this UMN
> > research group, since we need to make sure there are strong incentives
> > against wasting everyone's time with stunts like this.  Hopefully on
> > the academic side it can be made clear that this is not ethical
> > research - for example, why did IEEE think this was an acceptable
> > paper?
> 
> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> been long overdue, and kicked off a very important discussion.  Even
> more so as in this area malice is almost indistinguishable from normal
> incompetence.  I think they deserve a medel of honor.

Demonstrating this kind of attack would be very useful, if they bothered to
provide the raw data and their protocol.

They'd done neither, AFAICS.  There's no way to actually look at how the
submissions went, timings, etc.  We are offered what could (very generously)
be called aggregate stats illustrating the problems, along with bloody
worthless suggestions of improvements.  Use of the technics in question
is not limited to introducing UAF bugs; it's certainly possible to use
a (real or not) UAF bug as an excuse to get in something designed _not_
to be caught by any of their suggested scler^Whardening patches, etc.

There certainly are very real problems with review process, and examining
their data might provide useful insights - had any of that data been
given.

There are tons of problems with their paper, and not in the ethics part.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 16:38       ` Bart Van Assche
  2021-04-22 16:57         ` Leon Romanovsky
@ 2021-04-22 18:03         ` Jiri Kosina
  2021-04-22 21:26           ` Thomas Gleixner
  1 sibling, 1 reply; 153+ messages in thread
From: Jiri Kosina @ 2021-04-22 18:03 UTC (permalink / raw)
  To: Bart Van Assche
  Cc: James Bottomley, Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, 22 Apr 2021, Bart Van Assche wrote:

> Why was the trivial tree introduced? I may be missing some history here.

The idea (some time in the stone age, way before I took it over), IIRC, 
was that trivial patches are eating up cycles of maintainers that could be 
spent in better way.

This reasoning is completely moot now of course, as I myself don't have 
time for taking care of that tree any more for quite some time already.

Earth would definitely not stop rotating if we nuke any mentions of 
trivial@ from the Documentation/ altogether.

> I'm not convinced that sending trivial patches to a separate mailing 
> list and maintainer helps everyone. As an example, I want to see block 
> layer patches being posted on the block layer mailing list and I want to 
> see SCSI patches being posted on the SCSI mailing list. I don't want to 
> have to follow a separate "trivial" mailing list to verify whether or 
> not e.g. a patch is posted on that mailing list that changes a correct 
> comment into an incorrect comment.

Most of the patches have usually been of a 'fix typo in english wording in 
a comment / printk()' nature.

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-22 17:56       ` Leon Romanovsky
@ 2021-04-22 18:05         ` Konstantin Ryabitsev
  0 siblings, 0 replies; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-22 18:05 UTC (permalink / raw)
  To: Leon Romanovsky; +Cc: ksummit, tools

On Thu, Apr 22, 2021 at 08:56:45PM +0300, Leon Romanovsky wrote:
> >     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"
> > 
> > You'll need to adjust it to point at where your maildir lives, of course, but
> > that's the general idea. With it in place, you can hit "4" in the index view
> > to get the rest of the thread (without duplicating the messages you already
> > have).
> 
> Konstantin,
> 
> I tried the above and here the obstacles which I encounter.

This is probably better suited for tools@linux.kernel.org (cc'ing
accordingly).

> 1. My emails are stored in Maildir. The mb2md script half-worked but ok
> for the test.
> 2. b4 didn't work if I tried to use lore link from the middle of discussion,
> which is very common pattern to me.
> 3. b4 didn't grab the discussions, so I got the patches, but didn't get and
> won't get any interesting to me responses.

Are you sure you copied the command correctly? 

1. It should automatically recognize when it's pointed at a maildir, so no
   mb2md should be necessary. Are you sure you changed "-o ~/Mail" to be
   pointing at your maildir?
2. It's supposed to grab the message-id from the piped message, so you
   shouldn't need to pass any lore links.
3. Are you sure you're using "b4 mbox" not "b4 am"? The mbox command just
   returns the entire thread.

Please feel free to drop ksummit and others on your reply.

-K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22  9:59     ` Johannes Berg
  2021-04-22 10:52       ` Mauro Carvalho Chehab
@ 2021-04-22 20:15       ` Alexandre Belloni
  2021-04-23  0:09         ` Randy Dunlap
  1 sibling, 1 reply; 153+ messages in thread
From: Alexandre Belloni @ 2021-04-22 20:15 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Mauro Carvalho Chehab, Dan Carpenter, James Bottomley, ksummit

On 22/04/2021 11:59:38+0200, Johannes Berg wrote:
> On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:
> > 
> > Here, I use "wdiff" in order to deal with renames. It has a somewhat
> > funny dialect, but it helps a lot reviewing renaming patches.
> 
> This also helps for casual "git show" etc.:
> 
> [core]
> 	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX
> 
> (path may vary, of course)
> 

I've been shown https://github.com/dandavison/delta/ a little while ago
and it has a very good side by side view, showing exactly what change on
each line. I'm using:

[core]
        pager = delta
[delta]
        plus-color = "#012800"
        minus-color = "#340001"
        syntax-theme = Solarized (light)
        line-numbers = true
        side-by-side = true

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 11:03   ` Sudip Mukherjee
  2021-04-22 14:00     ` Steven Rostedt
@ 2021-04-22 20:28     ` Andrew Morton
  2021-04-22 20:46       ` Steven Rostedt
  1 sibling, 1 reply; 153+ messages in thread
From: Andrew Morton @ 2021-04-22 20:28 UTC (permalink / raw)
  To: Sudip Mukherjee
  Cc: Mauro Carvalho Chehab, James Bottomley, ksummit, Jiri Kosina

On Thu, 22 Apr 2021 12:03:24 +0100 Sudip Mukherjee <sudipm.mukherjee@gmail.com> wrote:

> May I suggest that we have a separate tree for trivial patches like
> the trivial.git tree that Jiri has and all trivial patches goes
> through that tree.

I'd prefer that such things go through my own hands, please.  For
reasons such as those that started this discussion.


Also, yes, "who sent it" is a key input to how carefully the patch is
treated.  If I don't recognize the name, I'll go through the patch with
a toothcomb due to lack of trust.

If I'm still not confident and nobody else has reviewed it (believably)
then I simply won't send it upstream.

So, obviously, the way to get malicious stuff past me is to forge the
sender's email address.  But hopefully the developer whose address was
forged will be awake enough to say "hey I didn't write that" in
response to the 2+ copies which I'll echo back at him/her.


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 20:28     ` Andrew Morton
@ 2021-04-22 20:46       ` Steven Rostedt
  0 siblings, 0 replies; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 20:46 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Sudip Mukherjee, Mauro Carvalho Chehab, James Bottomley, ksummit,
	Jiri Kosina

On Thu, 22 Apr 2021 13:28:31 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> So, obviously, the way to get malicious stuff past me is to forge the
> sender's email address.  But hopefully the developer whose address was
> forged will be awake enough to say "hey I didn't write that" in
> response to the 2+ copies which I'll echo back at him/her.

And not yet senile where we are forgetting half the patches we write ;-)

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:19         ` Steven Rostedt
@ 2021-04-22 21:19           ` Thomas Gleixner
  2021-04-22 21:36             ` Steven Rostedt
  2021-04-23  6:15           ` Greg KH
  1 sibling, 1 reply; 153+ messages in thread
From: Thomas Gleixner @ 2021-04-22 21:19 UTC (permalink / raw)
  To: Steven Rostedt, Mark Brown
  Cc: Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22 2021 at 11:19, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 14:23:39 +0100
> Mark Brown <broonie@kernel.org> wrote:
>
>> > For me the most annoying is to get several patches from the middle of a
>> > series. IMHO, sending at least cover letter to everyone is the bare minimum
>> > so that people at least can take a look at high level details and request a
>> > repost.  
>> 
>> Yes, the cover letter should always go to everyone.
>
> And that's still the one thing that quilt send-mail does not support :-p

It's not rocket science to fix that with some scripting around it.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 18:03         ` Jiri Kosina
@ 2021-04-22 21:26           ` Thomas Gleixner
  2021-04-22 21:36             ` Jiri Kosina
  0 siblings, 1 reply; 153+ messages in thread
From: Thomas Gleixner @ 2021-04-22 21:26 UTC (permalink / raw)
  To: Jiri Kosina, Bart Van Assche
  Cc: James Bottomley, Shuah Khan, Mauro Carvalho Chehab, ksummit

On Thu, Apr 22 2021 at 20:03, Jiri Kosina wrote:
> On Thu, 22 Apr 2021, Bart Van Assche wrote:
>
>> Why was the trivial tree introduced? I may be missing some history here.
>
> The idea (some time in the stone age, way before I took it over), IIRC, 
> was that trivial patches are eating up cycles of maintainers that could be 
> spent in better way.
>
> This reasoning is completely moot now of course, as I myself don't have 
> time for taking care of that tree any more for quite some time already.
>
> Earth would definitely not stop rotating if we nuke any mentions of 
> trivial@ from the Documentation/ altogether.
>
>> I'm not convinced that sending trivial patches to a separate mailing 
>> list and maintainer helps everyone. As an example, I want to see block 
>> layer patches being posted on the block layer mailing list and I want to 
>> see SCSI patches being posted on the SCSI mailing list. I don't want to 
>> have to follow a separate "trivial" mailing list to verify whether or 
>> not e.g. a patch is posted on that mailing list that changes a correct 
>> comment into an incorrect comment.
>
> Most of the patches have usually been of a 'fix typo in english wording in 
> a comment / printk()' nature.

But even that typo muck creates conflicts which are not necessary at
all. So yes, that trivial thing should just die.

It seemed to be a good idea long ago ...

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:31         ` Sudip Mukherjee
@ 2021-04-22 21:33           ` Thomas Gleixner
  0 siblings, 0 replies; 153+ messages in thread
From: Thomas Gleixner @ 2021-04-22 21:33 UTC (permalink / raw)
  To: Sudip Mukherjee, Jiri Kosina
  Cc: Steven Rostedt, Mauro Carvalho Chehab, James Bottomley, ksummit

On Thu, Apr 22 2021 at 16:31, Sudip Mukherjee wrote:
> On Thu, Apr 22, 2021 at 3:07 PM Jiri Kosina <jikos@kernel.org> wrote:
>>
>> On Thu, 22 Apr 2021, Steven Rostedt wrote:
>>
>> > > May I suggest that we have a separate tree for trivial patches like
>> > > the trivial.git tree that Jiri has and all trivial patches goes
>> >
>> > Funny that you suggest something that we already have and you mention. Yes
>> > Jiri had the trivial tree, but because it ends up being a lot of work, and
>> > if the maintainer of that tree doesn't have the time to maintain it, it
>> > becomes a dead end for those patches.
>> >
>> > It requires someone with a good enough reputation to maintain it, and that
>> > means most people who have that reputation do not have the time to maintain
>> > it ;-)
>>
>> Yeah, amen to that :)
>
> I know, shortage of maintainers and reviewers.
> I guess my suggestion was that all trivial patches goes via the
> trivial tree and to have a group of interested people reviewing
> patches which are submitted to trivial.
>
>>
>> That tree still sort of exists, I am collecting the patches that are sent
>> there every now and then in big batches, and those which are still
>> relevant by then I send to Linus afterwards.
>
> I think this is a big blocker. Unless patches are applied to the tree
> soon and added to linux-next, anyone creating patches based on that
> tree and sending the patch might/will see the patch irrelevant.

The proper solution is to get rid of trivial@ completely. It's not
solving any problem at all.

And a new variant of trivial@ will have the same fate.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 21:19           ` Thomas Gleixner
@ 2021-04-22 21:36             ` Steven Rostedt
  2021-04-22 22:39               ` Thomas Gleixner
  0 siblings, 1 reply; 153+ messages in thread
From: Steven Rostedt @ 2021-04-22 21:36 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Mark Brown, Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Thu, 22 Apr 2021 23:19:41 +0200
Thomas Gleixner <tglx@linutronix.de> wrote:

> On Thu, Apr 22 2021 at 11:19, Steven Rostedt wrote:
> > On Thu, 22 Apr 2021 14:23:39 +0100
> > Mark Brown <broonie@kernel.org> wrote:
> >  
> >> > For me the most annoying is to get several patches from the middle of a
> >> > series. IMHO, sending at least cover letter to everyone is the bare minimum
> >> > so that people at least can take a look at high level details and request a
> >> > repost.    
> >> 
> >> Yes, the cover letter should always go to everyone.  
> >
> > And that's still the one thing that quilt send-mail does not support :-p  
> 
> It's not rocket science to fix that with some scripting around it.
> 

You can script it so that everyone in the Cc's gets all patches, but you
need to modify quilt to make it where it sends the extra Cc's just the
cover letter.

Another approach is to have quilt just save to a mbox, and modify that, and
use another mail program to send that mbox.

-- Steve

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 21:26           ` Thomas Gleixner
@ 2021-04-22 21:36             ` Jiri Kosina
  0 siblings, 0 replies; 153+ messages in thread
From: Jiri Kosina @ 2021-04-22 21:36 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Bart Van Assche, James Bottomley, Shuah Khan,
	Mauro Carvalho Chehab, ksummit

On Thu, 22 Apr 2021, Thomas Gleixner wrote:

> >> I'm not convinced that sending trivial patches to a separate mailing 
> >> list and maintainer helps everyone. As an example, I want to see block 
> >> layer patches being posted on the block layer mailing list and I want to 
> >> see SCSI patches being posted on the SCSI mailing list. I don't want to 
> >> have to follow a separate "trivial" mailing list to verify whether or 
> >> not e.g. a patch is posted on that mailing list that changes a correct 
> >> comment into an incorrect comment.
> >
> > Most of the patches have usually been of a 'fix typo in english wording in 
> > a comment / printk()' nature.
> 
> But even that typo muck creates conflicts which are not necessary at
> all. So yes, that trivial thing should just die.
> 
> It seemed to be a good idea long ago ...

Yeah, the tools for applying patches have improved since then a little bit 
:), so it's not really saving time of anyone any longer (even if it was 
actually functional, which it's not).

I'll remove it for 5.13 from Documentation/ and MAINTAINERS unless anybody 
comes up with a very good reason for keeping it. Which I doubt.

Thanks,

-- 
Jiri Kosina
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 18:03       ` Al Viro
@ 2021-04-22 22:35         ` Thomas Gleixner
  2021-04-22 22:53           ` Laurent Pinchart
  0 siblings, 1 reply; 153+ messages in thread
From: Thomas Gleixner @ 2021-04-22 22:35 UTC (permalink / raw)
  To: Al Viro, Christoph Hellwig
  Cc: Roland Dreier, Steven Rostedt, James Bottomley, ksummit

Al,

On Thu, Apr 22 2021 at 18:03, Al Viro wrote:
> On Thu, Apr 22, 2021 at 06:59:48AM +0100, Christoph Hellwig wrote:
>> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
>> > I also think there does need to be a strong sanction against this UMN
>> > research group, since we need to make sure there are strong incentives
>> > against wasting everyone's time with stunts like this.  Hopefully on
>> > the academic side it can be made clear that this is not ethical
>> > research - for example, why did IEEE think this was an acceptable
>> > paper?
>> 
>> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
>> been long overdue, and kicked off a very important discussion.  Even
>> more so as in this area malice is almost indistinguishable from normal
>> incompetence.  I think they deserve a medel of honor.
>
> Demonstrating this kind of attack would be very useful, if they bothered to
> provide the raw data and their protocol.
>
> They'd done neither, AFAICS.  There's no way to actually look at how the
> submissions went, timings, etc.  We are offered what could (very generously)
> be called aggregate stats illustrating the problems, along with bloody
> worthless suggestions of improvements.  Use of the technics in question
> is not limited to introducing UAF bugs; it's certainly possible to use
> a (real or not) UAF bug as an excuse to get in something designed _not_
> to be caught by any of their suggested scler^Whardening patches, etc.
>
> There certainly are very real problems with review process, and examining
> their data might provide useful insights - had any of that data been
> given.

I agree.

Though the most important takeaway for me is that this demonstrated the
problems which the kernel development has - once more.

What's worse is that it's known for quite some time that the kernel
development is understaffed and cannot keep up with the influx of
patches. Of course this has been willfully ignored - similar to other
completely avoidable horrors like the ssl disaster.

There is a long list of issues which lead to that situation, but let me
pick a few really important ones:

  - The 'features and performance first, correctness maybe' mentality in
    this industry.

  - The ignorance which takes the availability and sustainability of
    FOSS components especially "low-level plumbing" ones for granted,
    even if their business is built on and depends on these.

  - The unwillingness to put money on basic "low-level" technology just
    because it does not come with the 'hype-of-the-day' tag and is
    therefore useless for marketing and headlines.

None of these things can be solved at the technical level. There is no
technical solution which solves problems at the human stupidity and
even less so at the greed level.

While in theory the approach of sharing the workload for base technology
is obviously the right thing to do, the reality tells that sharing is
interpreted as make sure that someone else pays for it and I can push my
feature agenda.

As long as that does not change, nothing will change.

We can put technical countermeasures (as discussed elsewhere in this
thread) in place as much as we want, they are just futile attempts which
try to cure the symptoms.

As technical people we all know how useful the approach of curing the
symptoms instead of the root cause is. But still we try to do that
because we think it's our only option.

It's about time to rethink that approach.

Thanks,

        Thomas








^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 21:36             ` Steven Rostedt
@ 2021-04-22 22:39               ` Thomas Gleixner
  2021-04-23  0:26                 ` Joe Perches
  0 siblings, 1 reply; 153+ messages in thread
From: Thomas Gleixner @ 2021-04-22 22:39 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Mark Brown, Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22 2021 at 17:36, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 23:19:41 +0200
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
>> On Thu, Apr 22 2021 at 11:19, Steven Rostedt wrote:
>> > On Thu, 22 Apr 2021 14:23:39 +0100
>> > Mark Brown <broonie@kernel.org> wrote:
>> >  
>> >> > For me the most annoying is to get several patches from the middle of a
>> >> > series. IMHO, sending at least cover letter to everyone is the bare minimum
>> >> > so that people at least can take a look at high level details and request a
>> >> > repost.    
>> >> 
>> >> Yes, the cover letter should always go to everyone.  
>> >
>> > And that's still the one thing that quilt send-mail does not support :-p  
>> 
>> It's not rocket science to fix that with some scripting around it.
>> 
>
> You can script it so that everyone in the Cc's gets all patches, but you
> need to modify quilt to make it where it sends the extra Cc's just the
> cover letter.
>
> Another approach is to have quilt just save to a mbox, and modify that, and
> use another mail program to send that mbox.

Which is not rocket science either :)


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 22:35         ` Thomas Gleixner
@ 2021-04-22 22:53           ` Laurent Pinchart
  2021-07-20 16:26             ` Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Daniel Vetter
  0 siblings, 1 reply; 153+ messages in thread
From: Laurent Pinchart @ 2021-04-22 22:53 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Al Viro, Christoph Hellwig, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

Hi Thomas,

On Fri, Apr 23, 2021 at 12:35:02AM +0200, Thomas Gleixner wrote:
> On Thu, Apr 22 2021 at 18:03, Al Viro wrote:
> > On Thu, Apr 22, 2021 at 06:59:48AM +0100, Christoph Hellwig wrote:
> >> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> >> > I also think there does need to be a strong sanction against this UMN
> >> > research group, since we need to make sure there are strong incentives
> >> > against wasting everyone's time with stunts like this.  Hopefully on
> >> > the academic side it can be made clear that this is not ethical
> >> > research - for example, why did IEEE think this was an acceptable
> >> > paper?
> >> 
> >> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> >> been long overdue, and kicked off a very important discussion.  Even
> >> more so as in this area malice is almost indistinguishable from normal
> >> incompetence.  I think they deserve a medel of honor.
> >
> > Demonstrating this kind of attack would be very useful, if they bothered to
> > provide the raw data and their protocol.
> >
> > They'd done neither, AFAICS.  There's no way to actually look at how the
> > submissions went, timings, etc.  We are offered what could (very generously)
> > be called aggregate stats illustrating the problems, along with bloody
> > worthless suggestions of improvements.  Use of the technics in question
> > is not limited to introducing UAF bugs; it's certainly possible to use
> > a (real or not) UAF bug as an excuse to get in something designed _not_
> > to be caught by any of their suggested scler^Whardening patches, etc.
> >
> > There certainly are very real problems with review process, and examining
> > their data might provide useful insights - had any of that data been
> > given.
> 
> I agree.
> 
> Though the most important takeaway for me is that this demonstrated the
> problems which the kernel development has - once more.
> 
> What's worse is that it's known for quite some time that the kernel
> development is understaffed and cannot keep up with the influx of
> patches. Of course this has been willfully ignored - similar to other
> completely avoidable horrors like the ssl disaster.
> 
> There is a long list of issues which lead to that situation, but let me
> pick a few really important ones:
> 
>   - The 'features and performance first, correctness maybe' mentality in
>     this industry.
> 
>   - The ignorance which takes the availability and sustainability of
>     FOSS components especially "low-level plumbing" ones for granted,
>     even if their business is built on and depends on these.
> 
>   - The unwillingness to put money on basic "low-level" technology just
>     because it does not come with the 'hype-of-the-day' tag and is
>     therefore useless for marketing and headlines.
> 
> None of these things can be solved at the technical level. There is no
> technical solution which solves problems at the human stupidity and
> even less so at the greed level.
> 
> While in theory the approach of sharing the workload for base technology
> is obviously the right thing to do, the reality tells that sharing is
> interpreted as make sure that someone else pays for it and I can push my
> feature agenda.

I'd like to point out explicitly that this issue isn't limited to
"low-level" or "core" technology. On the driver side, it feels more
often than not that the community is used as a dumping ground for BSP
core of dubious quality, when that code isn't just kept out-of-tree
altogether. I wouldn't necessarily blame greed in all cases, as I've
seen vendors who are willing to do the right thing but don't know what
it would be (what we take for granted as being obvious seems not to be
so for a large number of people who are not all stupid :-)).

While I may not be fully convinced by all the details of the experiment,
I think there's something to be learnt from how DRM/KMS handles
contributors, and how they've managed to get many contributors from the
industry to get and stay involved at the subsystem level in the longer
term. I'm sure there can be other initiatives I'm not aware of.

> As long as that does not change, nothing will change.
> 
> We can put technical countermeasures (as discussed elsewhere in this
> thread) in place as much as we want, they are just futile attempts which
> try to cure the symptoms.
> 
> As technical people we all know how useful the approach of curing the
> symptoms instead of the root cause is. But still we try to do that
> because we think it's our only option.
> 
> It's about time to rethink that approach.

Amen. Incentives to contribute in the right way need to be higher, and
depending on the vendors, this can be carrot, stick, or both.

-- 
Regards,

Laurent Pinchart

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 20:15       ` Alexandre Belloni
@ 2021-04-23  0:09         ` Randy Dunlap
  0 siblings, 0 replies; 153+ messages in thread
From: Randy Dunlap @ 2021-04-23  0:09 UTC (permalink / raw)
  To: Alexandre Belloni, Johannes Berg
  Cc: Mauro Carvalho Chehab, Dan Carpenter, James Bottomley, ksummit

On 4/22/21 1:15 PM, Alexandre Belloni wrote:
> On 22/04/2021 11:59:38+0200, Johannes Berg wrote:
>> On Thu, 2021-04-22 at 11:34 +0200, Mauro Carvalho Chehab wrote:
>>>
>>> Here, I use "wdiff" in order to deal with renames. It has a somewhat
>>> funny dialect, but it helps a lot reviewing renaming patches.
>>
>> This also helps for casual "git show" etc.:
>>
>> [core]
>> 	pager = /usr/share/git-core/contrib/diff-highlight | less -RFX
>>
>> (path may vary, of course)
>>
> 
> I've been shown https://github.com/dandavison/delta/ a little while ago
> and it has a very good side by side view, showing exactly what change on
> each line. I'm using:
> 
> [core]
>         pager = delta
> [delta]
>         plus-color = "#012800"
>         minus-color = "#340001"
>         syntax-theme = Solarized (light)
>         line-numbers = true
>         side-by-side = true
> 

If anyone is into a similar(?) (non-git) old school solution, you can try
patchview:  https://www.infradead.org/~rdunlap/scripts/patchview

It might be nice to have an "ignore whitespace" option...

-- 
~Randy


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 22:39               ` Thomas Gleixner
@ 2021-04-23  0:26                 ` Joe Perches
  0 siblings, 0 replies; 153+ messages in thread
From: Joe Perches @ 2021-04-23  0:26 UTC (permalink / raw)
  To: Thomas Gleixner, Steven Rostedt
  Cc: Mark Brown, Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Fri, 2021-04-23 at 00:39 +0200, Thomas Gleixner wrote:
> > Another approach is to have quilt just save to a mbox, and modify that, and
> > use another mail program to send that mbox.

Which, if the cc list is long, won't let the cover letter be accepted
and forwarded by some mailing lists.

There are no great options for some treewide patch cases.

A possible option would be to bcc individuals on the cover letter, and
cc all the mailing lists, but in that case if an individual replies,
only the lists would get the replies.



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 14:20         ` Rob Herring
@ 2021-04-23  6:04           ` Mauro Carvalho Chehab
  2021-04-23  6:46             ` Joe Perches
  0 siblings, 1 reply; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23  6:04 UTC (permalink / raw)
  To: Rob Herring
  Cc: Steven Rostedt, Leon Romanovsky, James Bottomley, ksummit, tools

Em Thu, 22 Apr 2021 09:20:19 -0500
Rob Herring <robherring2@gmail.com> escreveu:

> On Thu, Apr 22, 2021 at 8:30 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Thu, 22 Apr 2021 14:34:53 +0300
> > Leon Romanovsky <leon@kernel.org> wrote:
> >  
> > > > This is not a matter of bad practice. There are a couple of reasons
> > > > why each patch on a series will have a different group of Cc, like:
> > > >
> > > >     - driver maintainers for each patch may be different;
> > > >     - scripts/get_maintainers.pl will return a different Cc/To;
> > > >     - patch series touch different subsystems;  
> > >
> > > Like Christoph said, if it is unrelated send the patches as separated
> > > series.  
> >
> > Since I use quilt to send my patches, my only two choices are all patches,
> > or individual ones with Cc. Some of my patches will need to touch every
> > architecture. I'll Cc the maintainers of the architecture code, but not
> > include them in every architecture patch. And because this code depends on
> > other patches, I can not send them as individual series.
> >
> > I use to have issues with this, but now with lore, I can trivially find the
> > entire thread and read it the whole story. IMO, it is no longer bad
> > practice to Cc only a single patch is a larger series to a maintainer, for
> > the one patch that touches their code. It's a "FYI, I'm touching your
> > code". But because of lore, it's really easy for them to get the full
> > picture.
> >
> > I much rather have my INBOX today be only patches that touches my code,
> > then full series of patches that I really don't care about. Worse yet, I'll
> > get Cc'd on a full series of 20 patches, where only one patch touches my
> > code. The sad part is, I'm much more likely to ignore that series, because
> > I'm added to stuff by get-maintainers for the strangest reason, and
> > completely miss that there's a single patch in there that really requires
> > my review.
> >
> > Please, just Cc me on code that touches something I maintain or listed as
> > a reviewer (which is still a lot).  
> 
> Unless the process of who to Cc or not is completely automated,
> relying on submitters to do the right thing to give you the subset of
> emails you want to see is never going to work. I have frequent
> problems with folks not Cc'ing the DT list for DT patches, how hard is
> that? I think the answer is making where patches are sent less
> important and better/easier filtering from lore (which is coming).

I have a script to automate it, but I had to tweak it while handling
patches that cross a single subsystem boundaries, using git send-email
with the c/c list obtained from get_maintainers.pl.

By default, the script adds all maintainers, reviewers and all mailing
lists to the cover letter, but that sometimes generate a cover letter
with 80+ c/c, which will be automatically rejected by anti-spam
measures and by mail servers.

So, I played with two different alternatives:

1. At the beginning, I changed the script to c/c only the mailing lists,
   excluding maintainers/reviewers;
2. As the feedback was not great, I changed the script to c/c only
   the maintainers, excluding mailing lists/reviewers. It seems that
   this worked better.

I didn't try to play with bcc, as replying to it would not send
the replies to everyone.

If you think it is worth, I could submit it to scripts/, but I
suspect we may need to adjust it to work with all maintainers'
workflows.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:19         ` Steven Rostedt
  2021-04-22 21:19           ` Thomas Gleixner
@ 2021-04-23  6:15           ` Greg KH
  2021-04-23  6:50             ` Dan Williams
                               ` (2 more replies)
  1 sibling, 3 replies; 153+ messages in thread
From: Greg KH @ 2021-04-23  6:15 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Mark Brown, Mike Rapoport, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:19:39AM -0400, Steven Rostedt wrote:
> On Thu, 22 Apr 2021 14:23:39 +0100
> Mark Brown <broonie@kernel.org> wrote:
> 
> > > For me the most annoying is to get several patches from the middle of a
> > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > so that people at least can take a look at high level details and request a
> > > repost.  
> > 
> > Yes, the cover letter should always go to everyone.
> 
> And that's still the one thing that quilt send-mail does not support :-p

'git format-patch --cover-letter' also does not seem to support this, so
what tool does?

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  6:04           ` Mauro Carvalho Chehab
@ 2021-04-23  6:46             ` Joe Perches
  2021-04-23  7:13               ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 153+ messages in thread
From: Joe Perches @ 2021-04-23  6:46 UTC (permalink / raw)
  To: Mauro Carvalho Chehab, Rob Herring
  Cc: Steven Rostedt, Leon Romanovsky, James Bottomley, ksummit, tools

On Fri, 2021-04-23 at 08:04 +0200, Mauro Carvalho Chehab wrote:
> I have a script to automate it, but I had to tweak it while handling
> patches that cross a single subsystem boundaries, using git send-email
> with the c/c list obtained from get_maintainers.pl.
> 
> By default, the script adds all maintainers, reviewers and all mailing
> lists to the cover letter, but that sometimes generate a cover letter
> with 80+ c/c, which will be automatically rejected by anti-spam
> measures and by mail servers.
> 
> So, I played with two different alternatives:
> 
> 1. At the beginning, I changed the script to c/c only the mailing lists,
>    excluding maintainers/reviewers;
> 2. As the feedback was not great, I changed the script to c/c only
>    the maintainers, excluding mailing lists/reviewers. It seems that
>    this worked better.
> 
> I didn't try to play with bcc, as replying to it would not send
> the replies to everyone.
> 
> If you think it is worth, I could submit it to scripts/, but I
> suspect we may need to adjust it to work with all maintainers'
> workflows.

I have a very similar script

A portion of a cc script I use tests whether cc'ing the cover letter
to all listed maintainers of a patch series creates a header of less
than 512 chars and if so cc's all relevant maintainers, otherwise it
just cc's the mailing lists.

(Ingo didn't/doesn't want to receive any emails from me)

$ cat ~/bin/remove_undesirable_emails.sh
grep -vPi "(?:\bIngo\s+Molnar\b)"

$ cat ~/bin/cc.sh
#!/bin/bash

opts="--nogit --nogit-fallback --norolestats"
maint_file=$(mktemp -t XXXXXXXX.cc)

if [[ $(basename $1) =~ ^0000- ]] ; then
    ./scripts/get_maintainer.pl $opts $(dirname $1)/* |  \
	~/bin/remove_undesirable_emails.sh > $maint_file
    count=$(wc -c $maint_file | cut -f1 -d" ")
    if [[ $count -lt 512 ]] ; then
	cat $maint_file
    else
	./scripts/get_maintainer.pl -nom -nor $opts $(dirname $1)/* | \
	    ~/bin/remove_undesirable_emails.sh
    fi

...


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  6:15           ` Greg KH
@ 2021-04-23  6:50             ` Dan Williams
  2021-04-23  7:13             ` Geert Uytterhoeven
  2021-04-23  9:12             ` Michal Hocko
  2 siblings, 0 replies; 153+ messages in thread
From: Dan Williams @ 2021-04-23  6:50 UTC (permalink / raw)
  To: Greg KH
  Cc: Steven Rostedt, Mark Brown, Mike Rapoport, Leon Romanovsky,
	James Bottomley, ksummit

On Thu, Apr 22, 2021 at 11:17 PM Greg KH <greg@kroah.com> wrote:
>
> On Thu, Apr 22, 2021 at 11:19:39AM -0400, Steven Rostedt wrote:
> > On Thu, 22 Apr 2021 14:23:39 +0100
> > Mark Brown <broonie@kernel.org> wrote:
> >
> > > > For me the most annoying is to get several patches from the middle of a
> > > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > > so that people at least can take a look at high level details and request a
> > > > repost.
> > >
> > > Yes, the cover letter should always go to everyone.
> >
> > And that's still the one thing that quilt send-mail does not support :-p
>
> 'git format-patch --cover-letter' also does not seem to support this, so
> what tool does?
>

Hey, I know this one. Stacked GIT does, but I think I'm the last
person using it.

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  6:46             ` Joe Perches
@ 2021-04-23  7:13               ` Mauro Carvalho Chehab
  2021-04-23  7:20                 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
  2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
  0 siblings, 2 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23  7:13 UTC (permalink / raw)
  To: Joe Perches
  Cc: Rob Herring, Steven Rostedt, Leon Romanovsky, James Bottomley,
	ksummit, tools

Em Thu, 22 Apr 2021 23:46:31 -0700
Joe Perches <joe@perches.com> escreveu:

> On Fri, 2021-04-23 at 08:04 +0200, Mauro Carvalho Chehab wrote:
> > I have a script to automate it, but I had to tweak it while handling
> > patches that cross a single subsystem boundaries, using git send-email
> > with the c/c list obtained from get_maintainers.pl.
> > 
> > By default, the script adds all maintainers, reviewers and all mailing
> > lists to the cover letter, but that sometimes generate a cover letter
> > with 80+ c/c, which will be automatically rejected by anti-spam
> > measures and by mail servers.
> > 
> > So, I played with two different alternatives:
> > 
> > 1. At the beginning, I changed the script to c/c only the mailing lists,
> >    excluding maintainers/reviewers;
> > 2. As the feedback was not great, I changed the script to c/c only
> >    the maintainers, excluding mailing lists/reviewers. It seems that
> >    this worked better.
> > 
> > I didn't try to play with bcc, as replying to it would not send
> > the replies to everyone.
> > 
> > If you think it is worth, I could submit it to scripts/, but I
> > suspect we may need to adjust it to work with all maintainers'
> > workflows.  
> 
> I have a very similar script
> 
> A portion of a cc script I use tests whether cc'ing the cover letter
> to all listed maintainers of a patch series creates a header of less
> than 512 chars and if so cc's all relevant maintainers, otherwise it
> just cc's the mailing lists.
> 
> (Ingo didn't/doesn't want to receive any emails from me)
> 
> $ cat ~/bin/remove_undesirable_emails.sh
> grep -vPi "(?:\bIngo\s+Molnar\b)"
> 
> $ cat ~/bin/cc.sh
> #!/bin/bash
> 
> opts="--nogit --nogit-fallback --norolestats"
> maint_file=$(mktemp -t XXXXXXXX.cc)
> 
> if [[ $(basename $1) =~ ^0000- ]] ; then
>     ./scripts/get_maintainer.pl $opts $(dirname $1)/* |  \
> 	~/bin/remove_undesirable_emails.sh > $maint_file
>     count=$(wc -c $maint_file | cut -f1 -d" ")
>     if [[ $count -lt 512 ]] ; then
> 	cat $maint_file
>     else
> 	./scripts/get_maintainer.pl -nom -nor $opts $(dirname $1)/* | \
> 	    ~/bin/remove_undesirable_emails.sh
>     fi
> 
> ...
> 

Heh, mine is a lot more complex than that ;-) 

It internally runs git format-patch, git send-email and get_maintainers.pl,
and, when --cover or --annotate is used, it opens a window to allow
editing the text. It has several options in order to tweak its behavior. 

That's the result of trying to send a patch series (in this example,
 16 patches for staging/media drivers):

<snip>
$ send-patches.pl upstream/master.. --cover
$ git format-patch -o patches/tmp --stat --summary --patience --signoff --thread=shallow --cover-letter --subject-prefix 'PATCH' upstream/master..
Checking patches/tmp/0000-cover-letter.patch
Checking patches/tmp/0001-media-staging-media-hantro-Align-line-break-to-the-o.patch
./scripts/get_maintainer.pl  patches/tmp/0001-media-staging-media-hantro-Align-line-break-to-the-o.patch
    Cc + cover Cc: Ezequiel Garcia <ezequiel@collabora.com> (maintainer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc + cover Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer)
    Cc + cover Cc: Philipp Zabel <p.zabel@pengutronix.de> (maintainer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
    Cc + cover Cc: linux-rockchip@lists.infradead.org (open list)
Checking patches/tmp/0002-media-staging-media-hantro-Align-line-break-to-the-o.patch
./scripts/get_maintainer.pl  patches/tmp/0002-media-staging-media-hantro-Align-line-break-to-the-o.patch
    Cc + cover Cc: Ezequiel Garcia <ezequiel@collabora.com> (maintainer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc + cover Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer)
    Cc + cover Cc: Philipp Zabel <p.zabel@pengutronix.de> (maintainer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
    Cc + cover Cc: linux-rockchip@lists.infradead.org (open list)
Checking patches/tmp/0003-media-staging-media-omap4iss-Align-line-break-to-the.patch
./scripts/get_maintainer.pl  patches/tmp/0003-media-staging-media-omap4iss-Align-line-break-to-the.patch
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc + cover Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (maintainer)
    Cc + cover Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0004-media-staging-media-atomisp-Removed-a-superfluous-el.patch
./scripts/get_maintainer.pl  patches/tmp/0004-media-staging-media-atomisp-Removed-a-superfluous-el.patch
    Cc: Filip Kolev <fil.kolev@gmail.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Martiros Shakhzadyan <vrzh@vrzh.net> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc + cover Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0005-media-staging-media-atomisp-i2c-align-line-break-to-.patch
./scripts/get_maintainer.pl  patches/tmp/0005-media-staging-media-atomisp-i2c-align-line-break-to-.patch
    Cc: Beatriz Martins de Carvalho <martinsdecarvalhobeatriz@gmail.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0006-media-staging-media-intel-ipu3-remove-unnecessary-bl.patch
./scripts/get_maintainer.pl  patches/tmp/0006-media-staging-media-intel-ipu3-remove-unnecessary-bl.patch
    Cc + cover Cc: Bingbu Cao <bingbu.cao@intel.com> (reviewer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Mitali Borkar <mitaliborkar810@gmail.com> (commit_signer)
    Cc: Rahul Gottipati <rahul.blr97@gmail.com> (cc)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: Tianshu Qiu <tian.shu.qiu@intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0007-media-staging-media-intel-ipu3-reduce-length-of-line.patch
./scripts/get_maintainer.pl  patches/tmp/0007-media-staging-media-intel-ipu3-reduce-length-of-line.patch
    Cc + cover Cc: Bingbu Cao <bingbu.cao@intel.com> (reviewer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Mitali Borkar <mitaliborkar810@gmail.com> (commit_signer)
    Cc: Rahul Gottipati <rahul.blr97@gmail.com> (cc)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: Tianshu Qiu <tian.shu.qiu@intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0008-media-staging-media-intel-ipu3-remove-space-before-t.patch
./scripts/get_maintainer.pl  patches/tmp/0008-media-staging-media-intel-ipu3-remove-space-before-t.patch
    Cc + cover Cc: Bingbu Cao <bingbu.cao@intel.com> (reviewer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Mitali Borkar <mitaliborkar810@gmail.com> (commit_signer)
    Cc: Rahul Gottipati <rahul.blr97@gmail.com> (cc)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: Tianshu Qiu <tian.shu.qiu@intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0009-media-staging-media-intel-ipu3-line-should-not-end-w.patch
./scripts/get_maintainer.pl  patches/tmp/0009-media-staging-media-intel-ipu3-line-should-not-end-w.patch
    Cc + cover Cc: Bingbu Cao <bingbu.cao@intel.com> (reviewer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (cc)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Mitali Borkar <mitaliborkar810@gmail.com> (commit_signer)
    Cc: Rahul Gottipati <rahul.blr97@gmail.com> (commit_signer)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: Tianshu Qiu <tian.shu.qiu@intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0010-media-staging-media-zoran-add-spaces-around-operator.patch
./scripts/get_maintainer.pl  patches/tmp/0010-media-staging-media-zoran-add-spaces-around-operator.patch
    Cc + cover Cc: Corentin Labbe <clabbe@baylibre.com> (maintainer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc + cover Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
    Cc + cover Cc: mjpeg-users@lists.sourceforge.net (open list)
Checking patches/tmp/0011-media-staging-media-atomisp-Minor-code-style-changes.patch
./scripts/get_maintainer.pl  patches/tmp/0011-media-staging-media-atomisp-Minor-code-style-changes.patch
    Cc: Filip Kolev <fil.kolev@gmail.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Martiros Shakhzadyan <vrzh@vrzh.net> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc + cover Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0012-media-staging-media-omap4iss-Remove-unused-macro-fun.patch
./scripts/get_maintainer.pl  patches/tmp/0012-media-staging-media-omap4iss-Remove-unused-macro-fun.patch
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc + cover Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> (maintainer)
    Cc + cover Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0013-media-staging-media-atomisp-pci-Correct-identation-i.patch
./scripts/get_maintainer.pl  patches/tmp/0013-media-staging-media-atomisp-pci-Correct-identation-i.patch
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc + cover Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0014-media-staging-media-atomisp-pci-Correct-identation-i.patch
./scripts/get_maintainer.pl  patches/tmp/0014-media-staging-media-atomisp-pci-Correct-identation-i.patch
    Cc: Aline Santana Cordeiro <alinesantanacordeiro@gmail.com> (commit_signer)
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0015-media-staging-media-atomisp-pci-Format-comments-acco.patch
./scripts/get_maintainer.pl  patches/tmp/0015-media-staging-media-atomisp-pci-Format-comments-acco.patch
    Cc: Aline Santana Cordeiro <alinesantanacordeiro@gmail.com> (commit_signer)
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (commit_signer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
Checking patches/tmp/0016-media-staging-media-atomisp-pci-Format-comments-acco.patch
./scripts/get_maintainer.pl  patches/tmp/0016-media-staging-media-atomisp-pci-Format-comments-acco.patch
    Cc: Aline Santana Cordeiro <alinesantanacordeiro@gmail.com> (commit_signer)
    Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (commit_signer)
    Cc: Arnd Bergmann <arnd@arndb.de> (commit_signer)
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cc)
    Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl> (commit_signer)
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org> (commit_signer)
    Cc + cover Cc: Sakari Ailus <sakari.ailus@linux.intel.com> (reviewer)
    Cc + cover Cc: devel@driverdev.osuosl.org (open list)
    Cc + cover Cc: linux-kernel@vger.kernel.org (open list)
    Cc + cover Cc: linux-media@vger.kernel.org (open list)
patches/tmp/0000-cover-letter.patch:
    Cc: Bingbu Cao <bingbu.cao@intel.com>
    Cc: Corentin Labbe <clabbe@baylibre.com>
    Cc: Ezequiel Garcia <ezequiel@collabora.com>
    Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Philipp Zabel <p.zabel@pengutronix.de>
    Cc: Sakari Ailus <sakari.ailus@linux.intel.com>
    Cc: Tianshu Qiu <tian.shu.qiu@intel.com>
    Cc: devel@driverdev.osuosl.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-media@vger.kernel.org
    Cc: linux-rockchip@lists.infradead.org
    Cc: mjpeg-users@lists.sourceforge.net
Number of Cc at cover: 13
</snip>

I guess I'll post it as a RFC patch c/c this thread.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  6:15           ` Greg KH
  2021-04-23  6:50             ` Dan Williams
@ 2021-04-23  7:13             ` Geert Uytterhoeven
  2021-04-23 14:41               ` Shuah Khan
  2021-04-23  9:12             ` Michal Hocko
  2 siblings, 1 reply; 153+ messages in thread
From: Geert Uytterhoeven @ 2021-04-23  7:13 UTC (permalink / raw)
  To: Greg KH
  Cc: Steven Rostedt, Mark Brown, Mike Rapoport, Leon Romanovsky,
	James Bottomley, ksummit

Hi Greg,

On Fri, Apr 23, 2021 at 8:17 AM Greg KH <greg@kroah.com> wrote:
> On Thu, Apr 22, 2021 at 11:19:39AM -0400, Steven Rostedt wrote:
> > On Thu, 22 Apr 2021 14:23:39 +0100
> > Mark Brown <broonie@kernel.org> wrote:
> > > > For me the most annoying is to get several patches from the middle of a
> > > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > > so that people at least can take a look at high level details and request a
> > > > repost.
> > >
> > > Yes, the cover letter should always go to everyone.
> >
> > And that's still the one thing that quilt send-mail does not support :-p
>
> 'git format-patch --cover-letter' also does not seem to support this, so
> what tool does?

You can (manually) add "Cc: name <address>" lines to the individual
files created by "git format-patch", which will be used by
"git send-email".
I guess this can also be done to the mbox saved by "quilt mail --mbox"?

Alternatively, if you have format.thread in your git config, the saved
files will already have their final Message-IDs, so you can add to
all individual patches a lore link pointing to the cover letter.

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	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
  2021-04-22 13:08       ` Leon Romanovsky
  2021-04-22 17:56       ` Leon Romanovsky
@ 2021-04-23  7:19       ` Greg KH
  2021-04-23  7:31       ` Christian Brauner
  3 siblings, 0 replies; 153+ messages in thread
From: Greg KH @ 2021-04-23  7:19 UTC (permalink / raw)
  To: Konstantin Ryabitsev
  Cc: Mauro Carvalho Chehab, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 08:53:57AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> > Also, nowadays, with lore and b4, it would be easy to retrieve the
> > entire patch series, even for those that aren't subscribed on a 
> > c/c mailing list.
> 
> If you're a mutt user, you can set up a keybinding, e.g.:
> 
>     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"

What???

I didn't know about "-f", that is wonderful!!!

/me goes off to add yet-another-mutt-macro

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* [PATCH RFC] scripts: add a script for sending patches
  2021-04-23  7:13               ` Mauro Carvalho Chehab
@ 2021-04-23  7:20                 ` Mauro Carvalho Chehab
  2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
  1 sibling, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23  7:20 UTC (permalink / raw)
  Cc: linuxarm, mauro.chehab, Mauro Carvalho Chehab, James Bottomley,
	Joe Perches, Leon Romanovsky, Rob Herring, Steven Rostedt,
	ksummit, linux-kernel, tools

This script send patches to an upstream maintainer's tree,
using git send-email and producing the relevant c/c list,
by using scripts/get_maintainers.pl.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---

As result of the current discussions about Rethinking the acceptance
policy for  "trivial" patches,  I'm submitting the script I wrote in order
to help me to send patches upstream using get_maintainers.pl.

I've been playing with this script since 2015, and had to improve and
add new options to it over time, based on some specific needs that
I detected while submitting patches both to a single subsystem and to
multiple ones.

 scripts/send-patches.pl | 658 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 658 insertions(+)
 create mode 100755 scripts/send-patches.pl

diff --git a/scripts/send-patches.pl b/scripts/send-patches.pl
new file mode 100755
index 000000000000..b4aa73979e4d
--- /dev/null
+++ b/scripts/send-patches.pl
@@ -0,0 +1,658 @@
+#!/usr/bin/perl
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (c) 2015- by Mauro Carvalho Chehab <mchehab@kernel.org>
+
+use strict;
+use warnings;
+use Email::Simple;
+use Email::Address;
+use Getopt::Long;
+use Pod::Usage;
+use File::Path 'make_path';
+require Tk;
+require Tk::Text;
+require Tk::Font;
+require Tk::Toplevel;
+
+# Where the patch series will be stored. If doesn't exits,
+# it will be automatically created
+my $tmp_dir = "patches/tmp";
+
+# Used together with --avoid-resend
+my $resend_cache_dir = "patches/last_patches";
+my $version_ctrl = ".version_control";
+
+#
+# File editor function. Currently relies on Tk to open
+# a separate edit window.
+#
+sub edit_text($) {
+	my $fname = shift;
+	my $string = qx(cat $fname);
+	my $edited_text;
+
+	my $toplvl = MainWindow->new();
+	my $font = $toplvl->Font(family  => 'fixed', size => 12);
+
+	my $frame_txt = $toplvl->Frame();
+	my $frame_btn = $toplvl->Frame();
+
+	$toplvl->configure(-title => "Editing $fname");
+
+	my $text = $frame_txt->Scrolled('Text')->pack;
+	$text->configure(-height      => 30,
+			-background  => 'black',
+			-foreground  => 'gray',
+			-insertbackground => 'white',
+			-width       => 80,
+			-wrap        => 'word',
+			-font        => $font);
+
+	my $Button1 = $frame_btn->Button();
+	$Button1->configure(-text    => 'OK',
+		       -bg      => 'lightblue',
+		       -width   => 5,
+		       -height  => 1,
+		       -command => sub{$edited_text = $text->get("1.0", "end"); $toplvl->destroy} );
+
+	$text->insert('1.0', $string);
+
+	# Pack the widgets in the frames
+	$text->pack();
+	$frame_txt->pack();
+	$frame_btn->pack();
+	$Button1->pack();
+
+	$text->waitWindow();
+
+	return $edited_text;
+}
+
+#
+# Argument handling
+#
+my $edit = 0;
+my $cover = 0;
+my $man = 0;
+my $help = 0;
+my $cmd_line = "git format-patch -o $tmp_dir --stat --summary --patience --signoff --thread=shallow";
+my $changeset = 0;
+my $dont_send = 0;
+my $avoid_resend = 0;
+my $reply_patches = 0;
+my $subject_prefix = "PATCH";
+my $dont_get_maintainer = 0;
+my $dont_get_reviewer = 0;
+my $reroll_count = "";
+my $git = 0;
+my $nogit = 0;
+my $add_everyone = 0;
+my $unify = "";
+my $to_maintainers = 0;
+
+GetOptions(
+	"cover|letter" => sub { $cmd_line .= " --cover-letter"; $cover = 1},
+	"no-merge|no-merges|no-renames" =>  sub { $cmd_line .= " --no-renames" },
+	"merge|M" =>  sub { $cmd_line .= " -M01" },
+	"delete|D" =>  sub { $cmd_line .= " -D" },
+	"unify|U=s" =>  \$unify,
+	"to=s" => sub { my ($opt, $arg) = @_; $cmd_line .= " --to '$arg'" },
+	"cc=s" => sub { my ($opt, $arg) = @_; $cmd_line .= " --cc '$arg'" },
+	"prefix|subject-prefix=s" => \$subject_prefix,
+	"edit|annotate" => \$edit,
+	"dry-run|dont-send" => \$dont_send,
+	"reply-patches" => sub { $reply_patches = 1; $avoid_resend = 1; $cmd_line .= " -N" },
+	"avoid-resend" => sub { $avoid_resend = 1; $cmd_line .= " -N" },
+	"dont-get-maintainer" => \$dont_get_maintainer,
+	"dont-get-reviewer" => \$dont_get_reviewer,
+	"everyone|add-everyone" => \$add_everyone,
+	"git" => \$git,
+	"no-git-fallback" => \$nogit,
+	"to-maintainers" => \$to_maintainers,
+	"v|reroll_count=s" => \$reroll_count,
+	"help" => \$help,
+	"man" => \$man,
+) or pod2usage(2);
+
+$help = 1 if (@ARGV < 1);
+
+if ($avoid_resend && $cover) {
+	printf ("Sorry, you can't avoid resend patches and add a cover yet.\n");
+}
+
+pod2usage(1) if $help;
+pod2usage(-verbose => 2) if $man;
+
+$cmd_line .= " --subject-prefix '$subject_prefix'";
+$cmd_line .= " -v $reroll_count" if ($reroll_count);
+$cmd_line .= " -U$unify" if ($unify);
+$cmd_line = join(' ', $cmd_line, @ARGV);
+
+$dont_get_reviewer = 1 if ($dont_get_maintainer);
+
+#
+# Prepare to avoid resending patches
+#
+
+my %cgid_to_msgid;
+my %msgid_to_file;
+my %msgid_to_subject;
+
+sub msgid_from_last_patch($)
+{
+	my $change_id = shift;
+
+	return 0 if (!$change_id);
+	return 0 if (!$cgid_to_msgid{$change_id});
+
+	return $cgid_to_msgid{$change_id};
+}
+
+if ($avoid_resend) {
+	open IN, $version_ctrl or print "Can't find $version_ctrl\n";
+	while (<IN>) {
+		if (m/([^\t]+)\t([^\t]+).*\n/) {
+			$cgid_to_msgid{$1} = $2;
+		}
+	}
+	close IN;
+
+	opendir(my $dh, $resend_cache_dir) || die "can't read patches at $resend_cache_dir";
+	while(readdir $dh) {
+		my $name = "$resend_cache_dir/$_";
+		next if (-d $name);
+
+		my $raw_email = qx(cat $name);
+		my $email = Email::Simple->new($raw_email);
+		my $msgid = $email->header("Message-Id");
+		my $subject = $email->header("Subject");
+
+		$msgid_to_file{$msgid} = $name if ($msgid);
+		$msgid_to_subject{$msgid} = $subject if ($subject && $msgid);
+	}
+	closedir $dh;
+}
+
+sub get_maintainer($$)
+{
+	my $cmd = $_[0];
+	my @file_cc = @{$_[1]};
+	my $role;
+	my $e_mail;
+	my %cc = (
+		"linux-kernel\@vger.kernel.org" => 1
+	);
+
+	foreach $e_mail (@file_cc) {
+		my @addresses = Email::Address->parse($e_mail);
+		for my $address (@addresses) {
+			$cc{$address} = "cc";
+		}
+	}
+
+	$cmd = "./scripts/get_maintainer.pl " . $cmd;
+
+	print "$cmd\n";
+	open IN, "$cmd |" or die "can't run $cmd";
+	while (<IN>) {
+		$e_mail = $_;
+		$e_mail =~ s/(.*\@\S+)\s*\(.*/$1/;
+		$e_mail =~ s/\s*$//;
+
+
+		if (m/\(.*(open list|moderated list|subscriber list|maintainer|reviewer|modified|chief|commit_signer).*\)/) {
+			$role = $1;
+		} else {
+			$role = "cc";
+		}
+		# Discard myself
+		next if ($e_mail =~ m/(mchehab|mauro.?chehab)\S+\@\S+/);
+		$cc{$e_mail} = $role;
+	}
+	close IN;
+
+	return %cc;
+}
+
+#
+# Generate patches with git format-patch
+#
+make_path($tmp_dir);
+unlink glob "$tmp_dir/*";
+
+print "\$ $cmd_line\n";
+system ("$cmd_line >>/dev/null") && die("Failed to run git format-patch");
+
+#
+# Add Cc: based on get_maintainer.pl script
+#
+my @patches;
+my @send_patches;
+
+opendir(my $dh, $tmp_dir) || die "can't read patches at $tmp_dir";
+while(readdir $dh) {
+	my $name = "$tmp_dir/$_";
+	push @patches,$name if (-f $name);
+}
+closedir $dh;
+
+my %changeids;
+
+my $has_cover;
+my %cover_cc;
+
+foreach my $f(sort @patches) {
+	print "Checking $f\n";
+	if ($f =~ m,0000-cover-letter.patch$,) {
+		push @send_patches, $f;
+		$has_cover = 1;
+		next;
+	}
+
+	my $raw_email = qx(cat $f);
+	die "Can't read $f" if (!$raw_email);
+
+	my $email = Email::Simple->new($raw_email);
+
+	my $msgid = 0;
+	my $oldsubject;
+	my $change_id;
+
+	if ($raw_email =~ m/\nChange-Id:\s+([^\n]+)\n/) {
+		$change_id = $1;
+	}
+
+	if ($avoid_resend) {
+		$msgid = msgid_from_last_patch($change_id);
+		if ($msgid) {
+			if ($msgid_to_subject{$msgid}) {
+				$oldsubject = $msgid_to_subject{$msgid};
+
+				my $file = $msgid_to_file{$msgid};
+
+				my $old_md5 = qx(filterdiff $file | md5sum);
+				my $new_md5 = qx(filterdiff $f | md5sum);
+
+				$old_md5 =~ s/(\S+).*$/$1/;
+				$new_md5 =~ s/(\S+).*$/$1/;
+
+				if ($old_md5 eq $new_md5) {
+					printf "   Skipping patch as it is identical to previous version\n";
+					unlink $f;
+					next;
+				}
+			}
+			my $new_msgid = $email->header("Message-Id");
+			$changeids{$change_id} = $new_msgid if ($new_msgid);
+		}
+	}
+
+	# Patch was not avoided. Push to the list of patches to send
+	push @send_patches, $f;
+
+	my $cmd = "";
+	$cmd .= "--git" if ($git);
+	$cmd .="--nogit-fallback --nogit-blame --nogit" if ($nogit);
+	$cmd .=" $f";
+
+	my @file_cc = $email->header("Cc");
+	if ($to_maintainers) {
+		push @file_cc, $email->header("To") if ($email->header("To"));
+	}
+	my %cc_email_map = get_maintainer $cmd, \@file_cc;
+	my %maintainers;
+
+	@file_cc = ();
+	my @file_to = ();
+	foreach my $cc (sort keys %cc_email_map) {
+		my $ml_added = 0;
+		my $role = $cc_email_map{$cc};
+
+		my $type = "Cc";
+		$type = "To" if ($to_maintainers && $role =~ "maintainer");
+
+		if ($role =~ "maintainer") {
+			if (!$dont_get_maintainer) {
+				$ml_added = 1;
+				$cover_cc{$cc} = 1;
+			}
+		} elsif ($role =~ "reviewer") {
+			if (!$dont_get_reviewer) {
+				$ml_added = 1;
+				$cover_cc{$cc} = 1;
+			}
+		} elsif ($role =~ "list") {
+			$ml_added = 1;
+			$cover_cc{$cc} = 1;
+		} elsif ($add_everyone) {
+			$ml_added = 1;
+			$cover_cc{$cc} = 1;
+		}
+
+		if ($type eq "To") {
+			push @file_to, $cc;
+		} else {
+			push @file_cc, $cc;
+		}
+		if ($ml_added && $cover) {
+			printf "    $type + cover Cc: $cc (%s)\n", $role;
+		} else {
+			printf "    $type: $cc (%s)\n", $role;
+		}
+	}
+
+	$email->header_set("To", @file_to) if (@file_to);
+	$email->header_set("Cc", @file_cc) if (@file_cc);
+
+	# Remove Change-Id meta-data from the e-mail to be submitted
+	my $body = $email->body;
+	$body =~ s/(\nChange-Id:\s+[^\n]+\n)/\n/;
+	$email->body_set($body);
+
+	if ($avoid_resend) {
+		if (!$reply_patches && $msgid) {
+			$email->body_set("New version of $oldsubject\n\n$body");
+		} else {
+			die "New patches in the series. Can't proceed." if (!$msgid);
+			die "Failed to find old subject. Can't proceed." if (!$oldsubject);
+
+			$email->header_set("Subject", "Re: $oldsubject");
+		}
+		$email->header_set("In-Reply-To", $msgid);
+		$email->header_set("References", $msgid);
+	}
+
+	open OUT, ">$f";
+	print OUT $email->as_string;
+	close OUT;
+}
+
+# Sanity check
+die "Something wrong when generating/detecting a cover" if ($cover && !$has_cover);
+
+#
+# Add everyone at the cover's to: field
+#
+if ($has_cover) {
+	my $count_cc = 0;
+	foreach my $f(sort @patches) {
+		next if (!($f =~ m,0000-cover-letter.patch$,));
+
+		print "$f:\n";
+		my $raw_email = qx(cat $f);
+		die "Can't read $f" if (!$raw_email);
+
+		my $email = Email::Simple->new($raw_email);
+
+		my @file_cc = $email->header("Cc");
+
+		foreach my $e_mail (@file_cc) {
+			my @addresses = Email::Address->parse($e_mail);
+			for my $address (@addresses) {
+				$cover_cc{$address} = 1;
+			}
+		}
+
+		foreach my $to(sort keys %cover_cc) {
+			print "    Cc: $to\n";
+			push @file_cc, $to;
+			$count_cc++;
+		}
+
+		$email->header_set("Cc", @file_cc);
+
+		open OUT, ">$f";
+		print OUT $email->as_string;
+		close OUT;
+
+		print "Number of Cc at cover: $count_cc\n";
+	}
+}
+
+#
+# Renumber the patches
+#
+if ($avoid_resend && !$reply_patches) {
+	my $tot_patch = @send_patches;
+
+	$tot_patch-- if ($cover);
+
+	my $digits = int(log($tot_patch)/log(10)+0.99999);
+	my $patch = 1;
+
+	foreach my $f(@send_patches) {
+		next if ($f =~ m,0000-cover-letter.patch$,);
+
+		my $raw_email = qx(cat $f);
+		die "Can't read $f" if (!$raw_email);
+
+		my $email = Email::Simple->new($raw_email);
+
+		my $subject = $email->header("Subject");
+
+		my $number = sprintf("%0${digits}d/%0${digits}d", $patch, $tot_patch);
+
+		$subject =~ s/^\[[^\]]+\]\s*//;
+		$subject = "[$subject_prefix $number] " . $subject;
+		printf("$subject\n");
+		$email->header_set("Subject", $subject);
+
+		$patch++;
+
+		open OUT, ">$f";
+		print OUT $email->as_string;
+		close OUT;
+	}
+}
+
+#
+# Open an editor if needed
+#
+if ($edit || $cover) {
+	foreach my $f(sort @send_patches) {
+		my $new_text;
+
+		do {
+			$new_text = edit_text($f);
+		} while (!$new_text);
+
+		open OUT, ">$f";
+		print OUT $new_text;
+		close OUT;
+
+		last if ($cover);
+	}
+}
+
+#
+# Send the emails
+#
+
+if (!$dont_send) {
+	printf("\$ git send-email $tmp_dir\n");
+	system("git send-email $tmp_dir");
+} else {
+	printf("Use git send-email $tmp_dir to send the patches\n");
+}
+
+#
+# Update the change IDs with the new patches
+#
+foreach my $chgid (keys %changeids) {
+	$cgid_to_msgid{$chgid} = $changeids{$chgid};
+}
+
+open OUT,">$version_ctrl.new";
+foreach my $chgid (sort keys %cgid_to_msgid) {
+	printf OUT "%s\t%s\n", $chgid, $cgid_to_msgid{$chgid};
+}
+close OUT;
+
+if ($dont_send) {
+	printf("New version control stored as: .version_control.new\n" .
+	       "Don't forget rename it to .version_control for the next patch series after sending it.\n");
+} else {
+	rename $version_ctrl, "$version_ctrl.old";
+	rename "$version_ctrl.new", $version_ctrl;
+}
+
+
+__END__
+
+=head1 NAME
+
+send-patches.pl - Send patches upstream
+
+=head1 SYNOPSIS
+
+send-patches.pl [options] [changeset] -- [options for git format-patch]
+
+Options:
+
+--cover/--cover-letter
+--no-renames/--no-merges/--no-renames
+--merge/-M
+--delete/-D
+--unify/-U [level]
+--to [e@mail]
+--cc [e@mail]
+--prefix/--subject-prefix
+--edit
+--dont-send/--dry-run
+--avoid-resend
+--reply-patches
+--dont-get-maintainer
+--not-everyone/--dont-add-everyone
+--no-git-fallback
+--to-maintainers
+--help
+--man
+--reroll-count/-v [version number]
+
+=head1 OPTIONS
+
+=over 8
+
+=item B<--cover> or B<--cover-letter>
+
+Patch series will have a cover letter. Automatically enables edition
+
+=item B<--no-renames> or B<--no-merges> or B<--no-merge>
+
+Disables git merge detection with git show --no-renames
+
+=item B<--merge> or B<--M>
+
+Enables aggressive git merge detection with git show -M01
+
+=item B<--delete> or B<--D>
+
+Omit the previous content on deletes, printing only the header but
+not the diff between the removed files and /dev/null.
+
+=item B<--unify> or B<--U>
+
+Set the unify diff level (default=3).
+
+=item B<--to>
+
+Add one more recipient destination for the e-mail
+(at the To: part of the email)
+
+=item B<--cc>
+
+Add one more recipient carbon copy destination for the e-mail
+(at the Cc: part of the email)
+
+=item B<--prefix> or B<--subject-prefix>
+
+By default, the subject prefix will be "PATCH". This otpion allows changing
+it.
+
+=item B<--edit>
+
+Allows editing each patch in the series, and the cover letter.
+
+=item B<--dont-send> or B<--dry-run>
+
+Do everything but calling git send-email. Useful to test the tool or
+when you need to do more complex things.
+
+=item B<--reply-patches>
+
+Instead of sending a new series, reply to an existing one. This only
+works if no new patches were added at the series.
+
+=item B<--avoid-resend>
+
+Don't resend patches that are identical to the previosly send
+series of patches. The patches that will be send will be renumbered.
+
+Please notice that this option is currently incompatible with
+a --cover, as we need to teach this script how to remove the
+removed patches from the letter summary.
+
+=item B<--dont-get-maintainer>
+
+Ignore maintainers at the cover letter.
+
+=item B<--dont-get-reviewer>
+
+Ignore reviewers at the cover letter.
+
+=item B<--everyone>/<--add-everyone>
+
+The script/get_maintainers.pl returns maintainers, reviewers and mailing lists.
+It also returns a list of usual contributors.
+
+By default, the usual contributors are ignored at the cover letter, being
+added only at the patches themselves. When this flag is used, they'll also
+be c/c to the cover letter.
+
+=item B<--git>
+
+Include recent git *-by: signers.
+
+=item B<--no-git-fallback>
+
+Use git when no exact MAINTAINERS pattern. This disables detection of the
+usual contributors.
+
+=item B<--to-maintainers>
+
+Instead of placing patches on a series, send them individually
+to their own maintainers.
+
+=item B<-v>/<--reroll-count>
+
+Change the version number on a patch series, by passing --reroll-count
+to git format-patch.
+
+=item B<--help>
+
+Print a brief help message and exits.
+
+=item B<--man>
+
+Prints the manual page and exits.
+
+=back
+
+=head1 DESCRIPTION
+B<This program> will submit a patch series upstream.
+=cut
+
+=head1 BUGS
+
+Report bugs to Mauro Carvalho Chehab <mchehab@kernel.org>
+
+=head1 COPYRIGHT
+
+Copyright (c) 2015- by Mauro Carvalho Chehab <mcheha@kernel.org>.
+
+License GPLv2: GNU GPL version 2 <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.
+
+=cut
-- 
2.30.2



^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
                         ` (2 preceding siblings ...)
  2021-04-23  7:19       ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
@ 2021-04-23  7:31       ` Christian Brauner
  2021-04-23 18:50         ` Konstantin Ryabitsev
  3 siblings, 1 reply; 153+ messages in thread
From: Christian Brauner @ 2021-04-23  7:31 UTC (permalink / raw)
  To: Konstantin Ryabitsev
  Cc: Mauro Carvalho Chehab, Leon Romanovsky, James Bottomley, ksummit

On Thu, Apr 22, 2021 at 08:53:57AM -0400, Konstantin Ryabitsev wrote:
> On Thu, Apr 22, 2021 at 11:20:01AM +0200, Mauro Carvalho Chehab wrote:
> > Also, nowadays, with lore and b4, it would be easy to retrieve the
> > entire patch series, even for those that aren't subscribed on a 
> > c/c mailing list.
> 
> If you're a mutt user, you can set up a keybinding, e.g.:
> 
>     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"
> 
> You'll need to adjust it to point at where your maildir lives, of course, but
> that's the general idea. With it in place, you can hit "4" in the index view
> to get the rest of the thread (without duplicating the messages you already
> have).

I do currently have three keybindings:

macro index,pager A "<pipe-message>b4 am -t -l -s -g -c -C -Q <enter>"
macro index,pager S "<pipe-message>b4 am -t -c -Q <enter>"
macro index,pager M "<pipe-message>b4 mbox <enter>"

The -f switch is new, right?

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:52         ` Steven Rostedt
  2021-04-22 16:08           ` Shuah Khan
  2021-04-22 16:13           ` Jan Kara
@ 2021-04-23  7:58           ` Mauro Carvalho Chehab
  2021-04-23 10:54             ` Greg KH
  2021-04-23 17:09             ` Leon Romanovsky
  2 siblings, 2 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23  7:58 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: James Bottomley, Shuah Khan, ksummit, Greg KH

Em Thu, 22 Apr 2021 11:52:35 -0400
Steven Rostedt <rostedt@goodmis.org> escreveu:

> On Thu, 22 Apr 2021 08:48:21 -0700
> James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> 
> > On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> > [...]  
> > >    2. Improving the requirement for bug fixes and large series, like
> > > cover letters to everyone, adding fixes: tag and clear explanation.    
> > 
> > Just on this one, can we get the mailing list to help now we're moving
> > to a new infrastructure?  I was already thinking of asking if it could
> > reject email with html parts rather than simply losing it, but perhaps
> > it could reject threaded submissions where the cover letter isn't
> > correctly cc'd?  I know that's a big ask because there has to be an
> > easy way to recognize them (heuristics on the PATCH tag?) and a way to
> > recognize missing cc's (perhaps simply that someone cc'd on the
> > threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)  
> 
> Unfortunately, this breaks all quilt users, as quilt does not support this.

This will also break patch series that touch several subsystems.

Out of curiosity, I ran my script letting it to place at the cover letter
maintainers, reviewers and mailing lists, for this patch series:

	[PATCH 000/190] Revertion of all of the umn.edu commits
	https://lore.kernel.org/lkml/YIJyzkgglMrAzIwh@kroah.com/T/#m087445f69f5dd590b9ad5f4cdd62c2a812956435

The number of e-mails to be C/c is 221 e-mails! (see enclosed)

An e-mail like that will almost for sure be ignored by  all mail
servers[1], as the e-mail will be considered as SPAM.

[1] Except if the servers would have explicit rules to allow such
    really big c/c list to be accepted from maintainers, which is
    risky.

Looking at the actual e-mail from Greg at lore, the CC list was a lot
smaller than that:

Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Aditya Pakki <pakki001@umn.edu>, Kangjie Lu <kjlu@umn.edu>,
        Qiushi Wu <wu000273@umn.edu>, x86@kernel.org,
        Bjorn Helgaas <bhelgaas@google.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Arnd Bergmann <arnd@arndb.de>, David Airlie <airlied@linux.ie>,
        Michael Turquette <mturquette@baylibre.com>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Linus Walleij <linus.walleij@linaro.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Jean Delvare <jdelvare@suse.com>,
        Guenter Roeck <linux@roeck-us.net>,
        Jiri Kosina <jikos@kernel.org>, Will Deacon <will@kernel.org>,
        Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Jakub Kicinski <kuba@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Johan Hovold <johan@kernel.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Pablo Neira Ayuso <pablo@netfilter.org>,
        Johannes Berg <johannes@sipsolutions.net>,
        Takashi Iwai <tiwai@suse.com>

(Not sure what criteria Greg used to shorten the C/c list)

Thanks,
Mauro

---

The auto-generated list of c/c is:

patches/tmp/0000-cover-letter.patch:
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
    Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
    Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
    Cc: "Michael S. Tsirkin" <mst@redhat.com>
    Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
    Cc: Adit Ranadive <aditr@vmware.com>
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Alasdair Kergon <agk@redhat.com>
    Cc: Alessandro Zummo <a.zummo@towertech.it>
    Cc: Alex Elder <elder@kernel.org>
    Cc: Alex Williamson <alex.williamson@redhat.com>
    Cc: Alexander Aring <alex.aring@gmail.com>
    Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
    Cc: Alexandre Bounine <alex.bou9@gmail.com>
    Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
    Cc: Alim Akhtar <alim.akhtar@samsung.com>
    Cc: Amitkumar Karwar <amitkarwar@gmail.com>
    Cc: Andreas Noever <andreas.noever@gmail.com>
    Cc: Andrew Jeffery <andrew@aj.id.au>
    Cc: Andrew Lunn <andrew@lunn.ch>
    Cc: Andrzej Hajda <a.hajda@samsung.com>
    Cc: Andy Gross <agross@kernel.org>
    Cc: Ard Biesheuvel <ardb@kernel.org>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Avri Altman <avri.altman@wdc.com>
    Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
    Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
    Cc: Benoit Parrot <bparrot@ti.com>
    Cc: Benson Leung <bleung@chromium.org>
    Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Chas Williams <3chas3@gmail.com>
    Cc: Chen-Yu Tsai <wens@csie.org>
    Cc: Chris Leech <cleech@redhat.com>
    Cc: Chris Snook <chris.snook@gmail.com>
    Cc: Clemens Ladisch <clemens@ladisch.de>
    Cc: Cornelia Huck <cohuck@redhat.com>
    Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: David Ahern <dsahern@kernel.org>
    Cc: David Airlie <airlied@linux.ie>
    Cc: David Rhodes <david.rhodes@cirrus.com>
    Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
    Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
    Cc: Erik Andren <erik.andren@gmail.com>
    Cc: Ezequiel Garcia <ezequiel@collabora.com>
    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Felipe Balbi <balbi@kernel.org>
    Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
    Cc: Florian Fainelli <f.fainelli@gmail.com>
    Cc: Florian Westphal <fw@strlen.de>
    Cc: Gabriel Somlo <somlo@cmu.edu>
    Cc: Ganapathi Bhat <ganapathi017@gmail.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Guenter Roeck <groeck@chromium.org>
    Cc: Guenter Roeck <linux@roeck-us.net>
    Cc: Hans Verkuil <hverkuil@xs4all.nl>
    Cc: Hans de Goede <hdegoede@redhat.com>
    Cc: Heiko Stuebner <heiko@sntech.de>
    Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Jacob Chen <jacob-chen@iotwrt.com>
    Cc: Jakub Kicinski <kuba@kernel.org>
    Cc: James Morse <james.morse@arm.com>
    Cc: James Schulman <james.schulman@cirrus.com>
    Cc: Jan Kara <jack@suse.com>
    Cc: Jaroslav Kysela <perex@perex.cz>
    Cc: Jean Delvare <jdelvare@suse.com>
    Cc: Jean-Paul Roubelat <jpr@f6fbb.org>
    Cc: Jernej Skrabec <jernej.skrabec@siol.net>
    Cc: Jiri Kosina <jikos@kernel.org>
    Cc: Joerg Roedel <joro@8bytes.org>
    Cc: Johan Hovold <johan@kernel.org>
    Cc: Johannes Berg <johannes@sipsolutions.net>
    Cc: John Fastabend <john.fastabend@gmail.com>
    Cc: Jon Maloy <jmaloy@redhat.com>
    Cc: Jonathan Cameron <jic23@kernel.org>
    Cc: Jozsef Kadlecsik <kadlec@netfilter.org>
    Cc: KP Singh <kpsingh@kernel.org>
    Cc: Kalle Valo <kvalo@codeaurora.org>
    Cc: Karsten Keil <isdn@linux-pingi.de>
    Cc: Kirti Wankhede <kwankhede@nvidia.com>
    Cc: Krzysztof Kozlowski <krzk@kernel.org>
    Cc: Krzysztof Opasiak <k.opasiak@samsung.com>
    Cc: Lars-Peter Clausen <lars@metafoo.de>
    Cc: Lee Duncan <lduncan@suse.com>
    Cc: Linus Walleij <linus.walleij@linaro.org>
    Cc: Marcin Wojtas <mw@semihalf.com>
    Cc: Mark Brown <broonie@kernel.org>
    Cc: Mark Greer <mgreer@animalcreek.com>
    Cc: Martin KaFai Lau <kafai@fb.com>
    Cc: Matt Porter <mporter@kernel.crashing.org>
    Cc: Matthias Schwarzott <zzam@gentoo.org>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
    Cc: Maxime Ripard <mripard@kernel.org>
    Cc: Michael Jamet <michael.jamet@intel.com>
    Cc: Michael Turquette <mturquette@baylibre.com>
    Cc: Michal Ostrowski <mostrows@earthlink.net>
    Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
    Cc: Mike Snitzer <snitzer@redhat.com>
    Cc: NXP Linux Team <linux-imx@nxp.com>
    Cc: Oder Chiou <oder_chiou@realtek.com>
    Cc: Pablo Neira Ayuso <pablo@netfilter.org>
    Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
    Cc: Pavel Machek <pavel@ucw.cz>
    Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
    Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
    Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
    Cc: Philipp Zabel <p.zabel@pengutronix.de>
    Cc: Ping-Ke Shih <pkshih@realtek.com>
    Cc: Pravin B Shelar <pshelar@ovn.org>
    Cc: Richard Genoud <richard.genoud@gmail.com>
    Cc: Rob Herring <robh@kernel.org>
    Cc: Robert Foss <robert.foss@linaro.org>
    Cc: Robert Richter <rric@kernel.org>
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: SHA-cyfmac-dev-list@infineon.com
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Cc: Sebastian Reichel <sre@kernel.org>
    Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com>
    Cc: Shawn Guo <shawnguo@kernel.org>
    Cc: Simon Horman <simon.horman@netronome.com>
    Cc: Siva Rebbagondla <siva8118@gmail.com>
    Cc: Solomon Peachy <pizza@shaftnet.org>
    Cc: Song Liu <songliubraving@fb.com>
    Cc: Stefan Schmidt <stefan@datenfreihafen.org>
    Cc: Stefano Stabellini <sstabellini@kernel.org>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Takashi Iwai <tiwai@suse.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Todor Tomov <todor.too@gmail.com>
    Cc: Tony Lindgren <tony@atomide.com>
    Cc: VMware PV-Drivers <pv-drivers@vmware.com>
    Cc: Vaibhav Agarwal <vaibhav.sr@gmail.com>
    Cc: Vinod Koul <vkoul@kernel.org>
    Cc: Vivien Didelot <vivien.didelot@gmail.com>
    Cc: Vladimir Oltean <olteanv@gmail.com>
    Cc: Will Deacon <will@kernel.org>
    Cc: Xinming Hu <huxinming820@gmail.com>
    Cc: Xue Liu <liuxuenetmail@gmail.com>
    Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
    Cc: Ying Xue <ying.xue@windriver.com>
    Cc: Yonghong Song <yhs@fb.com>
    Cc: alsa-devel@alsa-project.org
    Cc: amd-gfx@lists.freedesktop.org
    Cc: bpf@vger.kernel.org
    Cc: brcm80211-dev-list.pdl@broadcom.com
    Cc: clang-built-linux@googlegroups.com
    Cc: coreteam@netfilter.org
    Cc: dev@openvswitch.org
    Cc: dm-devel@redhat.com
    Cc: dmaengine@vger.kernel.org
    Cc: dri-devel@lists.freedesktop.org
    Cc: ecryptfs@vger.kernel.org
    Cc: greybus-dev@lists.linaro.org
    Cc: intel-wired-lan@lists.osuosl.org
    Cc: iommu@lists.linux-foundation.org
    Cc: kvm@vger.kernel.org
    Cc: libertas-dev@lists.infradead.org
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-afs@lists.infradead.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-arm-msm@vger.kernel.org
    Cc: linux-aspeed@lists.ozlabs.org
    Cc: linux-atm-general@lists.sourceforge.net
    Cc: linux-audit@redhat.com
    Cc: linux-clk@vger.kernel.org
    Cc: linux-edac@vger.kernel.org
    Cc: linux-efi@vger.kernel.org
    Cc: linux-fbdev@vger.kernel.org
    Cc: linux-gpio@vger.kernel.org
    Cc: linux-hams@vger.kernel.org
    Cc: linux-hwmon@vger.kernel.org
    Cc: linux-iio@vger.kernel.org
    Cc: linux-input@vger.kernel.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-leds@vger.kernel.org
    Cc: linux-media@vger.kernel.org
    Cc: linux-mmc@vger.kernel.org
    Cc: linux-nfc@lists.01.org
    Cc: linux-nfs@vger.kernel.org
    Cc: linux-nvdimm@lists.01.org
    Cc: linux-nvidia@lists.surfsouth.com
    Cc: linux-omap@vger.kernel.org
    Cc: linux-pci@vger.kernel.org
    Cc: linux-pm@vger.kernel.org
    Cc: linux-raid@vger.kernel.org
    Cc: linux-rdma@vger.kernel.org
    Cc: linux-renesas-soc@vger.kernel.org
    Cc: linux-rockchip@lists.infradead.org
    Cc: linux-rtc@vger.kernel.org
    Cc: linux-s390@vger.kernel.org
    Cc: linux-samsung-soc@vger.kernel.org
    Cc: linux-scsi@vger.kernel.org
    Cc: linux-serial@vger.kernel.org
    Cc: linux-spi@vger.kernel.org
    Cc: linux-staging@lists.linux.dev
    Cc: linux-stm32@st-md-mailman.stormreply.com
    Cc: linux-sunxi@lists.linux.dev
    Cc: linux-tegra@vger.kernel.org
    Cc: linux-usb@vger.kernel.org
    Cc: linux-wireless@vger.kernel.org
    Cc: linux-wpan@vger.kernel.org
    Cc: netdev@vger.kernel.org
    Cc: netfilter-devel@vger.kernel.org
    Cc: nouveau@lists.freedesktop.org
    Cc: ocfs2-devel@oss.oracle.com
    Cc: open-iscsi@googlegroups.com
    Cc: oss-drivers@netronome.com
    Cc: patches@opensource.cirrus.com
    Cc: qemu-devel@nongnu.org
    Cc: rds-devel@oss.oracle.com
    Cc: target-devel@vger.kernel.org
    Cc: tipc-discussion@lists.sourceforge.net
    Cc: usb-storage@lists.one-eyed-alien.net
    Cc: x86@kernel.org
    Cc: xen-devel@lists.xenproject.org
Number of Cc at cover: 221


^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:38                   ` Shuah Khan
@ 2021-04-23  9:06                     ` Mauro Carvalho Chehab
  2021-04-23 17:17                       ` Leon Romanovsky
  2021-04-23 22:41                       ` Shuah Khan
  0 siblings, 2 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23  9:06 UTC (permalink / raw)
  To: Shuah Khan
  Cc: Leon Romanovsky, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

Em Thu, 22 Apr 2021 09:38:03 -0600
Shuah Khan <skhan@linuxfoundation.org> escreveu:

> On 4/22/21 6:18 AM, Leon Romanovsky wrote:
> > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:  
> >> Em Thu, 22 Apr 2021 09:34:38 +0200
> >> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> >>  
> >>> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:  
> >>>> On Wed, 21 Apr 2021, Julia Lawall wrote:  
> >>>>> The apology states that they didn't detect any vulnerabilities.  They
> >>>>> found three non exploitable bugs and submitted incorrect patches for them.
> >>>>> When the patches received some positive feedback, they explained that the
> >>>>> patches were incorrect and provided a proper fix.
> >>>>>
> >>>>> So they damaged trust, but not actually the Linux kernel...  
> >>>>
> >>>> The issue is that there was no consent and no coordination, so we don't
> >>>> know the scope of the experiment and whether it was still continuing.
> >>>>
> >>>> We are this not able to trust anything the group said about what they'd
> >>>> done or not done, until now [1].
> >>>>
> >>>> In all probability there is nothing further amiss but we would not have
> >>>> expected them to use fake gmail accounts to submit bugs to the kernel
> >>>> either.
> >>>>
> >>>> It's now on us to audit all of their known contributions, because we don't
> >>>> know the scope of the experiment, which was based on the use of deception,
> >>>> and we can't make any assumptions based on what they have said.
> >>>>
> >>>> We also need the identity of the 'random' gmail accounts they used,
> >>>> although this should be handled by a small trusted group in private, as it
> >>>> will lead to privacy issues for kernel maintainers who responded to them
> >>>> in public.  
> >>>
> >>> What do we gain by blindly reverting all[1] umn.edu patches, and
> >>> ignoring future patches from umn.edu?
> >>> I think all of this is moot: other people may be doing the same thing,
> >>> or even "in worse faith".  The only thing that helps is making sure
> >>> patches get reviewed[2] before being applied.
> >>>
> >>> [1] Judging from the new review comments, many of the 190 patches
> >>>      to be reverted were real fixes.  
> >>
> >> The reverted ones for media (29 patches) didn't contain any malicious code.
> >> One was useless (because the media core already fixes the pointed issue),
> >> but the other ones were valid patches.  
> > 
> > I'm sorry that I didn't check all media commits, but this random commit
> > 467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
> > broke sp8870 (I don't know what is it).
> > 
> > diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
> > index 8d31cf3f4f07..270a3c559e08 100644
> > --- a/drivers/media/dvb-frontends/sp8870.c
> > +++ b/drivers/media/dvb-frontends/sp8870.c
> > @@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
> >          sp8870_writereg(state, 0xc05, reg0xc05);
> > 
> >          // read status reg in order to clear pending irqs
> > -       sp8870_readreg(state, 0x200);
> > +       err = sp8870_readreg(state, 0x200);
> > +       if (err)
> > +               return err;
> > 
> >          // system controller start
> >          sp8870_microcontroller_start(state);
> > 
> > 
> >     67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
> >     68 {
> >     69         int ret;
> >   <...>
> >     77         if (ret != 2) {
> >     78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
> >     79                 return -1;
> >     80         }
> >     81
> >     82         return (b1[0] << 8 | b1[1]);
> >     83 }
> > 
> > The valid check should be if (err < 0);
> >   
> 
> Correct. Like all the other callers of sp8870_readreg() do with
> its return. Non-zero return is valid for this routine.

This particular patch is completely broken and should be reverted.
Also, probably a comment should be added to ensure that people won't
try to send us similar "trivial" fixes.

Basically, the logic at sp8870_set_frontend_parameters() is called
when tuning into a new DVB-T channel. the call there for 

		sp8870_readreg(state, 0x200);

Seems to be there just to reset IRQ registers. It should _not_ check
the return results on this particular case.

Yet, this driver was written back in 1999 for a DVB-T device that
used to be available on that time. Just one driver (av7110) can
use such tuner. Those PCI chipsets had stopped produced a very long
time ago. Even the company that used to produce av7110 has long
gone, more than 17 years ago.

I guess it is time to get rid of av7110 and the ancillary drivers
used only on it. 

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  6:15           ` Greg KH
  2021-04-23  6:50             ` Dan Williams
  2021-04-23  7:13             ` Geert Uytterhoeven
@ 2021-04-23  9:12             ` Michal Hocko
  2 siblings, 0 replies; 153+ messages in thread
From: Michal Hocko @ 2021-04-23  9:12 UTC (permalink / raw)
  To: Greg KH
  Cc: Steven Rostedt, Mark Brown, Mike Rapoport, Leon Romanovsky,
	James Bottomley, ksummit

On Fri 23-04-21 08:15:34, Greg KH wrote:
> On Thu, Apr 22, 2021 at 11:19:39AM -0400, Steven Rostedt wrote:
> > On Thu, 22 Apr 2021 14:23:39 +0100
> > Mark Brown <broonie@kernel.org> wrote:
> > 
> > > > For me the most annoying is to get several patches from the middle of a
> > > > series. IMHO, sending at least cover letter to everyone is the bare minimum
> > > > so that people at least can take a look at high level details and request a
> > > > repost.  
> > > 
> > > Yes, the cover letter should always go to everyone.
> > 
> > And that's still the one thing that quilt send-mail does not support :-p
> 
> 'git format-patch --cover-letter' also does not seem to support this, so
> what tool does?

My workflow is to put Cc: in respective patches, git format-patch the
series and then use --cc-cmd=./cc-cmd-only-cover.sh along with git
send-email --compose. It sucks but it is manageable.

$ cat cc-cmd-only-cover.sh
#!/bin/bash

if [[ $1 == *gitsendemail.msg* || $1 == *cover-letter* ]]; then
        grep '<.*@.*>' -h *.patch | sed 's/^.*: //' | sort | uniq
fi
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 15:36       ` Mark Brown
  2021-04-22 15:40         ` James Bottomley
@ 2021-04-23  9:27         ` Dan Carpenter
  1 sibling, 0 replies; 153+ messages in thread
From: Dan Carpenter @ 2021-04-23  9:27 UTC (permalink / raw)
  To: Mark Brown
  Cc: James Bottomley, Martin K. Petersen, Mauro Carvalho Chehab, ksummit

On Thu, Apr 22, 2021 at 04:36:46PM +0100, Mark Brown wrote:
> On Thu, Apr 22, 2021 at 08:28:00AM -0700, James Bottomley wrote:
> > On Thu, 2021-04-22 at 08:32 -0400, Martin K. Petersen wrote:
> > > Another metric that may be worth capturing is how many Fixes: tags
> > > refer to patches authored by this submitter.
> 
> > Or perhaps invert it: no bug fix without a Fixes: tag.  Some of the
> > human handlers of robot based finders, like Dan's smatch, do go back
> > and figure out where the bug came from, but if we encourage the rule
> > that if you're fixing a bug you must identify the origin and explain
> > the bug it may help weed out some bogus fixes.
> 
> Script that use git blame to generate a commit to put in the Fixes: tag
> incoming...

I always put the person who wrote the original commit in the To line.
They're probably the best person to review the patch.  People do get
annoyed if you blame them for someone else's bug.

regards,
dan carpenter

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  7:58           ` Mauro Carvalho Chehab
@ 2021-04-23 10:54             ` Greg KH
  2021-04-23 17:09             ` Leon Romanovsky
  1 sibling, 0 replies; 153+ messages in thread
From: Greg KH @ 2021-04-23 10:54 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Steven Rostedt, James Bottomley, Shuah Khan, ksummit

On Fri, Apr 23, 2021 at 09:58:30AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 11:52:35 -0400
> Steven Rostedt <rostedt@goodmis.org> escreveu:
> 
> > On Thu, 22 Apr 2021 08:48:21 -0700
> > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > > On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> > > [...]  
> > > >    2. Improving the requirement for bug fixes and large series, like
> > > > cover letters to everyone, adding fixes: tag and clear explanation.    
> > > 
> > > Just on this one, can we get the mailing list to help now we're moving
> > > to a new infrastructure?  I was already thinking of asking if it could
> > > reject email with html parts rather than simply losing it, but perhaps
> > > it could reject threaded submissions where the cover letter isn't
> > > correctly cc'd?  I know that's a big ask because there has to be an
> > > easy way to recognize them (heuristics on the PATCH tag?) and a way to
> > > recognize missing cc's (perhaps simply that someone cc'd on the
> > > threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)  
> > 
> > Unfortunately, this breaks all quilt users, as quilt does not support this.
> 
> This will also break patch series that touch several subsystems.
> 
> Out of curiosity, I ran my script letting it to place at the cover letter
> maintainers, reviewers and mailing lists, for this patch series:
> 
> 	[PATCH 000/190] Revertion of all of the umn.edu commits
> 	https://lore.kernel.org/lkml/YIJyzkgglMrAzIwh@kroah.com/T/#m087445f69f5dd590b9ad5f4cdd62c2a812956435
> 
> The number of e-mails to be C/c is 221 e-mails! (see enclosed)
> 
> An e-mail like that will almost for sure be ignored by  all mail
> servers[1], as the e-mail will be considered as SPAM.
> 
> [1] Except if the servers would have explicit rules to allow such
>     really big c/c list to be accepted from maintainers, which is
>     risky.
> 
> Looking at the actual e-mail from Greg at lore, the CC list was a lot
> smaller than that:
> 
> Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
>         Linus Torvalds <torvalds@linux-foundation.org>,
>         Aditya Pakki <pakki001@umn.edu>, Kangjie Lu <kjlu@umn.edu>,
>         Qiushi Wu <wu000273@umn.edu>, x86@kernel.org,
>         Bjorn Helgaas <bhelgaas@google.com>,
>         "Rafael J. Wysocki" <rjw@rjwysocki.net>,
>         Arnd Bergmann <arnd@arndb.de>, David Airlie <airlied@linux.ie>,
>         Michael Turquette <mturquette@baylibre.com>,
>         Bjorn Andersson <bjorn.andersson@linaro.org>,
>         Linus Walleij <linus.walleij@linaro.org>,
>         Bartosz Golaszewski <bgolaszewski@baylibre.com>,
>         Daniel Vetter <daniel@ffwll.ch>,
>         Jean Delvare <jdelvare@suse.com>,
>         Guenter Roeck <linux@roeck-us.net>,
>         Jiri Kosina <jikos@kernel.org>, Will Deacon <will@kernel.org>,
>         Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
>         Jakub Kicinski <kuba@kernel.org>,
>         "David S. Miller" <davem@davemloft.net>,
>         Johan Hovold <johan@kernel.org>,
>         Jiri Slaby <jirislaby@kernel.org>,
>         Pablo Neira Ayuso <pablo@netfilter.org>,
>         Johannes Berg <johannes@sipsolutions.net>,
>         Takashi Iwai <tiwai@suse.com>
> 
> (Not sure what criteria Greg used to shorten the C/c list)

I looked at the actual maintainers for the whole list of patches and
made a judgement call to slim it down to something "manageable"

In other words, I was forced to do it "by hand" :(

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-22 17:08             ` Martin K. Petersen
@ 2021-04-23 11:16               ` Jan Kara
  2021-04-23 12:57                 ` Mauro Carvalho Chehab
  0 siblings, 1 reply; 153+ messages in thread
From: Jan Kara @ 2021-04-23 11:16 UTC (permalink / raw)
  To: Martin K. Petersen
  Cc: Jan Kara, Steven Rostedt, James Bottomley, Shuah Khan,
	Mauro Carvalho Chehab, ksummit

On Thu 22-04-21 13:08:09, Martin K. Petersen wrote:
> 
> Jan,
> 
> > Is it that hard to improve quilt?
> 
> Now that we have tighter integration between the various components of
> our infrastructure, I wonder if we should reconsider the patch
> submission process?
> 
> Instead of putting the burden on the submitter to pick the right 20
> mailing lists to CC: and accommodate 100 developers and maintainers with
> individual delivery preferences, why not let the k.org infrastructure
> automate that aspect?
> 
> Have a patch ingress email address that runs get_maintainer.pl to figure
> out who to reach out to. And then everybody with a kernel.org account
> can twiddle their preferences wrt. whether to receive the whole series,
> only patches that touch files they are responsible for, opt not to
> receive individual mails but only the relevant mailing list copy,
> whether to receive stable backport notifications, etc.
> 
> That would substantially lower the barrier of entry for patch
> submitters. More work for Konstantin, obviously. And potentially some
> transitional grievances for most of the rest of us based on our
> individual workflows and preferences.
> 
> Just an idea, I know it's a bit controversial. However, there seems to
> be no shortage of problems originating in the patch mail preparation and
> sending department. Seems like a bigger barrier for some than developing
> the actual patch.
> 
> We could even consider supporting receiving and disseminating git
> bundles on the ingress. That would help overcome the many problems with
> corporate email servers vs. git send-email. A ton of problems are
> introduced as developers copy and paste things from their corporate
> email to GMail, etc. Seems like our backend tooling could help alleviate
> some of those pains without completely wrecking the mail-based flow we
> maintainers are comfortable with...

I agree this would be a nicer solution and I think something like this is
eventual Konstantin's goal. So hopefully we'll get there once :)

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23 11:16               ` Jan Kara
@ 2021-04-23 12:57                 ` Mauro Carvalho Chehab
  0 siblings, 0 replies; 153+ messages in thread
From: Mauro Carvalho Chehab @ 2021-04-23 12:57 UTC (permalink / raw)
  To: Jan Kara
  Cc: Martin K. Petersen, Steven Rostedt, James Bottomley, Shuah Khan, ksummit

Em Fri, 23 Apr 2021 13:16:06 +0200
Jan Kara <jack@suse.cz> escreveu:

> On Thu 22-04-21 13:08:09, Martin K. Petersen wrote:
> > 
> > Jan,
> >   
> > > Is it that hard to improve quilt?  
> > 
> > Now that we have tighter integration between the various components of
> > our infrastructure, I wonder if we should reconsider the patch
> > submission process?
> > 
> > Instead of putting the burden on the submitter to pick the right 20
> > mailing lists to CC: and accommodate 100 developers and maintainers with
> > individual delivery preferences, why not let the k.org infrastructure
> > automate that aspect?
> > 
> > Have a patch ingress email address that runs get_maintainer.pl to figure
> > out who to reach out to. And then everybody with a kernel.org account
> > can twiddle their preferences wrt. whether to receive the whole series,
> > only patches that touch files they are responsible for, opt not to
> > receive individual mails but only the relevant mailing list copy,
> > whether to receive stable backport notifications, etc.
> > 
> > That would substantially lower the barrier of entry for patch
> > submitters. More work for Konstantin, obviously. And potentially some
> > transitional grievances for most of the rest of us based on our
> > individual workflows and preferences.
> > 
> > Just an idea, I know it's a bit controversial. However, there seems to
> > be no shortage of problems originating in the patch mail preparation and
> > sending department. Seems like a bigger barrier for some than developing
> > the actual patch.
> > 
> > We could even consider supporting receiving and disseminating git
> > bundles on the ingress. That would help overcome the many problems with
> > corporate email servers vs. git send-email. A ton of problems are
> > introduced as developers copy and paste things from their corporate
> > email to GMail, etc. Seems like our backend tooling could help alleviate
> > some of those pains without completely wrecking the mail-based flow we
> > maintainers are comfortable with...  
> 
> I agree this would be a nicer solution and I think something like this is
> eventual Konstantin's goal. So hopefully we'll get there once :)

The idea is nice, but, for this to work, the reply-to address should point
to some bot at kernel.org infra, as all replies to a given patch (or cover)
should be replied to everyone that it was c/c on the original e-mail, plus
the patch submitter.

Thanks,
Mauro

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  7:13             ` Geert Uytterhoeven
@ 2021-04-23 14:41               ` Shuah Khan
  0 siblings, 0 replies; 153+ messages in thread
From: Shuah Khan @ 2021-04-23 14:41 UTC (permalink / raw)
  To: Geert Uytterhoeven, Greg KH
  Cc: Steven Rostedt, Mark Brown, Mike Rapoport, Leon Romanovsky,
	James Bottomley, ksummit, Shuah Khan

On 4/23/21 1:13 AM, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Fri, Apr 23, 2021 at 8:17 AM Greg KH <greg@kroah.com> wrote:
>> On Thu, Apr 22, 2021 at 11:19:39AM -0400, Steven Rostedt wrote:
>>> On Thu, 22 Apr 2021 14:23:39 +0100
>>> Mark Brown <broonie@kernel.org> wrote:
>>>>> For me the most annoying is to get several patches from the middle of a
>>>>> series. IMHO, sending at least cover letter to everyone is the bare minimum
>>>>> so that people at least can take a look at high level details and request a
>>>>> repost.
>>>>
>>>> Yes, the cover letter should always go to everyone.
>>>
>>> And that's still the one thing that quilt send-mail does not support :-p
>>
>> 'git format-patch --cover-letter' also does not seem to support this, so
>> what tool does?
> 
> You can (manually) add "Cc: name <address>" lines to the individual
> files created by "git format-patch", which will be used by
> "git send-email".
> I guess this can also be done to the mbox saved by "quilt mail --mbox"?
> 

I add them manually compiling list for individual patches in a series.

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-23  7:13               ` Mauro Carvalho Chehab
  2021-04-23  7:20                 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
@ 2021-04-23 14:52                 ` Doug Anderson
  2021-04-23 16:03                   ` Mark Brown
  1 sibling, 1 reply; 153+ messages in thread
From: Doug Anderson @ 2021-04-23 14:52 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Joe Perches, Rob Herring, Steven Rostedt, Leon Romanovsky,
	James Bottomley, ksummit, tools, Simon Glass

Hi,

On Fri, Apr 23, 2021 at 12:13 AM Mauro Carvalho Chehab
<mchehab@kernel.org> wrote:
>
> Em Thu, 22 Apr 2021 23:46:31 -0700
> Joe Perches <joe@perches.com> escreveu:
>
> > On Fri, 2021-04-23 at 08:04 +0200, Mauro Carvalho Chehab wrote:
> > > I have a script to automate it, but I had to tweak it while handling
> > > patches that cross a single subsystem boundaries, using git send-email
> > > with the c/c list obtained from get_maintainers.pl.
> > >
> > > By default, the script adds all maintainers, reviewers and all mailing
> > > lists to the cover letter, but that sometimes generate a cover letter
> > > with 80+ c/c, which will be automatically rejected by anti-spam
> > > measures and by mail servers.
> > >
> > > So, I played with two different alternatives:
> > >
> > > 1. At the beginning, I changed the script to c/c only the mailing lists,
> > >    excluding maintainers/reviewers;
> > > 2. As the feedback was not great, I changed the script to c/c only
> > >    the maintainers, excluding mailing lists/reviewers. It seems that
> > >    this worked better.
> > >
> > > I didn't try to play with bcc, as replying to it would not send
> > > the replies to everyone.
> > >
> > > If you think it is worth, I could submit it to scripts/, but I
> > > suspect we may need to adjust it to work with all maintainers'
> > > workflows.
> >
> > I have a very similar script
> >
> > A portion of a cc script I use tests whether cc'ing the cover letter
> > to all listed maintainers of a patch series creates a header of less
> > than 512 chars and if so cc's all relevant maintainers, otherwise it
> > just cc's the mailing lists.
> >
> > (Ingo didn't/doesn't want to receive any emails from me)
> >
> > $ cat ~/bin/remove_undesirable_emails.sh
> > grep -vPi "(?:\bIngo\s+Molnar\b)"
> >
> > $ cat ~/bin/cc.sh
> > #!/bin/bash
> >
> > opts="--nogit --nogit-fallback --norolestats"
> > maint_file=$(mktemp -t XXXXXXXX.cc)
> >
> > if [[ $(basename $1) =~ ^0000- ]] ; then
> >     ./scripts/get_maintainer.pl $opts $(dirname $1)/* |  \
> >       ~/bin/remove_undesirable_emails.sh > $maint_file
> >     count=$(wc -c $maint_file | cut -f1 -d" ")
> >     if [[ $count -lt 512 ]] ; then
> >       cat $maint_file
> >     else
> >       ./scripts/get_maintainer.pl -nom -nor $opts $(dirname $1)/* | \
> >           ~/bin/remove_undesirable_emails.sh
> >     fi
> >
> > ...
> >
>
> Heh, mine is a lot more complex than that ;-)
>
> It internally runs git format-patch, git send-email and get_maintainers.pl,
> and, when --cover or --annotate is used, it opens a window to allow
> editing the text. It has several options in order to tweak its behavior.

FWIW, I suppose I'll take this opportunity to point out "patman",
which is the tool I use for this. It lives in U-Boot but I (and
several others) also use it for Linux development. See
<https://source.denx.de/u-boot/u-boot/-/blob/master/tools/patman/README>.
I seem to remember at one point Olof criticizing it as making it too
easy to send big patch series (apologies if I remembered this wrong
Olof), which I actually took as a big praise for the tool. ;-)

At the moment, patman does this for Linux:

1. By default calls "get_maintainer" to (separately) add CCs to each
patch in the series. There has been talk about this not being the
default for Linux and by default CCing everyone on all patches (or at
least making an option for it).

2. By default CCs everyone on the cover letter.

3. Neatly handles version history and includes version history both in
the cover letter and each patch.

4. ...and a whole load of other cool things.

I know it's nearly impossible to get people to change their workflows,
but if you're open to it I definitely suggest giving it a try. Simon
Glass (the original author) is also quite receptive to improvements.

-Doug

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
@ 2021-04-23 16:03                   ` Mark Brown
  2021-04-23 17:12                     ` Leon Romanovsky
  0 siblings, 1 reply; 153+ messages in thread
From: Mark Brown @ 2021-04-23 16:03 UTC (permalink / raw)
  To: Doug Anderson
  Cc: Mauro Carvalho Chehab, Joe Perches, Rob Herring, Steven Rostedt,
	Leon Romanovsky, James Bottomley, ksummit, tools, Simon Glass

[-- Attachment #1: Type: text/plain, Size: 514 bytes --]

On Fri, Apr 23, 2021 at 07:52:30AM -0700, Doug Anderson wrote:

> I know it's nearly impossible to get people to change their workflows,
> but if you're open to it I definitely suggest giving it a try. Simon
> Glass (the original author) is also quite receptive to improvements.

I have something broadly similar (much more simplistic and overall less
capable) which I wrote myself - the things I have that this doesn't have
are:

 - Attesting the outgoing patches with b4.
 - Tagging the published series in git.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  7:58           ` Mauro Carvalho Chehab
  2021-04-23 10:54             ` Greg KH
@ 2021-04-23 17:09             ` Leon Romanovsky
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-23 17:09 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Steven Rostedt, James Bottomley, Shuah Khan, ksummit, Greg KH

On Fri, Apr 23, 2021 at 09:58:30AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 11:52:35 -0400
> Steven Rostedt <rostedt@goodmis.org> escreveu:
> 
> > On Thu, 22 Apr 2021 08:48:21 -0700
> > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> > 
> > > On Thu, 2021-04-22 at 08:42 -0700, James Bottomley wrote:
> > > [...]  
> > > >    2. Improving the requirement for bug fixes and large series, like
> > > > cover letters to everyone, adding fixes: tag and clear explanation.    
> > > 
> > > Just on this one, can we get the mailing list to help now we're moving
> > > to a new infrastructure?  I was already thinking of asking if it could
> > > reject email with html parts rather than simply losing it, but perhaps
> > > it could reject threaded submissions where the cover letter isn't
> > > correctly cc'd?  I know that's a big ask because there has to be an
> > > easy way to recognize them (heuristics on the PATCH tag?) and a way to
> > > recognize missing cc's (perhaps simply that someone cc'd on the
> > > threaded [PATCH x/y] reply isn't cc'd on [PATCH 0/y]?)  
> > 
> > Unfortunately, this breaks all quilt users, as quilt does not support this.
> 
> This will also break patch series that touch several subsystems.
> 
> Out of curiosity, I ran my script letting it to place at the cover letter
> maintainers, reviewers and mailing lists, for this patch series:
> 
> 	[PATCH 000/190] Revertion of all of the umn.edu commits
> 	https://lore.kernel.org/lkml/YIJyzkgglMrAzIwh@kroah.com/T/#m087445f69f5dd590b9ad5f4cdd62c2a812956435
> 
> The number of e-mails to be C/c is 221 e-mails! (see enclosed)
> 
> An e-mail like that will almost for sure be ignored by  all mail
> servers[1], as the e-mail will be considered as SPAM.
> 
> [1] Except if the servers would have explicit rules to allow such
>     really big c/c list to be accepted from maintainers, which is
>     risky.
> 
> Looking at the actual e-mail from Greg at lore, the CC list was a lot
> smaller than that:
> 
> Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
>         Linus Torvalds <torvalds@linux-foundation.org>,
>         Aditya Pakki <pakki001@umn.edu>, Kangjie Lu <kjlu@umn.edu>,
>         Qiushi Wu <wu000273@umn.edu>, x86@kernel.org,
>         Bjorn Helgaas <bhelgaas@google.com>,
>         "Rafael J. Wysocki" <rjw@rjwysocki.net>,
>         Arnd Bergmann <arnd@arndb.de>, David Airlie <airlied@linux.ie>,
>         Michael Turquette <mturquette@baylibre.com>,
>         Bjorn Andersson <bjorn.andersson@linaro.org>,
>         Linus Walleij <linus.walleij@linaro.org>,
>         Bartosz Golaszewski <bgolaszewski@baylibre.com>,
>         Daniel Vetter <daniel@ffwll.ch>,
>         Jean Delvare <jdelvare@suse.com>,
>         Guenter Roeck <linux@roeck-us.net>,
>         Jiri Kosina <jikos@kernel.org>, Will Deacon <will@kernel.org>,
>         Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
>         Jakub Kicinski <kuba@kernel.org>,
>         "David S. Miller" <davem@davemloft.net>,
>         Johan Hovold <johan@kernel.org>,
>         Jiri Slaby <jirislaby@kernel.org>,
>         Pablo Neira Ayuso <pablo@netfilter.org>,
>         Johannes Berg <johannes@sipsolutions.net>,
>         Takashi Iwai <tiwai@suse.com>
> 
> (Not sure what criteria Greg used to shorten the C/c list)
> 
> Thanks,
> Mauro
> 
> ---
> 
> The auto-generated list of c/c is:

Something wrong with this list, reverted RDMA commits should generate
Cc: Jason Gunthorpe and Doug Ledford

Thanks

> 
> patches/tmp/0000-cover-letter.patch:
>     Cc: "David S. Miller" <davem@davemloft.net>
>     Cc: "H. Peter Anvin" <hpa@zytor.com>
>     Cc: "James E.J. Bottomley" <jejb@linux.ibm.com>
>     Cc: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
>     Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
>     Cc: "Michael S. Tsirkin" <mst@redhat.com>
>     Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>     Cc: Adit Ranadive <aditr@vmware.com>
>     Cc: Alan Stern <stern@rowland.harvard.edu>
>     Cc: Alasdair Kergon <agk@redhat.com>
>     Cc: Alessandro Zummo <a.zummo@towertech.it>
>     Cc: Alex Elder <elder@kernel.org>
>     Cc: Alex Williamson <alex.williamson@redhat.com>
>     Cc: Alexander Aring <alex.aring@gmail.com>
>     Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
>     Cc: Alexandre Bounine <alex.bou9@gmail.com>
>     Cc: Alexandre Torgue <alexandre.torgue@foss.st.com>
>     Cc: Alim Akhtar <alim.akhtar@samsung.com>
>     Cc: Amitkumar Karwar <amitkarwar@gmail.com>
>     Cc: Andreas Noever <andreas.noever@gmail.com>
>     Cc: Andrew Jeffery <andrew@aj.id.au>
>     Cc: Andrew Lunn <andrew@lunn.ch>
>     Cc: Andrzej Hajda <a.hajda@samsung.com>
>     Cc: Andy Gross <agross@kernel.org>
>     Cc: Ard Biesheuvel <ardb@kernel.org>
>     Cc: Arnd Bergmann <arnd@arndb.de>
>     Cc: Avri Altman <avri.altman@wdc.com>
>     Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>     Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>     Cc: Benoit Parrot <bparrot@ti.com>
>     Cc: Benson Leung <bleung@chromium.org>
>     Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
>     Cc: Borislav Petkov <bp@alien8.de>
>     Cc: Chas Williams <3chas3@gmail.com>
>     Cc: Chen-Yu Tsai <wens@csie.org>
>     Cc: Chris Leech <cleech@redhat.com>
>     Cc: Chris Snook <chris.snook@gmail.com>
>     Cc: Clemens Ladisch <clemens@ladisch.de>
>     Cc: Cornelia Huck <cohuck@redhat.com>
>     Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
>     Cc: Daniel Vetter <daniel@ffwll.ch>
>     Cc: David Ahern <dsahern@kernel.org>
>     Cc: David Airlie <airlied@linux.ie>
>     Cc: David Rhodes <david.rhodes@cirrus.com>
>     Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>     Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>     Cc: Erik Andren <erik.andren@gmail.com>
>     Cc: Ezequiel Garcia <ezequiel@collabora.com>
>     Cc: Fabio Estevam <festevam@gmail.com>
>     Cc: Felipe Balbi <balbi@kernel.org>
>     Cc: Ferenc Bakonyi <fero@drama.obuda.kando.hu>
>     Cc: Florian Fainelli <f.fainelli@gmail.com>
>     Cc: Florian Westphal <fw@strlen.de>
>     Cc: Gabriel Somlo <somlo@cmu.edu>
>     Cc: Ganapathi Bhat <ganapathi017@gmail.com>
>     Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>     Cc: Guenter Roeck <groeck@chromium.org>
>     Cc: Guenter Roeck <linux@roeck-us.net>
>     Cc: Hans Verkuil <hverkuil@xs4all.nl>
>     Cc: Hans de Goede <hdegoede@redhat.com>
>     Cc: Heiko Stuebner <heiko@sntech.de>
>     Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
>     Cc: Ingo Molnar <mingo@redhat.com>
>     Cc: Jacob Chen <jacob-chen@iotwrt.com>
>     Cc: Jakub Kicinski <kuba@kernel.org>
>     Cc: James Morse <james.morse@arm.com>
>     Cc: James Schulman <james.schulman@cirrus.com>
>     Cc: Jan Kara <jack@suse.com>
>     Cc: Jaroslav Kysela <perex@perex.cz>
>     Cc: Jean Delvare <jdelvare@suse.com>
>     Cc: Jean-Paul Roubelat <jpr@f6fbb.org>
>     Cc: Jernej Skrabec <jernej.skrabec@siol.net>
>     Cc: Jiri Kosina <jikos@kernel.org>
>     Cc: Joerg Roedel <joro@8bytes.org>
>     Cc: Johan Hovold <johan@kernel.org>
>     Cc: Johannes Berg <johannes@sipsolutions.net>
>     Cc: John Fastabend <john.fastabend@gmail.com>
>     Cc: Jon Maloy <jmaloy@redhat.com>
>     Cc: Jonathan Cameron <jic23@kernel.org>
>     Cc: Jozsef Kadlecsik <kadlec@netfilter.org>
>     Cc: KP Singh <kpsingh@kernel.org>
>     Cc: Kalle Valo <kvalo@codeaurora.org>
>     Cc: Karsten Keil <isdn@linux-pingi.de>
>     Cc: Kirti Wankhede <kwankhede@nvidia.com>
>     Cc: Krzysztof Kozlowski <krzk@kernel.org>
>     Cc: Krzysztof Opasiak <k.opasiak@samsung.com>
>     Cc: Lars-Peter Clausen <lars@metafoo.de>
>     Cc: Lee Duncan <lduncan@suse.com>
>     Cc: Linus Walleij <linus.walleij@linaro.org>
>     Cc: Marcin Wojtas <mw@semihalf.com>
>     Cc: Mark Brown <broonie@kernel.org>
>     Cc: Mark Greer <mgreer@animalcreek.com>
>     Cc: Martin KaFai Lau <kafai@fb.com>
>     Cc: Matt Porter <mporter@kernel.crashing.org>
>     Cc: Matthias Schwarzott <zzam@gentoo.org>
>     Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
>     Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>     Cc: Maxime Ripard <mripard@kernel.org>
>     Cc: Michael Jamet <michael.jamet@intel.com>
>     Cc: Michael Turquette <mturquette@baylibre.com>
>     Cc: Michal Ostrowski <mostrows@earthlink.net>
>     Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
>     Cc: Mike Snitzer <snitzer@redhat.com>
>     Cc: NXP Linux Team <linux-imx@nxp.com>
>     Cc: Oder Chiou <oder_chiou@realtek.com>
>     Cc: Pablo Neira Ayuso <pablo@netfilter.org>
>     Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
>     Cc: Pavel Machek <pavel@ucw.cz>
>     Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
>     Cc: Peter Meerwald-Stadler <pmeerw@pmeerw.net>
>     Cc: Peter Oberparleiter <oberpar@linux.ibm.com>
>     Cc: Philipp Zabel <p.zabel@pengutronix.de>
>     Cc: Ping-Ke Shih <pkshih@realtek.com>
>     Cc: Pravin B Shelar <pshelar@ovn.org>
>     Cc: Richard Genoud <richard.genoud@gmail.com>
>     Cc: Rob Herring <robh@kernel.org>
>     Cc: Robert Foss <robert.foss@linaro.org>
>     Cc: Robert Richter <rric@kernel.org>
>     Cc: Russell King <linux@armlinux.org.uk>
>     Cc: SHA-cyfmac-dev-list@infineon.com
>     Cc: Sascha Hauer <s.hauer@pengutronix.de>
>     Cc: Sebastian Reichel <sre@kernel.org>
>     Cc: Sharvari Harisangam <sharvari.harisangam@nxp.com>
>     Cc: Shawn Guo <shawnguo@kernel.org>
>     Cc: Simon Horman <simon.horman@netronome.com>
>     Cc: Siva Rebbagondla <siva8118@gmail.com>
>     Cc: Solomon Peachy <pizza@shaftnet.org>
>     Cc: Song Liu <songliubraving@fb.com>
>     Cc: Stefan Schmidt <stefan@datenfreihafen.org>
>     Cc: Stefano Stabellini <sstabellini@kernel.org>
>     Cc: Stephen Boyd <sboyd@kernel.org>
>     Cc: Steven Rostedt <rostedt@goodmis.org>
>     Cc: Takashi Iwai <tiwai@suse.com>
>     Cc: Thomas Gleixner <tglx@linutronix.de>
>     Cc: Todor Tomov <todor.too@gmail.com>
>     Cc: Tony Lindgren <tony@atomide.com>
>     Cc: VMware PV-Drivers <pv-drivers@vmware.com>
>     Cc: Vaibhav Agarwal <vaibhav.sr@gmail.com>
>     Cc: Vinod Koul <vkoul@kernel.org>
>     Cc: Vivien Didelot <vivien.didelot@gmail.com>
>     Cc: Vladimir Oltean <olteanv@gmail.com>
>     Cc: Will Deacon <will@kernel.org>
>     Cc: Xinming Hu <huxinming820@gmail.com>
>     Cc: Xue Liu <liuxuenetmail@gmail.com>
>     Cc: Yehezkel Bernat <YehezkelShB@gmail.com>
>     Cc: Ying Xue <ying.xue@windriver.com>
>     Cc: Yonghong Song <yhs@fb.com>
>     Cc: alsa-devel@alsa-project.org
>     Cc: amd-gfx@lists.freedesktop.org
>     Cc: bpf@vger.kernel.org
>     Cc: brcm80211-dev-list.pdl@broadcom.com
>     Cc: clang-built-linux@googlegroups.com
>     Cc: coreteam@netfilter.org
>     Cc: dev@openvswitch.org
>     Cc: dm-devel@redhat.com
>     Cc: dmaengine@vger.kernel.org
>     Cc: dri-devel@lists.freedesktop.org
>     Cc: ecryptfs@vger.kernel.org
>     Cc: greybus-dev@lists.linaro.org
>     Cc: intel-wired-lan@lists.osuosl.org
>     Cc: iommu@lists.linux-foundation.org
>     Cc: kvm@vger.kernel.org
>     Cc: libertas-dev@lists.infradead.org
>     Cc: linux-acpi@vger.kernel.org
>     Cc: linux-afs@lists.infradead.org
>     Cc: linux-arm-kernel@lists.infradead.org
>     Cc: linux-arm-msm@vger.kernel.org
>     Cc: linux-aspeed@lists.ozlabs.org
>     Cc: linux-atm-general@lists.sourceforge.net
>     Cc: linux-audit@redhat.com
>     Cc: linux-clk@vger.kernel.org
>     Cc: linux-edac@vger.kernel.org
>     Cc: linux-efi@vger.kernel.org
>     Cc: linux-fbdev@vger.kernel.org
>     Cc: linux-gpio@vger.kernel.org
>     Cc: linux-hams@vger.kernel.org
>     Cc: linux-hwmon@vger.kernel.org
>     Cc: linux-iio@vger.kernel.org
>     Cc: linux-input@vger.kernel.org
>     Cc: linux-kernel@vger.kernel.org
>     Cc: linux-leds@vger.kernel.org
>     Cc: linux-media@vger.kernel.org
>     Cc: linux-mmc@vger.kernel.org
>     Cc: linux-nfc@lists.01.org
>     Cc: linux-nfs@vger.kernel.org
>     Cc: linux-nvdimm@lists.01.org
>     Cc: linux-nvidia@lists.surfsouth.com
>     Cc: linux-omap@vger.kernel.org
>     Cc: linux-pci@vger.kernel.org
>     Cc: linux-pm@vger.kernel.org
>     Cc: linux-raid@vger.kernel.org
>     Cc: linux-rdma@vger.kernel.org
>     Cc: linux-renesas-soc@vger.kernel.org
>     Cc: linux-rockchip@lists.infradead.org
>     Cc: linux-rtc@vger.kernel.org
>     Cc: linux-s390@vger.kernel.org
>     Cc: linux-samsung-soc@vger.kernel.org
>     Cc: linux-scsi@vger.kernel.org
>     Cc: linux-serial@vger.kernel.org
>     Cc: linux-spi@vger.kernel.org
>     Cc: linux-staging@lists.linux.dev
>     Cc: linux-stm32@st-md-mailman.stormreply.com
>     Cc: linux-sunxi@lists.linux.dev
>     Cc: linux-tegra@vger.kernel.org
>     Cc: linux-usb@vger.kernel.org
>     Cc: linux-wireless@vger.kernel.org
>     Cc: linux-wpan@vger.kernel.org
>     Cc: netdev@vger.kernel.org
>     Cc: netfilter-devel@vger.kernel.org
>     Cc: nouveau@lists.freedesktop.org
>     Cc: ocfs2-devel@oss.oracle.com
>     Cc: open-iscsi@googlegroups.com
>     Cc: oss-drivers@netronome.com
>     Cc: patches@opensource.cirrus.com
>     Cc: qemu-devel@nongnu.org
>     Cc: rds-devel@oss.oracle.com
>     Cc: target-devel@vger.kernel.org
>     Cc: tipc-discussion@lists.sourceforge.net
>     Cc: usb-storage@lists.one-eyed-alien.net
>     Cc: x86@kernel.org
>     Cc: xen-devel@lists.xenproject.org
> Number of Cc at cover: 221
> 
> 

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-23 16:03                   ` Mark Brown
@ 2021-04-23 17:12                     ` Leon Romanovsky
  2021-04-26 23:50                       ` Simon Glass
  0 siblings, 1 reply; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-23 17:12 UTC (permalink / raw)
  To: Mark Brown
  Cc: Doug Anderson, Mauro Carvalho Chehab, Joe Perches, Rob Herring,
	Steven Rostedt, James Bottomley, ksummit, tools, Simon Glass

On Fri, Apr 23, 2021 at 05:03:10PM +0100, Mark Brown wrote:
> On Fri, Apr 23, 2021 at 07:52:30AM -0700, Doug Anderson wrote:
> 
> > I know it's nearly impossible to get people to change their workflows,
> > but if you're open to it I definitely suggest giving it a try. Simon
> > Glass (the original author) is also quite receptive to improvements.
> 
> I have something broadly similar (much more simplistic and overall less
> capable) which I wrote myself - the things I have that this doesn't have
> are:
> 
>  - Attesting the outgoing patches with b4.
>  - Tagging the published series in git.

I have something similar too, which actually wrapper over git format-patch
that properly set target (net-next, rdma-next, iproute2, rdma-core, mlx5-next
e.t.c) and changes "To;" based on target.

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  9:06                     ` Mauro Carvalho Chehab
@ 2021-04-23 17:17                       ` Leon Romanovsky
  2021-04-23 22:41                       ` Shuah Khan
  1 sibling, 0 replies; 153+ messages in thread
From: Leon Romanovsky @ 2021-04-23 17:17 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Shuah Khan, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit

On Fri, Apr 23, 2021 at 11:06:43AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:38:03 -0600
> Shuah Khan <skhan@linuxfoundation.org> escreveu:
> 
> > On 4/22/21 6:18 AM, Leon Romanovsky wrote:
> > > On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:  
> > >> Em Thu, 22 Apr 2021 09:34:38 +0200
> > >> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
> > >>  
> > >>> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:  
> > >>>> On Wed, 21 Apr 2021, Julia Lawall wrote:  
> > >>>>> The apology states that they didn't detect any vulnerabilities.  They
> > >>>>> found three non exploitable bugs and submitted incorrect patches for them.
> > >>>>> When the patches received some positive feedback, they explained that the
> > >>>>> patches were incorrect and provided a proper fix.
> > >>>>>
> > >>>>> So they damaged trust, but not actually the Linux kernel...  
> > >>>>
> > >>>> The issue is that there was no consent and no coordination, so we don't
> > >>>> know the scope of the experiment and whether it was still continuing.
> > >>>>
> > >>>> We are this not able to trust anything the group said about what they'd
> > >>>> done or not done, until now [1].
> > >>>>
> > >>>> In all probability there is nothing further amiss but we would not have
> > >>>> expected them to use fake gmail accounts to submit bugs to the kernel
> > >>>> either.
> > >>>>
> > >>>> It's now on us to audit all of their known contributions, because we don't
> > >>>> know the scope of the experiment, which was based on the use of deception,
> > >>>> and we can't make any assumptions based on what they have said.
> > >>>>
> > >>>> We also need the identity of the 'random' gmail accounts they used,
> > >>>> although this should be handled by a small trusted group in private, as it
> > >>>> will lead to privacy issues for kernel maintainers who responded to them
> > >>>> in public.  
> > >>>
> > >>> What do we gain by blindly reverting all[1] umn.edu patches, and
> > >>> ignoring future patches from umn.edu?
> > >>> I think all of this is moot: other people may be doing the same thing,
> > >>> or even "in worse faith".  The only thing that helps is making sure
> > >>> patches get reviewed[2] before being applied.
> > >>>
> > >>> [1] Judging from the new review comments, many of the 190 patches
> > >>>      to be reverted were real fixes.  
> > >>
> > >> The reverted ones for media (29 patches) didn't contain any malicious code.
> > >> One was useless (because the media core already fixes the pointed issue),
> > >> but the other ones were valid patches.  
> > > 
> > > I'm sorry that I didn't check all media commits, but this random commit
> > > 467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
> > > broke sp8870 (I don't know what is it).
> > > 
> > > diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
> > > index 8d31cf3f4f07..270a3c559e08 100644
> > > --- a/drivers/media/dvb-frontends/sp8870.c
> > > +++ b/drivers/media/dvb-frontends/sp8870.c
> > > @@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
> > >          sp8870_writereg(state, 0xc05, reg0xc05);
> > > 
> > >          // read status reg in order to clear pending irqs
> > > -       sp8870_readreg(state, 0x200);
> > > +       err = sp8870_readreg(state, 0x200);
> > > +       if (err)
> > > +               return err;
> > > 
> > >          // system controller start
> > >          sp8870_microcontroller_start(state);
> > > 
> > > 
> > >     67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
> > >     68 {
> > >     69         int ret;
> > >   <...>
> > >     77         if (ret != 2) {
> > >     78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
> > >     79                 return -1;
> > >     80         }
> > >     81
> > >     82         return (b1[0] << 8 | b1[1]);
> > >     83 }
> > > 
> > > The valid check should be if (err < 0);
> > >   
> > 
> > Correct. Like all the other callers of sp8870_readreg() do with
> > its return. Non-zero return is valid for this routine.
> 
> This particular patch is completely broken and should be reverted.

This is exactly the point, many patches from @umn are broken and the
right way to check them is to checkout to the time when they were
introduced.

I just wanted to show you that you claim about validity of patches is
not accurate.

"The reverted ones for media (29 patches) didn't contain any malicious code.
 One was useless (because the media core already fixes the pointed issue),
 out the other ones were valid patches."

Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  7:31       ` Christian Brauner
@ 2021-04-23 18:50         ` Konstantin Ryabitsev
  0 siblings, 0 replies; 153+ messages in thread
From: Konstantin Ryabitsev @ 2021-04-23 18:50 UTC (permalink / raw)
  To: Christian Brauner
  Cc: Mauro Carvalho Chehab, Leon Romanovsky, James Bottomley, ksummit

On Fri, Apr 23, 2021 at 09:31:20AM +0200, Christian Brauner wrote:
> > If you're a mutt user, you can set up a keybinding, e.g.:
> > 
> >     macro index 4 "<pipe-message>~/work/git/korg/b4/b4.sh mbox -f -o ~/Mail<return>"
> > 
> > You'll need to adjust it to point at where your maildir lives, of course, but
> > that's the general idea. With it in place, you can hit "4" in the index view
> > to get the rest of the thread (without duplicating the messages you already
> > have).
> 
> I do currently have three keybindings:
> 
> macro index,pager A "<pipe-message>b4 am -t -l -s -g -c -C -Q <enter>"
> macro index,pager S "<pipe-message>b4 am -t -c -Q <enter>"
> macro index,pager M "<pipe-message>b4 mbox <enter>"
> 
> The -f switch is new, right?

Relatively so, yes. Note, that it shouldn't be used on huge inboxes, as it
will have to go through each message in the maildir to collect message-ids
that are already present.

-K

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches
  2021-04-23  9:06                     ` Mauro Carvalho Chehab
  2021-04-23 17:17                       ` Leon Romanovsky
@ 2021-04-23 22:41                       ` Shuah Khan
  1 sibling, 0 replies; 153+ messages in thread
From: Shuah Khan @ 2021-04-23 22:41 UTC (permalink / raw)
  To: Mauro Carvalho Chehab
  Cc: Leon Romanovsky, Geert Uytterhoeven, James Morris, Julia Lawall,
	Stephen Hemminger, Roland Dreier, Steven Rostedt,
	James Bottomley, ksummit, Shuah Khan

On 4/23/21 3:06 AM, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:38:03 -0600
> Shuah Khan <skhan@linuxfoundation.org> escreveu:
> 
>> On 4/22/21 6:18 AM, Leon Romanovsky wrote:
>>> On Thu, Apr 22, 2021 at 11:55:11AM +0200, Mauro Carvalho Chehab wrote:
>>>> Em Thu, 22 Apr 2021 09:34:38 +0200
>>>> Geert Uytterhoeven <geert@linux-m68k.org> escreveu:
>>>>   
>>>>> On Wed, Apr 21, 2021 at 11:50 PM James Morris <jmorris@namei.org> wrote:
>>>>>> On Wed, 21 Apr 2021, Julia Lawall wrote:
>>>>>>> The apology states that they didn't detect any vulnerabilities.  They
>>>>>>> found three non exploitable bugs and submitted incorrect patches for them.
>>>>>>> When the patches received some positive feedback, they explained that the
>>>>>>> patches were incorrect and provided a proper fix.
>>>>>>>
>>>>>>> So they damaged trust, but not actually the Linux kernel...
>>>>>>
>>>>>> The issue is that there was no consent and no coordination, so we don't
>>>>>> know the scope of the experiment and whether it was still continuing.
>>>>>>
>>>>>> We are this not able to trust anything the group said about what they'd
>>>>>> done or not done, until now [1].
>>>>>>
>>>>>> In all probability there is nothing further amiss but we would not have
>>>>>> expected them to use fake gmail accounts to submit bugs to the kernel
>>>>>> either.
>>>>>>
>>>>>> It's now on us to audit all of their known contributions, because we don't
>>>>>> know the scope of the experiment, which was based on the use of deception,
>>>>>> and we can't make any assumptions based on what they have said.
>>>>>>
>>>>>> We also need the identity of the 'random' gmail accounts they used,
>>>>>> although this should be handled by a small trusted group in private, as it
>>>>>> will lead to privacy issues for kernel maintainers who responded to them
>>>>>> in public.
>>>>>
>>>>> What do we gain by blindly reverting all[1] umn.edu patches, and
>>>>> ignoring future patches from umn.edu?
>>>>> I think all of this is moot: other people may be doing the same thing,
>>>>> or even "in worse faith".  The only thing that helps is making sure
>>>>> patches get reviewed[2] before being applied.
>>>>>
>>>>> [1] Judging from the new review comments, many of the 190 patches
>>>>>       to be reverted were real fixes.
>>>>
>>>> The reverted ones for media (29 patches) didn't contain any malicious code.
>>>> One was useless (because the media core already fixes the pointed issue),
>>>> but the other ones were valid patches.
>>>
>>> I'm sorry that I didn't check all media commits, but this random commit
>>> 467a37fba93f ("media: dvb: Add check on sp8870_readreg") has a bug and
>>> broke sp8870 (I don't know what is it).
>>>
>>> diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
>>> index 8d31cf3f4f07..270a3c559e08 100644
>>> --- a/drivers/media/dvb-frontends/sp8870.c
>>> +++ b/drivers/media/dvb-frontends/sp8870.c
>>> @@ -293,7 +293,9 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
>>>           sp8870_writereg(state, 0xc05, reg0xc05);
>>>
>>>           // read status reg in order to clear pending irqs
>>> -       sp8870_readreg(state, 0x200);
>>> +       err = sp8870_readreg(state, 0x200);
>>> +       if (err)
>>> +               return err;
>>>
>>>           // system controller start
>>>           sp8870_microcontroller_start(state);
>>>
>>>
>>>      67 static int sp8870_readreg (struct sp8870_state* state, u16 reg)
>>>      68 {
>>>      69         int ret;
>>>    <...>
>>>      77         if (ret != 2) {
>>>      78                 dprintk("%s: readreg error (ret == %i)\n", __func__, ret);
>>>      79                 return -1;
>>>      80         }
>>>      81
>>>      82         return (b1[0] << 8 | b1[1]);
>>>      83 }
>>>
>>> The valid check should be if (err < 0);
>>>    
>>
>> Correct. Like all the other callers of sp8870_readreg() do with
>> its return. Non-zero return is valid for this routine.
> 
> This particular patch is completely broken and should be reverted.
> Also, probably a comment should be added to ensure that people won't
> try to send us similar "trivial" fixes.
> 
> Basically, the logic at sp8870_set_frontend_parameters() is called
> when tuning into a new DVB-T channel. the call there for
> 
> 		sp8870_readreg(state, 0x200);
> 
> Seems to be there just to reset IRQ registers. It should _not_ check
> the return results on this particular case.
> 
> Yet, this driver was written back in 1999 for a DVB-T device that
> used to be available on that time. Just one driver (av7110) can
> use such tuner. Those PCI chipsets had stopped produced a very long
> time ago. Even the company that used to produce av7110 has long
> gone, more than 17 years ago.
> 
> I guess it is time to get rid of av7110 and the ancillary drivers
> used only on it.
> 

Mauro,

Quick search shows me the following. Are you saying all of these
can be removed??

drivers/media/dvb-frontends/Kconfig
config DVB_SP8870

grep AV7 drivers/media/pci/ttpci/Kconfig

config DVB_AV7110_IR
	depends on RC_CORE=y || RC_CORE = DVB_AV7110
	default DVB_AV7110
config DVB_AV7110
	tristate "AV7110 cards"
	  Support for SAA7146 and AV7110 based DVB cards as produced
config DVB_AV7110_OSD
	bool "AV7110 OSD support"
	depends on DVB_AV7110
	default y if DVB_AV7110=y || DVB_AV7110=m
	  The AV7110 firmware provides some code to generate an OnScreenDisplay
	tristate "AV7110 cards with Budget Patch"
	depends on DVB_AV7110
	  SAA7146+AV7110 based cards (DVB-S cards). This
	  standard AV7110 driver prior to loading this

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Re: Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-23 17:12                     ` Leon Romanovsky
@ 2021-04-26 23:50                       ` Simon Glass
  0 siblings, 0 replies; 153+ messages in thread
From: Simon Glass @ 2021-04-26 23:50 UTC (permalink / raw)
  To: Leon Romanovsky
  Cc: Mark Brown, Doug Anderson, Mauro Carvalho Chehab, Joe Perches,
	Rob Herring, Steven Rostedt, James Bottomley, ksummit, tools

Hi,

The docs are on github also :
https://github.com/siemens/u-boot/blob/master/tools/patman/README

I find it relatively easy to update each patch with a little change
log as I change it. Then I know that when I type 'patman send' it will
do the right thing.

If people have workflows that would benefit from patman's help, but
need it to do an extra thing, I certainly accept patches to the tool.

Regards,
Simon

On Sat, 24 Apr 2021 at 03:12, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Fri, Apr 23, 2021 at 05:03:10PM +0100, Mark Brown wrote:
> > On Fri, Apr 23, 2021 at 07:52:30AM -0700, Doug Anderson wrote:
> >
> > > I know it's nearly impossible to get people to change their workflows,
> > > but if you're open to it I definitely suggest giving it a try. Simon
> > > Glass (the original author) is also quite receptive to improvements.
> >
> > I have something broadly similar (much more simplistic and overall less
> > capable) which I wrote myself - the things I have that this doesn't have
> > are:
> >
> >  - Attesting the outgoing patches with b4.
> >  - Tagging the published series in git.
>
> I have something similar too, which actually wrapper over git format-patch
> that properly set target (net-next, rdma-next, iproute2, rdma-core, mlx5-next
> e.t.c) and changes "To;" based on target.
>
> Thanks

^ permalink raw reply	[flat|nested] 153+ messages in thread

* Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches)
  2021-04-22 22:53           ` Laurent Pinchart
@ 2021-07-20 16:26             ` Daniel Vetter
  0 siblings, 0 replies; 153+ messages in thread
From: Daniel Vetter @ 2021-07-20 16:26 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: Thomas Gleixner, Al Viro, Christoph Hellwig, Roland Dreier,
	Steven Rostedt, James Bottomley, ksummit

Since I've just made myself popular again with the drivers/gpu merge
criteria I figured good time to dig this out from the big thread as a
separate topic. I entirely missed this interesting topic which was
unfortunately deeply burried in something I don't care a whole lot about
:-)

On Fri, Apr 23, 2021 at 12:53 AM Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> On Fri, Apr 23, 2021 at 12:35:02AM +0200, Thomas Gleixner wrote:
> > On Thu, Apr 22 2021 at 18:03, Al Viro wrote:
> > > On Thu, Apr 22, 2021 at 06:59:48AM +0100, Christoph Hellwig wrote:
> > >> On Wed, Apr 21, 2021 at 12:32:33PM -0700, Roland Dreier wrote:
> > >> > I also think there does need to be a strong sanction against this UMN
> > >> > research group, since we need to make sure there are strong incentives
> > >> > against wasting everyone's time with stunts like this.  Hopefully on
> > >> > the academic side it can be made clear that this is not ethical
> > >> > research - for example, why did IEEE think this was an acceptable
> > >> > paper?
> > >>
> > >> I wholeheartedly disagree.  Demonstrating this kind of "attack" has
> > >> been long overdue, and kicked off a very important discussion.  Even
> > >> more so as in this area malice is almost indistinguishable from normal
> > >> incompetence.  I think they deserve a medel of honor.
> > >
> > > Demonstrating this kind of attack would be very useful, if they bothered to
> > > provide the raw data and their protocol.
> > >
> > > They'd done neither, AFAICS.  There's no way to actually look at how the
> > > submissions went, timings, etc.  We are offered what could (very generously)
> > > be called aggregate stats illustrating the problems, along with bloody
> > > worthless suggestions of improvements.  Use of the technics in question
> > > is not limited to introducing UAF bugs; it's certainly possible to use
> > > a (real or not) UAF bug as an excuse to get in something designed _not_
> > > to be caught by any of their suggested scler^Whardening patches, etc.
> > >
> > > There certainly are very real problems with review process, and examining
> > > their data might provide useful insights - had any of that data been
> > > given.
> >
> > I agree.
> >
> > Though the most important takeaway for me is that this demonstrated the
> > problems which the kernel development has - once more.
> >
> > What's worse is that it's known for quite some time that the kernel
> > development is understaffed and cannot keep up with the influx of
> > patches. Of course this has been willfully ignored - similar to other
> > completely avoidable horrors like the ssl disaster.
> >
> > There is a long list of issues which lead to that situation, but let me
> > pick a few really important ones:
> >
> >   - The 'features and performance first, correctness maybe' mentality in
> >     this industry.
> >
> >   - The ignorance which takes the availability and sustainability of
> >     FOSS components especially "low-level plumbing" ones for granted,
> >     even if their business is built on and depends on these.
> >
> >   - The unwillingness to put money on basic "low-level" technology just
> >     because it does not come with the 'hype-of-the-day' tag and is
> >     therefore useless for marketing and headlines.
> >
> > None of these things can be solved at the technical level. There is no
> > technical solution which solves problems at the human stupidity and
> > even less so at the greed level.
> >
> > While in theory the approach of sharing the workload for base technology
> > is obviously the right thing to do, the reality tells that sharing is
> > interpreted as make sure that someone else pays for it and I can push my
> > feature agenda.
>
> I'd like to point out explicitly that this issue isn't limited to
> "low-level" or "core" technology. On the driver side, it feels more
> often than not that the community is used as a dumping ground for BSP
> core of dubious quality, when that code isn't just kept out-of-tree
> altogether. I wouldn't necessarily blame greed in all cases, as I've
> seen vendors who are willing to do the right thing but don't know what
> it would be (what we take for granted as being obvious seems not to be
> so for a large number of people who are not all stupid :-)).
>
> While I may not be fully convinced by all the details of the experiment,
> I think there's something to be learnt from how DRM/KMS handles
> contributors, and how they've managed to get many contributors from the
> industry to get and stay involved at the subsystem level in the longer
> term. I'm sure there can be other initiatives I'm not aware of.

I'm not sure our commit rights stuff helps a lot with getting vendors in.
It helps maybe with load-balancing the maintainer/review roles better
among volunteers and anyone who can cut away a bit of time here and there
to help out with subsystem stuff.

> > As long as that does not change, nothing will change.
> >
> > We can put technical countermeasures (as discussed elsewhere in this
> > thread) in place as much as we want, they are just futile attempts which
> > try to cure the symptoms.
> >
> > As technical people we all know how useful the approach of curing the
> > symptoms instead of the root cause is. But still we try to do that
> > because we think it's our only option.
> >
> > It's about time to rethink that approach.
>
> Amen. Incentives to contribute in the right way need to be higher, and
> depending on the vendors, this can be carrot, stick, or both.

So much.

Now as much as it's unpopular, the drivers/gpu merge criteria of
"userspace must be open source and ready for merging into relevant
upstream userspace project" is a really big stick here. It keeps all the
dump&run vendor contributions out, and any company that seriously
considers this path will spend a few years building up a team (which means
hiring existing people and consulting companies for training and ramp-up)
or just pay for the work to get done. Because tossing your entire
userspace space and creating a new one based on our upstream stack is not
a light undertaking at all for a gpu driver.

The downside is that there's a continual stream of "if you'd just merge
more gpu drivers it would be so much better for you and help get vendors
on board" style complaints, but I don't buy that. We'd definitely get more
code (some 10x for the same functionality), and it would be a lot more
crap. Plus, there'd be a lot less money floating around  to pay for
maintainance and improvement of the shared code and infrastructure.

It is more or less flat out extortion, but then nothing else seems to
avoid the tragedy of the commons.

I guess the plus side is that it's not extortion by a single entity that
holds the keys to the castle, but it's collective. If a vendor shows up
with a dump&run proposal they can talk to all the various maintainers we
have and try to enlist all the various consulting shops active in this
area, and the answer tends to be the same across the board.

Overall I think to make sure a subsystem is somewhat sustainable you need
a really big stick to force vendors to contribute in the right
(sustainable) way. The important part is to make sure the stick isn't just
bureaucracy to make it painful for everyone, so that you still have a
carrot left for the people who do get it and want to contribute properly.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

^ permalink raw reply	[flat|nested] 153+ messages in thread

end of thread, other threads:[~2021-07-20 16:26 UTC | newest]

Thread overview: 153+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-21 18:35 [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches James Bottomley
2021-04-21 18:46 ` Christian Borntraeger
2021-04-21 18:51 ` Alexey Dobriyan
2021-04-21 18:53   ` Christian Borntraeger
2021-04-21 19:06 ` Al Viro
2021-04-21 19:14 ` James Bottomley
2021-04-21 19:22 ` Steven Rostedt
2021-04-21 19:26   ` Kees Cook
2021-04-21 19:32   ` Roland Dreier
2021-04-21 19:55     ` Julia Lawall
2021-04-21 20:28       ` Stephen Hemminger
2021-04-21 20:37         ` Julia Lawall
2021-04-21 20:45           ` Steven Rostedt
2021-04-21 20:50             ` Julia Lawall
2021-04-21 21:03               ` Jiri Kosina
2021-04-21 21:37           ` James Morris
2021-04-22  7:34             ` Geert Uytterhoeven
2021-04-22  7:51               ` Mike Rapoport
2021-04-22  8:45                 ` Christian Brauner
2021-04-22 15:27                   ` Steven Rostedt
2021-04-22  9:39                 ` Mauro Carvalho Chehab
2021-04-22  9:55               ` Mauro Carvalho Chehab
2021-04-22 12:01                 ` Leon Romanovsky
2021-04-22 12:26                   ` Mark Brown
2021-04-22 12:35                     ` Leon Romanovsky
2021-04-22 12:52                       ` Hans Verkuil
2021-04-22 13:33                       ` Mauro Carvalho Chehab
2021-04-22 13:42                         ` Leon Romanovsky
2021-04-22 12:18                 ` Leon Romanovsky
2021-04-22 15:38                   ` Shuah Khan
2021-04-23  9:06                     ` Mauro Carvalho Chehab
2021-04-23 17:17                       ` Leon Romanovsky
2021-04-23 22:41                       ` Shuah Khan
2021-04-22  5:59     ` Christoph Hellwig
2021-04-22  6:28       ` Tomasz Figa
2021-04-22  7:05         ` Al Viro
2021-04-22  7:46           ` Al Viro
2021-04-22  7:06         ` H. Peter Anvin
2021-04-22  7:05       ` Jiri Kosina
2021-04-22 16:05       ` Roland Dreier
2021-04-22 16:24         ` Krzysztof Kozlowski
2021-04-22 18:03       ` Al Viro
2021-04-22 22:35         ` Thomas Gleixner
2021-04-22 22:53           ` Laurent Pinchart
2021-07-20 16:26             ` Kernel sustainability (was Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Daniel Vetter
2021-04-21 19:30 ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Jiri Kosina
2021-04-21 20:28   ` Jiri Kosina
2021-04-21 22:18     ` Shuah Khan
2021-04-21 23:17       ` Guenter Roeck
2021-04-21 23:21         ` Shuah Khan
2021-04-21 19:47 ` Dan Carpenter
2021-04-22  9:34   ` Mauro Carvalho Chehab
2021-04-22  9:59     ` Johannes Berg
2021-04-22 10:52       ` Mauro Carvalho Chehab
2021-04-22 12:16         ` Mike Rapoport
2021-04-22 13:41           ` Mauro Carvalho Chehab
2021-04-22 20:15       ` Alexandre Belloni
2021-04-23  0:09         ` Randy Dunlap
2021-04-21 19:49 ` Alexandre Belloni
2021-04-22  2:05 ` Martin K. Petersen
2021-04-22  3:04   ` Joe Perches
2021-04-22 10:13     ` Mauro Carvalho Chehab
2021-04-22 12:07     ` Mark Brown
2021-04-22 16:42     ` Bart Van Assche
2021-04-22 17:58       ` Jiri Kosina
2021-04-22  4:21 ` Leon Romanovsky
2021-04-22  4:56   ` Al Viro
2021-04-22  5:52     ` Leon Romanovsky
2021-04-22  6:05     ` Christoph Hellwig
2021-04-22  6:03   ` Christoph Hellwig
2021-04-22  6:18     ` Leon Romanovsky
2021-04-22  9:20   ` Mauro Carvalho Chehab
2021-04-22 11:34     ` Leon Romanovsky
2021-04-22 13:22       ` Mark Brown
2021-04-22 13:47         ` Leon Romanovsky
2021-04-22 13:51           ` Mark Brown
2021-04-22 14:12         ` Mauro Carvalho Chehab
2021-04-22 14:51           ` Leon Romanovsky
2021-04-22 13:29       ` Steven Rostedt
2021-04-22 13:58         ` Leon Romanovsky
2021-04-22 14:20         ` Rob Herring
2021-04-23  6:04           ` Mauro Carvalho Chehab
2021-04-23  6:46             ` Joe Perches
2021-04-23  7:13               ` Mauro Carvalho Chehab
2021-04-23  7:20                 ` [PATCH RFC] scripts: add a script for sending patches Mauro Carvalho Chehab
2021-04-23 14:52                 ` Better tools for sending patches (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Doug Anderson
2021-04-23 16:03                   ` Mark Brown
2021-04-23 17:12                     ` Leon Romanovsky
2021-04-26 23:50                       ` Simon Glass
2021-04-22 12:53     ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Konstantin Ryabitsev
2021-04-22 13:08       ` Leon Romanovsky
2021-04-22 13:27         ` Konstantin Ryabitsev
2021-04-22 13:41           ` Leon Romanovsky
2021-04-22 16:28           ` Serge E. Hallyn
2021-04-22 17:56       ` Leon Romanovsky
2021-04-22 18:05         ` backfilling threads with b4 (was: Re: [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches) Konstantin Ryabitsev
2021-04-23  7:19       ` [MAINTAINER SUMMIT] Rethinking the acceptance policy for "trivial" patches Greg KH
2021-04-23  7:31       ` Christian Brauner
2021-04-23 18:50         ` Konstantin Ryabitsev
2021-04-22 12:40   ` Mark Brown
2021-04-22 12:54     ` Mike Rapoport
2021-04-22 13:23       ` Mark Brown
2021-04-22 15:19         ` Steven Rostedt
2021-04-22 21:19           ` Thomas Gleixner
2021-04-22 21:36             ` Steven Rostedt
2021-04-22 22:39               ` Thomas Gleixner
2021-04-23  0:26                 ` Joe Perches
2021-04-23  6:15           ` Greg KH
2021-04-23  6:50             ` Dan Williams
2021-04-23  7:13             ` Geert Uytterhoeven
2021-04-23 14:41               ` Shuah Khan
2021-04-23  9:12             ` Michal Hocko
2021-04-22 14:51       ` Laurent Pinchart
2021-04-22 15:14         ` Mike Rapoport
2021-04-22 15:17           ` Laurent Pinchart
2021-04-22 15:35             ` Al Viro
2021-04-22 15:32           ` Shuah Khan
2021-04-22 10:35 ` Mauro Carvalho Chehab
2021-04-22 11:03   ` Sudip Mukherjee
2021-04-22 14:00     ` Steven Rostedt
2021-04-22 14:07       ` Jiri Kosina
2021-04-22 15:31         ` Sudip Mukherjee
2021-04-22 21:33           ` Thomas Gleixner
2021-04-22 20:28     ` Andrew Morton
2021-04-22 20:46       ` Steven Rostedt
2021-04-22 12:32   ` Martin K. Petersen
2021-04-22 15:11     ` Laurent Pinchart
2021-04-22 15:28     ` James Bottomley
2021-04-22 15:35       ` Johannes Berg
2021-04-22 15:36       ` Mark Brown
2021-04-22 15:40         ` James Bottomley
2021-04-23  9:27         ` Dan Carpenter
2021-04-22 13:24   ` Konstantin Ryabitsev
2021-04-22 14:31     ` Mauro Carvalho Chehab
2021-04-22 15:34   ` Shuah Khan
2021-04-22 15:42     ` James Bottomley
2021-04-22 15:48       ` James Bottomley
2021-04-22 15:52         ` Steven Rostedt
2021-04-22 16:08           ` Shuah Khan
2021-04-22 16:13           ` Jan Kara
2021-04-22 17:04             ` Steven Rostedt
2021-04-22 17:08             ` Martin K. Petersen
2021-04-23 11:16               ` Jan Kara
2021-04-23 12:57                 ` Mauro Carvalho Chehab
2021-04-23  7:58           ` Mauro Carvalho Chehab
2021-04-23 10:54             ` Greg KH
2021-04-23 17:09             ` Leon Romanovsky
2021-04-22 16:23         ` Konstantin Ryabitsev
2021-04-22 16:38       ` Bart Van Assche
2021-04-22 16:57         ` Leon Romanovsky
2021-04-22 18:03         ` Jiri Kosina
2021-04-22 21:26           ` Thomas Gleixner
2021-04-22 21:36             ` Jiri Kosina

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox