From: Nicolai Stange <nicstange@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johannes Berg <johannes@sipsolutions.net>,
"Paul E.McKenney" <paulmck@linux.vnet.ibm.com>,
Tyler Hall <tylerwhall@gmail.com>,
Mike Marciniszyn <mike.marciniszyn@intel.com>,
Dennis Dalessandro <dennis.dalessandro@intel.com>,
Doug Ledford <dledford@redhat.com>,
Sean Hefty <sean.hefty@intel.com>,
Hal Rosenstock <hal.rosenstock@gmail.com>,
linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
Nicolai Stange <nicstange@gmail.com>
Subject: [PATCH v3 0/8] debugfs: per-file removal protection
Date: Tue, 31 Oct 2017 00:15:46 +0100 [thread overview]
Message-ID: <20171030231554.6200-1-nicstange@gmail.com> (raw)
In-Reply-To: <CAOjnSCazvybpH5ZhHn=iTLm_dVGEdr=W1pUQv6zowRisB1MWTQ@mail.gmail.com>
Hi,
this is v3 of the per-file removal protection with the main change to v2
being that it's sent in non-RFC mode now.
For this, I dropped the questionable former [9/9] ("debugfs: free
debugfs_fsdata instances") for now. Perhaps I'll resend it later on
its own as a RFC again.
The problem this series attempts to address is that any indefinitely
blocking fops blocks _unrelated_ debugfs_remove()ers. This will be resolved
by introducing a per-file removal protection mechanism in place of the
former global debugfs_srcu shared among all debugfs files.
This problem has first been spotted and debugged by Johannes Berg [1]
and Tyler Hall is now facing the same issue again [2].
There's one patch to non-debugfs code,
[5/8] ("IB/hfi1: convert to debugfs_file_get() and -put()"),
which should be taken together with the rest of the series because
it depends on prior patches and later patches depend on it.
Applies to next-20171018.
I reviewed the patches once again and did an allmodconfig as well as an
allnoconfig build. I did more thorough testing on v2, including whether
the removal protection still works.
Thanks,
Nicolai
Changes to v2:
[9/9] ("debugfs: free debugfs_fsdata instances")
- dropped for now.
Changes to v1:
[2/9] ("debugfs: implement per-file removal protection")
- In an attempt to resolve the issue reported by the kernel test robot
for v1, restrict the "extended removal logic" to regular files in
__debugfs_remove().
[8/9] ("debugfs: defer debugfs_fsdata allocation to first usage")
- Following review from Johannes Berg, replace the WARN_ON in
debugfs_real_fops() by a WARN + 'return NULL'. The return NULL is
expected to crash current soon and serves as an alternative for a
BUG_ON here.
- Mention the change in debugfs_real_fops() in the commit message.
[9/9] ("debugfs: free debugfs_fsdata instances")
- Following advice from Paul E. McKenney, make debugfs_file_get()
release the RCU read section inbetween retry loop iterations.
- Fix a race in debugfs_file_get()'s path handling a concurrent
debugfs_file_put(): the former must not "help out resetting ->d_fsdata"
because this can wipe out another debugfs_file_get()'s achievements.
[1] http://lkml.kernel.org/r/1490280886.2766.4.camel@sipsolutions.net
[2] https://lkml.kernel.org/r/CAOjnSCYGprej+vEEsSXwr=wO+eWLe2d6sHQYTpp-DFpQ3pmguw@mail.gmail.com
Nicolai Stange (8):
debugfs: add support for more elaborate ->d_fsdata
debugfs: implement per-file removal protection
debugfs: debugfs_real_fops(): drop __must_hold sparse annotation
debugfs: convert to debugfs_file_get() and -put()
IB/hfi1: convert to debugfs_file_get() and -put()
debugfs: purge obsolete SRCU based removal protection
debugfs: call debugfs_real_fops() only after debugfs_file_get()
debugfs: defer debugfs_fsdata allocation to first usage
drivers/infiniband/hw/hfi1/debugfs.c | 20 ++--
fs/debugfs/file.c | 210 +++++++++++++++++++++--------------
fs/debugfs/inode.c | 56 +++++++---
fs/debugfs/internal.h | 14 +++
include/linux/debugfs.h | 33 +-----
lib/Kconfig.debug | 1 -
6 files changed, 196 insertions(+), 138 deletions(-)
--
2.13.6
next prev parent reply other threads:[~2017-10-30 23:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 20:01 deadlock in debugfs synchronize_srcu() when unplugging USB Tyler Hall
2017-10-12 21:04 ` Paul E. McKenney
2017-10-16 7:51 ` Greg Kroah-Hartman
2017-10-16 8:15 ` Johannes Berg
2017-10-16 8:31 ` Greg Kroah-Hartman
2017-10-16 15:08 ` Tyler Hall
2017-10-30 23:15 ` Nicolai Stange [this message]
2017-10-30 23:15 ` [PATCH v3 1/8] debugfs: add support for more elaborate ->d_fsdata Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 2/8] debugfs: implement per-file removal protection Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 3/8] debugfs: debugfs_real_fops(): drop __must_hold sparse annotation Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 4/8] debugfs: convert to debugfs_file_get() and -put() Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 5/8] IB/hfi1: " Nicolai Stange
2017-11-07 14:29 ` Dennis Dalessandro
2017-10-30 23:15 ` [PATCH v3 6/8] debugfs: purge obsolete SRCU based removal protection Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 7/8] debugfs: call debugfs_real_fops() only after debugfs_file_get() Nicolai Stange
2017-10-30 23:15 ` [PATCH v3 8/8] debugfs: defer debugfs_fsdata allocation to first usage Nicolai Stange
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=20171030231554.6200-1-nicstange@gmail.com \
--to=nicstange@gmail.com \
--cc=dennis.dalessandro@intel.com \
--cc=dledford@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hal.rosenstock@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mike.marciniszyn@intel.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=sean.hefty@intel.com \
--cc=tylerwhall@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome