ext4: fix racy may inline data check in dio write

In the Linux kernel, the following vulnerability has been resolved:

ext4: fix racy may inline data check in dio write

syzbot reports that the following warning from ext4_iomap_begin()

triggers as of the commit referenced below:

if (WARN_ON_ONCE(ext4_has_inline_data(inode)))

return -ERANGE;

This occurs during a dio write, which is never expected to encounter

an inode with inline data. To enforce this behavior,

ext4_dio_write_iter() checks the current inline state of the inode

and clears the MAY_INLINE_DATA state flag to either fall back to

buffered writes, or enforce that any other writers in progress on

the inode are not allowed to create inline data.

The problem is that the check for existing inline data and the state

flag can span a lock cycle. For example, if the ilock is originally

locked shared and subsequently upgraded to exclusive, another writer

may have reacquired the lock and created inline data before the dio

write task acquires the lock and proceeds.

The commit referenced below loosens the lock requirements to allow

some forms of unaligned dio writes to occur under shared lock, but

AFAICT the inline data check was technically already racy for any

dio write that would have involved a lock cycle. Regardless, lift

clearing of the state bit to the same lock critical section that

checks for preexisting inline data on the inode to close the race.