Message-Id: <20210702050543.2693141-1-mcgrof@kernel.org>
Date:   Thu,  1 Jul 2021 22:05:39 -0700
From:   Luis Chamberlain <mcgrof@...nel.org>
To:     gregkh@...uxfoundation.org, tj@...nel.org, shuah@...nel.org,
        akpm@...ux-foundation.org, rafael@...nel.org, davem@...emloft.net,
        kuba@...nel.org, ast@...nel.org, andriin@...com,
        daniel@...earbox.net, atenart@...nel.org, alobakin@...me,
        weiwan@...gle.com, ap420073@...il.com
Cc:     jeyu@...nel.org, ngupta@...are.org,
        sergey.senozhatsky.work@...il.com, minchan@...nel.org,
        mcgrof@...nel.org, axboe@...nel.dk, mbenes@...e.com,
        jpoimboe@...hat.com, tglx@...utronix.de, keescook@...omium.org,
        jikos@...nel.org, rostedt@...dmis.org, peterz@...radead.org,
        linux-block@...r.kernel.org, netdev@...r.kernel.org,
        linux-kselftest@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/4] selftests: add a new test driver for sysfs

I had posted a patch to fix a theoretical race with sysfs and device
removal [0].  While the issue is no longer present with the patch
present, the zram driver has already a lot of enhancements, so much so,
that the race alone is very difficult to reproduce. Likewise, the zram
driver had a series of other races on module removal which I recently
posted fixes for [1], and it makes it unclear if these paper over the
possible theoretical sysfs race. Although we even have gdb output
from an actual race where this issue presented itself, there are
other races which could happen before that and so what we realy need
is a clean separate driver where we can experiment and try to reproduce
unusual races.

This adds such a driver, a new sysfs_test driver, along with a set of
new tests for it. We take hint of observed issues with the sysfs on the
zram driver, and build sandbox based where wher can try to poke holes at
the kernel with.

There are two main races we're after trying to reproduce:

  1) proving the deadlock is real
  2) allowing for enough slack for us to try to see if we can
     reproduce the syfs / device removal race

In order to tackle the second race, we need a bit of help from kernefs,
given that the race is difficult to reproduce. So we add fault injection
support to kernfs, which allows us to trigger all possible races on
write.

This should be enough evidence for us to drop the suggested patch for
sysfs for the second race. The first race however which leads to a
deadlock is clearly explained now and I hope this shows how we need a
generic solution.

[0] https://lkml.kernel.org/r/20210623215007.862787-1-mcgrof@kernel.org
[1] https://lkml.kernel.org/r/20210702043716.2692247-1-mcgrof@kernel.org

Luis Chamberlain (4):
  selftests: add tests_sysfs module
  kernfs: add initial failure injection support
  test_sysfs: add support to use kernfs failure injection
  test_sysfs: demonstrate deadlock fix

 .../fault-injection/fault-injection.rst       |   22 +
 MAINTAINERS                                   |    9 +-
 fs/kernfs/Makefile                            |    1 +
 fs/kernfs/failure-injection.c                 |   82 +
 fs/kernfs/file.c                              |   13 +
 fs/kernfs/kernfs-internal.h                   |   73 +
 include/linux/kernfs.h                        |    5 +
 lib/Kconfig.debug                             |   23 +
 lib/Makefile                                  |    1 +
 lib/test_sysfs.c                              | 1037 +++++++++++++
 tools/testing/selftests/sysfs/Makefile        |   12 +
 tools/testing/selftests/sysfs/config          |    5 +
 tools/testing/selftests/sysfs/sysfs.sh        | 1376 +++++++++++++++++
 13 files changed, 2658 insertions(+), 1 deletion(-)
 create mode 100644 fs/kernfs/failure-injection.c
 create mode 100644 lib/test_sysfs.c
 create mode 100644 tools/testing/selftests/sysfs/Makefile
 create mode 100644 tools/testing/selftests/sysfs/config
 create mode 100755 tools/testing/selftests/sysfs/sysfs.sh

-- 
2.27.0

Powered by blists - more mailing lists