Re: [PATCH 6.6.y] xfs: set max_agbno to allow sparse alloc of last full inode chunk

[Sasha Levin <sashal@kernel.org>]

On Wed, Jan 21, 2026 at 09:08:02AM -0500, Brian Foster wrote:
>On Tue, Jan 20, 2026 at 09:13:29PM -0500, Sasha Levin wrote:
>> From: Brian Foster <bfoster@redhat.com>
>>
>> [ Upstream commit c360004c0160dbe345870f59f24595519008926f ]
>>
>> Sparse inode cluster allocation sets min/max agbno values to avoid
>> allocating an inode cluster that might map to an invalid inode
>> chunk. For example, we can't have an inode record mapped to agbno 0
>> or that extends past the end of a runt AG of misaligned size.
>>
>> The initial calculation of max_agbno is unnecessarily conservative,
>> however. This has triggered a corner case allocation failure where a
>> small runt AG (i.e. 2063 blocks) is mostly full save for an extent
>> to the EOFS boundary: [2050,13]. max_agbno is set to 2048 in this
>> case, which happens to be the offset of the last possible valid
>> inode chunk in the AG. In practice, we should be able to allocate
>> the 4-block cluster at agbno 2052 to map to the parent inode record
>> at agbno 2048, but the max_agbno value precludes it.
>>
>> Note that this can result in filesystem shutdown via dirty trans
>> cancel on stable kernels prior to commit 9eb775968b68 ("xfs: walk
>> all AGs if TRYLOCK passed to xfs_alloc_vextent_iterate_ags") because
>> the tail AG selection by the allocator sets t_highest_agno on the
>> transaction. If the inode allocator spins around and finds an inode
>> chunk with free inodes in an earlier AG, the subsequent dir name
>> creation path may still fail to allocate due to the AG restriction
>> and cancel.
>>
>> To avoid this problem, update the max_agbno calculation to the agbno
>> prior to the last chunk aligned agbno in the AG. This is not
>> necessarily the last valid allocation target for a sparse chunk, but
>> since inode chunks (i.e. records) are chunk aligned and sparse
>> allocs are cluster sized/aligned, this allows the sb_spino_align
>> alignment restriction to take over and round down the max effective
>> agbno to within the last valid inode chunk in the AG.
>>
>> Note that even though the allocator improvements in the
>> aforementioned commit seem to avoid this particular dirty trans
>> cancel situation, the max_agbno logic improvement still applies as
>> we should be able to allocate from an AG that has been appropriately
>> selected. The more important target for this patch however are
>> older/stable kernels prior to this allocator rework/improvement.
>>
>> Cc: stable@vger.kernel.org # v4.2
>> Fixes: 56d1115c9bc7 ("xfs: allocate sparse inode chunks on full chunk allocation failure")
>> Signed-off-by: Brian Foster <bfoster@redhat.com>
>> Reviewed-by: Darrick J. Wong <djwong@kernel.org>
>> Signed-off-by: Carlos Maiolino <cem@kernel.org>
>> [ xfs_ag_block_count(args.mp, pag_agno(pag)) => args.mp->m_sb.sb_agblocks ]
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>
>Hi Sasha,
>
>Thanks for sending out the rest of these. I think there's actually been
>a mixup on the stable targeting for this one. It's true that this fixes
>the commit tagged in the description above, but it really only matters
>in practice for codebases that also include upstream commit
>13325333582d4 ("xfs: fix sparse inode limits on runt AG").
>
>The latter is the commit that fixes the calculation to properly bound on
>the small runt AG case, where both of the associated problems are
>reproduced. This is also the commit that adds the xfs_ag_block_count()
>usage that these backports are working around.
>
>I didn't realize this commit wasn't in these repos when the patch was
>posted, so that is my mistake, but that is why I only went as far as
>resolving the conflict in v6.12. In any event, I think there are three
>options here for remaining stable versions:
>
>1. Disregard this subtlety and proceed with these backports as a safety
>for future inclusion of commit 13325333582d4. I think this is harmless,
>but doesn't effectively fix anything either (JFYI).
>
>2. Also include upstream commit 13325333582d4 as a dependency in these
>repos. This effectively fixes both issues (invalid post-eof inode
>records and allocation failure shutdowns).
>
>3. Drop this backport for repos that don't already have reason to
>include commit 13325333582d4.

Let's just go with option 3 :)

Thanks for the report!

-- 
Thanks,
Sasha