From: Tom Van Braeckel <tomvanbraeckel@gmail.com>
To: arnd@arndb.de, gregkh@linuxfoundation.org
Cc: linux-kernel@vger.kernel.org,
Tom Van Braeckel <tomvanbraeckel@gmail.com>
Subject: [PATCH] misc: pass miscdevice through file's private_data
Date: Tue, 31 Mar 2015 16:39:21 +0200 [thread overview]
Message-ID: <1427812761-20674-1-git-send-email-tomvanbraeckel@gmail.com> (raw)
Make the miscdevice accessible through the file's private_data.
Previously, this was done only when an open() file operation had been
registered. If no custom open() file operation was defined,
private_data was set to NULL.
This subtle quirk was confusing, to the point where kernel code
registered *empty* file open operations to have private_data point to
the misc device structure and avoid duplicating that logic.
And it could easily lead to bugs, where the addition or removal of a
custom open() file operation surprisingly changes the initial value of
a file's private_data structure.
To resolve this, we now place the miscdevice in the file's private_data
member unconditionally when open() is called.
Signed-off-by: Tom Van Braeckel <tomvanbraeckel@gmail.com>
---
All kernel code that uses private_data and misc_register() has been
checked for potential regressions and the code that relied on this
subtle behavior (only FUSE) has been fixed.
Although I feel confident about this patch, it might still be a good
idea to keep this in linux-next for at least a whole cycle, as Martin
Kepplinger suggested. As you wish.
Mind that the documentation about this change has already been
submitted by Martin and accepted into linux-next (commit 03190c67).
drivers/char/misc.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 5bb3a21..9fd5a91 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -140,12 +140,17 @@ static int misc_open(struct inode * inode, struct file * file)
goto fail;
}
+ /*
+ * Place the miscdevice in the file's
+ * private_data so it can be used by the
+ * file operations, including f_op->open below
+ */
+ file->private_data = c;
+
err = 0;
replace_fops(file, new_fops);
- if (file->f_op->open) {
- file->private_data = c;
+ if (file->f_op->open)
err = file->f_op->open(inode,file);
- }
fail:
mutex_unlock(&misc_mtx);
return err;
--
2.1.0
next reply other threads:[~2015-03-31 14:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-31 14:39 Tom Van Braeckel [this message]
-- strict thread matches above, loose matches on Subject: below --
2014-12-04 21:08 [PATCH] Misc: " Tom Van Braeckel
2014-12-04 21:13 ` Greg KH
2014-12-04 23:01 ` Tom Van Braeckel
2014-12-04 23:29 ` Greg KH
2014-12-05 4:37 ` [PATCH] misc: " Tom Van Braeckel
2015-01-09 23:02 ` Greg KH
2015-01-11 15:44 ` Tom Van Braeckel
2015-03-31 13:08 ` Tom Van Braeckel
2015-03-31 13:19 ` Greg KH
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=1427812761-20674-1-git-send-email-tomvanbraeckel@gmail.com \
--to=tomvanbraeckel@gmail.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/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