Re: [PATCH] Add EXT4_STATE_MAY_INLINE_DATA check in ext4_readdir
"Theodore Tso" <[email protected]>
| Newsgroups | org.kernel.vger.linux-ext4 |
|---|---|
| Message-ID | <[email protected]> |
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