Skip to content
  • Al Viro's avatar
    missing barriers in some of unix_sock ->addr and ->path accesses · f412aeb9
    Al Viro authored
    [ Upstream commit ae3b564179bfd06f32d051b9e5d72ce4b2a07c37 ]
    
    Several u->addr and u->path users are not holding any locks in
    common with unix_bind().  unix_state_lock() is useless for those
    purposes.
    
    u->addr is assign-once and *(u->addr) is fully set up by the time
    we set u->addr (all under unix_table_lock).  u->path is also
    set in the same critical area, also before setting u->addr, and
    any unix_sock with ->path filled will have non-NULL ->addr.
    
    So setting ->addr with smp_store_release() is all we need for those
    "lockless" users - just have them fetch ->addr with smp_load_acquire()
    and don't even bother looking at ->path if they see NULL ->addr.
    
    Users of ->addr and ->path fall into several classes now:
        1) ones that do smp_load_acquire(u->addr) and access *(u->addr)
    and u->path only if smp_load_acquire() has returned non-NULL.
        2) places holding unix_table_lock.  These are guaranteed that
    *(u->addr) is seen fully initialized.  If u...
    f412aeb9