1. 15 Apr, 2019 16 commits
  2. 14 Apr, 2019 21 commits
  3. 13 Apr, 2019 3 commits
    • David S. Miller's avatar
      Merge branch 'rhashtable-bit-locking-m68k' · 5fa7d3f9
      David S. Miller authored
      NeilBrown says:
      
      ====================
      Fix rhashtable bit-locking for m68k
      
      As reported by Guenter Roeck, the new rhashtable bit-locking
      doesn't work on m68k as it only requires 2-byte alignment, so BIT(1)
      is addresses is not unused.
      
      We current use BIT(0) to identify a NULLS marker, but that is only
      needed in ->next pointers.  The bucket head does not need a NULLS
      marker, so the lsb there can be used for locking.
      
      the first 4 patches make some small improvements and re-arrange some
      code.  The final patch converts to using only BIT(0) for these two
      different special purposes.
      
      I had previously suggested dropping the series until I fix it.  Given
      that this was fairly easy, I retract that I think it best simply to
      add these patches to fix the code.
      ====================
      Tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fa7d3f9
    • 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
    • NeilBrown's avatar
      rhashtable: replace rht_ptr_locked() with rht_assign_locked() · f4712b46
      NeilBrown authored
      The only times rht_ptr_locked() is used, it is to store a new
      value in a bucket-head.  This is the only time it makes sense
      to use it too.  So replace it by a function which does the
      whole task:  Sets the lock bit and assigns to a bucket head.
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4712b46