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: 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).