linux-ext4 - Re: [PATCH 5.10 387/770] fanotify: Allow users to request FAN_FS

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: <912A3B93-366C-490D-86BF-02599F3E1A97@oracle.com>
Date: Tue, 23 Jul 2024 15:57:48 +0000
From: Chuck Lever III <chuck.lever@...cle.com>
To: Gabriel Krisman Bertazi <gabriel@...sman.be>
CC: Amir Goldstein <amir73il@...il.com>, Ajay Kaher <ajay.kaher@...adcom.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jan Kara <jack@...e.cz>,
        "krisman@...labora.com" <krisman@...labora.com>,
        "patches@...ts.linux.dev"
	<patches@...ts.linux.dev>,
        Sasha Levin <sashal@...nel.org>,
        linux-stable
	<stable@...r.kernel.org>,
        "adilger.kernel@...ger.ca"
	<adilger.kernel@...ger.ca>,
        "linux-ext4@...r.kernel.org"
	<linux-ext4@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>,
        "alexey.makhalov@...adcom.com" <alexey.makhalov@...adcom.com>,
        "vasavi.sirnapalli@...adcom.com" <vasavi.sirnapalli@...adcom.com>,
        "florian.fainelli@...adcom.com" <florian.fainelli@...adcom.com>
Subject: Re: [PATCH 5.10 387/770] fanotify: Allow users to request
 FAN_FS_ERROR events



> On Jul 23, 2024, at 10:34 AM, Gabriel Krisman Bertazi <gabriel@...sman.be> wrote:
> 
> Amir Goldstein <amir73il@...il.com> writes:
> 
>> On Tue, Jul 23, 2024 at 10:06 AM Ajay Kaher <ajay.kaher@...adcom.com> wrote:
>>> Without 9709bd548f11 in v5.10.y skips LTP fanotify22 test case, as:
>>> fanotify22.c:312: TCONF: FAN_FS_ERROR not supported in kernel
>>> 
>>> With 9709bd548f11 in v5.10.220, LTP fanotify22 is failing because of
>>> timeout as no notification. To fix need to merge following two upstream
>>> commit to v5.10:
>>> 
>>> 124e7c61deb27d758df5ec0521c36cf08d417f7a:
>>> 0001-ext4_fix_error_code_saved_on_super_block_during_file_system.patch
>>> https://lore.kernel.org/stable/1721717240-8786-1-git-send-email-ajay.kaher@broadcom.com/T/#mf76930487697d8c1383ed5d21678fe504e8e2305
>>> 
>>> 9a089b21f79b47eed240d4da7ea0d049de7c9b4d:
>>> 0001-ext4_Send_notifications_on_error.patch
>>> Link: https://lore.kernel.org/stable/1721717240-8786-1-git-send-email-ajay.kaher@broadcom.com/T/#md1be98e0ecafe4f92d7b61c048e15bcf286cbd53
>>> 
>>> -Ajay
>> 
>> I agree that this is the best approach, because the test has no other
>> way to test
>> if ext4 specifically supports FAN_FS_ERROR.
>> 
>> Chuck,
>> 
>> I wonder how those patches end up in 5.15.y but not in 5.10.y?
> 
> I wonder why this was backported to stable in the first place.

I wanted to fix the myriad problems with the NFSD file cache
in v5.10.y and v5.15.y. These problems were addressed by a
long list of changes from v5.19 to v6.3. I was told that it
was preferred that I do a full backport of all NFSD commits
from v6.3 to the older kernels.

The fanotify patches were dependencies.


> I get
> there is a lot of refactoring in this series, which might be useful when
> backporting further fixes. but 9709bd548f11 just enabled a new feature -
> which seems against stable rules.  Considering that "anything is a CVE",
> we really need to be cautious about this kind of stuff in stable
> kernels.

These patches were posted for review before they were
included. Amir noted there were some changes to fanotify
that would require man page updates and some modifications
to ltp, but there were no other comments.


> Is it possible to drop 9709bd548f11 from stable instead?

I've attempted a revert. It's not clean, but seems to be
fixable by hand.

I can run some tests to see if that breaks NFSD.


>> Gabriel, if 9abeae5d4458 has a Fixes: tag it may have been auto seleced
>> for 5.15.y after c0baf9ac0b05 was picked up...
> 
> right.  It would be really cool if we had a way to append this
> information after the fact.  How would people feel about using
> git-notes in the kernel tree to support that?
> 
> -- 
> Gabriel Krisman Bertazi

--
Chuck Lever