In fa1f68db6ca ("drivers: misc: pass miscdevice pointer via file
private data"), the misc driver infrastructure was changed to assigned
file->private_data as a pointer to the 'struct miscdevice' that
corresponds to the device being opened.
However, this assignment was only done when the misc driver was
declaring a driver-specific ->open() operation in its
file_operations. This doesn't make sense, as the driver may not
necessarily have a custom ->open() operation, and might still be
interested in having file->private_data properly set for use in its
->read() and write() operations.
Therefore, we move the assignment of file->private_data outside of the
condition that tests whether a driver-specific ->open() operation was
defined.
Signed-off-by: Thomas Petazzoni <[email protected]>
---
drivers/char/misc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/misc.c b/drivers/char/misc.c
index 190d442..fd504d3 100644
--- a/drivers/char/misc.c
+++ b/drivers/char/misc.c
@@ -143,8 +143,8 @@ static int misc_open(struct inode * inode, struct file * file)
err = 0;
old_fops = file->f_op;
file->f_op = new_fops;
+ file->private_data = c;
if (file->f_op->open) {
- file->private_data = c;
err=file->f_op->open(inode,file);
if (err) {
fops_put(file->f_op);
--
1.8.1.2
On Friday 21 June 2013, Thomas Petazzoni wrote:
> n fa1f68db6ca ("drivers: misc: pass miscdevice pointer via file
> private data"), the misc driver infrastructure was changed to assigned
> file->private_data as a pointer to the 'struct miscdevice' that
> corresponds to the device being opened.
>
> However, this assignment was only done when the misc driver was
> declaring a driver-specific ->open() operation in its
> file_operations. This doesn't make sense, as the driver may not
> necessarily have a custom ->open() operation, and might still be
> interested in having file->private_data properly set for use in its
> ->read() and write() operations.
>
> Therefore, we move the assignment of file->private_data outside of the
> condition that tests whether a driver-specific ->open() operation was
> defined.
>
> Signed-off-by: Thomas Petazzoni <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
On Fri, Jun 21, 2013 at 03:01:05PM +0200, Thomas Petazzoni wrote:
> In fa1f68db6ca ("drivers: misc: pass miscdevice pointer via file
> private data"), the misc driver infrastructure was changed to assigned
> file->private_data as a pointer to the 'struct miscdevice' that
> corresponds to the device being opened.
>
> However, this assignment was only done when the misc driver was
> declaring a driver-specific ->open() operation in its
> file_operations. This doesn't make sense, as the driver may not
> necessarily have a custom ->open() operation, and might still be
> interested in having file->private_data properly set for use in its
> ->read() and write() operations.
>
> Therefore, we move the assignment of file->private_data outside of the
> condition that tests whether a driver-specific ->open() operation was
> defined.
Does this solve a problem with an existing misc driver? Or are you just
trying to be "safe" for future, broken, drivers?
thanks,
greg k-h
Dear Greg Kroah-Hartman,
On Mon, 24 Jun 2013 15:26:42 -0700, Greg Kroah-Hartman wrote:
> > However, this assignment was only done when the misc driver was
> > declaring a driver-specific ->open() operation in its
> > file_operations. This doesn't make sense, as the driver may not
> > necessarily have a custom ->open() operation, and might still be
> > interested in having file->private_data properly set for use in its
> > ->read() and write() operations.
> >
> > Therefore, we move the assignment of file->private_data outside of the
> > condition that tests whether a driver-specific ->open() operation was
> > defined.
>
> Does this solve a problem with an existing misc driver? Or are you just
> trying to be "safe" for future, broken, drivers?
This problem was spotted while implementing a dummy/example misc driver
for training purposes. I am not aware of any mainline misc driver
affected by this problem, but I haven't reviewed all misc drivers.
It simply seems to make sense to implement the feature of fa1f68db6ca
("drivers: misc: pass miscdevice pointer via file private data") in a
way that also allows misc drivers that do not provide their own
->open() operation to use it.
That said, I'm not sure why you call such drivers 'broken'.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com