On Thu, 2025-05-29 at 19:36 +0100, Al Viro wrote: > On Thu, May 29, 2025 at 06:34:43PM +0000, Viacheslav Dubeyko wrote: > > > diff --git a/fs/hfsplus/extents.c b/fs/hfsplus/extents.c > > > index a6d61685ae79..b1699b3c246a 100644 > > > --- a/fs/hfsplus/extents.c > > > +++ b/fs/hfsplus/extents.c > > > @@ -342,9 +342,6 @@ static int hfsplus_free_extents(struct super_block *sb, > > > int i; > > > int err = 0; > > > > > > - /* Mapping the allocation file may lock the extent tree */ > > > - WARN_ON(mutex_is_locked(&HFSPLUS_SB(sb)->ext_tree->tree_lock)); > > > - > > > > Makes sense to me. Looks good. > > > > But I really like your mentioning of reproducing the issue in generic/013 and > > really nice analysis of the issue there. Sadly, we haven't it in the comment. :) > > Umm... *Is* that thing safe to call without that lock? As far as I can see, hfsplus_free_fork() works under ext_tree->tree_lock mutex lock. And hfsplus_free_extents() calls hfsplus_block_free(). This guy uses sbi->alloc_mutex to protect free blocks operation. So, operation should be mostly safe. Thanks, Slava.
