Re: [PATCH v2] xfs: zero newly allocated btree root space

[Yousef Alhouseen]

Understood. I'll rework this as a v3 that zeroes the extents-to-btree
allocation/layout gap at the specific conversion site, instead of
adding __GFP_ZERO to every if_broot allocation and reallocation.

Thanks,
Yousef

On Tue, 7 Jul 2026 09:38:39 -0700, "Darrick J. Wong" <djwong@xxxxxxxxxx> wrote:
> On Tue, Jul 07, 2026 at 10:15:01AM +0200, Carlos Maiolino wrote:
> > On Thu, Jul 02, 2026 at 08:31:02AM -0700, Darrick J. Wong wrote:
> > > On Thu, Jul 02, 2026 at 04:05:06AM -0700, Christoph Hellwig wrote:
> > > > On Wed, Jul 01, 2026 at 08:52:34AM -0700, Darrick J. Wong wrote:
> > > > > > This almost sounds like we should explicitly zero this case just for that
> > > > > > particular case. Although Darrick was kinda heading in a different
> > > > > > direction and I don't want to start a fight here.
> > > > >
> > > > > I'm fine with either solution; I simply prefer the one that fixes all
> > > > > the current and future "oops we forgot to zero a hidden padding" bugs in
> > > > > one action.
> > > >
> > > > Maybe we should avoid creating hidden zero padding to start with? :)
> > > > But this is a small allocation, and most of it gets overwritten
> > > > while the cache is still hot, so I can live with the unconditional
> > > > zeroing. Still feels a bit odd to reach for the big hammer.
> > >
> > > <shrug> If this is truly the only place where we forget to initialize
> > > if_broot fully then I'm ok with just doing that and not going for
> > > GFP_ZERO. If we have an army of KASAN syzbotters whacking away at the
> > > system, then I could reevaluate my resistance to whack-a-mole.
> > >
> > > --D
> > >
> >
> > Sorry, this conversation fell through the cracks.
> >
> > I'd say the right approach here would be to measure the performance
> > penalty if we opt to go with GFP_ZERO and document it on the patch
> > description.
> > But I'd also prefer to just closing this gap and initializing if_broot
> > only here instead of GFP_ZEROing everything.
>
> Ok, let's do that then. I concede there /are/ far fewer
> extents_to_btree calls than if_broot reallocations.
>
> --D