From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: LTP List <ltp@lists.linux.it>, Jan Kara <jack@suse.com>,
Ext4 <linux-ext4@vger.kernel.org>,
Khazhismel Kumykov <khazhy@google.com>,
kernel@collabora.com
Subject: Re: [PATCH 6/7] syscalls/fanotify20: Test file event with broken inode
Date: Wed, 04 Aug 2021 00:52:52 -0400 [thread overview]
Message-ID: <87k0l1hkuz.fsf@collabora.com> (raw)
In-Reply-To: <CAOQ4uxizX0ar7d9eYgazcenQcA7Ku7quEZOLbcaxKJiY0sTPLA@mail.gmail.com> (Amir Goldstein's message of "Tue, 3 Aug 2021 12:08:11 +0300")
Amir Goldstein <amir73il@gmail.com> writes:
> On Tue, Aug 3, 2021 at 12:47 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> 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 <krisman@collabora.com>
>> ---
>> .../kernel/syscalls/fanotify/fanotify20.c | 38 +++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>> diff --git a/testcases/kernel/syscalls/fanotify/fanotify20.c b/testcases/kernel/syscalls/fanotify/fanotify20.c
>> index e7ced28eb61d..0c63e90edc3a 100644
>> --- a/testcases/kernel/syscalls/fanotify/fanotify20.c
>> +++ b/testcases/kernel/syscalls/fanotify/fanotify20.c
>> @@ -76,6 +76,36 @@ static void trigger_fs_abort(void)
>> MS_REMOUNT|MS_RDONLY, "abort");
>> }
>>
>> +#define TCASE2_BASEDIR "tcase2"
>> +#define TCASE2_BAD_DIR TCASE2_BASEDIR"/bad_dir"
>> +
>> +static unsigned int tcase2_bad_ino;
>> +static void tcase2_prepare_fs(void)
>> +{
>> + struct stat stat;
>> +
>> + SAFE_MKDIR(MOUNT_PATH"/"TCASE2_BASEDIR, 0777);
>> + SAFE_MKDIR(MOUNT_PATH"/"TCASE2_BAD_DIR, 0777);
>> +
>> + SAFE_STAT(MOUNT_PATH"/"TCASE2_BAD_DIR, &stat);
>> + tcase2_bad_ino = stat.st_ino;
>> +
>> + SAFE_UMOUNT(MOUNT_PATH);
>> + do_debugfs_request(tst_device->dev, "sif " TCASE2_BAD_DIR " mode 0xff");
>> + SAFE_MOUNT(tst_device->dev, MOUNT_PATH, tst_device->fs_type, 0, NULL);
>> +}
>> +
>> +static void tcase2_trigger_lookup(void)
>> +{
>> + int ret;
>> +
>> + /* SAFE_OPEN cannot be used here because we expect it to fail. */
>> + ret = open(MOUNT_PATH"/"TCASE2_BAD_DIR, O_RDONLY, 0);
>> + if (ret != -1 && errno != EUCLEAN)
>> + tst_res(TFAIL, "Unexpected lookup result(%d) of %s (%d!=%d)",
>> + ret, TCASE2_BAD_DIR, errno, EUCLEAN);
>> +}
>> +
>> static const struct test_case {
>> char *name;
>> int error;
>> @@ -92,6 +122,14 @@ static const struct test_case {
>> .error_count = 1,
>> .error = EXT4_ERR_ESHUTDOWN,
>> .inode = NULL
>> + },
>> + {
>> + .name = "Lookup of inode with invalid mode",
>> + .prepare_fs = tcase2_prepare_fs,
>> + .trigger_error = &tcase2_trigger_lookup,
>> + .error_count = 1,
>> + .error = 0,
>> + .inode = &tcase2_bad_ino,
>
> Why is error 0?
> What's the rationale?
Hi Amir,
That is specific to Ext4. Some ext4 conditions report bogus error codes. I will
come up with a kernel patch changing it.
--
Gabriel Krisman Bertazi
WARNING: multiple messages have this Message-ID (diff)
From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 6/7] syscalls/fanotify20: Test file event with broken inode
Date: Wed, 04 Aug 2021 00:52:52 -0400 [thread overview]
Message-ID: <87k0l1hkuz.fsf@collabora.com> (raw)
In-Reply-To: <CAOQ4uxizX0ar7d9eYgazcenQcA7Ku7quEZOLbcaxKJiY0sTPLA@mail.gmail.com> (Amir Goldstein's message of "Tue, 3 Aug 2021 12:08:11 +0300")
Amir Goldstein <amir73il@gmail.com> writes:
> On Tue, Aug 3, 2021 at 12:47 AM Gabriel Krisman Bertazi
> <krisman@collabora.com> 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 <krisman@collabora.com>
>> ---
>> .../kernel/syscalls/fanotify/fanotify20.c | 38 +++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>> diff --git a/testcases/kernel/syscalls/fanotify/fanotify20.c b/testcases/kernel/syscalls/fanotify/fanotify20.c
>> index e7ced28eb61d..0c63e90edc3a 100644
>> --- a/testcases/kernel/syscalls/fanotify/fanotify20.c
>> +++ b/testcases/kernel/syscalls/fanotify/fanotify20.c
>> @@ -76,6 +76,36 @@ static void trigger_fs_abort(void)
>> MS_REMOUNT|MS_RDONLY, "abort");
>> }
>>
>> +#define TCASE2_BASEDIR "tcase2"
>> +#define TCASE2_BAD_DIR TCASE2_BASEDIR"/bad_dir"
>> +
>> +static unsigned int tcase2_bad_ino;
>> +static void tcase2_prepare_fs(void)
>> +{
>> + struct stat stat;
>> +
>> + SAFE_MKDIR(MOUNT_PATH"/"TCASE2_BASEDIR, 0777);
>> + SAFE_MKDIR(MOUNT_PATH"/"TCASE2_BAD_DIR, 0777);
>> +
>> + SAFE_STAT(MOUNT_PATH"/"TCASE2_BAD_DIR, &stat);
>> + tcase2_bad_ino = stat.st_ino;
>> +
>> + SAFE_UMOUNT(MOUNT_PATH);
>> + do_debugfs_request(tst_device->dev, "sif " TCASE2_BAD_DIR " mode 0xff");
>> + SAFE_MOUNT(tst_device->dev, MOUNT_PATH, tst_device->fs_type, 0, NULL);
>> +}
>> +
>> +static void tcase2_trigger_lookup(void)
>> +{
>> + int ret;
>> +
>> + /* SAFE_OPEN cannot be used here because we expect it to fail. */
>> + ret = open(MOUNT_PATH"/"TCASE2_BAD_DIR, O_RDONLY, 0);
>> + if (ret != -1 && errno != EUCLEAN)
>> + tst_res(TFAIL, "Unexpected lookup result(%d) of %s (%d!=%d)",
>> + ret, TCASE2_BAD_DIR, errno, EUCLEAN);
>> +}
>> +
>> static const struct test_case {
>> char *name;
>> int error;
>> @@ -92,6 +122,14 @@ static const struct test_case {
>> .error_count = 1,
>> .error = EXT4_ERR_ESHUTDOWN,
>> .inode = NULL
>> + },
>> + {
>> + .name = "Lookup of inode with invalid mode",
>> + .prepare_fs = tcase2_prepare_fs,
>> + .trigger_error = &tcase2_trigger_lookup,
>> + .error_count = 1,
>> + .error = 0,
>> + .inode = &tcase2_bad_ino,
>
> Why is error 0?
> What's the rationale?
Hi Amir,
That is specific to Ext4. Some ext4 conditions report bogus error codes. I will
come up with a kernel patch changing it.
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2021-08-04 4:52 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-02 21:46 [PATCH 0/7] Test the new fanotify FAN_FS_ERROR event Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-02 21:46 ` [PATCH 1/7] syscalls/fanotify20: Introduce helpers for FAN_FS_ERROR test Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-03 8:30 ` Amir Goldstein
2021-08-03 8:30 ` [LTP] " Amir Goldstein
2021-08-02 21:46 ` [PATCH 2/7] syscalls/fanotify20: Validate the generic error info Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-03 8:42 ` Amir Goldstein
2021-08-03 8:42 ` [LTP] " Amir Goldstein
2021-08-02 21:46 ` [PATCH 3/7] syscalls/fanotify20: Validate incoming FID in FAN_FS_ERROR Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-03 8:56 ` Amir Goldstein
2021-08-03 8:56 ` [LTP] " Amir Goldstein
2021-08-04 4:54 ` Gabriel Krisman Bertazi
2021-08-04 4:54 ` [LTP] " Gabriel Krisman Bertazi
2021-08-04 5:39 ` Amir Goldstein
2021-08-04 5:39 ` [LTP] " Amir Goldstein
2021-08-04 7:40 ` Matthew Bobrowski
2021-08-04 7:40 ` [LTP] " Matthew Bobrowski
2021-08-20 10:21 ` Petr Vorel
2021-08-20 10:21 ` Petr Vorel
2021-08-20 21:58 ` Matthew Bobrowski
2021-08-20 21:58 ` Matthew Bobrowski
2021-08-23 9:35 ` Jan Kara
2021-08-23 9:35 ` Jan Kara
2021-08-23 11:19 ` Matthew Bobrowski
2021-08-23 11:19 ` Matthew Bobrowski
2021-08-23 14:34 ` Gabriel Krisman Bertazi
2021-08-23 14:34 ` Gabriel Krisman Bertazi
2021-08-02 21:46 ` [PATCH 4/7] syscalls/fanotify20: Watch event after filesystem abort Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-02 21:46 ` [PATCH 5/7] syscalls/fanotify20: Support submission of debugfs commands Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-02 21:46 ` [PATCH 6/7] syscalls/fanotify20: Test file event with broken inode Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
2021-08-03 9:04 ` Amir Goldstein
2021-08-03 9:04 ` [LTP] " Amir Goldstein
2021-08-03 9:08 ` Amir Goldstein
2021-08-03 9:08 ` [LTP] " Amir Goldstein
2021-08-04 4:52 ` Gabriel Krisman Bertazi [this message]
2021-08-04 4:52 ` Gabriel Krisman Bertazi
2021-08-04 5:27 ` Amir Goldstein
2021-08-04 5:27 ` [LTP] " Amir Goldstein
2021-08-05 21:50 ` Gabriel Krisman Bertazi
2021-08-05 21:50 ` [LTP] " Gabriel Krisman Bertazi
2021-08-02 21:46 ` [PATCH 7/7] syscalls/fanotify20: Test capture of multiple errors Gabriel Krisman Bertazi
2021-08-02 21:46 ` [LTP] " Gabriel Krisman Bertazi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k0l1hkuz.fsf@collabora.com \
--to=krisman@collabora.com \
--cc=amir73il@gmail.com \
--cc=jack@suse.com \
--cc=kernel@collabora.com \
--cc=khazhy@google.com \
--cc=linux-ext4@vger.kernel.org \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.