linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Baokun Li <libaokun1@huawei.com>
Cc: Jan Kara <jack@suse.cz>, Qianqiang Liu <qianqiang.liu@163.com>,
	adilger.kernel@dilger.ca,
	syzbot <syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com>,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
	syzkaller-bugs@googlegroups.com,
	Yang Erkun <yangerkun@huawei.com>
Subject: Re: [PATCH] ext4: fix out-of-bounds issue in ext4_xattr_set_entry
Date: Thu, 17 Oct 2024 10:47:31 -0400	[thread overview]
Message-ID: <20241017144731.GA3254556@mit.edu> (raw)
In-Reply-To: <811eb084-55d4-4725-9388-05a6e8f489d9@huawei.com>

On Thu, Oct 17, 2024 at 08:42:59PM +0800, Baokun Li wrote:
> Indeed, our rough plan is to first implement isolation of abnormal file
> system resources, so that the system can continue to run normally even
> when there is an error; then implement online scanning, so that the
> maintainer can see the health report at any time; and finally implement
> the most difficult online repair.

We have some of this already; if a block group has obvious
inconsistencies --- for example, if there is an attempt to mark a
block or inode as free, but it's already marked as free as the
allocation bitmap, we can mark the block group as inconsistent, and
then avoid allocating from the block group.  That's easy because it's
the kind of inconsistency which can be detected locally.

The problem comes with those inconsistencies which require a global
examination of the file system data structures.  For example, is the
refcount of an inode correct?  Or is a block claimed by more than one
inode?  The e2scrub approach requires creating a read-only snapshot
(which is why we need LVM) and then running e2fsck in userspace,
because it does a global examination of all file system data
structures.

> We do need to establish the mapping of physical blocks to inodes and
> inodes to parent dir. By tree managed by jbd2 do you mean updating
> the tree when committing to journal? Or are updates to the tree
> logged to journal?

When we allocate a block, we need to journal the changes to the
allocation bitmap.  If we are going to also update the reverse mapping
data structure, that needs to be journalled also, so that after a
crash, the data structures are consistent.

						- Ted

  reply	other threads:[~2024-10-17 14:47 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-22  0:16 [syzbot] [ext4?] KASAN: out-of-bounds Read in ext4_xattr_set_entry syzbot
2024-09-22  5:46 ` Qianqiang Liu
2024-09-22  6:35   ` syzbot
2024-09-22  6:42     ` [PATCH] ext4: fix out-of-bounds issue " Qianqiang Liu
2024-10-01  9:41       ` Ojaswin Mujoo
2024-10-01 10:15         ` Qianqiang Liu
2024-10-02  6:27         ` Qianqiang Liu
2024-10-08  7:40       ` Baokun Li
2024-10-09 15:50         ` Jan Kara
2024-10-11  2:18           ` Baokun Li
2024-10-14 16:31             ` Jan Kara
2024-10-16  8:02               ` Baokun Li
2024-10-16 20:47                 ` Theodore Ts'o
2024-10-17 12:42                   ` Baokun Li
2024-10-17 14:47                     ` Theodore Ts'o [this message]
2024-10-18  3:44                       ` Baokun Li
2024-10-02  6:31     ` [syzbot] [ext4?] KASAN: out-of-bounds Read " Qianqiang Liu
2024-10-02  6:54       ` syzbot

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=20241017144731.GA3254556@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=libaokun1@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qianqiang.liu@163.com \
    --cc=syzbot+f792df426ff0f5ceb8d1@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=yangerkun@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).