search for: sk

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

From: Andy King <acking at vmware.com> ** Introduce VM Sockets *** In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the VM Sockets (VSOCK, formerly VMCI Sockets) (vmw_vsock) kernel module for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. Unlike previous

Hi, Sometimes, users might find that the `ssh-sk-helper` crashes after enrolling a new key when using external SK libraries. Currently, the memory returned by SK APIs is freed by the host, but external libraries may have their own methods of handling memory. For instance some external libraries are linked against a foreign libc statically. As a...

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware to address Greg's and all other's code review comments. Summary of changes: - Rebase our linux kernel tree from v3.5 to v3.7. - Fix all checkpatch warnings and errors. Fix some checkpatch with -strict errors. This addresses Greg's comment: On 15 Nov 2012

...------- 2 files changed, 39 insertions(+), 18 deletions(-) diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index c660402b10f2..a5e1e134261d 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -27,6 +27,7 @@ extern spinlock_t vsock_table_lock; struct vsock_sock { /* sk must be the first member. */ struct sock sk; + const struct vsock_transport *transport; struct sockaddr_vm local_addr; struct sockaddr_vm remote_addr; /* Links for the global tables of bound and connected sockets. */ diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index f60...

...have more then one {Security Key,HSM}-FIDO2 device attached to my Linux machine (Arch Linux). With ``` # fido2-token -L /dev/hidraw7: vendor=0x1d50, product=0x60fc (CRYPTOTRUST ONLYKEY) /dev/hidraw5: vendor=0x20a0, product=0x42b2 (Nitrokey Nitrokey 3) ``` I am able to get the device paths of both SK, which I can use to generate an `ecdsa-sk` on a specific device: ``` $ ssh-keygen \ -t ecdsa-sk \ -f /tmp/TEST-id_ed25519-sk \ -N '' \ -O device=/dev/hidraw5 \ -O resident \ -O verify-required ... The key fingerprint is: SHA256:HixXHmVbrCZRxWUXIDOZF50VAIf/cVESDcBZsKSWcro bernd `...

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

* * * In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (VSOCK) (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vsock kernel module. The vmw_vmci kernel module has been presented in

...------- 2 files changed, 39 insertions(+), 18 deletions(-) diff --git a/include/net/af_vsock.h b/include/net/af_vsock.h index c660402b10f2..a5e1e134261d 100644 --- a/include/net/af_vsock.h +++ b/include/net/af_vsock.h @@ -27,6 +27,7 @@ extern spinlock_t vsock_table_lock; struct vsock_sock { /* sk must be the first member. */ struct sock sk; + const struct vsock_transport *transport; struct sockaddr_vm local_addr; struct sockaddr_vm remote_addr; /* Links for the global tables of bound and connected sockets. */ diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 2f2...

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

* * * This series of VSOCK linux upstreaming patches include latest udpate from VMware. Summary of changes: - Sparse clean. - Checkpatch clean with one exception, a "complex macro" in which we can't add parentheses. - Remove all runtime assertions. - Fix device name, so that existing user clients work. - Fix VMCI handle lookup. * *

...+ +#ifndef VMCHANNEL_H +#define VMCHANNEL_H + +#define VMCHANNEL_NAME_MAX 80 +struct sockaddr_vmchannel { + sa_family_t svmchannel_family; + char svmchannel_name[VMCHANNEL_NAME_MAX]; +}; + +#ifdef __KERNEL__ + +#define VIRTIO_ID_VMCHANNEL 6 +#define VMCHANNEL_BAD_ID (~(__u32)0) + +#define vmchannel_sk(__sk) ((struct vmchannel_sock *) __sk) + +struct vmchannel_sock { + struct sock sk; + char name[VMCHANNEL_NAME_MAX]; + __u32 id; + struct sk_buff_head backlog_skb_q; +}; + +struct vmchannel_info { + __u32 id; + char *name; +}; + +struct vmchannel_dev { + struct virtio_device *vdev; + struct virtque...

...+ +#ifndef VMCHANNEL_H +#define VMCHANNEL_H + +#define VMCHANNEL_NAME_MAX 80 +struct sockaddr_vmchannel { + sa_family_t svmchannel_family; + char svmchannel_name[VMCHANNEL_NAME_MAX]; +}; + +#ifdef __KERNEL__ + +#define VIRTIO_ID_VMCHANNEL 6 +#define VMCHANNEL_BAD_ID (~(__u32)0) + +#define vmchannel_sk(__sk) ((struct vmchannel_sock *) __sk) + +struct vmchannel_sock { + struct sock sk; + char name[VMCHANNEL_NAME_MAX]; + __u32 id; + struct sk_buff_head backlog_skb_q; +}; + +struct vmchannel_info { + __u32 id; + char *name; +}; + +struct vmchannel_dev { + struct virtio_device *vdev; + struct virtque...

...ine BTRFS_ROOT_TREE_DIR_OBJECTID 6ULL +#define BTRFS_DIR_ITEM_KEY 84 + +/* + * * this is used for both forward and backward root refs + * */ +struct btrfs_root_ref { + __le64 dirid; + __le64 sequence; + __le16 name_len; +} __attribute__ ((__packed__)); + +struct btrfs_disk_key { + __le64 objectid; + u8 type; + __le64 offset; +} __attribute__ ((__packed__)); + +struct btrfs_dir_item { + struct btrfs_disk_key location; + __le64 transid; + __le16 data_len; + __le16 name_len; + u8 type; +} __attribute__ ((__packed__...

...hen __vsock_release() > is called recursively: > > ============================================ > WARNING: possible recursive locking detected > 5.3.0+ #1 Not tainted > -------------------------------------------- > server/1795 is trying to acquire lock: > ffff8880c5158990 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock] > > but task is already holding lock: > ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock] > > other info that might help us debug this: > Possible unsafe locking scenario: > >...

...rs/vhost/net.c b/drivers/vhost/net.c > index 62bb8e8..2790959 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -429,6 +429,52 @@ static int vhost_net_enable_vq(struct vhost_net *n, > return vhost_poll_start(poll, sock->file); > } > > +static int sk_has_rx_data(struct sock *sk) > +{ > + struct socket *sock = sk->sk_socket; > + > + if (sock->ops->peek_len) > + return sock->ops->peek_len(sock); > + > + return skb_queue_empty(&sk->sk_receive_queue); > +} > + > +static void vhost_net_busy_poll(s...

...rs/vhost/net.c b/drivers/vhost/net.c > index 62bb8e8..2790959 100644 > --- a/drivers/vhost/net.c > +++ b/drivers/vhost/net.c > @@ -429,6 +429,52 @@ static int vhost_net_enable_vq(struct vhost_net *n, > return vhost_poll_start(poll, sock->file); > } > > +static int sk_has_rx_data(struct sock *sk) > +{ > + struct socket *sock = sk->sk_socket; > + > + if (sock->ops->peek_len) > + return sock->ops->peek_len(sock); > + > + return skb_queue_empty(&sk->sk_receive_queue); > +} > + > +static void vhost_net_busy_poll(s...

...hen __vsock_release() > is called recursively: > > ============================================ > WARNING: possible recursive locking detected > 5.3.0+ #1 Not tainted > -------------------------------------------- > server/1795 is trying to acquire lock: > ffff8880c5158990 (sk_lock-AF_VSOCK){+.+.}, at: hvs_release+0x10/0x120 [hv_sock] > > but task is already holding lock: > ffff8880c5158150 (sk_lock-AF_VSOCK){+.+.}, at: __vsock_release+0x2e/0xf0 [vsock] > > other info that might help us debug this: > Possible unsafe locking scenario: > >...

...a); @@ -425,6 +425,7 @@ static void handle_rx_mergeable(struct vhost_net *net) vq_log = unlikely(vhost_has_feature(&net->dev, VHOST_F_LOG_ALL)) ? vq->log : NULL; + mergeable = vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF); while ((sock_len = peek_head_len(sock->sk))) { sock_len += sock_hlen; @@ -474,7 +475,7 @@ static void handle_rx_mergeable(struct vhost_net *net) break; } /* TODO: Should check and handle checksum. */ - if (vhost_has_feature(&net->dev, VIRTIO_NET_F_MRG_RXBUF) && + if (likely(mergeable) && memcpy_...