Jan Kara changed bug 1216841
What Removed Added
Status NEW IN_PROGRESS

Comment # 7 on bug 1216841 from Jan Kara
So the first thing to note: fanotify16 test from LTP is passing for me in my
test VM with SLE15-SP6 kernel (as well as current upstream kernel) and always
has been as far as I remember. The EXDEV failure seems to be some artifact in
how openQA runs this test. Also there were no recent changes to fanotify or
ext4 driver (which is used for ext2 test) that I'd be aware of that could cause
this error or appear / disappear...

Now to the EXDEV error from fanotify_mark(2) itself. This error can be
generated by fanotify_mark() in exactly one place and that is
fanotify_test_fsid() if f_fsid as reported by statfs(2) for the path passed to
fanotify_mark(2) is different from f_fsid reported by statfs(2) for the root of
the filesystem containing the path. The only filesystem where these two fsid's
could differ is btrfs (with subvolumes) so it really doesn't make sense that
the test would fail with this error for ext2... checking the details of the
fanotify16 test ... oh, the fanotify_mark() call that is failing is before we
actually get to testing the real functionality in
fanotify_events_supported_by_kernel() where we do (already did const
propagation ;):

fanotify_mark(fd, FAN_MARK_ADD, FAN_RENAME, AT_FDCWD, ".")

so *if* the LTP is run so that CWD is actually in a subvolume of btrfs
filesystem, then indeed this would be failing. Now we are planning to lift this
limitation from btrfs but it didn't happen yet so I suspect what has likely
happened is that in Tumbleweed openQA started to execute LTP with different CWD
and so the test started to pass.

In either case this is a bug in fanotify16 test. I'll take it to upstream so
that this is fixed but wrt SLE15-SP6, I'd say we can safely ignore this.


You are receiving this mail because: