Details
-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
3
-
9223372036854775807
Description
I was reading through the pdirops patch and noticed that the lh_hbits field in the ldiskfs pdirops patch is not initialized correctly. This indirectly results in the "major" hash of the filename to always be zero, and the full 32-bit hash value is stored in the minor version of the hash. It isn't clear what impact this error would have on performance.
enum { HTREE_HBITS_MIN = 2, HTREE_HBITS_DEF = 14, HTREE_HBITS_MAX = 32, }; struct htree_lock_head * htree_lock_head_alloc(unsigned depth, unsigned hbits, unsigned priv) { : lhead = kzalloc(offsetof(struct htree_lock_head, lh_children[depth]) + priv, GFP_NOFS); if (lhead == NULL) return NULL; if (hbits < HTREE_HBITS_MIN) lhead->lh_hbits = HTREE_HBITS_MIN; else if (hbits > HTREE_HBITS_MAX) lhead->lh_hbits = HTREE_HBITS_MAX; : } struct htree_lock_head *ext4_htree_lock_head_alloc(unsigned hbits) { struct htree_lock_head *lhead; lhead = htree_lock_head_alloc(EXT4_LK_MAX, hbits, 0); if (lhead != NULL) { htree_lock_event_attach(lhead, EXT4_LK_SPIN, HTREE_EVENT_WR, ext4_htree_event_cb); } return lhead; } static int htree_node_lock_internal() { : key = hash_long(key, lhead->lh_hbits); mi_bits = lhead->lh_hbits >> 1; ma_bits = lhead->lh_hbits - mi_bits; lck->lk_nodes[dep].ln_major_key = major = key & ((1U << ma_bits) - 1); lck->lk_nodes[dep].ln_minor_key = minor = key >> ma_bits; : } struct htree_lock_head *ldiskfs_htree_lock_head_alloc(unsigned hbits) { return htree_lock_head_alloc(LDISKFS_LK_MAX, hbits, 0); } obj->oo_hl_head = ldiskfs_htree_lock_head_alloc(HTREE_HBITS_DEF);