From: Greg KH <gregkh@linuxfoundation.org>
To: matt.hsiao@hpe.com
Cc: linux-kernel@vger.kernel.org, arnd@arndb.de,
jerry.hoemann@hpe.com, scott.norton@hpe.com, camille.lu@hpe.com,
geoffrey.ndu@hpe.com, gustavo.knuppe@hpe.com
Subject: Re: [PATCH v2 1/1] misc: hpilo: switch .{read,write} ops to .{read,write}_iter
Date: Wed, 13 Jul 2022 20:28:24 +0200 [thread overview]
Message-ID: <Ys8OyLA35o/wr1jB@kroah.com> (raw)
In-Reply-To: <20220713175452.4221-2-matt.hsiao@hpe.com>
On Thu, Jul 14, 2022 at 01:54:52AM +0800, matt.hsiao@hpe.com wrote:
> From: Matt Hsiao <matt.hsiao@hpe.com>
>
> Commit 4d03e3cc59828c82ee89 ("fs: don't allow kernel reads and writes
> without iter ops") requested exclusive .{read,write}_iter ops for
> kernel_{read,write}. To support dependent drivers to access hpilo by
> kernel_{read,write}, switch .{read,write} ops to their iter variants.
>
> Signed-off-by: Matt Hsiao <matt.hsiao@hpe.com>
So this fixes a bug? What commit does this fix?
Should it go to stable branches? If so, which ones?
But my main question is I have no idea what the changelog means here.
What is a "dependent driver"? What does "exclusive" mean here? What is
a iter variant?
> ---
> drivers/misc/hpilo.c | 31 ++++++++++++++++++-------------
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/misc/hpilo.c b/drivers/misc/hpilo.c
> index 8d00df9243c4..5d431a56b7eb 100644
> --- a/drivers/misc/hpilo.c
> +++ b/drivers/misc/hpilo.c
> @@ -23,6 +23,7 @@
> #include <linux/wait.h>
> #include <linux/poll.h>
> #include <linux/slab.h>
> +#include <linux/uio.h>
> #include "hpilo.h"
>
> static struct class *ilo_class;
> @@ -435,14 +436,14 @@ static void ilo_set_reset(struct ilo_hwinfo *hw)
> }
> }
>
> -static ssize_t ilo_read(struct file *fp, char __user *buf,
> - size_t len, loff_t *off)
> +static ssize_t ilo_read_iter(struct kiocb *iocb, struct iov_iter *to)
> {
> - int err, found, cnt, pkt_id, pkt_len;
> - struct ccb_data *data = fp->private_data;
> + int err = 0, found, cnt, pkt_id, pkt_len;
> + struct ccb_data *data = iocb->ki_filp->private_data;
> struct ccb *driver_ccb = &data->driver_ccb;
> struct ilo_hwinfo *hw = data->ilo_hw;
> void *pkt;
> + size_t len = iov_iter_count(to), copied;
>
> if (is_channel_reset(driver_ccb)) {
> /*
> @@ -477,7 +478,9 @@ static ssize_t ilo_read(struct file *fp, char __user *buf,
> if (pkt_len < len)
> len = pkt_len;
>
> - err = copy_to_user(buf, pkt, len);
> + copied = copy_to_iter(pkt, len, to);
> + if (unlikely(copied != len))
Why unlikely? If you can prove it is needed in benchmarks, great,
otherwise never add likely/unlikely as they are almost always wrong and
the compiler and cpu can do it better.
> + err = -EFAULT;
>
> /* return the received packet to the queue */
> ilo_pkt_enqueue(hw, driver_ccb, RECVQ, pkt_id, desc_mem_sz(1));
> @@ -485,14 +488,14 @@ static ssize_t ilo_read(struct file *fp, char __user *buf,
> return err ? -EFAULT : len;
> }
>
> -static ssize_t ilo_write(struct file *fp, const char __user *buf,
> - size_t len, loff_t *off)
> +static ssize_t ilo_write_iter(struct kiocb *iocb, struct iov_iter *from)
> {
> - int err, pkt_id, pkt_len;
> - struct ccb_data *data = fp->private_data;
> + int err = 0, pkt_id, pkt_len;
> + struct ccb_data *data = iocb->ki_filp->private_data;
> struct ccb *driver_ccb = &data->driver_ccb;
> struct ilo_hwinfo *hw = data->ilo_hw;
> void *pkt;
> + size_t len = iov_iter_count(from), copied;
>
> if (is_channel_reset(driver_ccb))
> return -ENODEV;
> @@ -506,9 +509,11 @@ static ssize_t ilo_write(struct file *fp, const char __user *buf,
> len = pkt_len;
>
> /* on failure, set the len to 0 to return empty packet to the device */
> - err = copy_from_user(pkt, buf, len);
> - if (err)
> + copied = copy_from_iter(pkt, len, from);
> + if (unlikely(copied != len)) {
Same here.
thanks,
greg k-h
next prev parent reply other threads:[~2022-07-13 18:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-13 17:54 [PATCH v2 0/1] misc: hpilo: switch .{read,write} ops to .{read,write}_iter matt.hsiao
2022-07-13 17:54 ` [PATCH v2 1/1] " matt.hsiao
2022-07-13 18:28 ` Greg KH [this message]
2022-07-15 8:55 ` Matt Hsiao
2022-07-15 11:36 ` Greg KH
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=Ys8OyLA35o/wr1jB@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=camille.lu@hpe.com \
--cc=geoffrey.ndu@hpe.com \
--cc=gustavo.knuppe@hpe.com \
--cc=jerry.hoemann@hpe.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.hsiao@hpe.com \
--cc=scott.norton@hpe.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox