From: Gao Xiang <xiang@kernel.org>
To: Greg KH <greg@kroah.com>
Cc: stable@vger.kernel.org, Sasha Levin <sashal@kernel.org>,
stable-commits@vger.kernel.org, xiang@kernel.org,
Chao Yu <chao@kernel.org>, Yue Hu <zbestahu@gmail.com>,
Jeffle Xu <jefflexu@linux.alibaba.com>,
Sandeep Dhavale <dhavale@google.com>,
Hongbo Li <hongbohbli@tencent.com>,
Chunhai Guo <guochunhai@vivo.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
linux-erofs@lists.ozlabs.org
Subject: Re: Patch "erofs: remove fscache backend entirely" has been added to the 6.18-stable tree
Date: Tue, 13 Oct 2026 13:30:20 +0200 [thread overview]
Message-ID: <as4WTEbunXMcOIvc@MacBookPro> (raw)
In-Reply-To: <2026101340-upcountry-wildland-6ebf@gregkh>
On Tue, Oct 13, 2026 at 12:37:56PM +0200, Greg KH wrote:
> On Tue, Oct 13, 2026 at 10:16:29AM +0200, Gao Xiang wrote:
> > Hi Greg,
> >
> > On Tue, Oct 13, 2026 at 09:59:58AM +0200, Greg KH wrote:
> > > On Tue, Oct 13, 2026 at 09:28:44AM +0200, Gao Xiang wrote:
> > > > Hi Sasha,
> > > >
> > > > I'm not sure why we need to backport this into stable kernels, as there
> > > > are users who use EROFS over fscache on these stable kernels.
> > > >
> > > > The functionality works and it's a breaking change. Could you please
> > > > kindly tell why?
> > >
> > > Why would you have a breaking change in Linus's tree? We never break
> > > existing users, so how was this ever accepted in mainline?
> >
> > Because the similar + better functionality "erofs over fanotify" is
> > already available in the recent upstream, and it has simpler interfaces
> > than "erofs over fscache.", so we don't actually break users as long
> > as one of those functionalities exist ("erofs over fanotify" or
> > "erofs over fscache". Many stable kernels don't support "erofs over
> > fsnotify", so backport this commit will make existing users using
> > old stable kernels have no choice (no "erofs over fanotify" nor
> > "erofs over fscache").
> >
> > The commit message is already described well I think.
> >
> > >
> > > As this removal fixes known bugs, isn't that a good thing for those
> > > older users as well? Why would you want them to run broken systems?
> >
> > I think it depends on the importance of the bug, at least "erofs over
> > fscache" is usable (and it's used by vendors) on stable kernels, but
> > it's unneeded to address every edge case found by LLMs since I mostly
> > think it doesn't impact the real use case, and as I said, we have
> > a new unique interface ("erofs over fanotify") now, but only on very
> > latest kernels.
> >
> > Also there could always be breaking changes for various reasons (e.g.
> > obsolete/dispute filesystem breaking changes these years like
> > bcachefs, etc), will these commits be backported to all stable kernels
> > too?
>
> Sometimes, yes they are.
>
> But this makes sense, I'll go drop this patch now, thanks.
Thanks, Greg. As I said, "erofs over fscache" is still used by
Xiaomi on old stable kernels for example:
https://lore.kernel.org/all/20260923084823.496741-1-hwenwur@gmail.com
But we prefer to use fanotify in recent kernels and it has
a simpler and unique interface than the old one.
There is no need to leave two same functionality features within
the same codebase, so we deprecated fscache two years ago, and
removed it months before so that we could sunset the old
interface over time.
I think another similar example is XFS v4 format, The kconfig says
that it will be removed in 2030 as well:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/xfs/Kconfig?h=v7.2#n51
Thanks,
Gao Xiang
>
> greg k-h
>
next prev parent reply other threads:[~2026-10-13 11:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20261013020044.2527207-1-sashal@kernel.org>
2026-10-13 7:28 ` Patch "erofs: remove fscache backend entirely" has been added to the 6.18-stable tree Gao Xiang
2026-10-13 7:59 ` Greg KH
2026-10-13 8:16 ` Gao Xiang
2026-10-13 10:37 ` Greg KH
2026-10-13 11:30 ` Gao Xiang [this message]
2026-10-13 11:10 ` Michael Bommarito
2026-10-13 11:22 ` Gao Xiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=as4WTEbunXMcOIvc@MacBookPro \
--to=xiang@kernel.org \
--cc=chao@kernel.org \
--cc=corbet@lwn.net \
--cc=dhavale@google.com \
--cc=greg@kroah.com \
--cc=guochunhai@vivo.com \
--cc=hongbohbli@tencent.com \
--cc=jefflexu@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=rdunlap@infradead.org \
--cc=sashal@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=stable-commits@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=zbestahu@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.