> -----Original Message-----
> From: Greg KH [mailto:g...@kroah.com]
> Sent: Saturday, October 7, 2017 2:35 AM
> To: Limonciello, Mario <mario_limoncie...@dell.com>
> Cc: dvh...@infradead.org; Andy Shevchenko <andy.shevche...@gmail.com>;
> LKML <linux-kernel@vger.kernel.org>; platform-driver-...@vger.kernel.org;
> Andy Lutomirski <l...@kernel.org>; quasi...@google.com;
> pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de
> Subject: Re: [PATCH v5 13/14] platform/x86: wmi: create character devices when
> requested by drivers
>
> On Fri, Oct 06, 2017 at 11:59:57PM -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.
> >
> > When a WMI vendor driver declares an ioctl callback in the wmi_driver
> > the WMI bus driver will create a character device that maps to that
> > function.
> >
> > 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.
> >
> > 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.
>
> What prevents the vendor driver from being unloaded while the ioctl is
> being called in it? I don't see any protection here from that at all :(
>
In my driver I take a mutex that blocks unloading while running ioctl,
but you mean you want one in the bus driver more generally, OK.
> > +static long wmi_unlocked_ioctl(struct file *filp, unsigned int cmd,
> > + unsigned long arg)
> > +{
> > + return match_ioctl(filp, cmd, arg, 0);
> > +}
> > +
> > +static long wmi_compat_ioctl(struct file *filp, unsigned int cmd,
> > + unsigned long arg)
> > +{
> > + return match_ioctl(filp, cmd, arg, 1);
> > +}
>
> Why a compat ioctl at all? That's for older interfaces, not for brand
> new ones where you design the ioctl structures "correctly" to work on
> both 32 and 64 bits at the same time. That should not be needed at all.
>
> thanks,
>
> greg k-h
I was trying to make sure that any other future vendor drivers had it for an
option. I wasn't aware that new code shouldn't use it. OK, I'll remove it.
