Amir Goldstein <amir73il@xxxxxxxxx> writes: > On Tue, Jul 23, 2024 at 10:06 AM Ajay Kaher <ajay.kaher@xxxxxxxxxxxx> 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@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 >> >> -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 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. Is it possible to drop 9709bd548f11 from stable instead? > 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
