From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>,
Greg KH <gregkh@linuxfoundation.org>
Cc: git@thegavinli.com, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, jarkko.sakkinen@linux.intel.com,
stern@rowland.harvard.edu, Jeremy Linton <jeremy.linton@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] usb: usbfs: correct kernel->user page attribute mismatch
Date: Fri, 01 May 2020 11:54:08 +0100 [thread overview]
Message-ID: <0aa2a8a9a5b6c00b2e1a1fcf71c121ce@kernel.org> (raw)
In-Reply-To: <20200501103712.GA51954@C02TD0UTHF1T.local>
On 2020-05-01 11:37, Mark Rutland wrote:
> On Fri, May 01, 2020 at 09:05:00AM +0200, Greg KH wrote:
>> On Thu, Apr 30, 2020 at 04:19:22PM -0500, Jeremy Linton wrote:
>> > On arm64, and possibly other architectures, requesting
>> > IO coherent memory may return Normal-NC if the underlying
>> > hardware isn't coherent. If these pages are then
>> > remapped into userspace as Normal, that defeats the
>> > purpose of getting Normal-NC, as well as resulting in
>> > mappings with differing cache attributes.
>>
>> What is "Normal-NC"?
>
> Arm terminology for "Normal Non-Cacheable"; it might be better to say
> something like:
>
> On some architectures (e.g. arm64) an IO coherent mapping may use
> non-cachable attributes if the relevant device is cache coherent.
is *not* cache coherent.
> If userspace mappings are cacheable, these may not be coherent with
> non-cacheable mappings. On arm64 this is the case for Normal-NC and
> Normal (cacheable) mappings.
And to answer some of Greg's questions:
- This can show up on current HW that doesn't offer full IO coherency,
which is likely on low-end arm/arm64 systems.
- I guess nobody noticed this before as x86 is perfectly happy with
conflicting attributes for the same physical page, and there is
(wild guess) probably not that much userspace making use of shared
mappings between kernel and userspace using this interface.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-05-01 10:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-30 21:19 [PATCH] usb: usbfs: correct kernel->user page attribute mismatch Jeremy Linton
2020-05-01 7:05 ` Greg KH
2020-05-01 10:37 ` Mark Rutland
2020-05-01 10:54 ` Marc Zyngier [this message]
2020-05-01 10:55 ` Greg KH
2020-05-01 15:36 ` Robin Murphy
2020-05-01 15:47 ` Jeremy Linton
2020-05-04 7:13 ` Greg KH
2020-05-04 13:21 ` Jeremy Linton
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=0aa2a8a9a5b6c00b2e1a1fcf71c121ce@kernel.org \
--to=maz@kernel.org \
--cc=git@thegavinli.com \
--cc=gregkh@linuxfoundation.org \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jeremy.linton@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=stern@rowland.harvard.edu \
/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;
as well as URLs for NNTP newsgroup(s).