Re: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding

[John Hubbard]

On 9/10/20 11:13 AM, Jason Gunthorpe wrote:
> On Thu, Sep 10, 2020 at 10:35:38AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 10, 2020 at 2:40 AM Alexander Gordeev
> > <agordeev@xxxxxxxxxxxxx> wrote:
> > > It is only gup_fast case that exposes the issue. It hits because
> > > pointers to stack copies are passed to gup_pXd_range iterators, not
> > > pointers to real page tables itself.
> >
> > Can we possibly change fast-gup to not do the stack copies?
> >
> > I'd actually rather do something like that, than the "addr_end" thing.
>
> > As you say, none of the other page table walking code does what the
> > GUP code does, and I don't think it's required.
>
> As I understand it, the requirement is because fast-gup walks without
> the page table spinlock, or mmap_sem held so it must READ_ONCE the
> *pXX.
>
> It then checks that it is a valid page table pointer, then calls
> pXX_offset().
>
> The arch implementation of pXX_offset() derefs again the passed pXX
> pointer. So it defeats the READ_ONCE and the 2nd load could observe
> something that is no longer a page table pointer and crash.

Just to be clear, though, that makes it sound a little wilder and
reckless than it really is, right?

Because actually, the page tables cannot be freed while gup_fast is
walking them, due to either IPI blocking during the walk, or the moral
equivalent (MMU_GATHER_RCU_TABLE_FREE) for non-IPI architectures. So the
pages tables can *change* underneath gup_fast, and for example pages can
be unmapped. But they remain valid page tables, it's just that their
contents are unstable. Even if pXd_none()==true.

Or am I way off here, and it really is possible (aside from the current
s390 situation) to observe something that "is no longer a page table"?


thanks,
--
John Hubbard
NVIDIA