From: Joseph Qi <joseph.qi@linux.alibaba.com>
To: Ahmet Eray Karadag <eraykrdg1@gmail.com>
Cc: mark@fasheh.com, jlbec@evilplan.org,
Heming Zhao <heming.zhao@suse.com>,
ocfs2-devel@lists.linux.dev, linux-kernel@vger.kernel.org,
david.hunter.linux@gmail.com, skhan@linuxfoundation.org,
Albin Babu Varghese <albinbabuvarghese20@gmail.com>
Subject: Re: [PATCH v3 2/2] ocfs2: Convert remaining read-only checks to ocfs2_emergency_state
Date: Wed, 3 Dec 2025 09:00:53 +0800 [thread overview]
Message-ID: <c160b184-8411-40d9-94b7-3fe6caea907e@linux.alibaba.com> (raw)
In-Reply-To: <aS-IVZyCZgE115f6@eray-kasa>
On 2025/12/3 08:46, Ahmet Eray Karadag wrote:
> On Tue, Dec 02, 2025 at 03:39:30PM +0800, Joseph Qi wrote:
>>
>>
>> On 2025/12/2 10:54, Ahmet Eray Karadag wrote:
>>> To centralize error checking, follow the pattern of other filesystems
>>> like ext4 (which uses `ext4_emergency_state()`), and prepare for
>>> future enhancements, this patch introduces a new helper function:
>>> `ocfs2_emergency_state()`.
>>>
>>> The purpose of this helper is to provide a single, unified location
>>> for checking all filesystem-level emergency conditions. In this
>>> initial implementation, the function only checks for the existing
>>> hard and soft read-only modes, returning -EROFS if either is set.
>>>
>>> This provides a foundation where future checks (e.g., for fatal error
>>> states returning -EIO, or shutdown states) can be easily added in
>>> one place.
>>>
>>> This patch also adds this new check to the beginning of
>>> `ocfs2_setattr()`. This ensures that operations like `ftruncate`
>>> (which triggered the original BUG) fail-fast with -EROFS when the
>>> filesystem is already in a read-only state.
>>>
>>
>> The above commit log is the same with patch 1 and doesn't reflect
>> the following changes.
>>
>>> Co-developed-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
>>> Signed-off-by: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
>>> Signed-off-by: Ahmet Eray Karadag <eraykrdg1@gmail.com>
>>> ---
>>> v2:
>>> - Use `unlikely()` for status check
>>> ---
>>> fs/ocfs2/buffer_head_io.c | 4 ++--
>>> fs/ocfs2/file.c | 17 ++++++++++-------
>>> fs/ocfs2/inode.c | 3 +--
>>> fs/ocfs2/move_extents.c | 5 +++--
>>> fs/ocfs2/resize.c | 8 +++++---
>>> fs/ocfs2/super.c | 2 +-
>>> 6 files changed, 22 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/fs/ocfs2/buffer_head_io.c b/fs/ocfs2/buffer_head_io.c
>>> index 8f714406528d..61a0f522c673 100644
>>> --- a/fs/ocfs2/buffer_head_io.c
>>> +++ b/fs/ocfs2/buffer_head_io.c
>>> @@ -434,8 +434,8 @@ int ocfs2_write_super_or_backup(struct ocfs2_super *osb,
>>> BUG_ON(buffer_jbd(bh));
>>> ocfs2_check_super_or_backup(osb->sb, bh->b_blocknr);
>>>
>>> - if (ocfs2_is_hard_readonly(osb) || ocfs2_is_soft_readonly(osb)) {
>>> - ret = -EROFS;
>>> + ret = ocfs2_emergency_state(osb);
>>> + if (unlikely(ret)) {
>>
>> I'd like use the following style:
>> if (ocfs2_emergency_state(osb)) {
>> ret = -EROFS;
>> ...
>> }
>>
>> So that ocfs2_emergency_state() can be expended with other cases(properly
>> other return code), without touching these code flows.
>
> In the future, there might be other return codes added to ocfs2_emergency_state().
> Correct me if I'm wrong, but with your proposed style, we would only return
> -EROFS in any case. Shouldn't we consider future improvements?
>
> Thanks,
> Ahmet Eray
>>
Return EROFS here is to be consistent with before.
i.e. No functional change.
Joseph
prev parent reply other threads:[~2025-12-03 1:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 2:54 [PATCH v3 0/2] ocfs2: Refactor read-only checks to use ocfs2_emergency_state Ahmet Eray Karadag
2025-12-02 2:54 ` [PATCH v3 1/2] ocfs2: Add ocfs2_emergency_state helper and apply to setattr Ahmet Eray Karadag
2025-12-02 3:16 ` Heming Zhao
2025-12-02 7:31 ` Joseph Qi
2025-12-02 2:54 ` [PATCH v3 2/2] ocfs2: Convert remaining read-only checks to ocfs2_emergency_state Ahmet Eray Karadag
2025-12-02 3:16 ` Heming Zhao
2025-12-02 7:39 ` Joseph Qi
2025-12-03 0:46 ` Ahmet Eray Karadag
2025-12-03 1:00 ` Joseph Qi [this message]
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=c160b184-8411-40d9-94b7-3fe6caea907e@linux.alibaba.com \
--to=joseph.qi@linux.alibaba.com \
--cc=albinbabuvarghese20@gmail.com \
--cc=david.hunter.linux@gmail.com \
--cc=eraykrdg1@gmail.com \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=skhan@linuxfoundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®