On Thu, Jan 09, 2025 at 04:05:13PM +0100, Christian Brauner wrote: > On Wed, Jan 08, 2025 at 04:32:55PM -0600, Bill O'Donnell wrote: > > On Tue, Jan 07, 2025 at 03:35:35PM +0100, Christian Brauner wrote: > > > On Mon, Jan 06, 2025 at 05:24:01PM +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? > > > > > > Let's try and kill it. We can always put it back if we have to. > > > > > So should any work toward converting sysv to the new mount API stop? ;) > > So I would suggest we try and remove it for v6.15. If the removal > survives the release of v6.16 I would call it a (qualified) success. > > If during this time we find out that we have to keep it and have to > reintroduce it then we may as well spend the time to port it to the new > mount api. > > Thoughts? Makes sense to me.
