Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()

[Jason Wang]

On 2017年11月29日 09:53, Jason Wang wrote:



On 2017年11月29日 01:17, w...@redhat.com wrote:

From: Wei Xu 

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 
---
  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(>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

Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()

[Jason Wang]

On 2017年11月29日 01:17, w...@redhat.com wrote:

From: Wei Xu 

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 
---
  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(>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(_iter, READ, vq->iov, 1, 1);
@@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
 */
iov_iter_advance(_iter, vhost_hlen);
}
+   if (nvq->rx_array)
+   msg.msg_control = vhost_net_buf_consume(>rxq);
err = sock->ops->recvmsg(sock, ,
 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

Re: [PATCH v3] virtio_balloon: include disk/file caches memory statistics

[Michael S. Tsirkin]

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ý 


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();
>  
>   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_AVAIL6   /* 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

[PATCH] virtio: release virtio index when fail to device_register

[weiping zhang]

index can be reused by other virtio device.

Signed-off-by: weiping zhang 
---
 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);
+   if (err)
+   ida_simple_remove(_index_ida, dev->index);
 out:
if (err)
virtio_add_status(dev, VIRTIO_CONFIG_S_FAILED);
-- 
2.9.4

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH] VSOCK: Don't set sk_state to TCP_CLOSE before testing it

[David Miller]

From: Jorgen Hansen 
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 

Applied.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC] virtio-net: help live migrate SR-IOV devices

[Jesse Brandeburg]

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:
-  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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()

[Michael S. Tsirkin]

On Tue, Nov 28, 2017 at 12:17:16PM -0500, w...@redhat.com wrote:
> From: Wei Xu 
> 
> 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 

Given the amount of effort Matthew has put into this,
you definitely want

Reported-by: Matthew Rosato 

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(>rxq);
>   /* On overrun, truncate and discard */
>   if (unlikely(headcount > UIO_MAXIOV)) {
>   iov_iter_init(_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
>*/
>   iov_iter_advance(_iter, vhost_hlen);
>   }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(>rxq);
>   err = sock->ops->recvmsg(sock, ,
>sock_len, MSG_DONTWAIT | MSG_TRUNC);
>   /* Userspace might have consumed the packet meanwhile:
> -- 
> 1.8.3.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH net,stable] vhost: fix skb leak in handle_rx()

[Michael S. Tsirkin]

On Tue, Nov 28, 2017 at 12:17:16PM -0500, w...@redhat.com wrote:
> From: Wei Xu 
> 
> 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 

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(>rxq);
>   /* On overrun, truncate and discard */
>   if (unlikely(headcount > UIO_MAXIOV)) {
>   iov_iter_init(_iter, READ, vq->iov, 1, 1);
> @@ -809,6 +807,8 @@ static void handle_rx(struct vhost_net *net)
>*/
>   iov_iter_advance(_iter, vhost_hlen);
>   }
> + if (nvq->rx_array)
> + msg.msg_control = vhost_net_buf_consume(>rxq);
>   err = sock->ops->recvmsg(sock, ,
>sock_len, MSG_DONTWAIT | MSG_TRUNC);
>   /* Userspace might have consumed the packet meanwhile:
> -- 
> 1.8.3.1
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3] s390/virtio: add BSD license to virtio-ccw

[Cornelia Huck]

On Tue, 28 Nov 2017 15:17:52 +0200
"Michael S. Tsirkin"  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 
> Acked-by: Cornelia Huck 
> Signed-off-by: Michael S. Tsirkin 
> ---
>  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 
>   */
>  #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 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 

Shouldn't the second hunk already be in master?

Still ack otherwise.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3] s390/virtio: add BSD license to virtio-ccw

[Michael S. Tsirkin]

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 
Acked-by: Cornelia Huck 
Signed-off-by: Michael S. Tsirkin 
---
 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 
  */
 #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 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Greg KH]

On Tue, Nov 28, 2017 at 12:30:30PM +, 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 +, 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 
> > > > > 
> > > > > 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

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Sudip Mukherjee]

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 +, 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 
> > > > 
> > > > 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

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Greg KH]

On Tue, Nov 28, 2017 at 11:22:17AM +0100, Daniel Vetter wrote:
> On Mon, Nov 27, 2017 at 08:52:19PM +, 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 
> > > 
> > > 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

Re: [PATCH] VSOCK: Don't set sk_state to TCP_CLOSE before testing it

[Stefan Hajnoczi]

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 
> ---
>  net/vmw_vsock/vmci_transport.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Sorry, silly bug on my part!

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH 02/13] fbdev: add remove_conflicting_pci_framebuffers()

[Daniel Vetter]

On Mon, Nov 27, 2017 at 08:52:19PM +, 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 
> > 
> > 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