On Tue 07-01-25 08:17:00, Cedric Blancher wrote: > 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. Hum, do you *know* any user of sysv filesystem driver? Because the kernel should be spewing warnings for sleeping in atomic context left and right when you use that driver for 20 years and nobody complained. > Better add a test to CI That's easier said than done. AFAIK we don't have tools to create the filesystem or verify its integrity. And perhaps most importantly I don't know of anyone wishing to invest their time into keeping this filesystem alive. Are you volunteering to become a SYSV maintainer? Honza > 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 -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
