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: Fri, 31 Oct 2025 10:22:14 -0400 [thread overview]
Message-ID: <aQTGFvVX22RmDhb0@arch-box> (raw)
In-Reply-To: <stmj7kbqis2idlscf5iwch23ft2azuyyr7q2kmelavjk5lnug4@66in667d6bym>
> > > I support adding make_bad_inode() in ocfs2_read_inode_block_full().
> > > ocfs2_read_locked_inode() calls ocfs2_read_inode_block[_full] to read the inode
> > > from disk. However, ocfs2_read_inode_block[_full] have many callers, and in
> > > current code, only ocfs2_read_locked_inode() marks the inode as bad. All others
> > > forget to set the bad_inode.
> > >
> > > The 'forbid' write operations when read-only mode is worth another patch, and
> > > I plan to create this patch. This patch adds a similar ext4_emergency_state()
> > > function for ocfs2.
> >
> > We're working on this as part of the Linux Kernel Mentorship Program, and we'd
> > love to take on implementing the read-only check if it's not overly
> > complicated. We're just beginners, but we thought it would be a great learning
> > experience to work on this following the ext4 pattern you mentioned - if you
> > haven't already started working on it by the time you see this reply.
>
> I haven't started the patch job, you are welcome to take it.
Thank you! We'll work on it and send the patch for review.
Cheers,
Albin
next prev parent reply other threads:[~2025-10-31 14:22 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
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 [this message]
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=aQTGFvVX22RmDhb0@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.