lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 20 Feb 2022 12:13:04 +0000
From:   Matthew Wilcox <>
To:,,, Jan Kara <>
Subject: Is it time to remove reiserfs?

Keeping reiserfs in the tree has certain costs.  For example, I would
very much like to remove the 'flags' argument to ->write_begin.  We have
the infrastructure in place to handle AOP_FLAG_NOFS differently, but
AOP_FLAG_CONT_EXPAND is still around, used only by reiserfs.

Looking over the patches to reiserfs over the past couple of years, there
are fixes for a few syzbot reports and treewide changes.  There don't
seem to be any fixes for user-spotted bugs since 2019.  Does reiserfs
still have a large install base that is just very happy with an old
stable filesystem?  Or have all its users migrated to new and exciting
filesystems with active feature development?

We've removed support for senescent filesystems before (ext, xiafs), so
it's not unprecedented.  But while I have a clear idea of the benefits to
other developers of removing reiserfs, I don't have enough information to
weigh the costs to users.  Maybe they're happy with having 5.15 support
for their reiserfs filesystems and can migrate to another filesystem
before they upgrade their kernel after 5.15.

Another possibility beyond outright removal would be to trim the kernel
code down to read-only support for reiserfs.  Most of the quirks of
reiserfs have to do with write support, so this could be a useful way
forward.  Again, I don't have a clear picture of how people actually
use reiserfs, so I don't know whether it is useful or not.

NB: Please don't discuss the personalities involved.  This is purely a
"we have old code using old APIs" discussion.

Powered by blists - more mailing lists