All of lore.kernel.org
 help / color / mirror / Atom feed
From: Albin Babu Varghese <albinbabuvarghese20@gmail.com>
To: Heming Zhao <heming.zhao@suse.com>
Cc: Ahmet Eray Karadag <eraykrdg1@gmail.com>,
	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,
	syzbot+b93b65ee321c97861072@syzkaller.appspotmail.com
Subject: Re: [RFC RFT PATCH] ocfs2: Mark inode bad upon validation failure during read
Date: Thu, 30 Oct 2025 23:59:08 -0400	[thread overview]
Message-ID: <aQQ0DLqL0iVN7D15@arch-box> (raw)
In-Reply-To: <qfizhbe5rwzddwnoekr6xjy3gozbqbtl64c5xmfeuudxvficmv@onazesxv4ur6>

Hi Heming, Thanks for the feedback.

> > I had one question about your proposal to combine this patch with
> > Albin's [1]. When you mentioned, "We should forbid any write
> > operations," were you referring to Albin's read-only check in
> > ocfs2_setattr as the mechanism to "forbid" the operation? Or
> > were you suggesting we should use the inode size sanity check
> > itself (e.g., by converting the BUG_ON to an -EIO return)
> > as that mechanism?
> > 
> 
> The 'forbid' refers to the read-only check in ocfs2_setattr.
> We can refer to ext4_setattr(), which calls ext4_emergency_state()
> to forbid write operations.

I just looked at the ext4 implementation you mentioned. When we were working on
it, I actually referenced how XFS's setattr was handling this because I
couldn't find the exact ext4 implementation for this at the time, so I wasn't
sure. From what I understand now, ext4 is doing something similar too.

If everything looks good, we can combine these two patches and send them as a
patch series.

Best,
	Albin

  reply	other threads:[~2025-10-31  3:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 22:57 [RFC RFT PATCH] ocfs2: Mark inode bad upon validation failure during read Ahmet Eray Karadag
2025-10-30  7:59 ` Heming Zhao
2025-10-30 22:07   ` Ahmet Eray Karadag
2025-10-31  2:30     ` Heming Zhao
2025-10-31  3:59       ` Albin Babu Varghese [this message]
2025-10-31  7:04         ` Heming Zhao
2025-10-31 13:54           ` Albin Babu Varghese
2025-10-31 14:05             ` Heming Zhao
2025-10-31 14:22               ` Albin Babu Varghese
2025-11-04 22:31                 ` Ahmet Eray Karadag
2025-11-05  1:40                   ` Joseph Qi
2025-10-31  7:10 ` 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=aQQ0DLqL0iVN7D15@arch-box \
    --to=albinbabuvarghese20@gmail.com \
    --cc=david.hunter.linux@gmail.com \
    --cc=eraykrdg1@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 \
    --cc=syzbot+b93b65ee321c97861072@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.