Re: [PATCH] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir
shuo chen <[email protected]>
| Newsgroups | org.kernel.vger.linux-ext4,dev.linux.lists.sashiko-reviews |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Aug 13, 2026 at 08:49:27AM +0000, [email protected] wrote: > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [High] Returning `-EINVAL` from `ext4_readdir` on a corrupted or inconsistent directory state breaks userspace expectations and bypasses filesystem error handling. > -- > > --- Patch [1]: [PATCH] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir --- > commit 419471105d79565b3d6563ce7e941b266526160b > Author: pipishuo <[email protected]> > > Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir > > This commit adds a check for EXT4_STATE_MAY_INLINE_DATA in ext4_readdir to > prevent reading incorrect inline data if the inode's inline state is > inconsistent after a failure in ext4_restore_inline_data. > > > diff --git a/fs/ext4/dir.c b/fs/ext4/dir.c > > index 8d7b81e6948e7..857cf02742c0c 100644 > > --- a/fs/ext4/dir.c > > +++ b/fs/ext4/dir.c > > [ ... ] > > > @@ -160,6 +161,9 @@ static int ext4_readdir(struct file *file, struct dir_context *ctx) > > } > > > > if (ext4_has_inline_data(inode)) { > > + if (!ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) > > + return -EINVAL; > > + > > [Severity: High] > Does returning -EINVAL here break userspace expectations and bypass the > standard filesystem corruption handling? > > If an operation (like ext4_convert_inline_data_nolock) fails and leaves > EXT4_INODE_INLINE_DATA set without EXT4_STATE_MAY_INLINE_DATA, this > indicates an internally corrupted or inconsistent directory state. > > By returning -EINVAL directly, this code bypasses the standard > ext4_error_file() error handler, which prevents the filesystem from taking > corrective action (such as remounting read-only). > > Additionally, returning -EINVAL from a readdir (getdents64) operation is > typically interpreted by userspace as a buffer size issue, which completely > misleads tools like ls. Should this instead invoke EXT4_ERROR_FILE() and > return -EFSCORRUPTED? Thanks for the reviews. I'll address all the comments and send v2 soon. > > > int has_inline_data = 1; > > err = ext4_read_inline_dir(file, ctx, > > &has_inline_data); > > -- > Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1