All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Ryusuke Konishi <konishi.ryusuke@gmail.com>
Cc: stable@vger.kernel.org, akpm@linux-foundation.org,
	hdanton@sina.com, jack@suse.cz, willy@infradead.org
Subject: Re: [PATCH 4.19 5.4 5.10 5.15 6.1 6.6] nilfs2: fix incorrect inode allocation from reserved inodes
Date: Tue, 9 Jul 2024 12:36:14 +0200	[thread overview]
Message-ID: <2024070908-fructose-ozone-34cf@gregkh> (raw)
In-Reply-To: <20240709053318.4528-1-konishi.ryusuke@gmail.com>

On Tue, Jul 09, 2024 at 02:33:18PM +0900, Ryusuke Konishi wrote:
> commit 93aef9eda1cea9e84ab2453fcceb8addad0e46f1 upstream.
> 
> If the bitmap block that manages the inode allocation status is corrupted,
> nilfs_ifile_create_inode() may allocate a new inode from the reserved
> inode area where it should not be allocated.
> 
> Previous fix commit d325dc6eb763 ("nilfs2: fix use-after-free bug of
> struct nilfs_root"), fixed the problem that reserved inodes with inode
> numbers less than NILFS_USER_INO (=11) were incorrectly reallocated due to
> bitmap corruption, but since the start number of non-reserved inodes is
> read from the super block and may change, in which case inode allocation
> may occur from the extended reserved inode area.
> 
> If that happens, access to that inode will cause an IO error, causing the
> file system to degrade to an error state.
> 
> Fix this potential issue by adding a wraparound option to the common
> metadata object allocation routine and by modifying
> nilfs_ifile_create_inode() to disable the option so that it only allocates
> inodes with inode numbers greater than or equal to the inode number read
> in "nilfs->ns_first_ino", regardless of the bitmap status of reserved
> inodes.
> 
> Link: https://lkml.kernel.org/r/20240623051135.4180-4-konishi.ryusuke@gmail.com
> Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
> Cc: Hillf Danton <hdanton@sina.com>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> Please apply this patch to the stable trees indicated by the subject
> prefix instead of the patch that failed.
> 
> This patch is tailored to avoid conflicts with a series involving
> extensive conversions and can be applied from v4.8 to v6.8.
> 
> Also, all the builds and tests I did on each stable tree passed.

Now queued up, thanks.

greg k-h

      reply	other threads:[~2024-07-09 10:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-09  5:33 [PATCH 4.19 5.4 5.10 5.15 6.1 6.6] nilfs2: fix incorrect inode allocation from reserved inodes Ryusuke Konishi
2024-07-09 10:36 ` Greg KH [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=2024070908-fructose-ozone-34cf@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=hdanton@sina.com \
    --cc=jack@suse.cz \
    --cc=konishi.ryusuke@gmail.com \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.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.