linux-kernel - Re: [RESEND][PATCH] bug: Exclude non-BUG/WARN exceptions from report

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]

Message-ID: <CA+55aFzG6od5cy_mmepygSb_9m3Em336T00LoOK-MVkVPsJ-hg@mail.gmail.com>
Date:   Fri, 2 Mar 2018 10:53:07 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        Richard Weinberger <richard.weinberger@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RESEND][PATCH] bug: Exclude non-BUG/WARN exceptions from report_bug()

On Thu, Mar 1, 2018 at 2:59 PM, Kees Cook <keescook@...omium.org> wrote:
>
> Resending through akpm since this technically isn't x86-specific.

Just a note on this part, because I think this is a general issue (and
has nothing to do with the particular patch itself).

Saying who you expect things to go through can definitely be a good
idea, because I generally ignore patches that get sent to me from
people I take pull requests from - I assume that I'm on the
participants list as a heads-up for for comments, rather than
applying. In fact, even if you don't send me pull requests, that's
generally what I assume, because the bulk of patches should be going
through some submaintainer that _does_ send me pull requests (or, like
Andrew, is known to send patches).

I'd expect that many other people face the same issue - particularly
when a patch doesn't have a very clear area, and there are multiple
people on the participants list, it's easy to assume that the intended
target is "somebody else". I do not, for example, tend to look at my
emails so closely that I care who is in the "To:" field, and who is in
the "Cc:" fields. I'd have to be very curious indeed to care that
deeply.

Which brings me to my point: maybe we should encourage people to make
this "for whom the patch tolls" information more obvious and more
explicit. It wasn't obvious in the first submission (yes, I saw the
patch then too), and even in this second one I actually initially
didn't notice this one line in between the commit message and the
actual patch. Maybe I get too much email, but I bet _that_ is very
true of others too.

The obvious place to encourage people to do it is in the [PATCH] part
in the subject, ie something like [PATCH/mm] or similar if you expect
it to go through Andrew's mm tree, or [PATCH/x86] it you expect the
x86 maintainers to pick it up. Or [PATCH/linus] if it's something that
you really expect to bypass all maintainers (why? I'd prefer for that
to then be explained).

But maybe other potential patch recipients would hate that kind of
extra mess in the subject line?

                   Linus