From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:18
Hi,
Now that FAN_FS_ERROR is close to being merged, I'm sending out a new
version of the LTP tests. This version only applies the previous
feedback and updates the interface to correspond to the changes
requested on the kernel patches.
One important detail is that, for the tests to succeed, there is a
dependency on an ext4 fix I sent today:
https://lore.kernel.org/linux-ext4/20211026173302.84000-1-krisman@collabora.com/T/#u
---
Original cover letter:
FAN_FS_ERROR is a new (still unmerged) fanotify event to monitor
fileystem errors. This patchset introduces a new LTP test for this
feature.
Testing file system errors is slightly tricky, in particular because
they are mostly file system dependent. Since there are only patches for
ext4, I choose to make the test around it, since there wouldn't be much
to do with other file systems. The second challenge is how we cause the
file system errors, since there is no error injection for ext4 in Linux.
In this series, this is done by corrupting specific data in the
test device with the help of debugfs.
The FAN_FS_ERROR feature is flying around linux-ext4 and fsdevel, and
the latest version is available on the branch below:
https://gitlab.collabora.com/krisman/linux -b fanotify-notifications-v9
A proper manpage description is also available on the respective mailing
list, or in the branch below:
https://gitlab.collabora.com/krisman/man-pages.git -b fan-fs-error
Please, let me know your thoughts.
Gabriel Krisman Bertazi (10):
syscalls: fanotify: Add macro to require specific mark types
syscalls: fanotify: Add macro to require specific events
syscalls/fanotify20: Introduce helpers for FAN_FS_ERROR test
syscalls/fanotify20: Validate the generic error info
syscalls/fanotify20: Validate incoming FID in FAN_FS_ERROR
syscalls/fanotify20: Support submission of debugfs commands
syscalls/fanotify20: Create a corrupted file
syscalls/fanotify20: Test event after filesystem abort
syscalls/fanotify20: Test file event with broken inode
syscalls/fanotify20: Test capture of multiple errors
testcases/kernel/syscalls/fanotify/.gitignore | 1 +
testcases/kernel/syscalls/fanotify/fanotify.h | 72 +++-
.../kernel/syscalls/fanotify/fanotify03.c | 4 +-
.../kernel/syscalls/fanotify/fanotify10.c | 3 +-
.../kernel/syscalls/fanotify/fanotify12.c | 3 +-
.../kernel/syscalls/fanotify/fanotify20.c | 313 ++++++++++++++++++
6 files changed, 389 insertions(+), 7 deletions(-)
create mode 100644 testcases/kernel/syscalls/fanotify/fanotify20.c
--
2.33.0
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:20
Like done for init flags and event types, and a macro to require a
specific mark type.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify.h | 5 +++++
1 file changed, 5 insertions(+)
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:27
Add a helper for tests to fail if an event is not available in the
kernel. Since some events only work with REPORT_FID or a specific
class, update the verifier to allow those to be specified.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify.h | 28 +++++++++++++++++--
.../kernel/syscalls/fanotify/fanotify03.c | 4 +--
.../kernel/syscalls/fanotify/fanotify10.c | 3 +-
.../kernel/syscalls/fanotify/fanotify12.c | 3 +-
4 files changed, 31 insertions(+), 7 deletions(-)
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:34
fanotify20 is a new test validating the FAN_FS_ERROR file system error
event. This adds some basic structure for the next patches.
The strategy for error reporting testing in fanotify20 goes like this:
- Generate a broken filesystem
- Start FAN_FS_ERROR monitoring group
- Make the file system notice the error through ordinary operations
- Observe the event generated
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
Changes since v1:
- Move defines to header file.
---
testcases/kernel/syscalls/fanotify/.gitignore | 1 +
testcases/kernel/syscalls/fanotify/fanotify.h | 3 +
.../kernel/syscalls/fanotify/fanotify20.c | 128 ++++++++++++++++++
3 files changed, 132 insertions(+)
create mode 100644 testcases/kernel/syscalls/fanotify/fanotify20.c
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:40
Implement some validation for the generic error info record emitted by
the kernel. The error number is fs-specific but, well, we only support
ext4 for now anyway.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
Changes since v1:
- Move defines to header file.
---
testcases/kernel/syscalls/fanotify/fanotify.h | 32 +++++++++++++++++
.../kernel/syscalls/fanotify/fanotify20.c | 35 ++++++++++++++++++-
2 files changed, 66 insertions(+), 1 deletion(-)
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:52
Verify the FID provided in the event. If the FH has size 0, this is
assumed to be a superblock error (i.e. null FH).
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
Changes since v1:
- Move defines to header file.
- Use 0-len FH for sb error
---
testcases/kernel/syscalls/fanotify/fanotify.h | 4 ++
.../kernel/syscalls/fanotify/fanotify20.c | 63 +++++++++++++++++++
2 files changed, 67 insertions(+)
@@ -34,20 +34,61 @@#ifdef HAVE_SYS_FANOTIFY_H#include"fanotify.h"+#ifndef FILEID_INVALID+#define FILEID_INVALID 0xff+#endif+#define BUF_SIZE 256staticcharevent_buf[BUF_SIZE];intfd_notify;#define MOUNT_PATH "test_mnt"+/* These expected FIDs are common to multiple tests */+staticstructfanotify_fid_tnull_fid;+staticstructtest_case{char*name;interror;unsignedinterror_count;+structfanotify_fid_t*fid;void(*trigger_error)(void);}testcases[]={};+intcheck_error_event_info_fid(structfanotify_event_info_fid*fid,+conststructtest_case*ex)+{+structfile_handle*fh=(structfile_handle*)&fid->handle;++if(memcmp(&fid->fsid,&ex->fid->fsid,sizeof(fid->fsid))){+tst_res(TFAIL,"%s: Received bad FSID type (%x...!=%x...)",+ex->name,FSID_VAL_MEMBER(fid->fsid,0),+FSID_VAL_MEMBER(ex->fid->fsid,0));++return1;+}+if(fh->handle_type!=ex->fid->handle.handle_type){+tst_res(TFAIL,"%s: Received bad file_handle type (%d!=%d)",+ex->name,fh->handle_type,ex->fid->handle.handle_type);+return1;+}++if(fh->handle_bytes!=ex->fid->handle.handle_bytes){+tst_res(TFAIL,"%s: Received bad file_handle len (%d!=%d)",+ex->name,fh->handle_bytes,ex->fid->handle.handle_bytes);+return1;+}++if(memcmp(fh->f_handle,ex->fid->handle.f_handle,fh->handle_bytes)){+tst_res(TFAIL,"%s: Received wrong handle. "+"Expected (%x...) got (%x...) ",ex->name,+*(int*)ex->fid->handle.f_handle,*(int*)fh->f_handle);+return1;+}+return0;+}+intcheck_error_event_info_error(structfanotify_event_info_error*info_error,conststructtest_case*ex){
@@ -109,6 +151,14 @@ void check_event(char *buf, size_t len, const struct test_case *ex)fail++;}+info_fid=get_event_info_fid(event);+if(info_fid)+fail+=check_error_event_info_fid(info_fid,ex);+else{+tst_res(TFAIL,"FID record not found");+fail++;+}+if(!fail)tst_res(TPASS,"Successfully received: %s",ex->name);}
@@ -125,12 +175,25 @@ static void do_test(unsigned int i)check_event(event_buf,read_len,tcase);}+staticvoidinit_null_fid(void)+{+/* Use fanotify_save_fid to fill the fsid and overwrite the+*file_handlertocreateanull_fid+*/+fanotify_save_fid(MOUNT_PATH,&null_fid);++null_fid.handle.handle_type=FILEID_INVALID;+null_fid.handle.handle_bytes=0;+}+staticvoidsetup(void){REQUIRE_FANOTIFY_EVENTS_SUPPORTED_ON_FS(FAN_CLASS_NOTIF|FAN_REPORT_FID,FAN_MARK_FILESYSTEM,FAN_FS_ERROR,".");+init_null_fid();+fd_notify=SAFE_FANOTIFY_INIT(FAN_CLASS_NOTIF|FAN_REPORT_FID,O_RDONLY);
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:43:59
In order to test FAN_FS_ERROR, we want to corrupt the filesystem. The
easiest way to do it is by using debugfs. Add a small helper to issue
debugfs requests. Since most likely this will be the only testcase to
need this, don't bother making it a proper helper for now.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
changes since v1:
- Add .needs_cmds to require debugfs
---
testcases/kernel/syscalls/fanotify/fanotify20.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
@@ -47,6 +47,13 @@ int fd_notify;/* These expected FIDs are common to multiple tests */staticstructfanotify_fid_tnull_fid;+staticvoiddo_debugfs_request(constchar*dev,char*request)+{+constchar*cmd[]={"debugfs","-w",dev,"-R",request,NULL};++SAFE_CMD(cmd,NULL,NULL);+}+staticstructtest_case{char*name;interror;
@@ -216,7 +223,11 @@ static struct tst_test test = {.mntpoint=MOUNT_PATH,.all_filesystems=0,.needs_root=1,-.dev_fs_type="ext4"+.dev_fs_type="ext4",+.needs_cmds=(constchar*[]){+"debugfs",+NULL+}};#else
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:44:06
Allocate a test directory and corrupt it with debugfs. The corruption
is done by writing an invalid inode mode. This file can be later
looked up to trigger a corruption error.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify20.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
@@ -43,9 +43,12 @@ static char event_buf[BUF_SIZE];intfd_notify;#define MOUNT_PATH "test_mnt"+#define BASE_DIR "internal_dir"+#define BAD_DIR BASE_DIR"/bad_dir"/* These expected FIDs are common to multiple tests */staticstructfanotify_fid_tnull_fid;+staticstructfanotify_fid_tbad_file_fid;staticvoiddo_debugfs_request(constchar*dev,char*request){
@@ -182,6 +185,18 @@ static void do_test(unsigned int i)check_event(event_buf,read_len,tcase);}+staticvoidpre_corrupt_fs(void)+{+SAFE_MKDIR(MOUNT_PATH"/"BASE_DIR,0777);+SAFE_MKDIR(MOUNT_PATH"/"BAD_DIR,0777);++fanotify_save_fid(MOUNT_PATH"/"BAD_DIR,&bad_file_fid);++SAFE_UMOUNT(MOUNT_PATH);+do_debugfs_request(tst_device->dev,"sif "BAD_DIR" mode 0xff");+SAFE_MOUNT(tst_device->dev,MOUNT_PATH,tst_device->fs_type,0,NULL);+}+staticvoidinit_null_fid(void){/* Use fanotify_save_fid to fill the fsid and overwrite the
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:44:19
This test monitors the error triggered after a file system abort. It
works by forcing a remount with the option "abort". This is an error
not related to a file so it is reported against the superblock with a
zero size fh.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify20.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:44:21
This test corrupts an inode entry with an invalid mode through debugfs
and then tries to access it. This should result in a ext4 error, which
we monitor through the fanotify group.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
.../kernel/syscalls/fanotify/fanotify20.c | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
@@ -63,6 +67,17 @@ static void trigger_fs_abort(void)MS_REMOUNT|MS_RDONLY,"abort");}+staticvoidtcase2_trigger_lookup(void)+{+intret;++/* SAFE_OPEN cannot be used here because we expect it to fail. */+ret=open(MOUNT_PATH"/"BAD_DIR,O_RDONLY,0);+if(ret!=-1&&errno!=EUCLEAN)+tst_res(TFAIL,"Unexpected lookup result(%d) of %s (%d!=%d)",+ret,BAD_DIR,errno,EUCLEAN);+}+staticstructtest_case{char*name;interror;
@@ -77,6 +92,13 @@ static struct test_case {.error=ESHUTDOWN,.fid=&null_fid,},+{+.name="Lookup of inode with invalid mode",+.trigger_error=&tcase2_trigger_lookup,+.error_count=1,+.error=EFSCORRUPTED,+.fid=&bad_file_fid,+},};intcheck_error_event_info_fid(structfanotify_event_info_fid*fid,
From: Gabriel Krisman Bertazi <hidden> Date: 2021-10-26 18:44:30
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 <redacted>
---
.../kernel/syscalls/fanotify/fanotify20.c | 26 +++++++++++++++++++
1 file changed, 26 insertions(+)
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:24:05
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
quoted hunk
Add a helper for tests to fail if an event is not available in the
kernel. Since some events only work with REPORT_FID or a specific
class, update the verifier to allow those to be specified.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify.h | 28 +++++++++++++++++--
.../kernel/syscalls/fanotify/fanotify03.c | 4 +--
.../kernel/syscalls/fanotify/fanotify10.c | 3 +-
.../kernel/syscalls/fanotify/fanotify12.c | 3 +-
4 files changed, 31 insertions(+), 7 deletions(-)
init flags in the print are incorrect, but I don't think you should
bother with that.
I think you should leave SAFE_FANOTIFY_INIT, because none of the existing
tests are going to fail the init flags and seems like your new test is
going to use the
REQUIRE_FANOTIFY_EVENTS_SUPPORTED_ON_FS macro that will fail
on unsupported init flags (with correct print) anyway.
The hardcoded FAN_CLASS_CONTENT was the common flag to use for all
test, but this
test in particular does not use FAN_CLASS_CONTENT it uses FAN_CLASS_NOTIFY, so
let's express the requirements accurately.
Thanks,
Amir.
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:33:58
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
quoted hunk
fanotify20 is a new test validating the FAN_FS_ERROR file system error
event. This adds some basic structure for the next patches.
The strategy for error reporting testing in fanotify20 goes like this:
- Generate a broken filesystem
- Start FAN_FS_ERROR monitoring group
- Make the file system notice the error through ordinary operations
- Observe the event generated
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
Changes since v1:
- Move defines to header file.
---
testcases/kernel/syscalls/fanotify/.gitignore | 1 +
testcases/kernel/syscalls/fanotify/fanotify.h | 3 +
.../kernel/syscalls/fanotify/fanotify20.c | 128 ++++++++++++++++++
3 files changed, 132 insertions(+)
create mode 100644 testcases/kernel/syscalls/fanotify/fanotify20.c
I think it is better to have the mark add/remove inside do_test
This way when running fanotify -i 10 (which testers do)
we also get test coverage for add/remove of mark with FS_ERROR mask.
Thanks,
Amir.
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:43:58
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
Implement some validation for the generic error info record emitted by
the kernel. The error number is fs-specific but, well, we only support
ext4 for now anyway.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
After fixing and testing configure.ac you may add:
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Need to add in configure.ac:
AC_CHECK_TYPES([struct fanotify_event_info_error, struct
fanotify_event_info_header],,,[#include <sys/fanotify.h>])
(not tested)
quoted hunk
+
/* NOTE: only for struct fanotify_event_info_fid */
#ifdef HAVE_STRUCT_FANOTIFY_EVENT_INFO_FID_FSID___VAL
# define FSID_VAL_MEMBER(fsid, i) (fsid.__val[i])
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:48:55
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
Verify the FID provided in the event. If the FH has size 0, this is
assumed to be a superblock error (i.e. null FH).
Signed-off-by: Gabriel Krisman Bertazi <redacted>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Except maybe move define of FILEID_INVALID to header.
quoted hunk
---
Changes since v1:
- Move defines to header file.
- Use 0-len FH for sb error
---
testcases/kernel/syscalls/fanotify/fanotify.h | 4 ++
.../kernel/syscalls/fanotify/fanotify20.c | 63 +++++++++++++++++++
2 files changed, 67 insertions(+)
@@ -34,20 +34,61 @@#ifdef HAVE_SYS_FANOTIFY_H#include"fanotify.h"+#ifndef FILEID_INVALID+#define FILEID_INVALID 0xff+#endif+#define BUF_SIZE 256staticcharevent_buf[BUF_SIZE];intfd_notify;#define MOUNT_PATH "test_mnt"+/* These expected FIDs are common to multiple tests */+staticstructfanotify_fid_tnull_fid;+staticstructtest_case{char*name;interror;unsignedinterror_count;+structfanotify_fid_t*fid;void(*trigger_error)(void);}testcases[]={};+intcheck_error_event_info_fid(structfanotify_event_info_fid*fid,+conststructtest_case*ex)+{+structfile_handle*fh=(structfile_handle*)&fid->handle;++if(memcmp(&fid->fsid,&ex->fid->fsid,sizeof(fid->fsid))){+tst_res(TFAIL,"%s: Received bad FSID type (%x...!=%x...)",+ex->name,FSID_VAL_MEMBER(fid->fsid,0),+FSID_VAL_MEMBER(ex->fid->fsid,0));++return1;+}+if(fh->handle_type!=ex->fid->handle.handle_type){+tst_res(TFAIL,"%s: Received bad file_handle type (%d!=%d)",+ex->name,fh->handle_type,ex->fid->handle.handle_type);+return1;+}++if(fh->handle_bytes!=ex->fid->handle.handle_bytes){+tst_res(TFAIL,"%s: Received bad file_handle len (%d!=%d)",+ex->name,fh->handle_bytes,ex->fid->handle.handle_bytes);+return1;+}++if(memcmp(fh->f_handle,ex->fid->handle.f_handle,fh->handle_bytes)){+tst_res(TFAIL,"%s: Received wrong handle. "+"Expected (%x...) got (%x...) ",ex->name,+*(int*)ex->fid->handle.f_handle,*(int*)fh->f_handle);+return1;+}+return0;+}+intcheck_error_event_info_error(structfanotify_event_info_error*info_error,conststructtest_case*ex){
@@ -109,6 +151,14 @@ void check_event(char *buf, size_t len, const struct test_case *ex)fail++;}+info_fid=get_event_info_fid(event);+if(info_fid)+fail+=check_error_event_info_fid(info_fid,ex);+else{+tst_res(TFAIL,"FID record not found");+fail++;+}+if(!fail)tst_res(TPASS,"Successfully received: %s",ex->name);}
@@ -125,12 +175,25 @@ static void do_test(unsigned int i)check_event(event_buf,read_len,tcase);}+staticvoidinit_null_fid(void)+{+/* Use fanotify_save_fid to fill the fsid and overwrite the+*file_handlertocreateanull_fid+*/+fanotify_save_fid(MOUNT_PATH,&null_fid);++null_fid.handle.handle_type=FILEID_INVALID;+null_fid.handle.handle_bytes=0;+}+staticvoidsetup(void){REQUIRE_FANOTIFY_EVENTS_SUPPORTED_ON_FS(FAN_CLASS_NOTIF|FAN_REPORT_FID,FAN_MARK_FILESYSTEM,FAN_FS_ERROR,".");+init_null_fid();+fd_notify=SAFE_FANOTIFY_INIT(FAN_CLASS_NOTIF|FAN_REPORT_FID,O_RDONLY);--
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:49:45
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
In order to test FAN_FS_ERROR, we want to corrupt the filesystem. The
easiest way to do it is by using debugfs. Add a small helper to issue
debugfs requests. Since most likely this will be the only testcase to
need this, don't bother making it a proper helper for now.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
@@ -47,6 +47,13 @@ int fd_notify;/* These expected FIDs are common to multiple tests */staticstructfanotify_fid_tnull_fid;+staticvoiddo_debugfs_request(constchar*dev,char*request)+{+constchar*cmd[]={"debugfs","-w",dev,"-R",request,NULL};++SAFE_CMD(cmd,NULL,NULL);+}+staticstructtest_case{char*name;interror;
@@ -216,7 +223,11 @@ static struct tst_test test = {.mntpoint=MOUNT_PATH,.all_filesystems=0,.needs_root=1,-.dev_fs_type="ext4"+.dev_fs_type="ext4",+.needs_cmds=(constchar*[]){+"debugfs",+NULL+}};#else--
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 06:51:23
On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
Allocate a test directory and corrupt it with debugfs. The corruption
is done by writing an invalid inode mode. This file can be later
looked up to trigger a corruption error.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
@@ -43,9 +43,12 @@ static char event_buf[BUF_SIZE];intfd_notify;#define MOUNT_PATH "test_mnt"+#define BASE_DIR "internal_dir"+#define BAD_DIR BASE_DIR"/bad_dir"/* These expected FIDs are common to multiple tests */staticstructfanotify_fid_tnull_fid;+staticstructfanotify_fid_tbad_file_fid;staticvoiddo_debugfs_request(constchar*dev,char*request){
@@ -182,6 +185,18 @@ static void do_test(unsigned int i)check_event(event_buf,read_len,tcase);}+staticvoidpre_corrupt_fs(void)+{+SAFE_MKDIR(MOUNT_PATH"/"BASE_DIR,0777);+SAFE_MKDIR(MOUNT_PATH"/"BAD_DIR,0777);++fanotify_save_fid(MOUNT_PATH"/"BAD_DIR,&bad_file_fid);++SAFE_UMOUNT(MOUNT_PATH);+do_debugfs_request(tst_device->dev,"sif "BAD_DIR" mode 0xff");+SAFE_MOUNT(tst_device->dev,MOUNT_PATH,tst_device->fs_type,0,NULL);+}+staticvoidinit_null_fid(void){/* Use fanotify_save_fid to fill the fsid and overwrite the
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 09:56:30
On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
quoted hunk
This test monitors the error triggered after a file system abort. It
works by forcing a remount with the option "abort". This is an error
not related to a file so it is reported against the superblock with a
zero size fh.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
---
testcases/kernel/syscalls/fanotify/fanotify20.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
I suppose you did not try to run fanotify20 -i 10 ...?
I guess you will need to end the setup() stage with unmounted fs and perform:
mount; fanotify_init; fanotify_mark; at beginning of do_test()
finishing do_test() with closing fanotify fd and unmount.
I never checked it there are pre-test/post-test callbacks available in LTP,
but setup/clean are called at start/end of test loop.
Thanks,
Amir.
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 09:57:45
On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
This test corrupts an inode entry with an invalid mode through debugfs
and then tries to access it. This should result in a ext4 error, which
we monitor through the fanotify group.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
@@ -63,6 +67,17 @@ static void trigger_fs_abort(void)MS_REMOUNT|MS_RDONLY,"abort");}+staticvoidtcase2_trigger_lookup(void)+{+intret;++/* SAFE_OPEN cannot be used here because we expect it to fail. */+ret=open(MOUNT_PATH"/"BAD_DIR,O_RDONLY,0);+if(ret!=-1&&errno!=EUCLEAN)+tst_res(TFAIL,"Unexpected lookup result(%d) of %s (%d!=%d)",+ret,BAD_DIR,errno,EUCLEAN);+}+staticstructtest_case{char*name;interror;
@@ -77,6 +92,13 @@ static struct test_case {.error=ESHUTDOWN,.fid=&null_fid,},+{+.name="Lookup of inode with invalid mode",+.trigger_error=&tcase2_trigger_lookup,+.error_count=1,+.error=EFSCORRUPTED,+.fid=&bad_file_fid,+},};intcheck_error_event_info_fid(structfanotify_event_info_fid*fid,--
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 10:01:09
On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi
[off-list ref] 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 <redacted>
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.
From: Amir Goldstein <amir73il@gmail.com> Date: 2021-10-27 10:19:50
On Wed, Oct 27, 2021 at 9:43 AM Amir Goldstein [off-list ref] wrote:
On Tue, Oct 26, 2021 at 9:43 PM Gabriel Krisman Bertazi
[off-list ref] wrote:
quoted
Implement some validation for the generic error info record emitted by
the kernel. The error number is fs-specific but, well, we only support
ext4 for now anyway.
Signed-off-by: Gabriel Krisman Bertazi <redacted>
After fixing and testing configure.ac you may add:
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Need to add in configure.ac:
AC_CHECK_TYPES([struct fanotify_event_info_error, struct
fanotify_event_info_header],,,[#include <sys/fanotify.h>])
(not tested)
According to Matthew's pidfd patches the syntax should be:
AC_CHECK_TYPES([struct fanotify_event_info_fid, struct
fanotify_event_info_header, struct fanotify_event_info_pidfd, struct
fanotify_event_info_error],,,[#include <sys/fanotify.h>])
Thanks,
Amir.
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,
--
Gabriel Krisman Bertazi