Re: [PATCH 4/7] xfs: allow blocking notifier chains with filesystem hooks

Darrick J. Wong
2024-01-03T18:40:17Z

On Tue, Jan 02, 2024 at 11:37:41PM -0800, Christoph Hellwig wrote:
> On Tue, Jan 02, 2024 at 05:07:47PM -0800, Darrick J. Wong wrote:
> > The main arches that xfs really cares about are arm64, ppc64, riscv,
> > s390x, and x86_64, right? Perhaps there's a stronger case for only
> > providing blocking notifiers and jump labels since there aren't many
> > m68k xfs users, right?
>
> Yes. And if there are m68k xfs users, they are even more unlikely to run
> with online repair enabled as they'd be very memory constrained.
>
> So I suspect always using blocking notifiers would be best to keep
> the complexity down. In fact I suspect we should simply make online
> repair depend on jump labels instead of selecting it when available
> to remove anoher rarely tested build combination.

Later on in the online fsck patch series, scrub will start using
LIVE_HOOKS for some of its scanning functionality. I don't know that
anyone will really want to use online fsck on weird old systems like you
said, but while it's EXPERIMENTAL I don't want to lose the option
entirely.

That said, static branches do have a fallback for !HAVE_ARCH_JUMP_LABEL
case, which is raw_atomic_read.

I'll get rid of the srcu notifier chain xfs_hook implementation to
reduce the complexity within xfs. Online fsck will always use static
branches + blocking rwsem notifiers. For modern arches like x64 there
will be almost zero runtime cost due to the nop sled. For m68k and
friends, they can kick the tires on xfs_scrub, but if the performance
sucks due to the READ_ONCE then oh well.

--D