From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Woody Lin <woodylin@google.com>
Cc: "Todd Kjos" <tkjos@android.com>,
"Arve Hjønnevåg" <arve@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Christian Brauner" <christian@brauner.io>,
"Hridya Valsaraju" <hridya@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev
Subject: Re: [PATCH] ANDROID: staging: add userpanic-dev driver
Date: Thu, 26 Aug 2021 12:01:03 +0200 [thread overview]
Message-ID: <YSdmX956TESnJDey@kroah.com> (raw)
In-Reply-To: <20210826092854.58694-1-woodylin@google.com>
On Thu, Aug 26, 2021 at 05:28:54PM +0800, Woody Lin wrote:
> Add char device driver 'userpanic-dev' that exposes an interface to
> userspace processes to request a system panic with customized panic
> message.
Some comments on the code now:
> obj-$(CONFIG_ASHMEM) += ashmem.o
> +obj-$(CONFIG_USERPANIC_CHARDEV) += userpanic-dev.o
Why CHARDEV?
> diff --git a/drivers/staging/android/userpanic-dev.c b/drivers/staging/android/userpanic-dev.c
> new file mode 100644
> index 000000000000..b9a0f0c01826
> --- /dev/null
> +++ b/drivers/staging/android/userpanic-dev.c
> @@ -0,0 +1,110 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/* userpanic-dev.c
> + *
> + * User-panic Device Interface
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
Why is this needed?
> +
> +#include <linux/slab.h>
> +#include <linux/module.h>
> +#include <linux/string.h>
> +#include <linux/miscdevice.h>
> +
> +struct userpanic_crash_info {
> + void __user *title_uaddr;
> + void __user *msg_uaddr;
> +};
If this is a user/kernel api, it can not be burried in a .c file,
otherwise it will be wrong over time.
And this is NOT how to handle user/kernel pointers at all, please fix.
> +
> +#define CRASH_INFO (_IOW('U', 179, struct userpanic_crash_info))
Why does this have to be an ioctl at all?
Why do you have to have a char device for this?
> +
> +static int do_userpanic(const char *title, const char *msg)
> +{
> + const size_t msgbuf_sz = PAGE_SIZE;
> + char *msgbuf;
> +
> + msgbuf = kmalloc(msgbuf_sz, GFP_KERNEL);
> + if (!msgbuf)
> + return -ENOMEM;
> +
> + pr_emerg("User process '%.*s' %d requesting kernel panic\n",
> + sizeof(current->comm), current->comm, current->pid);
You have a pointer to a struct device, always use it for this and all
other messages, it should be dev_*(), right?
> + if (msg)
> + pr_emerg(" with message: %s\n", msg);
Multi line messages? Why?
> +
> + /* Request panic with customized panic title. */
> + snprintf(msgbuf, msgbuf_sz, "U: %s: %s", current->comm, title);
> + panic(msgbuf);
> + kfree(msgbuf);
Nice, you cleaned up after panicing? Why?
> + return -EFAULT;
> +}
> +
> +static long userpanic_device_ioctl(struct file *file, u_int cmd, u_long arg)
> +{
> + struct userpanic_crash_info crash_info;
> + char *title;
> + char *msg = NULL;
> + int ret;
> +
> + switch (cmd) {
> + case CRASH_INFO:
> + if (copy_from_user(&crash_info, (void __user *)arg, sizeof(crash_info)))
> + return -EFAULT;
> +
> + if (!crash_info.title_uaddr)
> + return -EINVAL;
> +
> + title = strndup_user(crash_info.title_uaddr, PAGE_SIZE);
What if the string was bigger?
> + if (IS_ERR(title)) {
> + pr_err("failed to strndup .title_uaddr: %d\n", PTR_ERR(title));
> + return -EINVAL;
> + }
> +
> + if (crash_info.msg_uaddr) {
> + msg = strndup_user(crash_info.msg_uaddr, PAGE_SIZE);
> + if (IS_ERR(msg)) {
> + kfree(title);
> + pr_err("failed to strndup .msg_uaddr: %d\n", PTR_ERR(msg));
> + return -EINVAL;
> + }
> + }
> +
> + ret = do_userpanic(title, msg);
> + kfree(msg);
> + kfree(title);
> + return ret;
This can never be hit, right?
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct file_operations userpanic_device_fops = {
> + .owner = THIS_MODULE,
> + .unlocked_ioctl = userpanic_device_ioctl,
> + .compat_ioctl = compat_ptr_ioctl,
No need for the compat ioctl, do it right the first time.
> +};
> +
> +static struct miscdevice userpanic_device = {
> + .minor = MISC_DYNAMIC_MINOR,
> + .name = "userspace_panic",
> + .fops = &userpanic_device_fops,
> +};
> +
> +static int __init userspace_panic_dev_init(void)
> +{
> + int ret;
> +
> + ret = misc_register(&userpanic_device);
> + if (ret)
> + pr_err("misc_register failed for userspace_panic device\n");
> +
> + return ret;
> +}
Use the correct misc macro here, no need for an init or exit function.
Wait, where is your exit function?
> +device_initcall(userspace_panic_dev_init);
Why this init call level? Why not the normal one?
thanks,
greg k-h
next prev parent reply other threads:[~2021-08-26 10:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-26 9:28 [PATCH] ANDROID: staging: add userpanic-dev driver Woody Lin
2021-08-26 9:48 ` Greg Kroah-Hartman
2021-08-26 10:23 ` Woody Lin
2021-08-26 10:54 ` Greg Kroah-Hartman
2021-08-27 3:51 ` Woody Lin
2021-08-27 7:14 ` Greg Kroah-Hartman
2021-09-01 8:56 ` Woody Lin
2021-08-26 10:01 ` Greg Kroah-Hartman [this message]
2021-08-26 13:06 ` kernel test robot
2021-08-26 13:06 ` kernel test robot
2021-08-26 13:57 ` kernel test robot
2021-08-26 13:57 ` kernel test robot
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=YSdmX956TESnJDey@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=hridya@google.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=maco@android.com \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=woodylin@google.com \
/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.