arm64 ioremap question
Russell King - ARM Linux
linux at arm.linux.org.uk
Tue Oct 15 12:53:35 EDT 2013
On Tue, Oct 15, 2013 at 06:14:12PM +0200, Lucas Stach wrote:
> Am Dienstag, den 15.10.2013, 16:52 +0100 schrieb Russell King - ARM
> Linux:
> > On Tue, Oct 15, 2013 at 11:20:04AM -0400, Mark Salter wrote:
> > > ioremap() has a test to prevent RAM from being remapped:
> > >
> > > /*
> > > * Don't allow RAM to be mapped.
> > > */
> > > if (WARN_ON(pfn_valid(__phys_to_pfn(phys_addr))))
> > > return NULL;
> > >
> > >
> > > Is this really necessary even for reserved pages which are not being
> > > used for anything else?
> >
> > It helps to stop the abuse of using ioremap() on normal memory, which has
> > happened soo much in Aarch32 for years. Unfortuantely, bad habbits die
> > hard.
> >
> > "Reserved pages not being used for anything else" are still mapped, and
> > still subject to speculative fetches.
>
> Only slightly related to the issue here, but I'm really wondering if the
> speculative fill can happen on real implementations.
> I'm well aware that there is nothing in the arch preventing a
> speculative fill on a cached alias, but at least for the A9
> implementation the ARM infocenter claims that the prefetcher will not
> cross a 4KB boundary [1].
> So as long as we are talking about full pages, having a conflicting
> mapping should not cause any issues as long as you don't touch the
> memory region explicitly through the cached mapping.
>
> I know that we generally aim to avoid basing any kernel infrastructure
> on such vague guarantees, but I'm really wondering if my analysis is
> correct or is there anything I'm overlooking here?
And I know where this is leading so frankly I'm not answering. I don't
want to see any more of people commenting out code like this in their
vendor kernels because they don't care. Sorry if I'm being unhelpful
but I have experience of what happens here.
More information about the linux-arm-kernel
mailing list