• NeilBrown's avatar
    rhashtable: use BIT(0) for locking. · ca0b709d
    NeilBrown authored
    As reported by Guenter Roeck, the new bit-locking using
    BIT(1) doesn't work on the m68k architecture.  m68k only requires
    2-byte alignment for words and longwords, so there is only one
    unused bit in pointers to structs - We current use two, one for the
    NULLS marker at the end of the linked list, and one for the bit-lock
    in the head of the list.
    
    The two uses don't need to conflict as we never need the head of the
    list to be a NULLS marker - the marker is only needed to check if an
    object has moved to a different table, and the bucket head cannot
    move.  The NULLS marker is only needed in a ->next pointer.
    
    As we already have different types for the bucket head pointer (struct
    rhash_lock_head) and the ->next pointers (struct rhash_head), it is
    fairly easy to treat the lsb differently in each.
    
    So: Initialize buckets heads to NULL, and use the lsb for locking.
    When loading the pointer from the bucket head, if it is NULL (ignoring
    the lock big), report as being the expected NULLS marker.
    When storing a value into a bucket head, if it is a NULLS marker,
    store NULL instead.
    
    And convert all places that used bit 1 for locking, to use bit 0.
    
    Fixes: 8f0db018 ("rhashtable: use bit_spin_locks to protect hash bucket.")
    Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
    Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
    Signed-off-by: default avatarNeilBrown <neilb@suse.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    ca0b709d
rhashtable.c 29.5 KB