lkml.org 
[lkml]   [2020]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 4/7] x86: use exit_lazy_tlb rather than membarrier_mm_sync_core_before_usermode
    ----- On Jul 16, 2020, at 11:46 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:

    > ----- On Jul 16, 2020, at 12:42 AM, Nicholas Piggin npiggin@gmail.com wrote:
    >> I should be more complete here, especially since I was complaining
    >> about unclear barrier comment :)
    >>
    >>
    >> CPU0 CPU1
    >> a. user stuff 1. user stuff
    >> b. membarrier() 2. enter kernel
    >> c. smp_mb() 3. smp_mb__after_spinlock(); // in __schedule
    >> d. read rq->curr 4. rq->curr switched to kthread
    >> e. is kthread, skip IPI 5. switch_to kthread
    >> f. return to user 6. rq->curr switched to user thread
    >> g. user stuff 7. switch_to user thread
    >> 8. exit kernel
    >> 9. more user stuff
    >>
    >> What you're really ordering is a, g vs 1, 9 right?
    >>
    >> In other words, 9 must see a if it sees g, g must see 1 if it saw 9,
    >> etc.
    >>
    >> Userspace does not care where the barriers are exactly or what kernel
    >> memory accesses might be being ordered by them, so long as there is a
    >> mb somewhere between a and g, and 1 and 9. Right?
    >
    > This is correct.

    Actually, sorry, the above is not quite right. It's been a while
    since I looked into the details of membarrier.

    The smp_mb() at the beginning of membarrier() needs to be paired with a
    smp_mb() _after_ rq->curr is switched back to the user thread, so the
    memory barrier is between store to rq->curr and following user-space
    accesses.

    The smp_mb() at the end of membarrier() needs to be paired with the
    smp_mb__after_spinlock() at the beginning of schedule, which is
    between accesses to userspace memory and switching rq->curr to kthread.

    As to *why* this ordering is needed, I'd have to dig through additional
    scenarios from https://lwn.net/Articles/573436/. Or maybe Paul remembers ?

    Thanks,

    Mathieu


    > Note that the accesses to user-space memory can be
    > done either by user-space code or kernel code, it doesn't matter.
    > However, in order to be considered as happening before/after
    > either membarrier or the matching compiler barrier, kernel code
    > needs to have causality relationship with user-space execution,
    > e.g. user-space does a system call, or returns from a system call.
    >
    > In the case of io_uring, submitting a request or returning from waiting
    > on request completion appear to provide this causality relationship.
    >
    > Thanks,
    >
    > Mathieu
    >
    >
    > --
    > Mathieu Desnoyers
    > EfficiOS Inc.
    > http://www.efficios.com

    --
    Mathieu Desnoyers
    EfficiOS Inc.
    http://www.efficios.com

    \
     
     \ /
      Last update: 2020-07-16 18:05    [W:3.362 / U:0.180 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site