| Message ID | 20211026184239.151156-11-krisman@collabora.com |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | Test the new fanotify FAN_FS_ERROR event | expand |
On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi <krisman@collabora.com> wrote: > > When multiple FS errors occur, only the first is stored. This testcase > validates this behavior by issuing two different errors and making sure > only the first is stored, while the second is simply accumulated in > error_count. > > Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> Reviewed-by: Amir Goldstein <amir73il@gmail.com> > --- > .../kernel/syscalls/fanotify/fanotify20.c | 26 +++++++++++++++++++ > 1 file changed, 26 insertions(+) > > diff --git a/testcases/kernel/syscalls/fanotify/fanotify20.c b/testcases/kernel/syscalls/fanotify/fanotify20.c > index 7bcddcaa98cb..0083a018f2c6 100644 > --- a/testcases/kernel/syscalls/fanotify/fanotify20.c > +++ b/testcases/kernel/syscalls/fanotify/fanotify20.c > @@ -78,6 +78,18 @@ static void tcase2_trigger_lookup(void) > ret, BAD_DIR, errno, EUCLEAN); > } > > +static void tcase3_trigger(void) > +{ > + trigger_fs_abort(); > + tcase2_trigger_lookup(); So after remount,abort filesystem operations can still be executed? Then I guess my comment from the previous patch about running the test in a loop is not relevant? Thanks, Amir.
Amir Goldstein <amir73il@gmail.com> writes: > On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi >> --- a/testcases/kernel/syscalls/fanotify/fanotify20.c >> +++ b/testcases/kernel/syscalls/fanotify/fanotify20.c >> @@ -78,6 +78,18 @@ static void tcase2_trigger_lookup(void) >> ret, BAD_DIR, errno, EUCLEAN); >> } >> >> +static void tcase3_trigger(void) >> +{ >> + trigger_fs_abort(); >> + tcase2_trigger_lookup(); > > So after remount,abort filesystem operations can still be executed? > Then I guess my comment from the previous patch about running the test in a loop > is not relevant? Hi Amir, As you mentioned here, -i works fine. Abort will remount with MS_RDONLY, and this doesn't affect the existing tests. Future tests that write to the file system inside .trigger_error() would require the umount-mount cycle but, since the goal is testing fanotify and not specific fs errors, I think we don't need the added complexity of such tests. Output of '-i #' always pass: root@test-box:~/ltp/testcases/kernel/syscalls/fanotify# ./fanotify20 -i 5 tst_device.c:88: TINFO: Found free device 0 '/dev/loop0' tst_test.c:932: TINFO: Formatting /dev/loop0 with ext4 opts='' extra opts='' mke2fs 1.46.4 (18-Aug-2021) tst_test.c:1363: TINFO: Timeout per run is 0h 05m 00s fanotify.h:252: TINFO: fid(test_mnt) = 469af9fc.8ced5767.2.0.0... fanotify.h:252: TINFO: fid(test_mnt/internal_dir/bad_dir) = 469af9fc.8ced5767.8002.acd05469.0... debugfs 1.46.4 (18-Aug-2021) fanotify20.c:234: TPASS: Successfully received: Trigger abort fanotify20.c:234: TPASS: Successfully received: Lookup of inode with invalid mode fanotify20.c:234: TPASS: Successfully received: Multiple error submission fanotify20.c:234: TPASS: Successfully received: Multiple error submission 2 fanotify20.c:234: TPASS: Successfully received: Trigger abort fanotify20.c:234: TPASS: Successfully received: Lookup of inode with invalid mode fanotify20.c:234: TPASS: Successfully received: Multiple error submission fanotify20.c:234: TPASS: Successfully received: Multiple error submission 2 fanotify20.c:234: TPASS: Successfully received: Trigger abort fanotify20.c:234: TPASS: Successfully received: Lookup of inode with invalid mode fanotify20.c:234: TPASS: Successfully received: Multiple error submission fanotify20.c:234: TPASS: Successfully received: Multiple error submission 2 fanotify20.c:234: TPASS: Successfully received: Trigger abort fanotify20.c:234: TPASS: Successfully received: Lookup of inode with invalid mode fanotify20.c:234: TPASS: Successfully received: Multiple error submission fanotify20.c:234: TPASS: Successfully received: Multiple error submission 2 fanotify20.c:234: TPASS: Successfully received: Trigger abort fanotify20.c:234: TPASS: Successfully received: Lookup of inode with invalid mode fanotify20.c:234: TPASS: Successfully received: Multiple error submission fanotify20.c:234: TPASS: Successfully received: Multiple error submission 2 Summary: passed 20 failed 0 broken 0 skipped 0 warnings 0 Thanks,
diff --git a/testcases/kernel/syscalls/fanotify/fanotify20.c b/testcases/kernel/syscalls/fanotify/fanotify20.c index 7bcddcaa98cb..0083a018f2c6 100644 --- a/testcases/kernel/syscalls/fanotify/fanotify20.c +++ b/testcases/kernel/syscalls/fanotify/fanotify20.c @@ -78,6 +78,18 @@ static void tcase2_trigger_lookup(void) ret, BAD_DIR, errno, EUCLEAN); } +static void tcase3_trigger(void) +{ + trigger_fs_abort(); + tcase2_trigger_lookup(); +} + +static void tcase4_trigger(void) +{ + tcase2_trigger_lookup(); + trigger_fs_abort(); +} + static struct test_case { char *name; int error; @@ -99,6 +111,20 @@ static struct test_case { .error = EFSCORRUPTED, .fid = &bad_file_fid, }, + { + .name = "Multiple error submission", + .trigger_error = &tcase3_trigger, + .error_count = 2, + .error = ESHUTDOWN, + .fid = &null_fid, + }, + { + .name = "Multiple error submission 2", + .trigger_error = &tcase4_trigger, + .error_count = 2, + .error = EFSCORRUPTED, + .fid = &bad_file_fid, + } }; int check_error_event_info_fid(struct fanotify_event_info_fid *fid,
When multiple FS errors occur, only the first is stored. This testcase validates this behavior by issuing two different errors and making sure only the first is stored, while the second is simply accumulated in error_count. Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.com> --- .../kernel/syscalls/fanotify/fanotify20.c | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+)