From: "Theodore Ts'o" <tytso@mit.edu>
To: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Cc: Jan Kara <jack@suse.com>, Tao Ma <boyu.mt@taobao.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Eric Biggers <ebiggers@google.com>,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-dev@igalia.com,
syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com,
stable@vger.kernel.org
Subject: Re: [PATCH] ext4: inline: do not convert when writing to memory map
Date: Tue, 20 May 2025 10:57:08 -0400 [thread overview]
Message-ID: <20250520145708.GA432950@mit.edu> (raw)
In-Reply-To: <20250519-ext4_inline_page_mkwrite-v1-1-865d9a62b512@igalia.com>
On Mon, May 19, 2025 at 07:42:46AM -0300, Thadeu Lima de Souza Cascardo wrote:
> inline data handling has a race between writing and writing to a memory
> map.
>
> When ext4_page_mkwrite is called, it calls ext4_convert_inline_data, which
> destroys the inline data, but if block allocation fails, restores the
> inline data. In that process, we could have:
>
> CPU1 CPU2
> destroy_inline_data
> write_begin (does not see inline data)
> restory_inline_data
> write_end (sees inline data)
>
> The conversion inside ext4_page_mkwrite was introduced at commit
> 7b4cc9787fe3 ("ext4: evict inline data when writing to memory map"). This
> fixes a documented bug in the commit message, which suggests some
> alternatives fixes.
Your fix just reverts commit 7b4cc9787fe3, and removes the BUG_ON.
While this is great for shutting up the syzbot report, but it causes
file writes to an inline data file via a mmap to never get written
back to the storage device. So you are replacing BUG_ON that can get
triggered on a race condition in case of a failed block allocation,
with silent data corruption. This is not an improvement.
Thanks for trying to address this, but I'm not going to accept your
proposed fix.
- Ted
next prev parent reply other threads:[~2025-05-20 14:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-19 10:42 [PATCH] ext4: inline: do not convert when writing to memory map Thadeu Lima de Souza Cascardo
2025-05-20 14:57 ` Theodore Ts'o [this message]
2025-05-21 21:52 ` Thadeu Lima de Souza Cascardo
2025-05-26 13:43 ` Jan Kara
2025-05-26 14:10 ` Thadeu Lima de Souza Cascardo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250520145708.GA432950@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=boyu.mt@taobao.com \
--cc=cascardo@igalia.com \
--cc=ebiggers@google.com \
--cc=jack@suse.com \
--cc=kernel-dev@igalia.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.