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
next prev parent reply other threads:[~2017-10-05 7:16 UTC|newest]
Thread overview: 93+ 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 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 13:59 ` Mario.Limonciello
2017-10-05 14:14 ` Darren Hart
2017-10-05 14:47 ` Mario.Limonciello
2017-10-05 14:47 ` Mario.Limonciello
2017-10-05 17:22 ` Darren Hart
2017-10-05 17:32 ` Mario.Limonciello
2017-10-05 17:32 ` Mario.Limonciello
2017-10-05 5:34 ` Andy Shevchenko
2017-10-05 17:04 ` Mario.Limonciello
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 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-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 15:12 ` Mario.Limonciello
2017-10-05 17:57 ` Darren Hart
2017-10-05 19:47 ` Mario.Limonciello
2017-10-05 19:47 ` Mario.Limonciello
2017-10-06 16:44 ` Darren Hart
2017-10-06 16:47 ` Mario.Limonciello
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 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: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:39 ` Mario.Limonciello
2017-10-05 19:34 ` 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:28 ` Mario.Limonciello
2017-10-05 16:34 ` Pali Rohár
2017-10-05 16:40 ` Greg KH
2017-10-05 16:40 ` Greg KH
2017-10-05 7:33 ` Greg KH
2017-10-05 16:37 ` Mario.Limonciello
2017-10-05 16:37 ` Mario.Limonciello
2017-10-05 13:59 ` Alan Cox
2017-10-05 14:22 ` Mario.Limonciello
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-05 16:48 ` Mario.Limonciello
2017-10-10 19:40 ` Alan Cox
2017-10-10 19:40 ` Alan Cox
2017-10-10 19:51 ` Mario.Limonciello
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.