From: ebiederm@xmission.com (Eric W. Biederman)
To: Sasha Levin <Alexander.Levin@microsoft.com>
Cc: "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"stable\@vger.kernel.org" <stable@vger.kernel.org>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
"linux-parisc\@vger.kernel.org" <linux-parisc@vger.kernel.org>
Subject: Re: [PATCH AUTOSEL for 4.15 118/124] signal/parisc: Document a conflict with SI_USER with SIGFPE
Date: Wed, 21 Mar 2018 14:49:25 -0500 [thread overview]
Message-ID: <87370txl8a.fsf@xmission.com> (raw)
In-Reply-To: <20180321181842.rhniantbvz25bu2f@sasha-lappy> (Sasha Levin's message of "Wed, 21 Mar 2018 18:18:44 +0000")
Sasha Levin <Alexander.Levin@microsoft.com> writes:
> Hey Eric,
>
> On Tue, Mar 20, 2018 at 10:20:21AM -0500, Eric W. Biederman wrote:
>>Sasha Levin <Alexander.Levin@microsoft.com> writes:
>>
>>What is the justification for backporting this and the other similar
>>Documentation commits?
>
> It was flagged as a bug fixing patch by a new process we're testing, and
> when I looked at it I thought that the commit message suggests it fixes
> an ABI issue.
Unfortunately they just reveal an ABI issue. I believe there are some
fixes coming but given that the issues are a decade old in many cases
actually fixing these things must be approach with care so as not to
create regressions.
>>These commits just introduce a define _FIXME with value of 0, to
>>document that the userspace ABI was handled incorrectly long ago.
>>
>>These commits do not fix anything. Thes commits do not change anything
>>except a little how they are handled in siginfo_layout. And I don't see
>>the changes that introduce siginfo_layout in kernel/signal.c being
>>backported.
>>
>>Further these commits don't even have a fixes tag so I am curious
>>what is triggering them for backport.
>
> We're testing out a new mechanism where we train a neural network to
> detect bug fixing patches and flag them for manual review. We're working
> on a FAQ + more detailed information right now.
The neural network did seem to pick up on something that is worth
looking at.
Eric
next prev parent reply other threads:[~2018-03-21 19:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180319154645.11350-1-alexander.levin@microsoft.com>
2018-03-19 15:49 ` [PATCH AUTOSEL for 4.15 118/124] signal/parisc: Document a conflict with SI_USER with SIGFPE Sasha Levin
2018-03-20 15:20 ` Eric W. Biederman
2018-03-21 18:18 ` Sasha Levin
2018-03-21 19:49 ` Eric W. Biederman [this message]
2018-03-21 19:58 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87370txl8a.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=Alexander.Levin@microsoft.com \
--cc=deller@gmx.de \
--cc=jejb@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox