Re: [PATCH v2] hfsplus: annotate extents_lock nesting to silence lockdep false positive

[Mahmut Emin Kurhan]

Hi Slava,

Thanks. You're right that tree->cnid and inode->i_ino match for the special
inodes. hfsplus_btree_lock_class() itself can't be reused as-is, though: it
takes a struct hfs_btree * and BUG()s on any CNID that isn't one of the three
B-trees (CATALOG/EXTENTS/ATTR), while extents_lock is taken on regular inodes
and on the allocation file, which are not B-trees.

Looking more carefully, there is only one actual extents_lock nesting: a
regular inode's extents_lock is held in hfsplus_file_truncate() /
hfsplus_file_extend() while block alloc/free reads sbi->alloc_file
(hfsplus_block_free() -> read_mapping_page() -> hfsplus_get_block() on the
allocation file). The catalog/attr inodes are not taken nested under a regular
inode's extents_lock (the extents-overflow inode returns early in
hfsplus_get_block(), and the catalog/attr trees are reached under their own
tree_lock).

So the parallel enum + HFSPLUS_FIRSTUSER_CNID check is overkill (and, as you
note, FIRSTUSER also covers folders). I'll simplify to a single distinction:
give only the allocation file's extents_lock a separate subclass, leaving every
other inode at the default. That removes the duplication and the file/folder
ambiguity.

Does that direction look right to you? I'll send v3 accordingly and fold the
same into the HFS side.

Thanks,
Mahmut