Re: [PATCH v2] xfs: zero newly allocated btree root space
Yousef Alhouseen <[email protected]>
| Newsgroups | org.kernel.vger.linux-xfs,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CAMuQ4bUA2LOVRKZ+0DJy2uBBUTAabZ7-gO68T+a+dc4n5zApyA@mail.gmail.com> |
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" <[email protected]> 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