I disagree with the removal. This is still being used, but people running Debian will notice such bugs only with the next stable release. Imagine their nasty xmas present when SYSVFS support is gone for no reason. Better add a test to CI Ced On Tue, 7 Jan 2025 at 00:31, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > On Mon, Jan 06, 2025 at 02:52:11PM -0500, Jeff Layton wrote: > > On Mon, 2025-01-06 at 17:24 +0100, Jan Kara wrote: > > > Since 2002 (change "Replace BKL for chain locking with sysvfs-private > > > rwlock") the sysv filesystem was doing IO under a rwlock in its > > > get_block() function (yes, a non-sleepable lock hold over a function > > > used to read inode metadata for all reads and writes). Nobody noticed > > > until syzbot in 2023 [1]. This shows nobody is using the filesystem. > > > Just drop it. > > > > > > [1] https://lore.kernel.org/all/0000000000000ccf9a05ee84f5b0@xxxxxxxxxx/ > > > > > > Signed-off-by: Jan Kara <jack@xxxxxxx> > > > --- > > > What do people think about this? Or should we perhaps go through a (short) > > > deprecation period where we warn about removal? > > > > > > > FWIW, it was orphaned in 2023: > > > > commit a8cd2990b694ed2c0ef0e8fc80686c664b4ebbe5 > > Author: Christoph Hellwig <hch@xxxxxx> > > Date: Thu Feb 16 07:29:22 2023 +0100 > > > > orphan sysvfs > > > > This code has been stale for years and I have no way to test it. > > > > > > Given how long this was broken with no one noticing, and since it's not > > being adequately tested, I vote we remove it. > > I concur, if someone really wants this we can always add it back (after > making them deal with the bugs): > > Reviewed-by: "Darrick J. Wong" <djwong@xxxxxxxxxx> > > --D > > > > > Reviewed-by: Jeff Layton <jlayton@xxxxxxxxxx> > > > -- Cedric Blancher <cedric.blancher@xxxxxxxxx> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
