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

[Darrick J. Wong]

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