linux-kernel - Re: Is it time to remove reiserfs?

lists.openwall.net		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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YhltiUy/WtA0Dz5g@mit.edu>
Date:   Fri, 25 Feb 2022 19:00:09 -0500
From:   "Theodore Ts'o" <tytso@....edu>
To:     Dave Chinner <david@...morbit.com>
Cc:     Willy Tarreau <w@....eu>, Byron Stanoszek <gandalf@...ds.org>,
        Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        reiserfs-devel@...r.kernel.org
Subject: Re: Is it time to remove reiserfs?

On Sat, Feb 26, 2022 at 09:56:00AM +1100, Dave Chinner wrote:
> 
> Hence we have to acknowledge that fact that once upstream has
> deprecated a feature, it's up to distros to decide how they want to
> handle long term support for that feature. The upstream LTS kernel
> maintainers are going to have to decide on their own policy, too,
> because we cannot bind upstream maintenance decisions on random
> individual downstream support constraints. Downstream has to choose
> for itself how it handles upstream deprecation notices but, that
> said, upstream developers also need to listen to downstream distro
> support and deprecation requirements...

This is as it should be.  It might not make a difference for reiserfs,
where the development efforts is largely dead already, but once
upstream deprecates a feature, the distributions can no longer rely on
upstream developers to fix a critical stability or security bug in
upstream, so it can be backported into an LTS or stable distro kernel.
They are on their own.

The bug might even be fixed in one enterprise distro's kernel product,
but an isolated patch might not be available; only a megapatch of all
of the distro's changes afgainst an upstrema kernel as a single
un-broken-out-and-GPL-compliant patch.  So a critical bugfix present
in one distro release might not be so easily carried over to another
distro.

So that's an important thing to remember; an LTS kernel as a whole
might be "supported" by a stable kernel team from a backports
perspective for years, but that doesn't mean that a deprecated feature
or subsystem is going to be receiving upstream support, and it's fair
that this be advertised so that users and distributions can make their
own decisions about how long they want to use or support a deprecated
feature or subsystem on a downstream basis.

						- Ted