[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260109151740.GR21071@suse.cz>
Date: Fri, 9 Jan 2026 16:17:41 +0100
From: David Sterba <dsterba@...e.cz>
To: Qu Wenruo <wqu@...e.com>
Cc: Jiasheng Jiang <jiashengjiangcool@...il.com>, Chris Mason <clm@...com>,
David Sterba <dsterba@...e.com>, linux-btrfs@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] btrfs: add missing ASSERT for system space_info in
reserve_chunk_space
On Fri, Jan 09, 2026 at 10:02:00AM +1030, Qu Wenruo wrote:
>
>
> 在 2026/1/9 06:15, Jiasheng Jiang 写道:
> > In reserve_chunk_space(), btrfs_find_space_info() is called to retrieve
> > the space_info for the SYSTEM block group. However, the returned pointer
> > is immediately dereferenced by spin_lock(&info->lock) without validation.
> >
> > While the SYSTEM space_info is expected to be present during normal
> > operations, direct dereference without checking creates a risk of a
> > null pointer dereference. This deviates from the coding pattern seen
> > in peer functions like btrfs_chunk_alloc() where such returns are
> > validated with an ASSERT.
> >
> > Add an ASSERT() to ensure the pointer is valid before access, improving
> > code robustness and consistency with the rest of the block-group logic.
>
> If you know how system chunk works, you must understand without a system
> chunk a btrfs will never be mounted.
>
> The ASSERT() looks unnecessary to me.
Agreed. I tried to look for justification or an assertion pattern we
might have yet incomplete but I don't see it. The system chunk assertion
is in some functions but not everywhere, was added when zoned code was
extended so this makes some sense. We also don't validate most of the
btrfs_find_space_info() calls and I don't think we should, besides the
initial setup that must lead to a real error.
Powered by blists - more mailing lists