* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Daniel Vetter @ 2017-11-28 10:22 UTC (permalink / raw)
To: Sudip Mukherjee, Greg KH
Cc: Teddy Wang, David Airlie, amd-gfx, Michał Mirosław,
dri-devel, Daniel Vetter, Alex Deucher, virtualization,
Christian König
In-Reply-To: <20171127205219.GA3537@sudip-laptop>
On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote:
> On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > the same code. Extract common part from PCI drivers into separate
> > > remove_conflicting_pci_framebuffers().
> > >
> > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> >
> > Since the only driver that seems to use this is the staging one, which imo
> > is a DOA project, not sure it's worth to bother with this here.
>
> afaik, this device is used in production by few manufacturers and it is
> usefull for them to have it in the tree and the only reason it is still
> in staging is because Tomi announced he will not take any new drivers in
> fbdev. And, so I have not taken the initiative to properly move it out
> of staging. I think Bartlomiej will also not accept new drivers in fbdev.
Imo, if no one cares about porting it to kms (which will give you an fbdev
driver for free), then we should throw it out. At least I thought staging
was only for stuff that had a reasonable chance to get mainlined. Not as a
dumping ground for drivers that people use, but don't bother to get ready
for mainline.
Greg?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] VSOCK: Don't set sk_state to TCP_CLOSE before testing it
From: Stefan Hajnoczi @ 2017-11-28 10:35 UTC (permalink / raw)
To: Jorgen Hansen
Cc: pv-drivers, netdev, linux-kernel, virtualization, gregkh, davem
In-Reply-To: <1511789372-12672-1-git-send-email-jhansen@vmware.com>
[-- Attachment #1.1: Type: text/plain, Size: 632 bytes --]
On Mon, Nov 27, 2017 at 05:29:32AM -0800, Jorgen Hansen wrote:
> A recent commit (3b4477d2dcf2) converted the sk_state to use
> TCP constants. In that change, vmci_transport_handle_detach
> was changed such that sk->sk_state was set to TCP_CLOSE before
> we test whether it is TCP_SYN_SENT. This change moves the
> sk_state change back to the original locations in that function.
>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
> ---
> net/vmw_vsock/vmci_transport.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Sorry, silly bug on my part!
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Greg KH @ 2017-11-28 11:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: Teddy Wang, Christian König, David Airlie, amd-gfx,
Michał Mirosław, dri-devel, Alex Deucher,
virtualization, Sudip Mukherjee
In-Reply-To: <20171128102217.b7ynyqarwzkdvmdq@phenom.ffwll.local>
On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote:
> > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > > the same code. Extract common part from PCI drivers into separate
> > > > remove_conflicting_pci_framebuffers().
> > > >
> > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > >
> > > Since the only driver that seems to use this is the staging one, which imo
> > > is a DOA project, not sure it's worth to bother with this here.
> >
> > afaik, this device is used in production by few manufacturers and it is
> > usefull for them to have it in the tree and the only reason it is still
> > in staging is because Tomi announced he will not take any new drivers in
> > fbdev. And, so I have not taken the initiative to properly move it out
> > of staging. I think Bartlomiej will also not accept new drivers in fbdev.
>
> Imo, if no one cares about porting it to kms (which will give you an fbdev
> driver for free), then we should throw it out. At least I thought staging
> was only for stuff that had a reasonable chance to get mainlined. Not as a
> dumping ground for drivers that people use, but don't bother to get ready
> for mainline.
>
> Greg?
Yes, if no one is working to get it out of staging, that means no one
cares about it, and it needs to be removed from the tree.
thanks,
greg k-h
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Sudip Mukherjee @ 2017-11-28 12:30 UTC (permalink / raw)
To: Greg KH
Cc: Teddy Wang, David Airlie, amd-gfx, Michał Mirosław,
dri-devel, Daniel Vetter, Alex Deucher, virtualization,
Christian König
In-Reply-To: <20171128113238.GA29456@kroah.com>
On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
> On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote:
> > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > > > the same code. Extract common part from PCI drivers into separate
> > > > > remove_conflicting_pci_framebuffers().
> > > > >
> > > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > >
> > > > Since the only driver that seems to use this is the staging one, which imo
> > > > is a DOA project, not sure it's worth to bother with this here.
> > >
> > > afaik, this device is used in production by few manufacturers and it is
> > > usefull for them to have it in the tree and the only reason it is still
> > > in staging is because Tomi announced he will not take any new drivers in
> > > fbdev. And, so I have not taken the initiative to properly move it out
> > > of staging. I think Bartlomiej will also not accept new drivers in fbdev.
> >
> > Imo, if no one cares about porting it to kms (which will give you an fbdev
> > driver for free), then we should throw it out. At least I thought staging
> > was only for stuff that had a reasonable chance to get mainlined. Not as a
> > dumping ground for drivers that people use, but don't bother to get ready
> > for mainline.
> >
> > Greg?
>
> Yes, if no one is working to get it out of staging, that means no one
> cares about it, and it needs to be removed from the tree.
Agreed. I was not working on getting it out of staging as there is no
place for it to go.
But, Teddy Wang told me that they have a working drm driver for it, but
it is not atomic like Daniel was asking for. If it is ok, then I can send
in a patch to remove the existing sm750 from staging and add the new sm750
drm driver to staging. And after it is ready, we can go ahead with moving
it out of staging to drm.
Greg? Daniel?
--
Regards
Sudip
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()
From: Greg KH @ 2017-11-28 13:06 UTC (permalink / raw)
To: Sudip Mukherjee
Cc: Teddy Wang, David Airlie, amd-gfx, Michał Mirosław,
dri-devel, Daniel Vetter, Alex Deucher, virtualization,
Christian König
In-Reply-To: <20171128123008.GA12986@sudip-tp>
On Tue, Nov 28, 2017 at 12:30:30PM +0000, Sudip Mukherjee wrote:
> On Tue, Nov 28, 2017 at 12:32:38PM +0100, Greg KH wrote:
> > On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 27, 2017 at 08:52:19PM +0000, Sudip Mukherjee wrote:
> > > > On Mon, Nov 27, 2017 at 11:27:59AM +0100, Daniel Vetter wrote:
> > > > > On Fri, Nov 24, 2017 at 06:53:31PM +0100, Michał Mirosław wrote:
> > > > > > Almost all drivers using remove_conflicting_framebuffers() wrap it with
> > > > > > the same code. Extract common part from PCI drivers into separate
> > > > > > remove_conflicting_pci_framebuffers().
> > > > > >
> > > > > > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > > > >
> > > > > Since the only driver that seems to use this is the staging one, which imo
> > > > > is a DOA project, not sure it's worth to bother with this here.
> > > >
> > > > afaik, this device is used in production by few manufacturers and it is
> > > > usefull for them to have it in the tree and the only reason it is still
> > > > in staging is because Tomi announced he will not take any new drivers in
> > > > fbdev. And, so I have not taken the initiative to properly move it out
> > > > of staging. I think Bartlomiej will also not accept new drivers in fbdev.
> > >
> > > Imo, if no one cares about porting it to kms (which will give you an fbdev
> > > driver for free), then we should throw it out. At least I thought staging
> > > was only for stuff that had a reasonable chance to get mainlined. Not as a
> > > dumping ground for drivers that people use, but don't bother to get ready
> > > for mainline.
> > >
> > > Greg?
> >
> > Yes, if no one is working to get it out of staging, that means no one
> > cares about it, and it needs to be removed from the tree.
>
> Agreed. I was not working on getting it out of staging as there is no
> place for it to go.
> But, Teddy Wang told me that they have a working drm driver for it, but
> it is not atomic like Daniel was asking for. If it is ok, then I can send
> in a patch to remove the existing sm750 from staging and add the new sm750
> drm driver to staging. And after it is ready, we can go ahead with moving
> it out of staging to drm.
>
> Greg? Daniel?
I'll always take patches that delete code from staging :)
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH v3] s390/virtio: add BSD license to virtio-ccw
From: Michael S. Tsirkin @ 2017-11-28 13:17 UTC (permalink / raw)
To: linux-kernel
Cc: linux-s390, Cornelia Huck, Heiko Carstens, virtualization,
Martin Schwidefsky
The original intent of the virtio header relicensing
from 2008 was to make sure anyone can implement compatible
devices/drivers. The virtio-ccw was omitted by mistake.
We have an ack from the only contributor as well as the
maintainer from IBM, so it's not too late to fix that.
Make it dual-licensed with GPLv2, as the whole kernel is GPL2.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/s390/include/uapi/asm/virtio-ccw.h | 6 +-----
arch/s390/kernel/setup.c | 1 -
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/s390/include/uapi/asm/virtio-ccw.h b/arch/s390/include/uapi/asm/virtio-ccw.h
index 967aad3..2b605f7 100644
--- a/arch/s390/include/uapi/asm/virtio-ccw.h
+++ b/arch/s390/include/uapi/asm/virtio-ccw.h
@@ -1,13 +1,9 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
/*
* Definitions for virtio-ccw devices.
*
* Copyright IBM Corp. 2013
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License (version 2 only)
- * as published by the Free Software Foundation.
- *
* Author(s): Cornelia Huck <cornelia.huck@de.ibm.com>
*/
#ifndef __KVM_VIRTIO_CCW_H
diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
index 164a1e1..c022007 100644
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -60,7 +60,6 @@
#include <asm/ptrace.h>
#include <asm/sections.h>
#include <asm/ebcdic.h>
-#include <asm/kvm_virtio.h>
#include <asm/diag.h>
#include <asm/os_info.h>
#include <asm/sclp.h>
--
MST
^ permalink raw reply related
* Re: [PATCH v3] s390/virtio: add BSD license to virtio-ccw
From: Cornelia Huck @ 2017-11-28 13:51 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-s390, Heiko Carstens, linux-kernel, virtualization,
Martin Schwidefsky
In-Reply-To: <1511874948-27609-1-git-send-email-mst@redhat.com>
On Tue, 28 Nov 2017 15:17:52 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> The original intent of the virtio header relicensing
> from 2008 was to make sure anyone can implement compatible
> devices/drivers. The virtio-ccw was omitted by mistake.
>
> We have an ack from the only contributor as well as the
> maintainer from IBM, so it's not too late to fix that.
>
> Make it dual-licensed with GPLv2, as the whole kernel is GPL2.
>
> Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Acked-by: Cornelia Huck <cohuck@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> arch/s390/include/uapi/asm/virtio-ccw.h | 6 +-----
> arch/s390/kernel/setup.c | 1 -
> 2 files changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/arch/s390/include/uapi/asm/virtio-ccw.h b/arch/s390/include/uapi/asm/virtio-ccw.h
> index 967aad3..2b605f7 100644
> --- a/arch/s390/include/uapi/asm/virtio-ccw.h
> +++ b/arch/s390/include/uapi/asm/virtio-ccw.h
> @@ -1,13 +1,9 @@
> -/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
> +/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
> /*
> * Definitions for virtio-ccw devices.
> *
> * Copyright IBM Corp. 2013
> *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License (version 2 only)
> - * as published by the Free Software Foundation.
> - *
> * Author(s): Cornelia Huck <cornelia.huck@de.ibm.com>
> */
> #ifndef __KVM_VIRTIO_CCW_H
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 164a1e1..c022007 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -60,7 +60,6 @@
> #include <asm/ptrace.h>
> #include <asm/sections.h>
> #include <asm/ebcdic.h>
> -#include <asm/kvm_virtio.h>
> #include <asm/diag.h>
> #include <asm/os_info.h>
> #include <asm/sclp.h>
Shouldn't the second hunk already be in master?
Still ack otherwise.
^ permalink raw reply
* [PATCH v4] s390/virtio: add BSD license to virtio-ccw
From: Michael S. Tsirkin @ 2017-11-28 14:11 UTC (permalink / raw)
To: linux-kernel
Cc: linux-s390, Cornelia Huck, Heiko Carstens, virtualization,
Martin Schwidefsky
The original intent of the virtio header relicensing
from 2008 was to make sure anyone can implement compatible
devices/drivers. The virtio-ccw was omitted by mistake.
We have an ack from the only contributor as well as the
maintainer from IBM, so it's not too late to fix that.
Make it dual-licensed with GPLv2, as the whole kernel is GPL2.
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
arch/s390/include/uapi/asm/virtio-ccw.h | 6 +-----
1 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/s390/include/uapi/asm/virtio-ccw.h b/arch/s390/include/uapi/asm/virtio-ccw.h
index 967aad3..2b605f7 100644
--- a/arch/s390/include/uapi/asm/virtio-ccw.h
+++ b/arch/s390/include/uapi/asm/virtio-ccw.h
@@ -1,13 +1,9 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) */
/*
* Definitions for virtio-ccw devices.
*
* Copyright IBM Corp. 2013
*
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License (version 2 only)
- * as published by the Free Software Foundation.
- *
* Author(s): Cornelia Huck <cornelia.huck@de.ibm.com>
*/
#ifndef __KVM_VIRTIO_CCW_H
--
MST
^ permalink raw reply related
* [PATCH] virtio-mmio: Use PTR_ERR_OR_ZERO()
From: Vasyl Gomonovych @ 2017-11-28 15:15 UTC (permalink / raw)
To: mst, jasowang, virtualization; +Cc: gomonovych, linux-kernel
Fix ptr_ret.cocci warnings:
drivers/virtio/virtio_mmio.c:653:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Vasyl Gomonovych <gomonovych@gmail.com>
---
drivers/virtio/virtio_mmio.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 74dc7170fd35..8cffcb1706e1 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -650,10 +650,8 @@ static int vm_cmdline_set(const char *device,
pdev = platform_device_register_resndata(&vm_cmdline_parent,
"virtio-mmio", vm_cmdline_id++,
resources, ARRAY_SIZE(resources), NULL, 0);
- if (IS_ERR(pdev))
- return PTR_ERR(pdev);
- return 0;
+ return PTR_ERR_OR_ZERO(pdev);
}
static int vm_cmdline_get_device(struct device *dev, void *data)
--
1.9.1
^ permalink raw reply related
* [PATCH] virtio: release virtio index when fail to device_register
From: weiping zhang @ 2017-11-28 15:43 UTC (permalink / raw)
To: mst, jasowang; +Cc: virtualization
index can be reused by other virtio device.
Signed-off-by: weiping zhang <zhangweiping@didichuxing.com>
---
drivers/virtio/virtio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 48230a5..bf7ff39 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -333,6 +333,8 @@ int register_virtio_device(struct virtio_device *dev)
/* device_register() causes the bus infrastructure to look for a
* matching driver. */
err = device_register(&dev->dev);
+ if (err)
+ ida_simple_remove(&virtio_index_ida, dev->index);
out:
if (err)
virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
--
2.9.4
^ permalink raw reply related
* [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: wexu @ 2017-11-28 17:17 UTC (permalink / raw)
To: virtualization, netdev, linux-kernel; +Cc: mjrosato, wexu, mst
From: Wei Xu <wexu@redhat.com>
Matthew found a roughly 40% tcp throughput regression with commit
c67df11f(vhost_net: try batch dequing from skb array) as discussed
in the following thread:
https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
Eventually we figured out that it was a skb leak in handle_rx()
when sending packets to the VM. This usually happens when a guest
can not drain out vq as fast as vhost fills in, afterwards it sets
off the traffic jam and leaks skb(s) which occurs as no headcount
to send on the vq from vhost side.
This can be avoided by making sure we have got enough headcount
before actually consuming a skb from the batched rx array while
transmitting, which is simply done by deferring it a moment later
in this patch.
Signed-off-by: Wei Xu <wexu@redhat.com>
---
drivers/vhost/net.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 8d626d7..e76535e 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
/* On error, stop handling until the next kick. */
if (unlikely(headcount < 0))
goto out;
- if (nvq->rx_array)
- msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
/* On overrun, truncate and discard */
if (unlikely(headcount > UIO_MAXIOV)) {
iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
@@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
*/
iov_iter_advance(&msg.msg_iter, vhost_hlen);
}
+ if (nvq->rx_array)
+ msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
err = sock->ops->recvmsg(sock, &msg,
sock_len, MSG_DONTWAIT | MSG_TRUNC);
/* Userspace might have consumed the packet meanwhile:
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Michael S. Tsirkin @ 2017-11-28 17:50 UTC (permalink / raw)
To: wexu; +Cc: mjrosato, netdev, linux-kernel, virtualization
In-Reply-To: <1511889436-12876-1-git-send-email-wexu@redhat.com>
On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> From: Wei Xu <wexu@redhat.com>
>
> Matthew found a roughly 40% tcp throughput regression with commit
> c67df11f(vhost_net: try batch dequing from skb array) as discussed
> in the following thread:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>
> Eventually we figured out that it was a skb leak in handle_rx()
> when sending packets to the VM. This usually happens when a guest
> can not drain out vq as fast as vhost fills in, afterwards it sets
> off the traffic jam and leaks skb(s) which occurs as no headcount
> to send on the vq from vhost side.
>
> This can be avoided by making sure we have got enough headcount
> before actually consuming a skb from the batched rx array while
> transmitting, which is simply done by deferring it a moment later
> in this patch.
>
> Signed-off-by: Wei Xu <wexu@redhat.com>
Looks like a good way to fix it, but it will still leak if recvmsg
returns a wrong length (I'm not sure this can happen in practice, but
best to keep it simple).
Also, we need to add this before each recvmsg, including overrun,
and discard on error.
> ---
> drivers/vhost/net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8d626d7..e76535e 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> /* On error, stop handling until the next kick. */
> if (unlikely(headcount < 0))
> goto out;
> - if (nvq->rx_array)
> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> /* On overrun, truncate and discard */
> if (unlikely(headcount > UIO_MAXIOV)) {
> iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> */
> iov_iter_advance(&msg.msg_iter, vhost_hlen);
> }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> err = sock->ops->recvmsg(sock, &msg,
> sock_len, MSG_DONTWAIT | MSG_TRUNC);
> /* Userspace might have consumed the packet meanwhile:
> --
> 1.8.3.1
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Michael S. Tsirkin @ 2017-11-28 17:53 UTC (permalink / raw)
To: wexu; +Cc: mjrosato, netdev, linux-kernel, virtualization
In-Reply-To: <1511889436-12876-1-git-send-email-wexu@redhat.com>
On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> From: Wei Xu <wexu@redhat.com>
>
> Matthew found a roughly 40% tcp throughput regression with commit
> c67df11f(vhost_net: try batch dequing from skb array) as discussed
> in the following thread:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>
> Eventually we figured out that it was a skb leak in handle_rx()
> when sending packets to the VM. This usually happens when a guest
> can not drain out vq as fast as vhost fills in, afterwards it sets
> off the traffic jam and leaks skb(s) which occurs as no headcount
> to send on the vq from vhost side.
>
> This can be avoided by making sure we have got enough headcount
> before actually consuming a skb from the batched rx array while
> transmitting, which is simply done by deferring it a moment later
> in this patch.
>
> Signed-off-by: Wei Xu <wexu@redhat.com>
Given the amount of effort Matthew has put into this,
you definitely want
Reported-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
here.
Let's give credit where credit is due.
Thanks a lot Matthew!
> ---
> drivers/vhost/net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8d626d7..e76535e 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> /* On error, stop handling until the next kick. */
> if (unlikely(headcount < 0))
> goto out;
> - if (nvq->rx_array)
> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> /* On overrun, truncate and discard */
> if (unlikely(headcount > UIO_MAXIOV)) {
> iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> */
> iov_iter_advance(&msg.msg_iter, vhost_hlen);
> }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> err = sock->ops->recvmsg(sock, &msg,
> sock_len, MSG_DONTWAIT | MSG_TRUNC);
> /* Userspace might have consumed the packet meanwhile:
> --
> 1.8.3.1
^ permalink raw reply
* [RFC] virtio-net: help live migrate SR-IOV devices
From: Jesse Brandeburg @ 2017-11-28 19:27 UTC (permalink / raw)
To: virtualization
Cc: Jakub Kicinski, mst, Sridhar Samudrala, Achiad,
Peter Waskiewicz Jr, Singhai, Anjali, Andy Gospodarek, Or Gerlitz
Hi, I'd like to get some feedback on a proposal to enhance virtio-net
to ease configuration of a VM and that would enable live migration of
passthrough network SR-IOV devices.
Today we have SR-IOV network devices (VFs) that can be passed into a VM
in order to enable high performance networking direct within the VM.
The problem I am trying to address is that this configuration is
generally difficult to live-migrate. There is documentation [1]
indicating that some OS/Hypervisor vendors will support live migration
of a system with a direct assigned networking device. The problem I
see with these implementations is that the network configuration
requirements that are passed on to the owner of the VM are quite
complicated. You have to set up bonding, you have to configure it to
enslave two interfaces, those interfaces (one is virtio-net, the other
is SR-IOV device/driver like ixgbevf) must support MAC address changes
requested in the VM, and on and on...
So, on to the proposal:
Modify virtio-net driver to be a single VM network device that
enslaves an SR-IOV network device (inside the VM) with the same MAC
address. This would cause the virtio-net driver to appear and work like
a simplified bonding/team driver. The live migration problem would be
solved just like today's bonding solution, but the VM user's networking
config would be greatly simplified.
At it's simplest, it would appear something like this in the VM.
==========
= vnet0 =
=============
(virtio- = |
net) = |
= ==========
= = ixgbef =
========== ==========
(forgive the ASCII art)
The fast path traffic would prefer the ixgbevf or other SR-IOV device
path, and fall back to virtio's transmit/receive when migrating.
Compared to today's options this proposal would
1) make virtio-net more sticky, allow fast path traffic at SR-IOV
speeds
2) simplify end user configuration in the VM (most if not all of the
set up to enable migration would be done in the hypervisor)
3) allow live migration via a simple link down and maybe a PCI
hot-unplug of the SR-IOV device, with failover to the virtio-net
driver core
4) allow vendor agnostic hardware acceleration, and live migration
between vendors if the VM os has driver support for all the required
SR-IOV devices.
Runtime operation proposed:
- <in either order> virtio-net driver loads, SR-IOV driver loads
- virtio-net finds other NICs that match it's MAC address by
both examining existing interfaces, and sets up a new device notifier
- virtio-net enslaves the first NIC with the same MAC address
- virtio-net brings up the slave, and makes it the "preferred" path
- virtio-net follows the behavior of an active backup bond/team
- virtio-net acts as the interface to the VM
- live migration initiates
- link goes down on SR-IOV, or SR-IOV device is removed
- failover to virtio-net as primary path
- migration continues to new host
- new host is started with virio-net as primary
- if no SR-IOV, virtio-net stays primary
- hypervisor can hot-add SR-IOV NIC, with same MAC addr as virtio
- virtio-net notices new NIC and starts over at enslave step above
Future ideas (brainstorming):
- Optimize Fast east-west by having special rules to direct east-west
traffic through virtio-net traffic path
Thanks for reading!
Jesse
[1]
https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/virtual_machine_management_guide/sect-migrating_virtual_machines_between_hosts
^ permalink raw reply
* Re: [PATCH] VSOCK: Don't set sk_state to TCP_CLOSE before testing it
From: David Miller @ 2017-11-28 21:02 UTC (permalink / raw)
To: jhansen; +Cc: pv-drivers, netdev, linux-kernel, virtualization, stefanha,
gregkh
In-Reply-To: <1511789372-12672-1-git-send-email-jhansen@vmware.com>
From: Jorgen Hansen <jhansen@vmware.com>
Date: Mon, 27 Nov 2017 05:29:32 -0800
> A recent commit (3b4477d2dcf2) converted the sk_state to use
> TCP constants. In that change, vmci_transport_handle_detach
> was changed such that sk->sk_state was set to TCP_CLOSE before
> we test whether it is TCP_SYN_SENT. This change moves the
> sk_state change back to the original locations in that function.
>
> Signed-off-by: Jorgen Hansen <jhansen@vmware.com>
Applied.
^ permalink raw reply
* [PATCH] virtio: release virtio index when fail to device_register
From: weiping zhang @ 2017-11-29 1:23 UTC (permalink / raw)
To: mst, jasowang; +Cc: virtualization
index can be reused by other virtio device.
Signed-off-by: weiping zhang <zhangweiping@didichuxing.com>
---
drivers/virtio/virtio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 48230a5..bf7ff39 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -333,6 +333,8 @@ int register_virtio_device(struct virtio_device *dev)
/* device_register() causes the bus infrastructure to look for a
* matching driver. */
err = device_register(&dev->dev);
+ if (err)
+ ida_simple_remove(&virtio_index_ida, dev->index);
out:
if (err)
virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
--
2.9.4
^ permalink raw reply related
* Re: [PATCH v3] virtio_balloon: include disk/file caches memory statistics
From: Michael S. Tsirkin @ 2017-11-29 1:24 UTC (permalink / raw)
To: Tomáš Golembiovský
Cc: virtio-dev, Rik van Riel, kvm, Gal Hammer, qemu-devel,
virtualization, linux-mm, Shaohua Li, Huang Ying
In-Reply-To: <2e8c12f5242bcf755a33ee3a0e9ef94339d1808c.1510487579.git.tgolembi@redhat.com>
On Sun, Nov 12, 2017 at 01:05:38PM +0100, Tomáš Golembiovský wrote:
> Add a new field VIRTIO_BALLOON_S_CACHES to virtio_balloon memory
> statistics protocol. The value represents all disk/file caches.
>
> In this case it corresponds to the sum of values
> Buffers+Cached+SwapCached from /proc/meminfo.
>
> Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
I parked this on vhost branch, part of linux next.
> ---
> drivers/virtio/virtio_balloon.c | 4 ++++
> include/uapi/linux/virtio_balloon.h | 3 ++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index f0b3a0b9d42f..d2bd13bbaf9f 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -244,11 +244,13 @@ static unsigned int update_balloon_stats(struct virtio_balloon *vb)
> struct sysinfo i;
> unsigned int idx = 0;
> long available;
> + unsigned long caches;
>
> all_vm_events(events);
> si_meminfo(&i);
>
> available = si_mem_available();
> + caches = global_node_page_state(NR_FILE_PAGES);
>
> #ifdef CONFIG_VM_EVENT_COUNTERS
> update_stat(vb, idx++, VIRTIO_BALLOON_S_SWAP_IN,
> @@ -264,6 +266,8 @@ static unsigned int update_balloon_stats(struct virtio_balloon *vb)
> pages_to_bytes(i.totalram));
> update_stat(vb, idx++, VIRTIO_BALLOON_S_AVAIL,
> pages_to_bytes(available));
> + update_stat(vb, idx++, VIRTIO_BALLOON_S_CACHES,
> + pages_to_bytes(caches));
>
> return idx;
> }
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index 343d7ddefe04..4e8b8304b793 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -52,7 +52,8 @@ struct virtio_balloon_config {
> #define VIRTIO_BALLOON_S_MEMFREE 4 /* Total amount of free memory */
> #define VIRTIO_BALLOON_S_MEMTOT 5 /* Total amount of memory */
> #define VIRTIO_BALLOON_S_AVAIL 6 /* Available memory as in /proc */
> -#define VIRTIO_BALLOON_S_NR 7
> +#define VIRTIO_BALLOON_S_CACHES 7 /* Disk caches */
> +#define VIRTIO_BALLOON_S_NR 8
>
> /*
> * Memory statistics structure.
> --
> 2.15.0
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Jason Wang @ 2017-11-29 1:53 UTC (permalink / raw)
To: wexu, virtualization, netdev, linux-kernel; +Cc: mjrosato, mst
In-Reply-To: <1511889436-12876-1-git-send-email-wexu@redhat.com>
On 2017年11月29日 01:17, wexu@redhat.com wrote:
> From: Wei Xu <wexu@redhat.com>
>
> Matthew found a roughly 40% tcp throughput regression with commit
> c67df11f(vhost_net: try batch dequing from skb array) as discussed
> in the following thread:
> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>
> Eventually we figured out that it was a skb leak in handle_rx()
> when sending packets to the VM. This usually happens when a guest
> can not drain out vq as fast as vhost fills in, afterwards it sets
> off the traffic jam and leaks skb(s) which occurs as no headcount
> to send on the vq from vhost side.
>
> This can be avoided by making sure we have got enough headcount
> before actually consuming a skb from the batched rx array while
> transmitting, which is simply done by deferring it a moment later
> in this patch.
>
> Signed-off-by: Wei Xu <wexu@redhat.com>
> ---
> drivers/vhost/net.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 8d626d7..e76535e 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> /* On error, stop handling until the next kick. */
> if (unlikely(headcount < 0))
> goto out;
> - if (nvq->rx_array)
> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> /* On overrun, truncate and discard */
> if (unlikely(headcount > UIO_MAXIOV)) {
You need do msg.msg_control = vhost_net_buf_consume() here too,
otherwise we may still get it leaked.
Thanks
> iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> */
> iov_iter_advance(&msg.msg_iter, vhost_hlen);
> }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> err = sock->ops->recvmsg(sock, &msg,
> sock_len, MSG_DONTWAIT | MSG_TRUNC);
> /* Userspace might have consumed the packet meanwhile:
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Jason Wang @ 2017-11-29 5:06 UTC (permalink / raw)
To: wexu, virtualization, netdev, linux-kernel; +Cc: mjrosato, mst
In-Reply-To: <9b234fdd-baa3-f919-6c72-f6768265f1ca@redhat.com>
On 2017年11月29日 09:53, Jason Wang wrote:
>
>
> On 2017年11月29日 01:17, wexu@redhat.com wrote:
>> From: Wei Xu <wexu@redhat.com>
>>
>> Matthew found a roughly 40% tcp throughput regression with commit
>> c67df11f(vhost_net: try batch dequing from skb array) as discussed
>> in the following thread:
>> https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
>>
>> Eventually we figured out that it was a skb leak in handle_rx()
>> when sending packets to the VM. This usually happens when a guest
>> can not drain out vq as fast as vhost fills in, afterwards it sets
>> off the traffic jam and leaks skb(s) which occurs as no headcount
>> to send on the vq from vhost side.
>>
>> This can be avoided by making sure we have got enough headcount
>> before actually consuming a skb from the batched rx array while
>> transmitting, which is simply done by deferring it a moment later
>> in this patch.
>>
>> Signed-off-by: Wei Xu <wexu@redhat.com>
>> ---
>> drivers/vhost/net.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
>> index 8d626d7..e76535e 100644
>> --- a/drivers/vhost/net.c
>> +++ b/drivers/vhost/net.c
>> @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
>> /* On error, stop handling until the next kick. */
>> if (unlikely(headcount < 0))
>> goto out;
>> - if (nvq->rx_array)
>> - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
>> /* On overrun, truncate and discard */
>> if (unlikely(headcount > UIO_MAXIOV)) {
>
> You need do msg.msg_control = vhost_net_buf_consume() here too,
> otherwise we may still get it leaked.
>
> Thanks
Not a leak actually, but the packet won't be consumed and we will hit
UIO_MAXIOV forever in this case.
Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 5:44 UTC (permalink / raw)
To: Jason Wang; +Cc: mjrosato, netdev, mst, linux-kernel, virtualization
In-Reply-To: <37f16bef-4a59-b895-c61b-e3f473617411@redhat.com>
On Wed, Nov 29, 2017 at 01:06:28PM +0800, Jason Wang wrote:
>
>
> On 2017年11月29日 09:53, Jason Wang wrote:
> >
> >
> > On 2017年11月29日 01:17, wexu@redhat.com wrote:
> > > From: Wei Xu <wexu@redhat.com>
> > >
> > > Matthew found a roughly 40% tcp throughput regression with commit
> > > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > > in the following thread:
> > > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> > >
> > > Eventually we figured out that it was a skb leak in handle_rx()
> > > when sending packets to the VM. This usually happens when a guest
> > > can not drain out vq as fast as vhost fills in, afterwards it sets
> > > off the traffic jam and leaks skb(s) which occurs as no headcount
> > > to send on the vq from vhost side.
> > >
> > > This can be avoided by making sure we have got enough headcount
> > > before actually consuming a skb from the batched rx array while
> > > transmitting, which is simply done by deferring it a moment later
> > > in this patch.
> > >
> > > Signed-off-by: Wei Xu <wexu@redhat.com>
> > > ---
> > > drivers/vhost/net.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > > index 8d626d7..e76535e 100644
> > > --- a/drivers/vhost/net.c
> > > +++ b/drivers/vhost/net.c
> > > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > > /* On error, stop handling until the next kick. */
> > > if (unlikely(headcount < 0))
> > > goto out;
> > > - if (nvq->rx_array)
> > > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > > /* On overrun, truncate and discard */
> > > if (unlikely(headcount > UIO_MAXIOV)) {
> >
> > You need do msg.msg_control = vhost_net_buf_consume() here too,
> > otherwise we may still get it leaked.
> >
> > Thanks
>
> Not a leak actually, but the packet won't be consumed and we will hit
> UIO_MAXIOV forever in this case.
I see, thanks, will make a v2.
>
> Thanks
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 6:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: mjrosato, netdev, linux-kernel, virtualization
In-Reply-To: <20171128193713-mutt-send-email-mst@kernel.org>
On Tue, Nov 28, 2017 at 07:50:58PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> > From: Wei Xu <wexu@redhat.com>
> >
> > Matthew found a roughly 40% tcp throughput regression with commit
> > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > in the following thread:
> > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> >
> > Eventually we figured out that it was a skb leak in handle_rx()
> > when sending packets to the VM. This usually happens when a guest
> > can not drain out vq as fast as vhost fills in, afterwards it sets
> > off the traffic jam and leaks skb(s) which occurs as no headcount
> > to send on the vq from vhost side.
> >
> > This can be avoided by making sure we have got enough headcount
> > before actually consuming a skb from the batched rx array while
> > transmitting, which is simply done by deferring it a moment later
> > in this patch.
> >
> > Signed-off-by: Wei Xu <wexu@redhat.com>
>
> Looks like a good way to fix it, but it will still leak if recvmsg
> returns a wrong length (I'm not sure this can happen in practice, but
> best to keep it simple).
Right, it is better to defend this case, will include it in v2.
>
> Also, we need to add this before each recvmsg, including overrun,
> and discard on error.
OK.
Wei
>
> > ---
> > drivers/vhost/net.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 8d626d7..e76535e 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > /* On error, stop handling until the next kick. */
> > if (unlikely(headcount < 0))
> > goto out;
> > - if (nvq->rx_array)
> > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > /* On overrun, truncate and discard */
> > if (unlikely(headcount > UIO_MAXIOV)) {
> > iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> > @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> > */
> > iov_iter_advance(&msg.msg_iter, vhost_hlen);
> > }
> > + if (nvq->rx_array)
> > + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > err = sock->ops->recvmsg(sock, &msg,
> > sock_len, MSG_DONTWAIT | MSG_TRUNC);
> > /* Userspace might have consumed the packet meanwhile:
> > --
> > 1.8.3.1
^ permalink raw reply
* Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()
From: Wei Xu @ 2017-11-29 6:32 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: mjrosato, netdev, linux-kernel, virtualization
In-Reply-To: <20171128195140-mutt-send-email-mst@kernel.org>
On Tue, Nov 28, 2017 at 07:53:33PM +0200, Michael S. Tsirkin wrote:
> On Tue, Nov 28, 2017 at 12:17:16PM -0500, wexu@redhat.com wrote:
> > From: Wei Xu <wexu@redhat.com>
> >
> > Matthew found a roughly 40% tcp throughput regression with commit
> > c67df11f(vhost_net: try batch dequing from skb array) as discussed
> > in the following thread:
> > https://www.mail-archive.com/netdev@vger.kernel.org/msg187936.html
> >
> > Eventually we figured out that it was a skb leak in handle_rx()
> > when sending packets to the VM. This usually happens when a guest
> > can not drain out vq as fast as vhost fills in, afterwards it sets
> > off the traffic jam and leaks skb(s) which occurs as no headcount
> > to send on the vq from vhost side.
> >
> > This can be avoided by making sure we have got enough headcount
> > before actually consuming a skb from the batched rx array while
> > transmitting, which is simply done by deferring it a moment later
> > in this patch.
> >
> > Signed-off-by: Wei Xu <wexu@redhat.com>
>
> Given the amount of effort Matthew has put into this,
> you definitely want
>
> Reported-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
>
> here.
>
Absolutely we want that, sorry for missed you here, Matthew. It is more
like you have figured out this issue independently all by yourself with
a wide assortment of extremely quick tests(tools, throughput, slub leak,
etc), and I am happy that I have the opportunity to do the paperwork on
behalf of you.:) Thanks a lot Matthew.
Wei
> Let's give credit where credit is due.
>
> Thanks a lot Matthew!
>
> > ---
> > drivers/vhost/net.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> > index 8d626d7..e76535e 100644
> > --- a/drivers/vhost/net.c
> > +++ b/drivers/vhost/net.c
> > @@ -778,8 +778,6 @@ static void handle_rx(struct vhost_net *net)
> > /* On error, stop handling until the next kick. */
> > if (unlikely(headcount < 0))
> > goto out;
> > - if (nvq->rx_array)
> > - msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > /* On overrun, truncate and discard */
> > if (unlikely(headcount > UIO_MAXIOV)) {
> > iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1);
> > @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
> > */
> > iov_iter_advance(&msg.msg_iter, vhost_hlen);
> > }
> > + if (nvq->rx_array)
> > + msg.msg_control = vhost_net_buf_consume(&nvq->rxq);
> > err = sock->ops->recvmsg(sock, &msg,
> > sock_len, MSG_DONTWAIT | MSG_TRUNC);
> > /* Userspace might have consumed the packet meanwhile:
> > --
> > 1.8.3.1
^ permalink raw reply
* [PATCH RFC 0/4] crypto: engine - Permit to enqueue all async requests
From: Corentin Labbe @ 2017-11-29 8:41 UTC (permalink / raw)
To: herbert, alexandre.torgue, arei.gonglei, davem, jasowang,
mcoquelin.stm32, mst, fabien.dessenne
Cc: virtualization, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
Hello
The current crypto_engine support only ahash and ablkcipher.
My first patch which try to add skcipher was Nacked, it will add too many functions
and adding other algs(aead, asymetric_key) will make the situation worst.
This patchset remove all algs specific stuff and now only process generic crypto_async_request.
The requests handler function pointer are now moved out of struct engine and
are now stored directly in a crypto_engine_reqctx.
The original proposal of Herbert [1] cannot be done completly since the crypto_engine
could only dequeue crypto_async_request and it is impossible to access any request_ctx
without knowing the underlying request type.
So I do something near that was requested: adding crypto_engine_reqctx in TFM context.
Note that the current implementation expect that crypto_engine_reqctx
is the first member of the context.
The first patch convert the crypto engine with the new way,
while the following patchs convert the 3 existing users of crypto_engine.
Note that this split break bisection, so probably the final commit will be all merged.
The 3 latest patch were compile tested only, but the first is tested successfully
with my new sun8i-ce driver.
Regards
[1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html
Corentin Labbe (4):
crypto: engine - Permit to enqueue all async requests
crypto: omap: convert to new crypto engine API
crypto: virtio: convert to new crypto engine API
crypto: stm32: convert to the new crypto engine API
crypto/crypto_engine.c | 188 ++++++---------------------
drivers/crypto/omap-aes.c | 21 ++-
drivers/crypto/omap-aes.h | 3 +
drivers/crypto/omap-des.c | 24 +++-
drivers/crypto/stm32/stm32-hash.c | 22 +++-
drivers/crypto/virtio/virtio_crypto_algs.c | 15 ++-
drivers/crypto/virtio/virtio_crypto_common.h | 2 +-
drivers/crypto/virtio/virtio_crypto_core.c | 3 -
include/crypto/engine.h | 46 +++----
9 files changed, 122 insertions(+), 202 deletions(-)
--
2.13.6
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Corentin Labbe @ 2017-11-29 8:41 UTC (permalink / raw)
To: herbert, alexandre.torgue, arei.gonglei, davem, jasowang,
mcoquelin.stm32, mst, fabien.dessenne
Cc: virtualization, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171129084121.9385-1-clabbe.montjoie@gmail.com>
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue any type of crypto_async_request.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
crypto/crypto_engine.c | 188 +++++++++++-------------------------------------
include/crypto/engine.h | 46 +++++-------
2 files changed, 60 insertions(+), 174 deletions(-)
diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c
index 61e7c4e02fd2..f7c4c4c1f41b 100644
--- a/crypto/crypto_engine.c
+++ b/crypto/crypto_engine.c
@@ -34,11 +34,10 @@ static void crypto_pump_requests(struct crypto_engine *engine,
bool in_kthread)
{
struct crypto_async_request *async_req, *backlog;
- struct ahash_request *hreq;
- struct ablkcipher_request *breq;
unsigned long flags;
bool was_busy = false;
- int ret, rtype;
+ int ret;
+ struct crypto_engine_reqctx *enginectx;
spin_lock_irqsave(&engine->queue_lock, flags);
@@ -94,7 +93,6 @@ static void crypto_pump_requests(struct crypto_engine *engine,
spin_unlock_irqrestore(&engine->queue_lock, flags);
- rtype = crypto_tfm_alg_type(engine->cur_req->tfm);
/* Until here we get the request need to be encrypted successfully */
if (!was_busy && engine->prepare_crypt_hardware) {
ret = engine->prepare_crypt_hardware(engine);
@@ -104,57 +102,31 @@ static void crypto_pump_requests(struct crypto_engine *engine,
}
}
- switch (rtype) {
- case CRYPTO_ALG_TYPE_AHASH:
- hreq = ahash_request_cast(engine->cur_req);
- if (engine->prepare_hash_request) {
- ret = engine->prepare_hash_request(engine, hreq);
- if (ret) {
- dev_err(engine->dev, "failed to prepare request: %d\n",
- ret);
- goto req_err;
- }
- engine->cur_req_prepared = true;
- }
- ret = engine->hash_one_request(engine, hreq);
- if (ret) {
- dev_err(engine->dev, "failed to hash one request from queue\n");
- goto req_err;
- }
- return;
- case CRYPTO_ALG_TYPE_ABLKCIPHER:
- breq = ablkcipher_request_cast(engine->cur_req);
- if (engine->prepare_cipher_request) {
- ret = engine->prepare_cipher_request(engine, breq);
- if (ret) {
- dev_err(engine->dev, "failed to prepare request: %d\n",
- ret);
- goto req_err;
- }
- engine->cur_req_prepared = true;
- }
- ret = engine->cipher_one_request(engine, breq);
+ enginectx = crypto_tfm_ctx(async_req->tfm);
+
+ if (enginectx->op.prepare_request) {
+ ret = enginectx->op.prepare_request(engine, async_req);
if (ret) {
- dev_err(engine->dev, "failed to cipher one request from queue\n");
+ dev_err(engine->dev, "failed to prepare request: %d\n",
+ ret);
goto req_err;
}
- return;
- default:
- dev_err(engine->dev, "failed to prepare request of unknown type\n");
- return;
+ engine->cur_req_prepared = true;
+ }
+ if (!enginectx->op.do_one_request) {
+ dev_err(engine->dev, "failed to do request\n");
+ ret = -EINVAL;
+ goto req_err;
+ }
+ ret = enginectx->op.do_one_request(engine, async_req);
+ if (ret) {
+ dev_err(engine->dev, "failed to hash one request from queue\n");
+ goto req_err;
}
+ return;
req_err:
- switch (rtype) {
- case CRYPTO_ALG_TYPE_AHASH:
- hreq = ahash_request_cast(engine->cur_req);
- crypto_finalize_hash_request(engine, hreq, ret);
- break;
- case CRYPTO_ALG_TYPE_ABLKCIPHER:
- breq = ablkcipher_request_cast(engine->cur_req);
- crypto_finalize_cipher_request(engine, breq, ret);
- break;
- }
+ crypto_finalize_request(engine, async_req, ret);
return;
out:
@@ -170,59 +142,16 @@ static void crypto_pump_work(struct kthread_work *work)
}
/**
- * crypto_transfer_cipher_request - transfer the new request into the
- * enginequeue
+ * crypto_transfer_request - transfer the new request into the engine queue
* @engine: the hardware engine
* @req: the request need to be listed into the engine queue
*/
-int crypto_transfer_cipher_request(struct crypto_engine *engine,
- struct ablkcipher_request *req,
- bool need_pump)
+int crypto_transfer_request(struct crypto_engine *engine,
+ struct crypto_async_request *req, bool need_pump)
{
unsigned long flags;
int ret;
- spin_lock_irqsave(&engine->queue_lock, flags);
-
- if (!engine->running) {
- spin_unlock_irqrestore(&engine->queue_lock, flags);
- return -ESHUTDOWN;
- }
-
- ret = ablkcipher_enqueue_request(&engine->queue, req);
-
- if (!engine->busy && need_pump)
- kthread_queue_work(engine->kworker, &engine->pump_requests);
-
- spin_unlock_irqrestore(&engine->queue_lock, flags);
- return ret;
-}
-EXPORT_SYMBOL_GPL(crypto_transfer_cipher_request);
-
-/**
- * crypto_transfer_cipher_request_to_engine - transfer one request to list
- * into the engine queue
- * @engine: the hardware engine
- * @req: the request need to be listed into the engine queue
- */
-int crypto_transfer_cipher_request_to_engine(struct crypto_engine *engine,
- struct ablkcipher_request *req)
-{
- return crypto_transfer_cipher_request(engine, req, true);
-}
-EXPORT_SYMBOL_GPL(crypto_transfer_cipher_request_to_engine);
-
-/**
- * crypto_transfer_hash_request - transfer the new request into the
- * enginequeue
- * @engine: the hardware engine
- * @req: the request need to be listed into the engine queue
- */
-int crypto_transfer_hash_request(struct crypto_engine *engine,
- struct ahash_request *req, bool need_pump)
-{
- unsigned long flags;
- int ret;
spin_lock_irqsave(&engine->queue_lock, flags);
@@ -231,7 +160,7 @@ int crypto_transfer_hash_request(struct crypto_engine *engine,
return -ESHUTDOWN;
}
- ret = ahash_enqueue_request(&engine->queue, req);
+ ret = crypto_enqueue_request(&engine->queue, req);
if (!engine->busy && need_pump)
kthread_queue_work(engine->kworker, &engine->pump_requests);
@@ -239,80 +168,45 @@ int crypto_transfer_hash_request(struct crypto_engine *engine,
spin_unlock_irqrestore(&engine->queue_lock, flags);
return ret;
}
-EXPORT_SYMBOL_GPL(crypto_transfer_hash_request);
+EXPORT_SYMBOL_GPL(crypto_transfer_request);
/**
- * crypto_transfer_hash_request_to_engine - transfer one request to list
+ * crypto_transfer_request_to_engine - transfer one request to list
* into the engine queue
* @engine: the hardware engine
* @req: the request need to be listed into the engine queue
*/
-int crypto_transfer_hash_request_to_engine(struct crypto_engine *engine,
- struct ahash_request *req)
-{
- return crypto_transfer_hash_request(engine, req, true);
-}
-EXPORT_SYMBOL_GPL(crypto_transfer_hash_request_to_engine);
-
-/**
- * crypto_finalize_cipher_request - finalize one request if the request is done
- * @engine: the hardware engine
- * @req: the request need to be finalized
- * @err: error number
- */
-void crypto_finalize_cipher_request(struct crypto_engine *engine,
- struct ablkcipher_request *req, int err)
+int crypto_transfer_request_to_engine(struct crypto_engine *engine,
+ struct crypto_async_request *req)
{
- unsigned long flags;
- bool finalize_cur_req = false;
- int ret;
-
- spin_lock_irqsave(&engine->queue_lock, flags);
- if (engine->cur_req == &req->base)
- finalize_cur_req = true;
- spin_unlock_irqrestore(&engine->queue_lock, flags);
-
- if (finalize_cur_req) {
- if (engine->cur_req_prepared &&
- engine->unprepare_cipher_request) {
- ret = engine->unprepare_cipher_request(engine, req);
- if (ret)
- dev_err(engine->dev, "failed to unprepare request\n");
- }
- spin_lock_irqsave(&engine->queue_lock, flags);
- engine->cur_req = NULL;
- engine->cur_req_prepared = false;
- spin_unlock_irqrestore(&engine->queue_lock, flags);
- }
-
- req->base.complete(&req->base, err);
-
- kthread_queue_work(engine->kworker, &engine->pump_requests);
+ return crypto_transfer_request(engine, req, true);
}
-EXPORT_SYMBOL_GPL(crypto_finalize_cipher_request);
+EXPORT_SYMBOL_GPL(crypto_transfer_request_to_engine);
/**
- * crypto_finalize_hash_request - finalize one request if the request is done
+ * crypto_finalize_request - finalize one request if the request is done
* @engine: the hardware engine
* @req: the request need to be finalized
* @err: error number
*/
-void crypto_finalize_hash_request(struct crypto_engine *engine,
- struct ahash_request *req, int err)
+void crypto_finalize_request(struct crypto_engine *engine,
+ struct crypto_async_request *req, int err)
{
unsigned long flags;
bool finalize_cur_req = false;
int ret;
+ struct crypto_engine_reqctx *enginectx;
spin_lock_irqsave(&engine->queue_lock, flags);
- if (engine->cur_req == &req->base)
+ if (engine->cur_req == req)
finalize_cur_req = true;
spin_unlock_irqrestore(&engine->queue_lock, flags);
if (finalize_cur_req) {
+ enginectx = crypto_tfm_ctx(req->tfm);
if (engine->cur_req_prepared &&
- engine->unprepare_hash_request) {
- ret = engine->unprepare_hash_request(engine, req);
+ enginectx->op.unprepare_request) {
+ ret = enginectx->op.unprepare_request(engine, req);
if (ret)
dev_err(engine->dev, "failed to unprepare request\n");
}
@@ -322,11 +216,11 @@ void crypto_finalize_hash_request(struct crypto_engine *engine,
spin_unlock_irqrestore(&engine->queue_lock, flags);
}
- req->base.complete(&req->base, err);
+ req->complete(req, err);
kthread_queue_work(engine->kworker, &engine->pump_requests);
}
-EXPORT_SYMBOL_GPL(crypto_finalize_hash_request);
+EXPORT_SYMBOL_GPL(crypto_finalize_request);
/**
* crypto_engine_start - start the hardware engine
diff --git a/include/crypto/engine.h b/include/crypto/engine.h
index dd04c1699b51..2e45db45849b 100644
--- a/include/crypto/engine.h
+++ b/include/crypto/engine.h
@@ -17,7 +17,6 @@
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <crypto/algapi.h>
-#include <crypto/hash.h>
#define ENGINE_NAME_LEN 30
/*
@@ -65,19 +64,6 @@ struct crypto_engine {
int (*prepare_crypt_hardware)(struct crypto_engine *engine);
int (*unprepare_crypt_hardware)(struct crypto_engine *engine);
- int (*prepare_cipher_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
- int (*unprepare_cipher_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
- int (*prepare_hash_request)(struct crypto_engine *engine,
- struct ahash_request *req);
- int (*unprepare_hash_request)(struct crypto_engine *engine,
- struct ahash_request *req);
- int (*cipher_one_request)(struct crypto_engine *engine,
- struct ablkcipher_request *req);
- int (*hash_one_request)(struct crypto_engine *engine,
- struct ahash_request *req);
-
struct kthread_worker *kworker;
struct kthread_work pump_requests;
@@ -85,19 +71,25 @@ struct crypto_engine {
struct crypto_async_request *cur_req;
};
-int crypto_transfer_cipher_request(struct crypto_engine *engine,
- struct ablkcipher_request *req,
- bool need_pump);
-int crypto_transfer_cipher_request_to_engine(struct crypto_engine *engine,
- struct ablkcipher_request *req);
-int crypto_transfer_hash_request(struct crypto_engine *engine,
- struct ahash_request *req, bool need_pump);
-int crypto_transfer_hash_request_to_engine(struct crypto_engine *engine,
- struct ahash_request *req);
-void crypto_finalize_cipher_request(struct crypto_engine *engine,
- struct ablkcipher_request *req, int err);
-void crypto_finalize_hash_request(struct crypto_engine *engine,
- struct ahash_request *req, int err);
+struct crypto_engine_op {
+ int (*prepare_request)(struct crypto_engine *engine,
+ struct crypto_async_request *areq);
+ int (*unprepare_request)(struct crypto_engine *engine,
+ struct crypto_async_request *areq);
+ int (*do_one_request)(struct crypto_engine *engine,
+ struct crypto_async_request *areq);
+};
+
+struct crypto_engine_reqctx {
+ struct crypto_engine_op op;
+};
+
+int crypto_transfer_request(struct crypto_engine *engine,
+ struct crypto_async_request *req, bool need_pump);
+int crypto_transfer_request_to_engine(struct crypto_engine *engine,
+ struct crypto_async_request *req);
+void crypto_finalize_request(struct crypto_engine *engine,
+ struct crypto_async_request *req, int err);
int crypto_engine_start(struct crypto_engine *engine);
int crypto_engine_stop(struct crypto_engine *engine);
struct crypto_engine *crypto_engine_alloc_init(struct device *dev, bool rt);
--
2.13.6
^ permalink raw reply related
* [PATCH RFC 2/4] crypto: omap: convert to new crypto engine API
From: Corentin Labbe @ 2017-11-29 8:41 UTC (permalink / raw)
To: herbert, alexandre.torgue, arei.gonglei, davem, jasowang,
mcoquelin.stm32, mst, fabien.dessenne
Cc: virtualization, Corentin Labbe, linux-crypto, linux-arm-kernel,
linux-kernel
In-Reply-To: <20171129084121.9385-1-clabbe.montjoie@gmail.com>
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
---
drivers/crypto/omap-aes.c | 21 +++++++++++++++------
drivers/crypto/omap-aes.h | 3 +++
drivers/crypto/omap-des.c | 24 ++++++++++++++++++------
3 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index fbec0a2e76dd..4a31bbfca9a4 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -388,7 +388,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
pr_debug("err: %d\n", err);
- crypto_finalize_cipher_request(dd->engine, req, err);
+ crypto_finalize_request(dd->engine, &req->base, err);
pm_runtime_mark_last_busy(dd->dev);
pm_runtime_put_autosuspend(dd->dev);
@@ -408,14 +408,15 @@ static int omap_aes_handle_queue(struct omap_aes_dev *dd,
struct ablkcipher_request *req)
{
if (req)
- return crypto_transfer_cipher_request_to_engine(dd->engine, req);
+ return crypto_transfer_request_to_engine(dd->engine, &req->base);
return 0;
}
static int omap_aes_prepare_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
{
+ struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_aes_reqctx *rctx = ablkcipher_request_ctx(req);
@@ -468,8 +469,9 @@ static int omap_aes_prepare_req(struct crypto_engine *engine,
}
static int omap_aes_crypt_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
{
+ struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_aes_reqctx *rctx = ablkcipher_request_ctx(req);
struct omap_aes_dev *dd = rctx->dd;
@@ -601,6 +603,11 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
return omap_aes_crypt(req, FLAGS_CTR);
}
+static int omap_aes_prepare_req(struct crypto_engine *engine,
+ struct crypto_async_request *req);
+static int omap_aes_crypt_req(struct crypto_engine *engine,
+ struct crypto_async_request *req);
+
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
const char *name = crypto_tfm_alg_name(tfm);
@@ -616,6 +623,10 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
+ ctx->enginectx.op.prepare_request = omap_aes_prepare_req;
+ ctx->enginectx.op.unprepare_request = NULL;
+ ctx->enginectx.op.do_one_request = omap_aes_crypt_req;
+
return 0;
}
@@ -1119,8 +1130,6 @@ static int omap_aes_probe(struct platform_device *pdev)
goto err_engine;
}
- dd->engine->prepare_cipher_request = omap_aes_prepare_req;
- dd->engine->cipher_one_request = omap_aes_crypt_req;
err = crypto_engine_start(dd->engine);
if (err)
goto err_engine;
diff --git a/drivers/crypto/omap-aes.h b/drivers/crypto/omap-aes.h
index 8906342e2b9a..f6ce94907ade 100644
--- a/drivers/crypto/omap-aes.h
+++ b/drivers/crypto/omap-aes.h
@@ -13,6 +13,8 @@
#ifndef __OMAP_AES_H__
#define __OMAP_AES_H__
+#include <crypto/engine.h>
+
#define DST_MAXBURST 4
#define DMA_MIN (DST_MAXBURST * sizeof(u32))
@@ -95,6 +97,7 @@ struct omap_aes_gcm_result {
};
struct omap_aes_ctx {
+ struct crypto_engine_reqctx enginectx;
int keylen;
u32 key[AES_KEYSIZE_256 / sizeof(u32)];
u8 nonce[4];
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index ebc5c0f11f03..94212248159e 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -86,6 +86,7 @@
#define FLAGS_OUT_DATA_ST_SHIFT 10
struct omap_des_ctx {
+ struct crypto_engine_reqctx enginectx;
struct omap_des_dev *dd;
int keylen;
@@ -498,7 +499,7 @@ static void omap_des_finish_req(struct omap_des_dev *dd, int err)
pr_debug("err: %d\n", err);
- crypto_finalize_cipher_request(dd->engine, req, err);
+ crypto_finalize_request(dd->engine, &req->base, err);
pm_runtime_mark_last_busy(dd->dev);
pm_runtime_put_autosuspend(dd->dev);
@@ -520,14 +521,15 @@ static int omap_des_handle_queue(struct omap_des_dev *dd,
struct ablkcipher_request *req)
{
if (req)
- return crypto_transfer_cipher_request_to_engine(dd->engine, req);
+ return crypto_transfer_request_to_engine(dd->engine, &req->base);
return 0;
}
static int omap_des_prepare_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
{
+ struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_des_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_des_dev *dd = omap_des_find_dev(ctx);
@@ -582,8 +584,9 @@ static int omap_des_prepare_req(struct crypto_engine *engine,
}
static int omap_des_crypt_req(struct crypto_engine *engine,
- struct ablkcipher_request *req)
+ struct crypto_async_request *areq)
{
+ struct ablkcipher_request *req = ablkcipher_request_cast(areq);
struct omap_des_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
struct omap_des_dev *dd = omap_des_find_dev(ctx);
@@ -695,12 +698,23 @@ static int omap_des_cbc_decrypt(struct ablkcipher_request *req)
return omap_des_crypt(req, FLAGS_CBC);
}
+static int omap_des_prepare_req(struct crypto_engine *engine,
+ struct crypto_async_request *areq);
+static int omap_des_crypt_req(struct crypto_engine *engine,
+ struct crypto_async_request *areq);
+
static int omap_des_cra_init(struct crypto_tfm *tfm)
{
+ struct omap_des_ctx *ctx = crypto_tfm_ctx(tfm);
+
pr_debug("enter\n");
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_des_reqctx);
+ ctx->enginectx.op.prepare_request = omap_des_prepare_req;
+ ctx->enginectx.op.unprepare_request = NULL;
+ ctx->enginectx.op.do_one_request = omap_des_crypt_req;
+
return 0;
}
@@ -1046,8 +1060,6 @@ static int omap_des_probe(struct platform_device *pdev)
goto err_engine;
}
- dd->engine->prepare_cipher_request = omap_des_prepare_req;
- dd->engine->cipher_one_request = omap_des_crypt_req;
err = crypto_engine_start(dd->engine);
if (err)
goto err_engine;
--
2.13.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox