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.
