From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: wsa@kernel.org, jie.deng@intel.com, viresh.kumar@linaro.org,
conghui.chen@intel.com,
virtualization@lists.linux-foundation.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@axis.com
Subject: Re: [PATCH v2 2/2] i2c: virtio: fix completion handling
Date: Thu, 11 Nov 2021 11:57:30 -0500 [thread overview]
Message-ID: <20211111114630-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20211111160412.11980-3-vincent.whitchurch@axis.com>
On Thu, Nov 11, 2021 at 05:04:12PM +0100, Vincent Whitchurch wrote:
> The driver currently assumes that the notify callback is only received
> when the device is done with all the queued buffers.
>
> However, this is not true, since the notify callback could be called
> without any of the queued buffers being completed (for example, with
> virtio-pci and shared interrupts) or with only some of the buffers being
> completed (since the driver makes them available to the device in
> multiple separate virtqueue_add_sgs() calls).
>
> This can lead to incorrect data on the I2C bus or memory corruption in
> the guest if the device operates on buffers which are have been freed by
> the driver. (The WARN_ON in the driver is also triggered.)
>
> BUG kmalloc-128 (Tainted: G W ): Poison overwritten
> First byte 0x0 instead of 0x6b
> Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28
> memdup_user+0x2e/0xbd
> i2cdev_ioctl_rdwr+0x9d/0x1de
> i2cdev_ioctl+0x247/0x2ed
> vfs_ioctl+0x21/0x30
> sys_ioctl+0xb18/0xb41
> Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28
> kfree+0x1bd/0x1cc
> i2cdev_ioctl_rdwr+0x1bb/0x1de
> i2cdev_ioctl+0x247/0x2ed
> vfs_ioctl+0x21/0x30
> sys_ioctl+0xb18/0xb41
>
> Fix this by calling virtio_get_buf() from the notify handler like other
> virtio drivers and by actually waiting for all the buffers to be
> completed.
>
> Fixes: 3cfc88380413d20f ("i2c: virtio: add a virtio i2c frontend driver")
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> ---
> drivers/i2c/busses/i2c-virtio.c | 34 +++++++++++++++------------------
> 1 file changed, 15 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-virtio.c b/drivers/i2c/busses/i2c-virtio.c
> index 7b2474e6876f..2d3ae8e238ec 100644
> --- a/drivers/i2c/busses/i2c-virtio.c
> +++ b/drivers/i2c/busses/i2c-virtio.c
> @@ -22,24 +22,24 @@
> /**
> * struct virtio_i2c - virtio I2C data
> * @vdev: virtio device for this controller
> - * @completion: completion of virtio I2C message
> * @adap: I2C adapter for this controller
> * @vq: the virtio virtqueue for communication
> */
> struct virtio_i2c {
> struct virtio_device *vdev;
> - struct completion completion;
> struct i2c_adapter adap;
> struct virtqueue *vq;
> };
>
> /**
> * struct virtio_i2c_req - the virtio I2C request structure
> + * @completion: completion of virtio I2C message
> * @out_hdr: the OUT header of the virtio I2C message
> * @buf: the buffer into which data is read, or from which it's written
> * @in_hdr: the IN header of the virtio I2C message
> */
> struct virtio_i2c_req {
> + struct completion completion;
> struct virtio_i2c_out_hdr out_hdr ____cacheline_aligned;
> uint8_t *buf ____cacheline_aligned;
> struct virtio_i2c_in_hdr in_hdr ____cacheline_aligned;
> @@ -47,9 +47,11 @@ struct virtio_i2c_req {
>
> static void virtio_i2c_msg_done(struct virtqueue *vq)
> {
> - struct virtio_i2c *vi = vq->vdev->priv;
> + struct virtio_i2c_req *req;
> + unsigned int len;
>
> - complete(&vi->completion);
> + while ((req = virtqueue_get_buf(vq, &len)))
> + complete(&req->completion);
> }
>
> static int virtio_i2c_prepare_reqs(struct virtqueue *vq,
> @@ -69,6 +71,8 @@ static int virtio_i2c_prepare_reqs(struct virtqueue *vq,
> if (!msgs[i].len)
> break;
>
> + init_completion(&reqs[i].completion);
> +
> /*
> * Only 7-bit mode supported for this moment. For the address
> * format, Please check the Virtio I2C Specification.
> @@ -108,21 +112,13 @@ static int virtio_i2c_complete_reqs(struct virtqueue *vq,
> struct virtio_i2c_req *reqs,
> struct i2c_msg *msgs, int num)
> {
> - struct virtio_i2c_req *req;
> bool failed = false;
> - unsigned int len;
> int i, j = 0;
>
> for (i = 0; i < num; i++) {
> - /* Detach the ith request from the vq */
> - req = virtqueue_get_buf(vq, &len);
> + struct virtio_i2c_req *req = &reqs[i];
>
> - /*
> - * Condition req == &reqs[i] should always meet since we have
> - * total num requests in the vq. reqs[i] can never be NULL here.
> - */
> - if (!failed && (WARN_ON(req != &reqs[i]) ||
> - req->in_hdr.status != VIRTIO_I2C_MSG_OK))
> + if (!failed && req->in_hdr.status != VIRTIO_I2C_MSG_OK)
> failed = true;
>
> i2c_put_dma_safe_msg_buf(reqs[i].buf, &msgs[i], !failed);
> @@ -158,11 +154,13 @@ static int virtio_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
> * remote here to clear the virtqueue, so we can try another set of
> * messages later on.
> */
> -
> - reinit_completion(&vi->completion);
> virtqueue_kick(vq);
>
> - wait_for_completion(&vi->completion);
> + /*
> + * We only need to wait for the last one since the device is required
> + * to complete requests in order.
> + */
Hmm the spec only says:
A device MUST guarantee the requests in the virtqueue being processed in order
if multiple requests are received at a time.
it does not seem to require using the buffers in order.
In any case, just waiting for all of them in a loop
seems cleaner and likely won't take longer ...
> + wait_for_completion(&reqs[count - 1].completion);
>
> count = virtio_i2c_complete_reqs(vq, reqs, msgs, count);
>
> @@ -211,8 +209,6 @@ static int virtio_i2c_probe(struct virtio_device *vdev)
> vdev->priv = vi;
> vi->vdev = vdev;
>
> - init_completion(&vi->completion);
> -
> ret = virtio_i2c_setup_vqs(vi);
> if (ret)
> return ret;
> --
> 2.28.0
next prev parent reply other threads:[~2021-11-11 16:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-11 16:04 [PATCH v2 0/2] virtio-i2c: Fix buffer handling Vincent Whitchurch
2021-11-11 16:04 ` [PATCH v2 1/2] i2c: virtio: disable timeout handling Vincent Whitchurch
2021-11-11 16:46 ` Michael S. Tsirkin
2021-11-12 2:35 ` Viresh Kumar
2021-11-19 15:30 ` Vincent Whitchurch
2021-11-23 9:52 ` Wolfram Sang
2021-11-23 9:54 ` Viresh Kumar
2021-11-23 9:55 ` Wolfram Sang
2021-11-11 16:04 ` [PATCH v2 2/2] i2c: virtio: fix completion handling Vincent Whitchurch
2021-11-11 16:57 ` Michael S. Tsirkin [this message]
2021-12-02 15:34 ` Vincent Whitchurch
2021-11-24 23:55 ` [PATCH v2 0/2] virtio-i2c: Fix buffer handling Michael S. Tsirkin
2021-11-25 3:21 ` Viresh Kumar
2021-11-25 6:24 ` Wolfram Sang
2021-11-25 6:47 ` Viresh Kumar
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=20211111114630-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=conghui.chen@intel.com \
--cc=jie.deng@intel.com \
--cc=kernel@axis.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vincent.whitchurch@axis.com \
--cc=viresh.kumar@linaro.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=wsa@kernel.org \
/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).