linux-kernel - Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and managed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Oct 2018 01:39:18 -0700
From:   Joe Perches <joe@...ches.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Arun KS <arunks@...eaurora.org>, Kees Cook <keescook@...omium.org>,
        Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>, Minchan Kim <minchan@...nel.org>,
        Arun Sudhilal <getarunks@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] mm: convert totalram_pages, totalhigh_pages and
 managed_pages to atomic.

On Wed, 2018-10-24 at 10:23 +0200, Michal Hocko wrote:
> On Tue 23-10-18 23:26:16, Joe Perches wrote:
> > On Wed, 2018-10-24 at 08:15 +0200, Michal Hocko wrote:
> > > On Wed 24-10-18 10:47:52, Arun KS wrote:
> > > > On 2018-10-24 01:34, Kees Cook wrote:
> > > [...]
> > > > > Thank you -- I was struggling to figure out the best way to reply to
> > > > > this. :)
> > > > I'm sorry for the trouble caused. Sent the email using,
> > > > git send-email  --to-cmd="scripts/get_maintainer.pl -i"
> > > > 0001-convert-totalram_pages-totalhigh_pages-and-managed_p.patch
> > > > 
> > > > Is this not a recommended approach?
> > > 
> > > Not really for tree wide mechanical changes. It is much more preferrable
> > > IMHO to only CC people who should review the intention of the change
> > > rather than each and every maintainer whose code is going to be changed.
> > > This is a case by case thing of course but as soon as you see a giant CC
> > > list from get_maintainer.pl then you should try to think twice to use
> > > it. If not sure, just ask on the mailing list.
> > 
> > Generally, it's better to use scripts to control
> > the --to-cmd and --cc-cmd options.
> 
> I would argue that it is better to use a common sense much more than
> scripts.

Common sense isn't common.

Perhaps you could describe some guidelines you
use to determine what you think is sensible to
send patches to maintainers and reviewers and
appropriate mailing lists.

Then compare those to the rules in the scripts
I suggested.

My suggestions:

o send to all top-level listed maintainers and
  reviewers in MAINTAINERS for the specific files
  in a patch
o cc all maintainers and reviewers that are upstream
  paths for the files in a patch
o cc all the upstream mailing lists for the files
  in the patch.
o do not generally use git-history to exclude authors
  of patches like drive-by/whitespace cleanups

Other advanced possibilities for patches that
modify specific and perhaps complex logic blocks:

o cc the people that are not maintainers that
  have modified the specific blocks or functions