From: Michael Ellerman <mpe@ellerman.id.au>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
linuxppc-dev@lists.ozlabs.org
Cc: imunsie@au1.ibm.com
Subject: Re: cxl: fix setting of _PAGE_USER bit when handling page faults
Date: Mon, 11 Apr 2016 21:14:31 +1000 [thread overview]
Message-ID: <1460373271.17837.3.camel@ellerman.id.au> (raw)
In-Reply-To: <878u0kahqn.fsf@linux.vnet.ibm.com>
On Mon, 2016-04-11 at 10:01 +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman <mpe@ellerman.id.au> writes:
> > On Mon, 2016-04-11 at 14:10 +1000, Andrew Donnellan wrote:
> > > On 29/03/16 00:42, Aneesh Kumar K.V wrote:
> > > > I noticed this when doing radix support and have a variant posted at
> > > >
> > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-March/141036.html
> > >
> > > I'm happy for this to be fixed in your radix series.
> >
> > I'm not :)
> >
> > This needs a stand-alone fix that we can backport.
>
> It is done as an independent patch
>
> http://mid.gmane.org/1460182444-2468-2-git-send-email-aneesh.kumar@linux.vnet.ibm.com
Sure, but that's still not a *fix*.
A fix is a single commit, preferably with a subject that literally contains the
word "fix" or "bug", which fixes just the bug and nothing else. It should also
have a Fixes: line, if possible, and a Cc stable if appropriate.
It should also describe clearly what the bug is, why it's serious or just
annoying or whatever.
In this case it *looks* like we have a giant hole in the mm handling for CAPI
contexts, which would let userspace create mappings of kernel memory with
_PAGE_USER set. I think I agree with Ian that in fact that's not true, but it's
not clear from the diff that is the case. So I'd really like someone to write a
good commit message demonstrating that we understand what the bug is and why
it's not a big deal, despite the patch looking scary at first glance.
</grumpy> :)
cheers
next prev parent reply other threads:[~2016-04-11 11:14 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-18 4:01 [PATCH] cxl: fix setting of _PAGE_USER bit when handling page faults Andrew Donnellan
2016-03-18 6:30 ` Ian Munsie
2016-03-21 4:38 ` Andrew Donnellan
2016-03-25 10:01 ` Michael Ellerman
2016-03-25 17:15 ` Ian Munsie
2016-03-28 13:42 ` Aneesh Kumar K.V
2016-03-28 18:00 ` Aneesh Kumar K.V
2016-04-11 4:10 ` Andrew Donnellan
2016-04-11 4:27 ` Michael Ellerman
2016-04-11 4:31 ` Aneesh Kumar K.V
2016-04-11 11:14 ` Michael Ellerman [this message]
2016-04-11 13:42 ` Aneesh Kumar K.V
2016-04-12 11:42 ` Michael Ellerman
2016-03-29 22:08 ` [PATCH] " Matthew R. Ochs
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=1460373271.17837.3.camel@ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=andrew.donnellan@au1.ibm.com \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=imunsie@au1.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.