All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ahmet Eray Karadag <eraykrdg1@gmail.com>
To: Heming Zhao <heming.zhao@suse.com>
Cc: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.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 1/2] ocfs2: Add ocfs2_emergency_state helper and apply to setattr
Date: Fri, 28 Nov 2025 12:06:28 +0300	[thread overview]
Message-ID: <aSlmFFFxQfbnaRWV@eray-kasa> (raw)
In-Reply-To: <ykvzskyxtwsy42lxxin6avihe6lbub75ywvn7e6zod6m45dpyy@6xkfaynjpuos>

On Tue, Nov 25, 2025 at 10:58:32AM +0800, Heming Zhao wrote:
> On Tue, Nov 18, 2025 at 03:26:44AM +0300, 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.
> > 
> > Suggested-by: Heming Zhao <heming.zhao@suse.com>
> > 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>
> > ---
> >  fs/ocfs2/file.c  | 6 ++++++
> >  fs/ocfs2/ocfs2.h | 8 ++++++++
> >  2 files changed, 14 insertions(+)
> > 
> > diff --git a/fs/ocfs2/file.c b/fs/ocfs2/file.c
> > index 21d797ccccd0..03a98985ac92 100644
> > --- a/fs/ocfs2/file.c
> > +++ b/fs/ocfs2/file.c
> > @@ -1137,6 +1137,12 @@ int ocfs2_setattr(struct mnt_idmap *idmap, struct dentry *dentry,
> >  					from_kgid(&init_user_ns, attr->ia_gid) : 0);
> >  
> >  	/* ensuring we don't even attempt to truncate a symlink */
> > +	status = ocfs2_emergency_state(osb);
> > +	if (status < 0) {
> > +		mlog_errno(status);
> > +		goto bail;
> > +	}
> > +
> 
> I prefer the ext4_emerency_state() style, using "if (unlikely(status))" here.
> 
> >  	if (S_ISLNK(inode->i_mode))
> >  		attr->ia_valid &= ~ATTR_SIZE;
> >  
> > diff --git a/fs/ocfs2/ocfs2.h b/fs/ocfs2/ocfs2.h
> > index 6aaa94c554c1..2ac16632dd19 100644
> > --- a/fs/ocfs2/ocfs2.h
> > +++ b/fs/ocfs2/ocfs2.h
> > @@ -680,6 +680,14 @@ static inline int ocfs2_is_soft_readonly(struct ocfs2_super *osb)
> >  	return ret;
> >  }
> >  
> > +static inline int ocfs2_emergency_state(struct ocfs2_super *osb)
> > +{
> > +	if (ocfs2_is_soft_readonly(osb) || ocfs2_is_hard_readonly(osb)) {
> > +		return -EROFS;
> > +	}
> > +	return 0;
> > +}
> > +
> 
> calling ocfs2_is_[soft|hard]_readonly() is a little expensive because it
> involves acquiring the spinlock osb->osb_lock twice. In my view, we could
> introduce a new function, such as ocfs2_is_readonly():
In ext4, the helper functions check read-only flags without acquiring a lock.
Would it be problematic to do the same in ocfs2?
> 
> ```
> static inline int ocfs2_is_readonly(struct ocfs2_super *osb)
> {
>         int ret;
> 
>         spin_lock(&osb->osb_lock);
>         ret = osb->osb_flags & (OCFS2_OSB_SOFT_RO | OCFS2_OSB_HARD_RO);
>         spin_unlock(&osb->osb_lock);
> 
>         return ret
> }
> ```
> 
> Thanks,
> Heming
> 
> >  static inline int ocfs2_clusterinfo_valid(struct ocfs2_super *osb)
> >  {
> >  	return (osb->s_feature_incompat &
> > -- 
> > 2.43.0
> > 
I agree with the other comments. We will send v2.

  reply	other threads:[~2025-11-28  9:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18  0:26 [PATCH 0/2] ocfs2: Refactor read-only checks to use ocfs2_emergency_state Ahmet Eray Karadag
2025-11-18  0:26 ` [PATCH 1/2] ocfs2: Add ocfs2_emergency_state helper and apply to setattr Ahmet Eray Karadag
2025-11-25  2:58   ` Heming Zhao
2025-11-28  9:06     ` Ahmet Eray Karadag [this message]
2025-12-01  7:43       ` Heming Zhao
2025-11-18  0:26 ` [PATCH 2/2] ocfs2: Convert remaining read-only checks to ocfs2_emergency_state Ahmet Eray Karadag
2025-11-25  3:02   ` Heming Zhao

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=aSlmFFFxQfbnaRWV@eray-kasa \
    --to=eraykrdg1@gmail.com \
    --cc=albinbabuvarghese20@gmail.com \
    --cc=david.hunter.linux@gmail.com \
    --cc=heming.zhao@suse.com \
    --cc=jlbec@evilplan.org \
    --cc=joseph.qi@linux.alibaba.com \
    --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 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.