Displaying 20 results from an estimated 84 matches for "lock_sock".
Did you mean:
vsock_sock
2011 Jan 17
11
[PATCH 1/3] vhost-net: check the support of mergeable buffer outside the receive loop
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
Signed-off-by: Jason Wang <jasowang at redhat.com>
---
drivers/vhost/net.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index
2011 Jan 17
11
[PATCH 1/3] vhost-net: check the support of mergeable buffer outside the receive loop
No need to check the support of mergeable buffer inside the recevie
loop as the whole handle_rx()_xx is in the read critical region. So
this patch move it ahead of the receiving loop.
Signed-off-by: Jason Wang <jasowang at redhat.com>
---
drivers/vhost/net.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index
2019 Sep 26
0
[PATCH net v2] vsock: Fix a lockdep warning in __vsock_release()
Hi Dexuan,
On Thu, Sep 26, 2019 at 01:11:27AM +0000, Dexuan Cui wrote:
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning for hyperv and virtio sockets (vmci socket code
> doesn't have the issue) by using lock_sock_nested() when __vsock_release()
> is called recursively:
>
> ============================================
> WARNING: possible recursive locking detected
> 5.3.0+ #1 Not tainted
> --------------------------------------------
> server/1795 is trying to acquire lock:
> ffff888...
2020 May 29
0
[PATCH v2] virtio_vsock: Fix race condition in virtio_transport_recv_pkt
...rom the commit message.
>
> The race condition as follows:
> Task1 Task2
> ===== =====
> __sock_release virtio_transport_recv_pkt
> __vsock_release vsock_find_bound_socket (found)
> lock_sock_nested
> vsock_remove_sock
> sock_orphan
> sk_set_socket(sk, NULL)
Here we can add:
sk->sk_shutdown = SHUTDOWN_MASK;
> ...
> release_sock
> lock_sock
> virtio_transport_recv_conn...
2019 Oct 01
0
[PATCH net v3] vsock: Fix a lockdep warning in __vsock_release()
On Mon, Sep 30, 2019 at 06:43:50PM +0000, Dexuan Cui wrote:
> Lockdep is unhappy if two locks from the same class are held.
>
> Fix the below warning for hyperv and virtio sockets (vmci socket code
> doesn't have the issue) by using lock_sock_nested() when __vsock_release()
> is called recursively:
>
> ============================================
> WARNING: possible recursive locking detected
> 5.3.0+ #1 Not tainted
> --------------------------------------------
> server/1795 is trying to acquire lock:
> ffff888...
2020 May 31
0
[PATCH v3] virtio_vsock: Fix race condition in virtio_transport_recv_pkt
...r):
...
> The race condition is as follows:
> Task1 Task2
> ===== =====
> __sock_release virtio_transport_recv_pkt
> __vsock_release vsock_find_bound_socket (found sk)
> lock_sock_nested
> vsock_remove_sock
> sock_orphan
> sk_set_socket(sk, NULL)
> sk->sk_shutdown = SHUTDOWN_MASK
> ...
> release_sock
> lock_sock
> virtio_transport_recv_connecting
&g...
2019 Sep 27
0
[PATCH net v2] vsock: Fix a lockdep warning in __vsock_release()
...;dmesg" will show the scary
> call-trace, if the kernel is built with
> CONFIG_LOCKDEP=y
> CONFIG_LOCKDEP_SUPPORT=y
>
> 4. Apply the patch, do the same test and we should no longer see the call-trace.
Thanks very useful! I'll follow these steps!
>
> > > - lock_sock(sk);
> > > + /* When "level" is 2, use the nested version to avoid the
> > > + * warning "possible recursive locking detected".
> > > + */
> > > + if (level == 1)
> > > + lock_sock(sk);
> >
> > Since lock_sock() c...
2019 Sep 27
0
[RFC PATCH 04/13] vsock: add 'transport' member in the struct vsock_sock
...{
+ if (vsk->transport->init(vsk, psk) < 0) {
sk_free(sk);
return NULL;
}
@@ -638,7 +641,7 @@ static void __vsock_release(struct sock *sk)
vsk = vsock_sk(sk);
pending = NULL; /* Compiler warning. */
- transport->release(vsk);
+ vsk->transport->release(vsk);
lock_sock(sk);
sock_orphan(sk);
@@ -662,7 +665,7 @@ static void vsock_sk_destruct(struct sock *sk)
{
struct vsock_sock *vsk = vsock_sk(sk);
- transport->destruct(vsk);
+ vsk->transport->destruct(vsk);
/* When clearing these addresses, there's no need to set the family and
* possib...
2019 Oct 23
0
[PATCH net-next 04/14] vsock: add 'transport' member in the struct vsock_sock
..._timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT;
}
- if (transport->init(vsk, psk) < 0) {
+ if (vsk->transport->init(vsk, psk) < 0) {
sk_free(sk);
return NULL;
}
@@ -641,7 +644,7 @@ static void __vsock_release(struct sock *sk, int level)
/* The release call is supposed to use lock_sock_nested()
* rather than lock_sock(), if a sock lock should be acquired.
*/
- transport->release(vsk);
+ vsk->transport->release(vsk);
/* When "level" is SINGLE_DEPTH_NESTING, use the nested
* version to avoid the warning "possible recursive locking
@@ -670,...
2019 May 10
1
[PATCH v2 2/8] vsock/virtio: free packets during the socket release
...irtio_transport_close(struct vsock_sock *vsk)
>
> void virtio_transport_release(struct vsock_sock *vsk)
> {
> + struct virtio_vsock_sock *vvs = vsk->trans;
> + struct virtio_vsock_buf *buf;
> struct sock *sk = &vsk->sk;
> bool remove_sock = true;
>
> lock_sock(sk);
> if (sk->sk_type == SOCK_STREAM)
> remove_sock = virtio_transport_close(vsk);
> + while (!list_empty(&vvs->rx_queue)) {
> + buf = list_first_entry(&vvs->rx_queue,
> + struct virtio_vsock_buf, list);
Please use list_for_each_entry_safe().
2020 May 29
0
[PATCH] virtio_vsock: Fix race condition in virtio_transport_recv_pkt
...ret_from_fork+0x10/0x18
>
> The race condition as follows:
> Task1 Task2
> ===== =====
> __sock_release virtio_transport_recv_pkt
> __vsock_release vsock_find_bound_socket (found)
> lock_sock_nested
> vsock_remove_sock
> sock_orphan
> sk_set_socket(sk, NULL)
> ...
> release_sock
> lock_sock
> virtio_transport_recv_connecting
> sk->sk_so...
2013 Jan 25
4
[PATCH 0/1] VM Sockets for Linux upstreaming
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
2013 Jan 25
4
[PATCH 0/1] VM Sockets for Linux upstreaming
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
2019 Oct 09
2
[RFC PATCH 07/13] vsock: handle buffer_size sockopts in the core
...uct vsock_transport {
> struct vsock_transport_send_notify_data *);
> int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t,
> struct vsock_transport_send_notify_data *);
> + int (*notify_buffer_size)(struct vsock_sock *, u64 *);
Is ->notify_buffer_size() called under lock_sock(sk)? If yes, please
document it.
> +static void vsock_update_buffer_size(struct vsock_sock *vsk,
> + const struct vsock_transport *transport,
> + u64 val)
> +{
> + if (val > vsk->buffer_max_size)
> + val = vsk->buffer_max_size;
> +
> + if (val <...
2019 Oct 09
2
[RFC PATCH 07/13] vsock: handle buffer_size sockopts in the core
...uct vsock_transport {
> struct vsock_transport_send_notify_data *);
> int (*notify_send_post_enqueue)(struct vsock_sock *, ssize_t,
> struct vsock_transport_send_notify_data *);
> + int (*notify_buffer_size)(struct vsock_sock *, u64 *);
Is ->notify_buffer_size() called under lock_sock(sk)? If yes, please
document it.
> +static void vsock_update_buffer_size(struct vsock_sock *vsk,
> + const struct vsock_transport *transport,
> + u64 val)
> +{
> + if (val > vsk->buffer_max_size)
> + val = vsk->buffer_max_size;
> +
> + if (val <...
2013 Jan 08
7
[PATCH 0/6] VSOCK for Linux upstreaming
* * *
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
2013 Jan 08
7
[PATCH 0/6] VSOCK for Linux upstreaming
* * *
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
2019 Oct 23
33
[PATCH net-next 00/14] vsock: add multi-transports support
This series adds the multi-transports support to vsock, following
this proposal: https://www.spinics.net/lists/netdev/msg575792.html
With the multi-transports support, we can use VSOCK with nested VMs
(using also different hypervisors) loading both guest->host and
host->guest transports at the same time.
Before this series, vmci-transport supported this behavior but only
using VMware
2019 Oct 23
33
[PATCH net-next 00/14] vsock: add multi-transports support
This series adds the multi-transports support to vsock, following
this proposal: https://www.spinics.net/lists/netdev/msg575792.html
With the multi-transports support, we can use VSOCK with nested VMs
(using also different hypervisors) loading both guest->host and
host->guest transports at the same time.
Before this series, vmci-transport supported this behavior but only
using VMware
2019 Sep 27
29
[RFC PATCH 00/13] vsock: add multi-transports support
Hi all,
this series adds the multi-transports support to vsock, following
this proposal:
https://www.spinics.net/lists/netdev/msg575792.html
With the multi-transports support, we can use vsock with nested VMs
(using also different hypervisors) loading both guest->host and
host->guest transports at the same time.
Before this series, vmci-transport supported this behavior but only
using