From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
To: Nicolai Stange <nicstange@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/8] debugfs: prevent access to possibly dead file_operations at file open
Date: Thu, 10 Mar 2016 22:59:02 +0100 [thread overview]
Message-ID: <87d1r2uh95.fsf@rasmusvillemoes.dk> (raw)
In-Reply-To: <1457267103-28910-2-git-send-email-nicstange@gmail.com> (Nicolai Stange's message of "Sun, 6 Mar 2016 13:24:56 +0100")
On Sun, Mar 06 2016, Nicolai Stange <nicstange@gmail.com> wrote:
> + *
> + * Allow any ongoing concurrent call into debugfs_remove() or
> + * debugfs_remove_recursive() blocked by a former call to
> + * debugfs_use_file_start() to proceed and return to its caller.
> + */
> +static void debugfs_use_file_finish(int srcu_idx) __releases(&debugfs_srcu)
> +{
> + srcu_read_unlock(&debugfs_srcu, srcu_idx);
> +}
> +
> +#define F_DENTRY(filp) ((filp)->f_path.dentry)
> +
> +#define REAL_FOPS_DEREF(dentry) \
> + ((const struct file_operations *)(dentry)->d_fsdata)
> +
> +static int open_proxy_open(struct inode *inode, struct file *filp)
> +{
> + const struct dentry *dentry = F_DENTRY(filp);
> + const struct file_operations *real_fops = NULL;
> + int srcu_idx, r;
> +
> + r = debugfs_use_file_start(dentry, &srcu_idx);
> + if (r) {
> + debugfs_use_file_finish(srcu_idx);
> + r = -ENOENT;
> + goto out;
this...
> +out:
> + fops_put(real_fops);
> + debugfs_use_file_finish(srcu_idx);
... and that seems like an obvious double unlock?
Rasmus
next prev parent reply other threads:[~2016-03-10 21:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-06 12:24 [PATCH v5 0/8] fix debugfs file removal races Nicolai Stange
2016-03-06 12:24 ` [PATCH v5 1/8] debugfs: prevent access to possibly dead file_operations at file open Nicolai Stange
2016-03-10 21:59 ` Rasmus Villemoes [this message]
2016-03-11 19:28 ` Nicolai Stange
2016-03-06 12:24 ` [PATCH v5 2/8] debugfs: prevent access to removed files' private data Nicolai Stange
2016-03-06 12:24 ` [PATCH v5 3/8] debugfs: add support for self-protecting attribute file fops Nicolai Stange
2016-03-06 12:24 ` [PATCH v5 4/8] debugfs, coccinelle: check for obsolete DEFINE_SIMPLE_ATTRIBUTE() usage Nicolai Stange
2016-03-06 12:25 ` [PATCH v5 5/8] debugfs: unproxify integer attribute files Nicolai Stange
2016-03-06 12:25 ` [PATCH v5 6/8] debugfs: unproxify files created through debugfs_create_bool() Nicolai Stange
2016-03-06 12:25 ` [PATCH v5 7/8] debugfs: unproxify files created through debugfs_create_blob() Nicolai Stange
2016-03-06 12:25 ` [PATCH v5 8/8] debugfs: unproxify files created through debugfs_create_u32_array() 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=87d1r2uh95.fsf@rasmusvillemoes.dk \
--to=linux@rasmusvillemoes.dk \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicstange@gmail.com \
--cc=paulmck@linux.vnet.ibm.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