From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
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, 28 Mar 2016 19:12:20 +0530 [thread overview]
Message-ID: <8737rau3b7.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <3qWf364wYxz9sDG@ozlabs.org>
Michael Ellerman <mpe@ellerman.id.au> writes:
> [ text/plain ]
> On Fri, 2016-18-03 at 04:01:21 UTC, Andrew Donnellan wrote:
>> When handling page faults, cxl_handle_page_fault() checks whether the page
>> should be accessible by userspace and have its _PAGE_USER access bit set.
>> _PAGE_USER should be set if the context's kernel flag isn't set, or if the
>> page falls outside of kernel memory.
>>
>> However, the check currently uses the wrong operator, causing it to always
>> evalute to true. As such, we always set the _PAGE_USER bit, even when it
>> should be restricted to the kernel.
>>
>> Fix the check so that the _PAGE_USER bit is set only as intended.
>>
> ..
>> diff --git a/drivers/misc/cxl/fault.c b/drivers/misc/cxl/fault.c
>> index 9a8650b..a76cb8a 100644
>> --- a/drivers/misc/cxl/fault.c
>> +++ b/drivers/misc/cxl/fault.c
>> @@ -152,7 +152,7 @@ static void cxl_handle_page_fault(struct cxl_context *ctx,
>> access = _PAGE_PRESENT;
>> if (dsisr & CXL_PSL_DSISR_An_S)
>> access |= _PAGE_RW;
>> - if ((!ctx->kernel) || ~(dar & (1ULL << 63)))
>> + if ((!ctx->kernel) || !(dar & (1ULL << 63)))
>> access |= _PAGE_USER;
>
> I think you can (should) use is_kernel_addr() for the DAR check.
>
> I'm also slightly worried by that logic in the case of a non-kernel context.
>
> ie. if ctx->kernel is false, we get:
>
> if (true || !is_kernel_addr(dar))
> access |= _PAGE_USER;
>
> Which means we just add _PAGE_USER for any address. What am I missing here?
I noticed this when doing radix support and have a variant posted at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2016-March/141036.html
-aneesh
next prev parent reply other threads:[~2016-03-28 13:46 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 [this message]
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=8737rau3b7.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=andrew.donnellan@au1.ibm.com \
--cc=imunsie@au1.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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.