lkml.org 
[lkml]   [2020]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH v2 1/3] mm/gup: fix gup_fast with dynamic page table folding
    On Thu, 10 Sep 2020 11:33:17 -0700
    Linus Torvalds <torvalds@linux-foundation.org> wrote:

    > On Thu, Sep 10, 2020 at 11:13 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
    > >
    > > So.. To change away from the stack option I think we'd have to pass
    > > the READ_ONCE value to pXX_offset() as an extra argument instead of it
    > > derefing the pointer internally.
    >
    > Yeah, but I think that would actually be the better model than passing
    > an address to a random stack location.
    >
    > It's also effectively what we do in some other places, eg the whole
    > logic with "orig" in the regular pte fault handling is basically doing
    > unlocked loads of the pte, various decisions on that, and then doing a
    > final "is this still the same pte" after it has gotten the page table
    > lock.

    That sounds a lot like the pXd_offset_orig() from Martins first approach
    in this thread:
    https://lore.kernel.org/linuxppc-dev/20190418100218.0a4afd51@mschwideX1/

    It is also the "Patch 1" option from the start of this thread:
    https://lore.kernel.org/lkml/20200828140314.8556-1-gerald.schaefer@linux.ibm.com/

    I guess I chose wrongly there, should have had more trust in Martins
    approach, and not try so hard to do it like others...

    So, maybe we can start over again, from that patch option. It would of
    course also initially introduce some gup-specific helpers, like with
    the other approach. It seemed harder to generalize when I thought
    about it back then, but I guess it should not be a lot harder than
    the _addr_end stuff.

    Or, maybe this time, just not to risk Christian getting a heart attack,
    we could go for the gup-specific helper first, so that we would at
    least have a fix for the possible s390 data corruption. Jason, would
    you agree that we send a new RFC, this time with pXd_offset_orig()
    approach, and have that accepted as short-term fix?

    Or would you rather also wait for some proper generic change? Have
    lost that option from my radar, so cannot really judge how much more
    effort it would be. I'm on vacation next week anyway, but Alexander
    or Vasily (who did the option 1 patch) could look into this further.

    \
     
     \ /
      Last update: 2020-09-10 21:13    [W:4.724 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site