Messages in this thread | | | Date | Mon, 28 Sep 2020 09:49:37 -0300 | From | Jason Gunthorpe <> | Subject | Re: [PATCH 1/5] mm: Introduce mm_struct.has_pinned |
| |
On Sun, Sep 27, 2020 at 11:45:30AM -0700, Linus Torvalds wrote: > On Sun, Sep 27, 2020 at 11:16 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: > > > > Btw, I'm not convinced about the whole "turn the pte read-only and > > then back". If the fork races with another thread doing a pinning > > fast-GUP on another CPU, there are memory ordering issues etc too. > > That's not necessarily visible on x86 (the "turn read-only being a > > locked op will force serialization), but it all looks dodgy as heck.
Oh. Yes, looking again the atomics in the final arrangement of copy_present_page() aren't going to be strong enough to order this.
Sorry for missing, wasn't able to look very deeply during the weekend.
Not seeing an obvious option besides adding a smp_mb() before page_maybe_dma_pinned() as Peter once suggested.
> .. looking at it more, I also think it could possibly lose the dirty > bit for the case where another CPU did a HW dirty/accessed bit update > in between the original read of the pte, and then us writing back the > writable pte again.
Ah, I see:
set_pte_at(src_mm, addr, src_pte, pte);
wants to be some arch specific single bit ptep_clear_wrprotect()..
Thanks, Jason
| |