• David Sterba's avatar
    btrfs: add barriers to btrfs_sync_log before log_commit_wait wakeups · c9bda754
    David Sterba authored
    BugLink: https://bugs.launchpad.net/bugs/1791953
    
    [ Upstream commit 3d3a2e61 ]
    
    Currently the code assumes that there's an implied barrier by the
    sequence of code preceding the wakeup, namely the mutex unlock.
    
    As Nikolay pointed out:
    
    I think this is wrong (not your code) but the original assumption that
    the RELEASE semantics provided by mutex_unlock is sufficient.
    According to memory-barriers.txt:
    
    Section 'LOCK ACQUISITION FUNCTIONS' states:
    
     (2) RELEASE operation implication:
    
         Memory operations issued before the RELEASE will be completed before the
         RELEASE operation has completed.
    
         Memory operations issued after the RELEASE *may* be completed before the
         RELEASE operation has completed.
    
    (I've bolded the may portion)
    
    The example given there:
    
    As an example, consider the following:
    
        *A = a;
        *B = b;
        ACQUIRE
        *C = c;
        *D = d;
        RELEASE
        *E = e;
        *F = f;
    
    The following sequence of events is acceptable:
    
        ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE
    
    So if we assume that *C is modifying the flag which the waitqueue is checking,
    and *E is the actual wakeup, then those accesses can be re-ordered...
    
    IMHO this code should be considered broken...
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    Signed-off-by: default avatarStefan Bader <stefan.bader@canonical.com>
    Signed-off-by: default avatarKleber Sacilotto de Souza <kleber.souza@canonical.com>
    c9bda754
tree-log.c 150 KB