From patchwork Fri Oct 29 21:17:23 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Gabriel Krisman Bertazi X-Patchwork-Id: 1548347 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.linux.it (client-ip=2001:1418:10:5::2; helo=picard.linux.it; envelope-from=ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it; receiver=) Received: from picard.linux.it (picard.linux.it [IPv6:2001:1418:10:5::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4HgwJ749gnz9sP7 for ; Sat, 30 Oct 2021 08:17:57 +1100 (AEDT) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id A55E33C6F1D for ; Fri, 29 Oct 2021 23:17:53 +0200 (CEST) X-Original-To: ltp@lists.linux.it Delivered-To: ltp@picard.linux.it Received: from in-6.smtp.seeweb.it (in-6.smtp.seeweb.it [217.194.8.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id B08413C6E08 for ; Fri, 29 Oct 2021 23:17:50 +0200 (CEST) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by in-6.smtp.seeweb.it (Postfix) with ESMTPS id E1EC514010D1 for ; Fri, 29 Oct 2021 23:17:48 +0200 (CEST) Received: from localhost (unknown [IPv6:2804:14c:124:8a08::1002]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: krisman) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 983BB1F45C6F; Fri, 29 Oct 2021 22:17:46 +0100 (BST) From: Gabriel Krisman Bertazi To: jack@suse.com, amir73il@gmail.com, repnop@google.com Date: Fri, 29 Oct 2021 18:17:23 -0300 Message-Id: <20211029211732.386127-1-krisman@collabora.com> X-Mailer: git-send-email 2.33.0 MIME-Version: 1.0 X-Virus-Scanned: clamav-milter 0.102.4 at in-6.smtp.seeweb.it X-Virus-Status: Clean X-Spam-Status: No, score=-0.0 required=7.0 tests=SPF_HELO_PASS,SPF_PASS autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on in-6.smtp.seeweb.it Subject: [LTP] [PATCH v3 0/9] Test the new fanotify FAN_FS_ERROR event X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-ext4@vger.kernel.org, kernel@collabora.com, Gabriel Krisman Bertazi , khazhy@google.com, ltp@lists.linux.it Errors-To: ltp-bounces+incoming=patchwork.ozlabs.org@lists.linux.it Sender: "ltp" 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