Closed edliaw closed 1 week ago
Thanks for a detailed table.
@metan-ucw @mdoucha know more than me. AFAIK we noticed at least incorrect errno EISDIR
(obviously there is also ENODATA
) and hang on TST_FD_EPOLL
(I did not know about the following hangs), although AFAIK we did not reported it to the kernel mainline ML (lore).
splice07 seems to depend on https://github.com/torvalds/linux/commit/36e2c7421f02a22f71c9283e55fdb672a9eb58e7 ("fs: don't allow splice read/write without explicit ops") to pass.
Yes (https://lore.kernel.org/ltp/ZbO-Pl9S7KH2cKkb@yuki/).
FYI before the latest release we whitelisted 2 cases: (c04218579773e3c7017a87d8bb121771e3e0f09c, e5970b2e64c3add251bed820f93443322b1eda05) and had a plan to add tests which actually test splice() on /dev/zero and /proc/self/maps for kernels between v4.4 and v5.3 where it was working (https://lore.kernel.org/ltp/20240126132046.GA508599@pevik/).
The right approach would be to fix the kernel since all these failures are kernel bugs (maybe except for inotify -> writable pipe). It does not make sense to modify the test, not even to add a kernel version check.
splice07 seems to depend on https://github.com/torvalds/linux/commit/36e2c7421f02a22f71c9283e55fdb672a9eb58e7 ("fs: don't allow splice read/write without explicit ops") to pass. I've compiled a list of failing combinations on 5.4, but I'm not sure what's the right approach to modifying the test:
Should it just be gated by kernel version or is there a preferred way to modify it so that it is backwards compatible?