linux-ext4 - [PATCH v3 0/9] Test the new fanotify FAN_FS

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-next>] [day] [month] [year] [list]

Message-Id: <20211029211732.386127-1-krisman@collabora.com>
Date:   Fri, 29 Oct 2021 18:17:23 -0300
From:   Gabriel Krisman Bertazi <krisman@...labora.com>
To:     jack@...e.com, amir73il@...il.com, repnop@...gle.com
Cc:     ltp@...ts.linux.it, khazhy@...gle.com, kernel@...labora.com,
        linux-ext4@...r.kernel.org,
        Gabriel Krisman Bertazi <krisman@...labora.com>
Subject: [PATCH v3 0/9] Test the new fanotify FAN_FS_ERROR event

Hi,

Now that FAN_FS_ERROR is close to being merged, I'm sending a new
version of the LTP tests.  This is the v3 of this patchset, and it
applies the feedback of the previous version, in particular, it solves
the issue Amir pointed out, that ltp won't gracefully handle a test with
tcnt==0.  To solve that, I merged the patch that set up the environment
with a simple test, that only triggers a fs abort and watches the
event.

I'm also renaming the testcase from fanotify20 to fanotify21, to leave
room for the pidfs test that is also in the baking by Matthew Bobrowski.

One important detail is that, for the tests to succeed, there is a
dependency on an ext4 fix I sent a few days ago:

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 (9):
  syscalls: fanotify: Add macro to require specific mark types
  syscalls: fanotify: Add macro to require specific events
  syscalls/fanotify21: Introduce FAN_FS_ERROR test
  syscalls/fanotify21: Validate the generic error info
  syscalls/fanotify21: Validate incoming FID in FAN_FS_ERROR
  syscalls/fanotify21: Support submission of debugfs commands
  syscalls/fanotify21: Create a corrupted file
  syscalls/fanotify21: Test file event with broken inode
  syscalls/fanotify21: Test capture of multiple errors

 configure.ac                                  |   3 +-
 testcases/kernel/syscalls/fanotify/.gitignore |   1 +
 testcases/kernel/syscalls/fanotify/fanotify.h |  66 +++-
 .../kernel/syscalls/fanotify/fanotify03.c     |   4 +-
 .../kernel/syscalls/fanotify/fanotify10.c     |   3 +-
 .../kernel/syscalls/fanotify/fanotify12.c     |   3 +-
 .../kernel/syscalls/fanotify/fanotify21.c     | 312 ++++++++++++++++++
 7 files changed, 384 insertions(+), 8 deletions(-)
 create mode 100644 testcases/kernel/syscalls/fanotify/fanotify21.c

-- 
2.33.0