RE: [PATCH] hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()

[Viacheslav Dubeyko <Slava.Dubeyko@ibm.com>]

On Mon, 2025-07-07 at 23:45 +0900, Tetsuo Handa wrote:
> On 2025/07/07 23:22, Yangtao Li wrote:
> > 161         case HFSPLUS_VALID_ATTR_TREE:
> > 162                 return 0;
> > 163         case HFSPLUS_FAILED_ATTR_TREE:
> > 164                 return -EOPNOTSUPP;
> > 165         default:
> > 166                 BUG();
> > 167         }
> > 
> > I haven't delved into the implementation details of xattr yet, but
> > there is a bug in this function. It seems that we should convert
> > the bug to return EIO in another patch?
> 
> I don't think this BUG() is triggerable. attr_tree_state is an atomic_t
> which can take only one of HFSPLUS_EMPTY_ATTR_TREE, HFSPLUS_VALID_ATTR_TREE,
> HFSPLUS_FAILED_ATTR_TREE or HFSPLUS_CREATING_ATTR_TREE.

It's completely correct conclusion. The goal of this BUG() simply to trigger the
crash if somebody will change the set of possible states of attr_tree_state. But
this logic will not be reworked.

>> @@ -172,7 +172,11 @@ static int hfsplus_create_attributes_file(struct
super_block *sb)
>>   		return PTR_ERR(attr_file);
>>   	}
>>  
>> -	BUG_ON(i_size_read(attr_file) != 0);

But I still worry about i_size_read(attr_file). How this size could be not zero
during hfsplus_create_attributes_file() call?

Thanks,
Slava.