Re: [PATCH] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir

["Theodore Tso" <tytso@mit.edu>]

On Thu, Aug 13, 2026 at 04:33:57PM -0500, pipishuo wrote:
> After a failure in the route ext4_restore_inline_data ->
> ext4_create_inline_data -> ext4_mark_iloc_dirty, the inode will still
> be considered as having inline data.

How did you run across this?  Was this something that was actually
happening?  If so, what was triggering the error?

Or was this something that was found via AI?

I'm fairly sure this patch was created using AI.  This useless
inclusion was a bit of a tip-off:

> +#include <asm-generic/errno-base.h>

As far as the fix is concerned, there's a much better way of
implementing the functionality in ext4_restore_inline_data(), which is
to just capture a copy of the inode (since the inline data is stored
in the inode), and if we need to back out a failed conversion in
ext4_convert_inline_data_nolock(), we can just copy the old contents
of the inode back in place.

We can also do the conversion in a much safer way, by allocating the
data block first, and writing a copy of the data to the data block,
and only if that is successful, do we update the extent tree or
indirect block mapping in the inode.  Of course, this would require a
rewrite of ext4_convert_inline_data_nolock(), but this would allow us
to fix up the other aspects of the error handling which is not quite
right.

						- Ted