From: Andrew Donnellan <andrew.donnellan@au1•ibm.com>
To: Ian Munsie <imunsie@au1•ibm.com>
Cc: linuxppc-dev <linuxppc-dev@lists•ozlabs.org>, benh@kernel•crashing.org
Subject: Re: [PATCH] cxl: fix setting of _PAGE_USER bit when handling page faults
Date: Mon, 21 Mar 2016 15:38:39 +1100 [thread overview]
Message-ID: <56EF7ACF.5020506@au1.ibm.com> (raw)
In-Reply-To: <1458282296-sup-2460@x230.ozlabs.ibm.com>
On 18/03/16 17:30, Ian Munsie wrote:
> Excerpts from andrew.donnellan's message of 2016-03-18 15:01:21 +1100:
>> Fixes: f204e0b8cedd ("cxl: Driver code for powernv PCIe based cards for
>> userspace access")
>
> It doesn't fix that since there was no cxl kernel API support at the
> time, so this wasn't a regression - just something we missed when the
> kernel api was added (I believe the broken test in the code was a left
> over from some early bringup work and would never have been exercised on
> an upstream kernel until then).
Ah, fair enough - I just looked at what git blame told me. You're right,
it's not a fix to that commit per se. Happy to drop this tag.
> We haven't run into any problems because of this that I am aware of - do
> we have a test case for this?
I'd be surprised if it caused noticeable problems - the presence of the
_PAGE_USER bit when it's not necessary shouldn't break anything, as
opposed to the absence of _PAGE_USER when it is necessary. Not entirely
sure what the test case would be.
>
>> - if ((!ctx->kernel) || ~(dar & (1ULL << 63)))
>> + if ((!ctx->kernel) || !(dar & (1ULL << 63)))
>
> Should it be the top two bits?
benh told me that the top bit should be enough - anything above 0x8000*
should be kernel space.
--
Andrew Donnellan Software Engineer, OzLabs
andrew.donnellan@au1•ibm.com Australia Development Lab, Canberra
+61 2 6201 8874 (work) IBM Australia Limited
next prev parent reply other threads:[~2016-03-21 4:39 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 [this message]
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
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=56EF7ACF.5020506@au1.ibm.com \
--to=andrew.donnellan@au1$(echo .)ibm.com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=imunsie@au1$(echo .)ibm.com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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