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@xxxxxxxxxxxx/T/#mf76930487697d8c1383ed5d21678fe504e8e2305 > > 9a089b21f79b47eed240d4da7ea0d049de7c9b4d: > 0001-ext4_Send_notifications_on_error.patch > Link: https://lore.kernel.org/stable/1721717240-8786-1-git-send-email-ajay.kaher@xxxxxxxxxxxx/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 :) Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
