Re: [PATCH] ext4: convert pa_count from atomic_t to refcount_t

Hello everyone,

Thanks for the helpful responses! My name is Rafael A. Diaz Cruz and I'm hoping
to join the Linux community. I have a background in CS with a Masters from UC
Davis and am currently working as a Software Dev at AMEX.

I read the kernel in my spare time and joined the LFX mentorship starting in
April of this year but due to personal reasons I wasn't able to dedicate
much time until recently. I do hope to contribute more to ext4 and the kernel
as a whole, however, given that the kernel is over 40 million lines of
code I think it
might take me some time to catch up :) I do greatly appreciate your
tolerance for
my lack of expertise!

I did continue looking at what the overall ext4_prealloc_space struct
was used for and realized that the pa_count was being set to 0 on purpose. I did
not understand it at first given that other subsystems in the kernel
treat 0 references
as the object being completely dead. But I think I see now how it's being used.

I did try to build my mental model of how ext4 was treating the
preallocation blocks
from the comments alone, yet, it's taking me some time due to the sheer size of
mballoc.c and its complexity. I was wondering if there are some diagrams that
show the flow of the overall system? I get lost in particular when
thinking of multiple
threads reaching the same function.

Also, I have the unit tests for both the kernel and the ext4 fs but I
would like to know
if there are other methods by which I should check my work besides QEMU.

https://www.linkedin.com/in/rafaelalejandrodiazcruz/


On Mon, Jul 27, 2026 at 1:17 PM Theodore Tso <[email protected]> wrote:
>
> On Mon, Jul 27, 2026 at 01:57:11PM -0500, Jan Kara wrote:
> >
> > This is a bit problematic as for pa_count 0->1 transition is fine (as long
> > as pa_deleted isn't set) so this conversion will trigger false warnings as
> > the 0-day report shows.
>
> For better or for worse, the lifetime rules of the ext4_prealloc_space
> structure don't match those assumed by refcount.h.  Which is to say,
> it's not a reference count the same way that say, struct inode's
> i_links_count.
>
> The whole *point* of the preallocation space is that we are holding
> some blocks for use by an inode or by block group, because it's too
> expensive to figure out that this set of blocks is available for
> allocation.  So even though pa_count is zero, meaning that there isn't
> an *active* allocation in process, under normal circumstances we want
> to keep ext4_prealloc_space around and linked into its relevant linked
> list.  This is why the pa_count 0->1 transition is OK, and it is _not_
> an existing "use after free".
>
> There's actually quite a lot of documentation in fs/ext4/mballoc.c,
> but the comments don't really make this point clearly enough.  I think
> that's because the assumption is that this high-level description of
> what the goals of ext4_prealloc_space is assumed to be known by
> everyone trying to modify that part of the block allocator.
>
> But given that we are having more people trying to submit changes to
> ext4 (in some cases, assisted by LLM's), it might be a good idea to
> improve the documentation, both for the sake of the humans and the
> LLM's that are trying to understand how things work.
>
> Just for yucks, I asked an LLM to explain what a human might want to
> need to know about how the ext4_prealloc_space sutrcture was used, and
> it came up with this.  (See attached.)
>
> I don't propose adding this directly to the beginning of
> fs/ext4/mballoc.c, but we might want to see if there is some parts of
> this that we do want to add.  (And to seeif what we currently have as
> comments at the beginning of mballoc.c is accurate, since I don't
> think anyone has reviewed it in a while.)
>
> Cheers,
>
>                                                 - Ted
>
> P.S.  Hi Rafa/Rafad, it appears that you are a relatively new Kernel
> contributor; I see that the only other patch contribution from your
> gmail account is was to attempt to address a jfs syzkaller issue.  If
> you intend to contribute more ext4 changes, welcome!  It would be
> great if you introduced yourself so we know a bit more about who you
> are, and what name you would prefer to be known by.
>