On Sun, Sep 02, 2018 at 07:10:46PM -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> 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:
On Sun, Sep 02, 2018 at 07:10:46PM -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> 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:
On Sun, 2 Sep 2018, Linus Torvalds wrote:
> 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
On Sun, 2 Sep 2018, Linus Torvalds wrote:
> 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
On 03/09/18 04:10, Linus Torvalds wrote:
> 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.
And that was exactly the reason I brought it up. :-)
Juergen
On 03/09/18 04:10, Linus Torvalds wrote:
> 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.
And that was exactly the reason I brought it up. :-)
Juergen
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only
On Sun, 2018-09-02 at 19:52 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
> wrote:
> >
> > The comment actually does talk about it, although the comment also
> > claims that the cs read would use load_unaligned_zeropad(), which it
> > no longer does (now it only
On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
wrote:
>
> The comment actually does talk about it, although the comment also
> claims that the cs read would use load_unaligned_zeropad(), which it
> no longer does (now it only does the read_word_at_a_time).
IOW, look at commit 12f8ad4b0533 ("vfs:
On Sun, Sep 2, 2018 at 7:47 PM Linus Torvalds
wrote:
>
> The comment actually does talk about it, although the comment also
> claims that the cs read would use load_unaligned_zeropad(), which it
> no longer does (now it only does the read_word_at_a_time).
IOW, look at commit 12f8ad4b0533 ("vfs:
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> 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
On Sun, 2018-09-02 at 19:10 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
> 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
On Sun, Sep 2, 2018 at 7:25 PM Benjamin Herrenschmidt
wrote:
> 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 ?
The dentry qstr should always be 8-byte aligned because
On Sun, Sep 2, 2018 at 7:25 PM Benjamin Herrenschmidt
wrote:
> 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 ?
The dentry qstr should always be 8-byte aligned because
On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
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
On Sun, Sep 2, 2018 at 7:01 PM Benjamin Herrenschmidt
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
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous
On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> [ Adding a few new people the the cc.
>
> The issue is the worry about software-speculative accesses (ie
> things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
> speculation now) accessing past RAM into possibly contiguous
On Sun, 2018-09-02 at 18:42 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds
> wrote:
> > It's not used for vmalloc stuff. It's just regular kmalloc().
>
> Just to clarify .. that's true of the dcache stuff.
>
> The strscpy case actually explicitly limits things to
On Sun, 2018-09-02 at 18:42 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds
> wrote:
> > It's not used for vmalloc stuff. It's just regular kmalloc().
>
> Just to clarify .. that's true of the dcache stuff.
>
> The strscpy case actually explicitly limits things to
On Mon, 2018-09-03 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> > [ Adding a few new people the the cc.
> >
> > The issue is the worry about software-speculative accesses (ie
> > things like CONFIG_DCACHE_WORD_ACCESS - not talking
On Mon, 2018-09-03 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2018-09-01 at 11:06 -0700, Linus Torvalds wrote:
> > [ Adding a few new people the the cc.
> >
> > The issue is the worry about software-speculative accesses (ie
> > things like CONFIG_DCACHE_WORD_ACCESS - not talking
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > Also, if we cross page boundaries with those guys then we have a bigger
> > problem no ? we could fall off a vmalloc page into the nether or into
> > an ioremap
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > Also, if we cross page boundaries with those guys then we have a bigger
> > problem no ? we could fall off a vmalloc page into the nether or into
> > an ioremap
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > Also, if we cross page boundaries with those guys then we have a bigger
> > problem no ? we could fall off a vmalloc page into the nether or into
> > an ioremap
On Sun, 2018-09-02 at 18:38 -0700, Linus Torvalds wrote:
> On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
> wrote:
> >
> > Also, if we cross page boundaries with those guys then we have a bigger
> > problem no ? we could fall off a vmalloc page into the nether or into
> > an ioremap
On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds
wrote:
> It's not used for vmalloc stuff. It's just regular kmalloc().
Just to clarify .. that's true of the dcache stuff.
The strscpy case actually explicitly limits things to page boundaries
and falls back to the byte-by-byte case after that.
On Sun, Sep 2, 2018 at 6:38 PM Linus Torvalds
wrote:
> It's not used for vmalloc stuff. It's just regular kmalloc().
Just to clarify .. that's true of the dcache stuff.
The strscpy case actually explicitly limits things to page boundaries
and falls back to the byte-by-byte case after that.
On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
wrote:
>
> Also, if we cross page boundaries with those guys then we have a bigger
> problem no ? we could fall off a vmalloc page into the nether or into
> an ioremap mapping no ?
It's not used for vmalloc stuff. It's just regular kmalloc().
On Sun, Sep 2, 2018 at 6:32 PM Benjamin Herrenschmidt
wrote:
>
> Also, if we cross page boundaries with those guys then we have a bigger
> problem no ? we could fall off a vmalloc page into the nether or into
> an ioremap mapping no ?
It's not used for vmalloc stuff. It's just regular kmalloc().
On Sat, 1 Sep 2018, Al Viro wrote:
> IMO that's crap. In absolute majority of cases there is a guaranteed gap
> between the end of accessed object and the next page boundary.
So if that's the case, you're absolutely right. But I am unable to find
any such guarantee in our current code
On Sat, 1 Sep 2018, Al Viro wrote:
> IMO that's crap. In absolute majority of cases there is a guaranteed gap
> between the end of accessed object and the next page boundary.
So if that's the case, you're absolutely right. But I am unable to find
any such guarantee in our current code
[ Adding a few new people the the cc.
The issue is the worry about software-speculative accesses (ie
things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
speculation now) accessing past RAM into possibly contiguous IO ]
On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds
wrote:
>
> If
[ Adding a few new people the the cc.
The issue is the worry about software-speculative accesses (ie
things like CONFIG_DCACHE_WORD_ACCESS - not talking about the hw
speculation now) accessing past RAM into possibly contiguous IO ]
On Sat, Sep 1, 2018 at 10:27 AM Linus Torvalds
wrote:
>
> If
On Fri, Aug 31, 2018 at 2:18 PM Jiri Kosina wrote:
>
> If noone has any clever idea how to work this around (I don't), I am
> afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as
> it's silently dangerous.
No way in hell will I apply such a stupid patch.
It is NOT dangerous.
On Fri, Aug 31, 2018 at 2:18 PM Jiri Kosina wrote:
>
> If noone has any clever idea how to work this around (I don't), I am
> afraid we'd have to ditch the whole DCACHE_WORD_ACCESS optimization, as
> it's silently dangerous.
No way in hell will I apply such a stupid patch.
It is NOT dangerous.
On Sat, Sep 01, 2018 at 12:47:48PM +0200, Juergen Gross wrote:
> On 31/08/18 23:18, Jiri Kosina wrote:
> > On Wed, 29 Aug 2018, Juergen Gross wrote:
> >
> >> While being very unlikely I still believe this is possible. Any
> >> thoughts?
> >
> > So in theory we should somehow test whether the
On Sat, Sep 01, 2018 at 12:47:48PM +0200, Juergen Gross wrote:
> On 31/08/18 23:18, Jiri Kosina wrote:
> > On Wed, 29 Aug 2018, Juergen Gross wrote:
> >
> >> While being very unlikely I still believe this is possible. Any
> >> thoughts?
> >
> > So in theory we should somehow test whether the
On 31/08/18 23:18, Jiri Kosina wrote:
> On Wed, 29 Aug 2018, Juergen Gross wrote:
>
>> While being very unlikely I still believe this is possible. Any
>> thoughts?
>
> So in theory we should somehow test whether the next page is some form of
> mmio/gart/... mapping, but I guess that by itself
On 31/08/18 23:18, Jiri Kosina wrote:
> On Wed, 29 Aug 2018, Juergen Gross wrote:
>
>> While being very unlikely I still believe this is possible. Any
>> thoughts?
>
> So in theory we should somehow test whether the next page is some form of
> mmio/gart/... mapping, but I guess that by itself
On Wed, 29 Aug 2018, Juergen Gross wrote:
> While being very unlikely I still believe this is possible. Any
> thoughts?
So in theory we should somehow test whether the next page is some form of
mmio/gart/... mapping, but I guess that by itself would kill the
performance advantage of the whole
On Wed, 29 Aug 2018, Juergen Gross wrote:
> While being very unlikely I still believe this is possible. Any
> thoughts?
So in theory we should somehow test whether the next page is some form of
mmio/gart/... mapping, but I guess that by itself would kill the
performance advantage of the whole
42 matches
Mail list logo
