linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Mario Limonciello <mario.limonciello@dell.com>
Cc: dvhart@infradead.org, Andy Shevchenko <andy.shevchenko@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	platform-driver-x86@vger.kernel.org,
	Andy Lutomirski <luto@kernel.org>,
	quasisec@google.com, pali.rohar@gmail.com, rjw@rjwysocki.net,
	mjg59@google.com, hch@lst.de
Subject: Re: [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers
Date: Thu, 5 Oct 2017 09:16:19 +0200	[thread overview]
Message-ID: <20171005071619.GA25960@kroah.com> (raw)
In-Reply-To: <528c9a1ca4fa2f29aedbb37d3ed13c480ef093fc.1507156392.git.mario.limonciello@dell.com>

On Wed, Oct 04, 2017 at 05:48:38PM -0500, Mario Limonciello wrote:
> For WMI operations that are only Set or Query read or write sysfs
> attributes created by WMI vendor drivers make sense.
> 
> For other WMI operations that are run on Method, there needs to be a
> way to guarantee to userspace that the results from the method call
> belong to the data request to the method call.  Sysfs attributes don't
> work well in this scenario because two userspace processes may be
> competing at reading/writing an attribute and step on each other's
> data.

And you protect this from happening in the ioctl?  I didn't see it, but
ok, I'll take your word for it :)

> When a WMI vendor driver declares an ioctl in a file_operations object
> the WMI bus driver will create a character device that maps to those
> file operations.
> 
> That character device will correspond to this path:
> /dev/wmi/$driver
> 
> The WMI bus driver will interpret the IOCTL calls, test them for
> a valid instance and pass them on to the vendor driver to run.
> 
> This creates an implicit policy that only driver per character
> device.  If a module matches multiple GUID's, the wmi_devices
> will need to be all handled by the same wmi_driver if the same
> character device is used.

Interesting "way out" but ok, I can buy it...

> The WMI vendor drivers will be responsible for managing access to
> this character device and proper locking on it.
> 
> When a WMI vendor driver is unloaded the WMI bus driver will clean
> up the character device.
> 
> Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
> ---
>  MAINTAINERS                |  1 +
>  drivers/platform/x86/wmi.c | 67 +++++++++++++++++++++++++++++++++++++++++++++-
>  include/linux/wmi.h        |  2 ++
>  include/uapi/linux/wmi.h   | 10 +++++++
>  4 files changed, 79 insertions(+), 1 deletion(-)
>  create mode 100644 include/uapi/linux/wmi.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0357e9b1cfaf..6db1d84999bc 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -372,6 +372,7 @@ ACPI WMI DRIVER
>  L:	platform-driver-x86@vger.kernel.org
>  S:	Orphan
>  F:	drivers/platform/x86/wmi.c
> +F:	include/uapi/linux/wmi.h
>  
>  AD1889 ALSA SOUND DRIVER
>  M:	Thibaut Varene <T-Bone@parisc-linux.org>
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index bcb41c1c7f52..5aef052b4aab 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -38,6 +38,7 @@
>  #include <linux/init.h>
>  #include <linux/kernel.h>
>  #include <linux/list.h>
> +#include <linux/miscdevice.h>
>  #include <linux/module.h>
>  #include <linux/platform_device.h>
>  #include <linux/slab.h>
> @@ -69,6 +70,7 @@ struct wmi_block {
>  	struct wmi_device dev;
>  	struct list_head list;
>  	struct guid_block gblock;
> +	struct miscdevice misc_dev;
>  	struct acpi_device *acpi_device;
>  	wmi_notify_handler handler;
>  	void *handler_data;
> @@ -765,22 +767,80 @@ static int wmi_dev_match(struct device *dev, struct device_driver *driver)
>  	return 0;
>  }
>  
> +static long wmi_ioctl(struct file *filp, unsigned int cmd,
> +		      unsigned long arg)
> +{
> +	struct wmi_driver *wdriver;
> +	struct wmi_block *wblock;
> +	const char *driver_name;
> +	struct list_head *p;
> +	bool found = false;
> +
> +	if (_IOC_TYPE(cmd) != WMI_IOC)
> +		return -ENOTTY;
> +
> +	driver_name = filp->f_path.dentry->d_iname;
> +
> +	list_for_each(p, &wmi_block_list) {
> +		wblock = list_entry(p, struct wmi_block, list);
> +		wdriver = container_of(wblock->dev.dev.driver,
> +			struct wmi_driver, driver);
> +		if (strcmp(driver_name, wdriver->driver.name) == 0) {
> +			found = true;
> +			break;
> +		}
> +	}

You can provide an open() call to handle this type of logic for you, so
you don't have to do it on every ioctl() call, but I guess it's not
really a big deal, right?

> +	if (!found ||
> +	    !wdriver->file_operations ||
> +	    !wdriver->file_operations->unlocked_ioctl)
> +		return -ENODEV;

Shouldn't you check for unlocked_ioctl() already?  No need to check it
here, right?

And if you are only passing down unlocked_ioctl, there's no need for a
whole empty file_operations structure in the driver, right?  Just have
an ioctl callback to make things smaller and simpler to understand.

> +	/* make sure we're not calling a higher instance */
> +	if (_IOC_NR(cmd) > wblock->gblock.instance_count)
> +		return -EINVAL;

What exactly does this protect from?

> +	/* driver wants a character device made */
> +	if (wdriver->file_operations) {

Check for unlocked_ioctl here, actually, drop the file_operations
entirely, and just have that one callback.

> +		buf = kmalloc(strlen(wdriver->driver.name) + 4, GFP_KERNEL);
> +		if (!buf)
> +			return -ENOMEM;

No unwinding of other logic needed?

> +		strcpy(buf, "wmi/");
> +		strcpy(buf + 4, wdriver->driver.name);
> +		wblock->misc_dev.minor = MISC_DYNAMIC_MINOR;
> +		wblock->misc_dev.name = buf;
> +		wblock->misc_dev.fops = &wmi_fops;
> +		ret = misc_register(&wblock->misc_dev);
> +		if (ret) {
> +			dev_warn(dev, "failed to register char dev: %d", ret);
> +			kfree(buf);

Again, no unwinding needed?  Error message value returned?

> +		}
> +	}
> +
>  	if (wdriver->probe) {
>  		ret = wdriver->probe(dev_to_wdev(dev));
>  		if (ret != 0 && ACPI_FAILURE(wmi_method_enable(wblock, 0)))
>  			dev_warn(dev, "failed to disable device\n");
>  	}
> -
>  	return ret;
>  }
>  
> @@ -791,6 +851,11 @@ static int wmi_dev_remove(struct device *dev)
>  		container_of(dev->driver, struct wmi_driver, driver);
>  	int ret = 0;
>  
> +	if (wdriver->file_operations) {
> +		kfree(wblock->misc_dev.name);
> +		misc_deregister(&wblock->misc_dev);

Unregister before freeing the device name, right?

> --- /dev/null
> +++ b/include/uapi/linux/wmi.h
> @@ -0,0 +1,10 @@
> +#ifndef _UAPI_LINUX_WMI_H
> +#define _UAPI_LINUX_WMI_H
> +
> +#define WMI_IOC 'W'
> +#define WMI_IO(instance)	_IO(WMI_IOC, instance)
> +#define WMI_IOR(instance)	_IOR(WMI_IOC, instance, void*)
> +#define WMI_IOW(instance)	_IOW(WMI_IOC, instance, void*)
> +#define WMI_IOWR(instance)	_IOWR(WMI_IOC, instance, void*)

Ugh, void *, this is going to be "fun"...

My comments on just how fun is left for the actual driver that attempted
to implement these...

greg k-h

  parent reply	other threads:[~2017-10-05  7:16 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-04 22:48 [PATCH v4 00/14] Introduce support for Dell SMBIOS over WMI Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 01/14] platform/x86: wmi: Add new method wmidev_evaluate_method Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 02/14] platform/x86: dell-wmi: clean up wmi descriptor check Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 03/14] platform/x86: dell-wmi: allow 32k return size in the descriptor Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 04/14] platform/x86: dell-wmi: increase severity of some failures Mario Limonciello
2017-10-05  5:20   ` Andy Shevchenko
2017-10-05 15:02     ` Mario.Limonciello
2017-10-05 18:22       ` Andy Shevchenko
2017-10-04 22:48 ` [PATCH v4 05/14] platform/x86: dell-wmi-descriptor: split WMI descriptor into it's own driver Mario Limonciello
2017-10-05  1:09   ` Darren Hart
2017-10-05  5:29     ` Andy Shevchenko
2017-10-05  7:11       ` Darren Hart
2017-10-05  8:47         ` Andy Shevchenko
2017-10-05 13:59           ` Mario.Limonciello
2017-10-05 14:14             ` Darren Hart
2017-10-05 14:47               ` Mario.Limonciello
2017-10-05 17:22                 ` Darren Hart
2017-10-05 17:32                   ` Mario.Limonciello
2017-10-05  5:34   ` Andy Shevchenko
2017-10-05 17:04     ` Mario.Limonciello
2017-10-04 22:48 ` [PATCH v4 06/14] platform/x86: wmi: Don't allow drivers to get each other's GUIDs Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 07/14] platform/x86: dell-smbios: only run if proper oem string is detected Mario Limonciello
2017-10-04 22:48 ` [PATCH v4 08/14] platform/x86: dell-smbios: Add a sysfs interface for SMBIOS tokens Mario Limonciello
2017-10-05  8:49   ` Andy Shevchenko
2017-10-05 13:58     ` Mario.Limonciello
2017-10-05 14:22       ` Andy Shevchenko
2017-10-04 22:48 ` [PATCH v4 09/14] platform/x86: dell-smbios: Introduce dispatcher for SMM calls Mario Limonciello
2017-10-05  1:57   ` Darren Hart
2017-10-05 15:04     ` Mario.Limonciello
2017-10-04 22:48 ` [PATCH v4 10/14] platform/x86: dell-smbios-smm: test for WSMT Mario Limonciello
2017-10-05  1:59   ` Darren Hart
2017-10-04 22:48 ` [PATCH v4 11/14] platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver Mario Limonciello
2017-10-05  2:14   ` Darren Hart
2017-10-05 15:12     ` Mario.Limonciello
2017-10-05 17:57       ` Darren Hart
2017-10-05 19:47         ` Mario.Limonciello
2017-10-06 16:44           ` Darren Hart
2017-10-06 16:47             ` Mario.Limonciello
2017-10-04 22:48 ` [PATCH v4 12/14] platform/x86: wmi: create character devices when requested by drivers Mario Limonciello
2017-10-05  2:33   ` Darren Hart
2017-10-05  7:16   ` Greg KH [this message]
2017-10-05 14:35     ` Mario.Limonciello
2017-10-05 15:42       ` Greg KH
2017-10-05 15:51         ` Pali Rohár
2017-10-05 16:26           ` Greg KH
2017-10-05 17:39             ` Darren Hart
2017-10-05 18:47               ` Greg KH
2017-10-05 19:03                 ` Mario.Limonciello
2017-10-05 19:09                   ` Greg KH
2017-10-05 19:32                     ` Pali Rohár
2017-10-05 19:39                       ` Mario.Limonciello
2017-10-05 19:34                     ` Mario.Limonciello
2017-10-05 20:58                     ` Darren Hart
2017-10-05 20:51                   ` Darren Hart
2017-10-04 22:48 ` [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface Mario Limonciello
2017-10-05  7:23   ` Greg KH
2017-10-05 16:28     ` Mario.Limonciello
2017-10-05 16:34       ` Pali Rohár
2017-10-05 16:40       ` Greg KH
2017-10-05  7:33   ` Greg KH
2017-10-05 16:37     ` Mario.Limonciello
2017-10-05 13:59   ` Alan Cox
2017-10-05 14:22     ` Mario.Limonciello
2017-10-05 15:44       ` Greg KH
2017-10-05 15:56         ` Pali Rohár
2017-10-05 16:28           ` Greg KH
2017-10-05 16:48             ` Mario.Limonciello
2017-10-10 19:40               ` Alan Cox
2017-10-10 19:51                 ` Mario.Limonciello
2017-10-04 22:48 ` [PATCH v4 14/14] platform/x86: Kconfig: Set default for dell-smbios to ACPI_WMI Mario Limonciello
2017-10-05  0:09 ` [PATCH v4 00/14] Introduce support for Dell SMBIOS over WMI Darren Hart
2017-10-05  9:00   ` Andy Shevchenko

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=20171005071619.GA25960@kroah.com \
    --to=greg@kroah.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=dvhart@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mario.limonciello@dell.com \
    --cc=mjg59@google.com \
    --cc=pali.rohar@gmail.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=quasisec@google.com \
    --cc=rjw@rjwysocki.net \
    /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;
as well as URLs for NNTP newsgroup(s).