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: <CAOQ4uxjGrPbq8=znBSV8i79Kj2Or4p5O5BZ0+RL1oXbxxNu3rw@mail.gmail.com>
Date: Tue, 23 Jul 2024 13:13:41 +0300
From: Amir Goldstein <amir73il@...il.com>
To: Jan Kara <jack@...e.cz>
Cc: Ajay Kaher <ajay.kaher@...adcom.com>, gregkh@...uxfoundation.org, 
	chuck.lever@...cle.com, krisman@...labora.com, patches@...ts.linux.dev, 
	sashal@...nel.org, stable@...r.kernel.org, adilger.kernel@...ger.ca, 
	linux-ext4@...r.kernel.org, tytso@....edu, alexey.makhalov@...adcom.com, 
	vasavi.sirnapalli@...adcom.com, florian.fainelli@...adcom.com
Subject: Re: [PATCH 5.10 387/770] fanotify: Allow users to request
 FAN_FS_ERROR events

On Tue, Jul 23, 2024 at 12:29 PM Jan Kara <jack@...e.cz> wrote:
>
> On Tue 23-07-24 12:36:27, Ajay Kaher wrote:
> > > [ Upstream commit 9709bd548f11a092d124698118013f66e1740f9b ]
> > >
> > > Wire up the FAN_FS_ERROR event in the fanotify_mark syscall, allowing
> > > user space to request the monitoring of FAN_FS_ERROR events.
> > >
> > > These events are limited to filesystem marks, so check it is the
> > > case in the syscall handler.
> >
> > Greg,
> >
> > 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
>
> I know Chuck has been backporting the huge pile of fsnotify changes for
> stable and he was running LTP so I'm a bit curious if he saw the fanotify22
> failure as well. The reason for the test failure seems to be that the
> combination of features now present in stable has never been upstream which
> confuses the test. As such I'm not sure if backporting more features to
> stable is warranted just to fix a broken LTP test... But given the huge
> pile Chuck has backported already I'm not strongly opposed to backporting a
> few more, there's just a question where does this stop :)

I'm not sure is it exactly "more features".
The fanotify patches and ext4 patches that use them where merges as
a feature together.

IOW, FAN_FS_ERROR was merged with support for a single fs (ext4)
it would be weird to backport the feature with support for zero fs.
Also, 5.15.y already has the ext4 patches - not sure why 5.10.y didn't get them.

Thanks,
Amir.