lkml.org 
[lkml]   [2018]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Access to non-RAM pages
From
Date
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > Still, I can potentially see an issue with DEBUG_PAGEALLOC
>
> An unmapped page isn't a problem. That's what the whole
> load_unaligned_zeropad() is about: it's ok to take a fault on the part
> that crosses a page, and we'll just fill the value with zeroes (that's
> the "zeropad" part).

Ah, my bad reading, I was looking at read_word_at_a_time() instead of
load_unaligned_zeropad(). I'm not familiar enough with the dentry qstr
stuff, I assume this is safe ?

> So as long as it's rare (and it is), it's all fine.
>
> That said, I think we turn off for DEBUG_PAGEALLOC simply because it's
> not rare _enough_.
>
> And vmalloc() should actually be safe too, simply because I think we
> strive for a guard page between vmalloc areas.
>
> So only a *mapped* page after the page that matters, and only if it's
> something you can't read without side effects.
>
> Which basically doesn't happen on x86 in reality. BIOSes just don't
> put MMIO right after the last page of RAM. I think this is why it only
> triggered on Xen, due to some crazy "Xen reacts badly" case where we
> do the speculation into a balloon address.
>
> So _practically_ this is just a Xen bug, nothing more.
>
> But since in _theory_ you could have MMIO abut regular RAM directly,
> it's worth maybe making sure it's purely theory.


\
 
 \ /
  Last update: 2018-09-03 04:53    [W:0.156 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site