linux-kernel - Re: [PATCH v3 1/2] misc: pvpanic: introduce device capability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <X/hmz0ZdKyvwtq5z@kroah.com>
Date:   Fri, 8 Jan 2021 15:06:07 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     zhenwei pi <pizhenwei@...edance.com>
Cc:     arnd@...db.de, pbonzini@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] misc: pvpanic: introduce device capability

On Fri, Jan 08, 2021 at 09:52:22PM +0800, zhenwei pi wrote:
> According to pvpanic spec:
> https://git.qemu.org/?p=qemu.git;a=blob_plain;f=docs/specs/pvpanic.txt
> 
> The guest should determine pvpanic capability by RDPT, so initialize
> capability during device probing. There is no need to register panic
> notifier callback function if no events supported.
> 
> Before sending event to host side, check capability firstly.
> 
> Suggested by Greg KH, use sysfs to expose capability to user space.
> 
> Signed-off-by: zhenwei pi <pizhenwei@...edance.com>
> ---
>  .../ABI/testing/sysfs-bus-pci-devices-pvpanic |  7 ++++
>  drivers/misc/pvpanic.c                        | 41 ++++++++++++++++---
>  2 files changed, 42 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> new file mode 100644
> index 000000000000..5daf1167b1c1
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-pvpanic
> @@ -0,0 +1,7 @@
> +What:		/sys/devices/pci0000:00/*/QEMU0001:00/capability
> +Date:		Jan 2021
> +Contact:	zhenwei pi <pizhenwei@...edance.com>
> +Description:
> +		Capabilities of pvpanic device which are supported by
> +		QEMU.
> +		Format: %s.

This really can be 2 values in the string, shouldn't you list what the
file can contain here so that people know what to expect?

> diff --git a/drivers/misc/pvpanic.c b/drivers/misc/pvpanic.c
> index 951b37da5e3c..e1023c7b8fb0 100644
> --- a/drivers/misc/pvpanic.c
> +++ b/drivers/misc/pvpanic.c
> @@ -19,6 +19,27 @@
>  #include <uapi/misc/pvpanic.h>
>  
>  static void __iomem *base;
> +static unsigned int capability = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED;
> +
> +static ssize_t capability_show(struct device *dev,
> +			       struct device_attribute *attr, char *buf)
> +{
> +	return sprintf(buf, "%s%s\n",
> +		capability & PVPANIC_PANICKED ? "PANICKED " : "",
> +		capability & PVPANIC_CRASH_LOADED ? "CRASH_LOADED" : "");
> +}
> +static DEVICE_ATTR_RO(capability);
> +
> +static struct attribute *pvpanic_sysfs_entries[] = {
> +	&dev_attr_capability.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group pvpanic_attribute_group = {
> +	.name = NULL,
> +	.attrs = pvpanic_sysfs_entries,
> +};
> +
>  
>  MODULE_AUTHOR("Hu Tao <hutao@...fujitsu.com>");
>  MODULE_DESCRIPTION("pvpanic device driver");
> @@ -27,7 +48,8 @@ MODULE_LICENSE("GPL");
>  static void
>  pvpanic_send_event(unsigned int event)
>  {
> -	iowrite8(event, base);
> +	if (event & capability)
> +		iowrite8(event, base);
>  }
>  
>  static int
> @@ -62,17 +84,24 @@ static int pvpanic_mmio_probe(struct platform_device *pdev)
>  	if (IS_ERR(base))
>  		return PTR_ERR(base);
>  
> -	atomic_notifier_chain_register(&panic_notifier_list,
> -				       &pvpanic_panic_nb);
> +	/* initlize capability by RDPT */
> +	capability &= ioread8(base);
>  
> -	return 0;
> +	if (capability)
> +		atomic_notifier_chain_register(&panic_notifier_list,
> +					       &pvpanic_panic_nb);
> +
> +	return sysfs_create_group(&dev->kobj, &pvpanic_attribute_group);

You just raced with userspace and lost :(

If you ever find yourself calling a sysfs_* function in a driver, that
is a huge hint that you are not doing something correctly.  Please just
set the default groups of your platform driver to this group, and the
driver core will handle all of the file creation/removal automatically
for you, in a race-free way.

thanks,

greg k-h