linux-ext4 - Re: [PATCH v2 10/10] syscalls/fanotify20: Test capture of multiple errors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 27 Oct 2021 13:00:07 +0300
From:   Amir Goldstein <amir73il@...il.com>
To:     Gabriel Krisman Bertazi <krisman@...labora.com>
Cc:     LTP List <ltp@...ts.linux.it>, Jan Kara <jack@...e.com>,
        Khazhismel Kumykov <khazhy@...gle.com>, kernel@...labora.com,
        Ext4 <linux-ext4@...r.kernel.org>,
        Matthew Bobrowski <repnop@...gle.com>
Subject: Re: [PATCH v2 10/10] syscalls/fanotify20: Test capture of multiple errors

On Tue, Oct 26, 2021 at 9:44 PM Gabriel Krisman Bertazi
<krisman@...labora.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@...labora.com>

Reviewed-by: Amir Goldstein <amir73il@...il.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.