Re: [PATCH v3 09/26] compat_ioctl: move drivers to compat_ptr_ioctl
On Tue, Apr 16, 2019 at 10:19:47PM +0200, Arnd Bergmann wrote: > Each of these drivers has a copy of the same trivial helper function to > convert the pointer argument and then call the native ioctl handler. > > We now have a generic implementation of that, so use it. > > Acked-by: Greg Kroah-Hartman > Reviewed-by: Jarkko Sakkinen > Reviewed-by: Jason Gunthorpe > Signed-off-by: Arnd Bergmann > --- > drivers/char/ppdev.c | 12 +- > drivers/char/tpm/tpm_vtpm_proxy.c | 12 +- > drivers/firewire/core-cdev.c | 12 +- > drivers/hid/usbhid/hiddev.c | 11 + > drivers/hwtracing/stm/core.c | 12 +- > drivers/misc/mei/main.c | 22 + > drivers/mtd/ubi/cdev.c| 36 +++- > drivers/net/tap.c | 12 +- > drivers/staging/pi433/pi433_if.c | 12 +- > drivers/usb/core/devio.c | 16 + > drivers/vfio/vfio.c | 39 +++ > drivers/vhost/net.c | 12 +- > drivers/vhost/scsi.c | 12 +- > drivers/vhost/test.c | 12 +- > drivers/vhost/vsock.c | 12 +- > fs/fat/file.c | 13 +-- > 16 files changed, 20 insertions(+), 237 deletions(-) The vhost parts look good: Reviewed-by: Stefan Hajnoczi signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
On Tue, Aug 29, 2017 at 03:37:07PM +, Jorgen S. Hansen wrote: > > On Aug 29, 2017, at 4:36 AM, Dexuan Cui wrote: > If we allow multiple host side transports, virtio host side support and > vmci should be able to coexist regardless of the order of initialization. That sounds good to me. This means af_vsock.c needs to be aware of CID allocation. Currently the vhost_vsock.ko driver handles this itself (it keeps a list of CIDs and checks that they are not used twice). It should be possible to move that state into af_vsock.c so we have pairs. I'm currently working on NFS over AF_VSOCK and sock_diag support (for ss(8) and netstat-like tools). Multi-transport support is lower priority for me at the moment. I'm happy to review patches though. If there is no progress on this by the end of the year then I will have time to work on it. Are either of you are in Prague, Czech Republic on October 25-27 for Linux Kernel Summit, Open Source Summit Europe, Embedded Linux Conference Europe, KVM Forum, or MesosCon Europe? Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
On Tue, Aug 22, 2017 at 09:40:01PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote:
> > > > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > > > +{
> > > > > + static const u32 valid_cids[] = {
> > > > > + VMADDR_CID_ANY,
> > > >
> > > > Is this for loopback?
> > >
> > > No, we don't support lookback in Linux VM, at least for now.
> > > In our Linux implementation, Linux VM can only connect to the host, and
> > > here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> > > the same as VMADDR_CID_HOST.
> >
> > VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
> > connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
>
> Ok. Then I'll only allow VMADDR_CID_HOST as the destination CID, since
> we don't support loopback mode.
>
> > > > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x)
> > > > is
> > > > > + * reserved as ephemeral ports, which are used as the host's
> > > > > ports
> > > > > + * when the host initiates connections.
> > > > > + */
> > > > > + if (port > MAX_HOST_LISTEN_PORT)
> > > > > + return false;
> > > >
> > > > Without this if statement the guest will attempt to connect. I guess
> > > > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > > > connection attempt will fail.
> > >
> > > You're correct.
> > > To use the vsock common infrastructure, we have to map Hyper-V's
> > > GUID to int , and hence we must limit
> > > the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> > > we can only use half of the whole 32-bit port space for listen().
> > > This is detailed in the long comments starting at about Line 100.
> > >
> > > > ...but hardcode this knowledge into the guest driver?
> > > I'd like the guest's connect() to fail immediately here.
> > > IMO this is better than a connect timeout. :-)
> >
> > Thanks for explaining. Perhaps the comment could be updated:
> >
> > /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
> > * reserved as ephemeral ports, which are used as the host's ports when
> > * the host initiates connections.
> > *
> > * Perform this check in the guest so an immediate error is produced
> > * instead of a timeout.
> > */
> >
> > Stefan
>
> Thank you, Stefan!
> Please see the below for the updated version of the function:
>
> static bool hvs_stream_allow(u32 cid, u32 port)
> {
> /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
> * reserved as ephemeral ports, which are used as the host's ports
> * when the host initiates connections.
> *
> * Perform this check in the guest so an immediate error is produced
> * instead of a timeout.
> */
> if (port > MAX_HOST_LISTEN_PORT)
> return false;
>
> if (cid == VMADDR_CID_HOST)
> return true;
>
> return false;
> }
>
> I'll send a v2 of the patch later today.
Great, thanks!
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
On Fri, Aug 18, 2017 at 10:23:54PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > Sent: Thursday, August 17, 2017 07:56
> > To: Dexuan Cui
> > On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote:
> > > +static u32 hvs_get_local_cid(void)
> > > +{
> > > + return VMADDR_CID_ANY;
> > > +}
> >
> > Interesting concept: the guest never knows its CID. This is nice from a
> > live migration perspective. Currently VMCI and virtio adjust listen
> > socket local CIDs after migration.
> >
> > > +static bool hvs_stream_allow(u32 cid, u32 port)
> > > +{
> > > + static const u32 valid_cids[] = {
> > > + VMADDR_CID_ANY,
> >
> > Is this for loopback?
>
> No, we don't support lookback in Linux VM, at least for now.
> In our Linux implementation, Linux VM can only connect to the host, and
> here when Linux VM calls connect(), I treat VMADDR_CID_ANY
> the same as VMADDR_CID_HOST.
VMCI and virtio-vsock do not treat connect(VMADDR_CID_ANY) the same as
connect(VMADDR_CID_HOST). It is an error to connect to VMADDR_CID_ANY.
> > > + VMADDR_CID_HOST,
> > > + };
> > > + int i;
> > > +
> > > + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x)
> > is
> > > + * reserved as ephemeral ports, which are used as the host's ports
> > > + * when the host initiates connections.
> > > + */
> > > + if (port > MAX_HOST_LISTEN_PORT)
> > > + return false;
> >
> > Without this if statement the guest will attempt to connect. I guess
> > there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
> > connection attempt will fail.
>
> You're correct.
> To use the vsock common infrastructure, we have to map Hyper-V's
> GUID to int , and hence we must limit
> the port range we can listen() on to [0, MAX_LISTEN_PORT], i.e.
> we can only use half of the whole 32-bit port space for listen().
> This is detailed in the long comments starting at about Line 100.
>
> > ...but hardcode this knowledge into the guest driver?
> I'd like the guest's connect() to fail immediately here.
> IMO this is better than a connect timeout. :-)
Thanks for explaining. Perhaps the comment could be updated:
/* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
* reserved as ephemeral ports, which are used as the host's ports when
* the host initiates connections.
*
* Perform this check in the guest so an immediate error is produced
* instead of a timeout.
*/
Stefan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
On Fri, Aug 18, 2017 at 11:07:37PM +, Dexuan Cui wrote:
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > CID is not really used by us, because we only support guest<->host
> > communication,
> > > and don't support guest<->guest communication. The Hyper-V host
> > references
> > > every VM by VmID (which is invisible to the VM), and a VM can only talk to
> > the
> > > host via this feature.
> >
> > Applications running inside the guest should use VMADDR_CID_HOST (2) to
> > connect to the host, even on Hyper-V.
> I have no objection, and this patch does support this usage of the
> user-space applications.
>
> > By the way, we should collaborate on a test suite and a vsock(7) man
> > page that documents the semantics of AF_VSOCK sockets. This way our
> > transports will have the same behavior and AF_VSOCK applications will
> > work on all 3 hypervisors.
> I can't agree more. :-)
> BTW, I have been using Rolf's test suite to test my patch:
> https://github.com/rn/virtsock/tree/master/c
> Maybe this can be a good starting point.
Thanks for sharing this, I will try it with virtio-vsock.
I have a netcat-like utility here:
https://github.com/stefanha/linux/blob/vsock-extras/nc-vsock.c
> > Not all features need to be supported. For example, VMCI supports
> > SOCK_DGRAM while Hyper-V and virtio do not. But features that are
> > available should behave identically.
> I totally agree, though I'm afraid Hyper-V may have a little more limitations
> compared to VMware/KVM duo to the <-->
> mapping.
>
> > > Can we use the 'protocol' parameter in the socket() function:
> > > int socket(int domain, int type, int protocol)
> > >
> > > IMO currently the 'protocol' is not really used.
> > > I think we can modify __vsock_core_init() to allow multiple transport
> > > layers
> > to
> > > be registered, and we can define different 'protocol' numbers for
> > > VMware/KVM/Hyper-V, and ask the application to explicitly specify what
> > should
> > > be used. Considering compatibility, we can use the default transport in a
> > given
> > > VM depending on the underlying hypervisor.
> >
> > I think AF_VSOCK should hide the transport from users/applications.
> Ideally yes, but let's consider the KVM-on-KVM nested scenario: when
> an application in the Level-1 VM creates an AF_VSOCK socket and call
> connect() for it, how can we know if the app is trying to connect to
> the Level-0 host, or connect to the Level-2 VM? We can't.
We *can* by looking at the destination CID. Please take a look at
drivers/misc/vmw_vmci/vmci_route.c:vmci_route() to see how VMCI handles
nested virt.
It boils down to something like this:
static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
int addr_len, int flags)
{
...
if (remote_addr.svm_cid == VMADDR_CID_HOST)
transport = host_transport;
else
transport = guest_transport;
It's easy for connect(2) but Jorgen mentioned it's harder for listen(2)
because the socket would need to listen on both transports. We define
two new constants VMADDR_CID_LISTEN_FROM_GUEST and
VMADDR_CID_LISTEN_FROM_HOST for bind(2) so that applications can decide
which side to listen on. Or the listen socket could simply listen to
both sides.
Stefan
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)
On Tue, Aug 15, 2017 at 10:18:41PM +, Dexuan Cui wrote:
> +static u32 hvs_get_local_cid(void)
> +{
> + return VMADDR_CID_ANY;
> +}
Interesting concept: the guest never knows its CID. This is nice from a
live migration perspective. Currently VMCI and virtio adjust listen
socket local CIDs after migration.
> +static bool hvs_stream_allow(u32 cid, u32 port)
> +{
> + static const u32 valid_cids[] = {
> + VMADDR_CID_ANY,
Is this for loopback?
> + VMADDR_CID_HOST,
> + };
> + int i;
> +
> + /* The host's port range [MIN_HOST_EPHEMERAL_PORT, 0x) is
> + * reserved as ephemeral ports, which are used as the host's ports
> + * when the host initiates connections.
> + */
> + if (port > MAX_HOST_LISTEN_PORT)
> + return false;
Without this if statement the guest will attempt to connect. I guess
there will be no listen sockets above MAX_HOST_LISTEN_PORT, so the
connection attempt will fail.
...but hardcode this knowledge into the guest driver?
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race
On Tue, Aug 15, 2017 at 10:15:39PM +, Dexuan Cui wrote: > With the current code, when vsock_dequeue_accept() is removing a sock > from the list, nothing prevents vsock_enqueue_accept() from adding a new > sock into the list concurrently. We should add a lock to protect the list. The listener sock is locked, preventing concurrent modification. I have checked both the virtio and vmci transports. Can you post an example where the listener sock isn't locked? Stefan signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
On Fri, Aug 18, 2017 at 03:07:30AM +, Dexuan Cui wrote: > > From: Jorgen S. Hansen [mailto:jhan...@vmware.com] > > Sent: Thursday, August 17, 2017 08:17 > > > > > > Putting aside nested virtualization, I want to load the transport (vmci, > > > Hyper-V, vsock) for which there is paravirtualized hardware present > > > inside the guest. > > > > Good points. Completely agree that this is the desired behavior for a guest. > > > > > > > It's a little tricker on the host side (doesn't matter for Hyper-V and > > > probably also doesn't for VMware) because the host-side driver is a > > > software device with no hardware backing it. In KVM we assume the > > > vhost_vsock.ko kernel module will be loaded sufficiently early. > > > > Since the vmci driver is currently tied to PF_VSOCK it hasn’t been a > > problem, > > but on the host side the VMCI driver has no hardware backing it either, so > > when we move to a more appropriate solution, this will be an issue for VMCI > > as > > well. I’ll check our shipped products, but they most likely assume that if > > an > > upstreamed vmci module is present, it will be loaded automatically. > > Hyper-V Sockets is a standard feature of VMBus v4.0, so we can easily know > we can and should load iff vmbus_proto_version >= VERSION_WIN10. > > > > Things get trickier with nested virtualization because the VM might want > > > to talk to its host but also to its nested VMs. The simple way of > > > fixing this would be to allow two transports loaded simultaneously and > > > route traffic destined to CID 2 to the host transport and all other > > > traffic to the guest transport. > > This sounds like a little tricky to me. > CID is not really used by us, because we only support guest<->host > communication, > and don't support guest<->guest communication. The Hyper-V host references > every VM by VmID (which is invisible to the VM), and a VM can only talk to the > host via this feature. Applications running inside the guest should use VMADDR_CID_HOST (2) to connect to the host, even on Hyper-V. By the way, we should collaborate on a test suite and a vsock(7) man page that documents the semantics of AF_VSOCK sockets. This way our transports will have the same behavior and AF_VSOCK applications will work on all 3 hypervisors. Not all features need to be supported. For example, VMCI supports SOCK_DGRAM while Hyper-V and virtio do not. But features that are available should behave identically. > > This is close to the routing the VMCI driver does in a nested environment, > > but > > that is with the assumption that there is only one type of transport. > > Having two > > different transports would require that we delay resolving the transport > > type > > until the socket endpoint has been bound to an address. Things get trickier > > if > > listening sockets use VMADDR_CID_ANY - if only one transport is present, > > this > > would allow the socket to accept connections from both guests and outer > > host, > > but with multiple transports that won’t work, since we can’t associate a > > socket > > with a transport until the socket is bound. > > > > > > > > Perhaps we should discuss these cases a bit more to figure out how to > > > avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK). > > > > Agreed. > > Can we use the 'protocol' parameter in the socket() function: > int socket(int domain, int type, int protocol) > > IMO currently the 'protocol' is not really used. > I think we can modify __vsock_core_init() to allow multiple transport layers > to > be registered, and we can define different 'protocol' numbers for > VMware/KVM/Hyper-V, and ask the application to explicitly specify what should > be used. Considering compatibility, we can use the default transport in a > given > VM depending on the underlying hypervisor. I think AF_VSOCK should hide the transport from users/applications. Think of same-on-same nested virtualization: VMware-on-VMware or KVM-on-KVM. In that case specifying VMCI or virtio doesn't help. We'd still need to distinguish between "to guest" and "to host" (currently VMCI has code to do this but virtio does not). The natural place to distinguish the destination is when dealing with the sockaddr in connect(), bind(), etc. Stefan signature.asc Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] vsock: only load vmci transport on VMware hypervisor by default
On Thu, Aug 17, 2017 at 08:00:29AM +, Dexuan Cui wrote:
>
> Without the patch, vmw_vsock_vmci_transport.ko can automatically load
> when an application creates an AF_VSOCK socket.
>
> This is the expected good behavior on VMware hypervisor, but as we
> are going to add hv_sock.ko (i.e. Hyper-V transport for AF_VSOCK), we
> should make sure vmw_vsock_vmci_transport.ko can't load on Hyper-V,
> otherwise there is a -EBUSY conflict when both vmw_vsock_vmci_transport.ko
> and hv_sock.ko try to call vsock_core_init() on Hyper-V.
>
> On the other hand, hv_sock.ko can only load on Hyper-V, because it
> depends on hv_vmbus.ko, which detects Hyper-V in hv_acpi_init().
>
> KVM's vsock_virtio_transport doesn't have the issue because it doesn't
> define MODULE_ALIAS_NETPROTO(PF_VSOCK).
Thanks for sending this patch, vmci's MODULE_ALIAS_NETPROTO(PF_VSOCK) is
a problem for vhost_vsock.ko (the virtio host driver) too. A host
userspace program can create a AF_VSOCK socket before vhost_vsock is
loaded. The vmci transport will be unconditionally loaded and that's
not the right behavior.
Putting aside nested virtualization, I want to load the transport (vmci,
Hyper-V, vsock) for which there is paravirtualized hardware present
inside the guest.
It's a little tricker on the host side (doesn't matter for Hyper-V and
probably also doesn't for VMware) because the host-side driver is a
software device with no hardware backing it. In KVM we assume the
vhost_vsock.ko kernel module will be loaded sufficiently early.
Things get trickier with nested virtualization because the VM might want
to talk to its host but also to its nested VMs. The simple way of
fixing this would be to allow two transports loaded simultaneously and
route traffic destined to CID 2 to the host transport and all other
traffic to the guest transport.
Perhaps we should discuss these cases a bit more to figure out how to
avoid conflicts over MODULE_ALIAS_NETPROTO(PF_VSOCK).
>
> The patch also adds a module parameter "skip_hypervisor_check" for
> vmw_vsock_vmci_transport.ko.
>
> Signed-off-by: Dexuan Cui
> Cc: Alok Kataria
> Cc: Andy King
> Cc: Adit Ranadive
> Cc: George Zhang
> Cc: Jorgen Hansen
> Cc: K. Y. Srinivasan
> Cc: Haiyang Zhang
> Cc: Stephen Hemminger
> ---
> net/vmw_vsock/Kconfig | 2 +-
> net/vmw_vsock/vmci_transport.c | 11 +++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/net/vmw_vsock/Kconfig b/net/vmw_vsock/Kconfig
> index a24369d..3f52929 100644
> --- a/net/vmw_vsock/Kconfig
> +++ b/net/vmw_vsock/Kconfig
> @@ -17,7 +17,7 @@ config VSOCKETS
>
> config VMWARE_VMCI_VSOCKETS
> tristate "VMware VMCI transport for Virtual Sockets"
> - depends on VSOCKETS && VMWARE_VMCI
> + depends on VSOCKETS && VMWARE_VMCI && HYPERVISOR_GUEST
> help
> This module implements a VMCI transport for Virtual Sockets.
>
> diff --git a/net/vmw_vsock/vmci_transport.c b/net/vmw_vsock/vmci_transport.c
> index 10ae782..c068873 100644
> --- a/net/vmw_vsock/vmci_transport.c
> +++ b/net/vmw_vsock/vmci_transport.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -73,6 +74,10 @@ struct vmci_transport_recv_pkt_info {
> struct vmci_transport_packet pkt;
> };
>
> +static bool skip_hypervisor_check;
> +module_param(skip_hypervisor_check, bool, 0444);
> +MODULE_PARM_DESC(hot_add, "If set, attempt to load on non-VMware platforms");
> +
> static LIST_HEAD(vmci_transport_cleanup_list);
> static DEFINE_SPINLOCK(vmci_transport_cleanup_lock);
> static DECLARE_WORK(vmci_transport_cleanup_work, vmci_transport_cleanup);
> @@ -2085,6 +2090,12 @@ static int __init vmci_transport_init(void)
> {
> int err;
>
> + /* Check if we are running on VMware's hypervisor and bail out
> + * if we are not.
> + */
> + if (!skip_hypervisor_check && x86_hyper != &x86_hyper_vmware)
> + return -ENODEV;
> +
> /* Create the datagram handle that we will use to send and receive all
>* VSocket control messages for this context.
>*/
> --
> 2.7.4
>
signature.asc
Description: PGP signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/7] introduce Hyper-V VM Sockets(hvsock)
On Mon, Jul 06, 2015 at 07:39:35AM -0700, Dexuan Cui wrote: > Hyper-V VM Sockets (hvsock) is a byte-stream based communication mechanism > between Windowsd 10 (or later) host and a guest. It's kind of TCP over > VMBus, but the transportation layer (VMBus) is much simpler than IP. > With Hyper-V VM Sockets, applications between the host and a guest can > talk with each other directly by the traditional BSD-style socket APIs. > > The patchset implements the necessary support in the guest side by adding > the necessary new APIs in the vmbus driver, and introducing a new driver > hv_sock.ko, which implements_a new socket address family AF_HYPERV. > > > I know the kernel has already had a VM Sockets driver (AF_VSOCK) based > on VMware's VMCI (net/vmw_vsock/, drivers/misc/vmw_vmci), and KVM is > proposing AF_VSOCK of virtio version: > http://thread.gmane.org/gmane.linux.network/365205. > > However, though Hyper-V VM Sockets may seem conceptually similar to > AF_VOSCK, there are differences in the transportation layer, and IMO these > make the direct code reusing impractical: > > 1. In AF_VSOCK, the endpoint type is: , but in > AF_HYPERV, the endpoint type is: . Here GUID > is 128-bit. > > 2. AF_VSOCK supports SOCK_DGRAM, while AF_HYPERV doesn't. > > 3. AF_VSOCK supports some special sock opts, like SO_VM_SOCKETS_BUFFER_SIZE, > SO_VM_SOCKETS_BUFFER_MIN/MAX_SIZE and SO_VM_SOCKETS_CONNECT_TIMEOUT. > These are meaningless to AF_HYPERV. > > 4. Some AF_VSOCK's VMCI transportation ops are meanless to AF_HYPERV/VMBus, > like.notify_recv_init > .notify_recv_pre_block > .notify_recv_pre_dequeue > .notify_recv_post_dequeue > .notify_send_init > .notify_send_pre_block > .notify_send_pre_enqueue > .notify_send_post_enqueue > etc. > > So I think we'd better introduce a new address family: AF_HYPERV. Points 2-4 are not critical. I think there are solutions to them. Point 1 is the main issue: hvsock has addresses instead of vsock's addresses. Perhaps a mapping could be used but that is pretty ugly. One idea is something like a userspace <-> lookup function that applications can use if they want to accept GUIDs. I don't have a workable alternative to propose, so I agree that a new address family is justified. pgpnJR1xGGTMx.pgp Description: PGP signature ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/25] line6usb cleanup
On Sun, Jan 11, 2015 at 10:34 AM, Takashi Iwai wrote: > At Fri, 9 Jan 2015 23:35:46 -0600, > Chris Rorvick wrote: >> >> The line6usb driver references the device's idProduct and, in some >> cases, the interface number in a number of places to determine device- >> specific configuration values and to call device-specific functionality. >> Rework code to leverage the device table matching more effectively. >> Consolidate configuration settings into the properties entries and use >> function pointers setup at initialization to remove much of the >> conditional logic. >> >> I have a TonePort UX2 that I've used for testing, meaning that some of >> this is really only compile-tested. > > BTW, are there any active developers for this driver? It doesn't make > sense to sit in staging directory forever. It should be promoted to > the official sound directory, or dropped from the kernel tree if not. > If anyone is responsible for testing with real hardware, I'll happily > review. I am not active but willing to help with review and advice if anyone wants to tackle this driver. Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/25] line6usb cleanup
On Sat, Jan 10, 2015 at 5:35 AM, Chris Rorvick wrote: > The line6usb driver references the device's idProduct and, in some > cases, the interface number in a number of places to determine device- > specific configuration values and to call device-specific functionality. > Rework code to leverage the device table matching more effectively. > Consolidate configuration settings into the properties entries and use > function pointers setup at initialization to remove much of the > conditional logic. > > I have a TonePort UX2 that I've used for testing, meaning that some of > this is really only compile-tested. I no longer own a Pod HD300 so I cannot test these patches. The code looks fine. Reviewed-by: Stefan Hajnoczi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: line6: toneport.c: Fix for possible null pointer dereference
On Sun, Dec 21, 2014 at 10:43 PM, Rickard Strandqvist wrote: > The NULL check was done to late, and there it was a risk > of a possible null pointer dereference. > > This was partially found by using a static code analysis program called > cppcheck. > > Signed-off-by: Rickard Strandqvist > --- > drivers/staging/line6/toneport.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) Reviewed-by: Stefan Hajnoczi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on line6?
On Fri, Jun 27, 2014 at 1:39 AM, Greg KH wrote: > On Tue, Jun 24, 2014 at 10:12:03PM +0800, Stefan Hajnoczi wrote: >> On Tue, Jun 24, 2014 at 9:52 PM, Greg KH wrote: >> > On Tue, Jun 24, 2014 at 11:54:10AM +0800, Stefan Hajnoczi wrote: >> >> On Tue, Jun 24, 2014 at 4:23 AM, Kristina Martšenko >> >> wrote: >> >> > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that >> >> > nobody seems to have worked towards moving line6 out of staging in over >> >> > a year. Are there any plans to clean it up and move it out soon? Because >> >> > otherwise we're going to have to delete the driver, as we don't want >> >> > staging to become a permanent place for unfinished code. >> >> >> >> I do not have time to resume the work and am moving to new hardware in >> >> a few weeks. >> > >> > Do you know of anyone else using this hardware on Linux? >> >> Markus Grabner is the maintainer and still the best person to involve. >> >> People have popped up from time to time on the line6linux-devel >> mailing list but no one has stuck around: >> http://sourceforge.net/p/line6linux/mailman/line6linux-devel/ >> >> >> It's a shame since the driver is in a pretty good position for further >> >> cleanups and a move out of staging/. There's not that much left to do >> >> but the rate of progress at the moment is zero. >> > >> > If the code is "almost" ready to move, what do you think is left to do? >> >> 1. Run checkpatch.pl again to make sure there are no coding style >> issues remaining. >> >> 2. Audit remaining sysfs attributes and drop them where possible. I >> killed off the easy ones which just sent MIDI messages that userspace >> can send just as easily. Now only the weird ones are left: >> >> drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_volume); >> drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_period); >> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(device_id); >> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(firmware_version); >> drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(serial_number); >> drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_red, S_IWUSR | >> S_IRUGO, line6_nop_read, >> drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_green, S_IWUSR >> | S_IRUGO, line6_nop_read, >> >> Are sysfs attributes appropriate userspace ABIs for these parameters? >> Should ioctls be used instead? > > Are these even needed at all? Do people care about them? Probably not. > serial number > and firmware version seems trivial and not needed. leds should use the > led kernel interface instead. device_id is not needed as that's in the > sysfs "name" already. Most users probably care about audio and MIDI only. The sysfs attributes are probably not needed. The serial number and firmware version would be used for firmware upgrades but I wouldn't recommend trying that anyway. They can be added back later, if someone wants to develop and test a firmware upgrade tool (and brick their device). > So that leaves impulse_volume and period. What are these? Are there > any MIDI interfaces that use them? There is an impulse response test built into the driver. It's a compile-time option that is disabled by default. It can be used to analyze signal processing and latency from the device. I asked Markus whether we can drop this and do it in userspace. Due to the buffering in some devices, it is only possible to do this correctly in the kernel driver. There is a line6linux-devel email thread about it: http://comments.gmane.org/gmane.comp.audio.line6linux.devel/171 If this is the last hurdle to getting the driver out of staging, then I think the impulse response feature should be dropped from the driver. It can be added back later (if necessary). Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on line6?
On Tue, Jun 24, 2014 at 9:52 PM, Greg KH wrote: > On Tue, Jun 24, 2014 at 11:54:10AM +0800, Stefan Hajnoczi wrote: >> On Tue, Jun 24, 2014 at 4:23 AM, Kristina Martšenko >> wrote: >> > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that >> > nobody seems to have worked towards moving line6 out of staging in over >> > a year. Are there any plans to clean it up and move it out soon? Because >> > otherwise we're going to have to delete the driver, as we don't want >> > staging to become a permanent place for unfinished code. >> >> I do not have time to resume the work and am moving to new hardware in >> a few weeks. > > Do you know of anyone else using this hardware on Linux? Markus Grabner is the maintainer and still the best person to involve. People have popped up from time to time on the line6linux-devel mailing list but no one has stuck around: http://sourceforge.net/p/line6linux/mailman/line6linux-devel/ >> It's a shame since the driver is in a pretty good position for further >> cleanups and a move out of staging/. There's not that much left to do >> but the rate of progress at the moment is zero. > > If the code is "almost" ready to move, what do you think is left to do? 1. Run checkpatch.pl again to make sure there are no coding style issues remaining. 2. Audit remaining sysfs attributes and drop them where possible. I killed off the easy ones which just sent MIDI messages that userspace can send just as easily. Now only the weird ones are left: drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_volume); drivers/staging/line6/pcm.c:static DEVICE_ATTR_RW(impulse_period); drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(device_id); drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(firmware_version); drivers/staging/line6/pod.c:static DEVICE_ATTR_RO(serial_number); drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_red, S_IWUSR | S_IRUGO, line6_nop_read, drivers/staging/line6/toneport.c:static DEVICE_ATTR(led_green, S_IWUSR | S_IRUGO, line6_nop_read, Are sysfs attributes appropriate userspace ABIs for these parameters? Should ioctls be used instead? 3. Send patch to move driver to ALSA maintainers and address any review feedback. Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on line6?
On Tue, Jun 24, 2014 at 4:23 AM, Kristina Martšenko wrote: > I'm helping Greg do a bit of cleanup in the staging tree. I noticed that > nobody seems to have worked towards moving line6 out of staging in over > a year. Are there any plans to clean it up and move it out soon? Because > otherwise we're going to have to delete the driver, as we don't want > staging to become a permanent place for unfinished code. I do not have time to resume the work and am moving to new hardware in a few weeks. It's a shame since the driver is in a pretty good position for further cleanups and a move out of staging/. There's not that much left to do but the rate of progress at the moment is zero. Stefan ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: line6: toneport.c: Fix for possible null pointer dereference
On Mon, May 19, 2014 at 11:39 PM, Rickard Strandqvist
wrote:
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> drivers/staging/line6/toneport.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/line6/toneport.c
> b/drivers/staging/line6/toneport.c
> index af2e7e5..36fe76d 100644
> --- a/drivers/staging/line6/toneport.c
> +++ b/drivers/staging/line6/toneport.c
> @@ -431,11 +431,15 @@ void line6_toneport_disconnect(struct usb_interface
> *interface)
> {
> struct usb_line6_toneport *toneport;
> u16 idProduct;
> + struct snd_line6_pcm *line6pcm;
>
> if (interface == NULL)
> return;
>
> toneport = usb_get_intfdata(interface);
> + if (toneport == NULL)
> + return;
> +
> del_timer_sync(&toneport->timer);
> idProduct = le16_to_cpu(toneport->line6.usbdev->descriptor.idProduct);
>
> @@ -444,13 +448,11 @@ void line6_toneport_disconnect(struct usb_interface
> *interface)
> device_remove_file(&interface->dev, &dev_attr_led_green);
> }
>
> - if (toneport != NULL) {
> - struct snd_line6_pcm *line6pcm = toneport->line6.line6pcm;
Didn't look into this but it's the traditional "use before NULL
check". Can't hurt to fix it.
Reviewed-by: Stefan Hajnoczi
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] staging: line6: Add blank lines after declarations
On Mon, Mar 24, 2014 at 11:46 PM, Fabian Mewes wrote: > Use the more common kernel coding style. > > Signed-off-by: Fabian Mewes > --- > applies to next-20140324 > v1..v2: improve commit message as suggested by Joe > > drivers/staging/line6/driver.c | 1 + > drivers/staging/line6/playback.c | 5 + > drivers/staging/line6/toneport.c | 1 + > 3 files changed, 7 insertions(+) Reviewed-by: Stefan Hajnoczi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [patch] staging: line6: add bounds check in snd_toneport_source_put()
On Fri, Sep 13, 2013 at 10:07 AM, Dan Carpenter wrote: > "source" comes from the user in snd_ctl_elem_write() so it needs to be > checked. > > Signed-off-by: Dan Carpenter Reviewed-by: Stefan Hajnoczi ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
