* locking issue in vhost_net_set_backend
@ 2010-03-16 13:58 Jiri Slaby
2010-03-16 14:01 ` Jiri Slaby
2010-03-16 16:11 ` Jeff Dike
0 siblings, 2 replies; 4+ messages in thread
From: Jiri Slaby @ 2010-03-16 13:58 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, LKML
Hi,
Stanse found a locking problem in the following function:
static long vhost_net_set_backend(struct vhost_net *n, unsigned index,
int fd)
{
struct socket *sock, *oldsock;
struct vhost_virtqueue *vq;
int r;
mutex_lock(&n->dev.mutex);
r = vhost_dev_check_owner(&n->dev);
if (r)
goto err;
if (index >= VHOST_NET_VQ_MAX) {
r = -ENOBUFS;
goto err;
}
vq = n->vqs + index;
mutex_lock(&vq->mutex); <--- locked
/* Verify that ring has been setup correctly. */
if (!vhost_vq_access_ok(vq)) {
r = -EFAULT;
goto err; <--- not unlocked
}
sock = get_socket(fd);
if (IS_ERR(sock)) {
r = PTR_ERR(sock);
goto err; <--- not unlocked
}
/* start polling new socket */
oldsock = vq->private_data;
if (sock == oldsock)
goto done; <--- not unlocked
vhost_net_disable_vq(n, vq);
rcu_assign_pointer(vq->private_data, sock);
vhost_net_enable_vq(n, vq);
mutex_unlock(&vq->mutex);
done:
if (oldsock) {
vhost_net_flush_vq(n, index);
fput(oldsock->file);
}
err:
mutex_unlock(&n->dev.mutex);
return r;
}
I don't see how the lock is unlocked on the error paths and as it is not
on none of the them maybe I'm missing something?
thanks,
--
js
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: locking issue in vhost_net_set_backend
2010-03-16 13:58 locking issue in vhost_net_set_backend Jiri Slaby
@ 2010-03-16 14:01 ` Jiri Slaby
2010-03-16 14:48 ` Michael S. Tsirkin
2010-03-16 16:11 ` Jeff Dike
1 sibling, 1 reply; 4+ messages in thread
From: Jiri Slaby @ 2010-03-16 14:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, LKML
On 03/16/2010 02:58 PM, Jiri Slaby wrote:
> I don't see how the lock is unlocked on the error paths and as it is not
> on none of the them maybe I'm missing something?
And there is one more issue in vhost_set_vring, several returns from
VHOST_SET_VRING_KICK, VHOST_SET_VRING_CALL, VHOST_SET_VRING_ERR with the
vq->mutex held.
--
js
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: locking issue in vhost_net_set_backend
2010-03-16 14:01 ` Jiri Slaby
@ 2010-03-16 14:48 ` Michael S. Tsirkin
0 siblings, 0 replies; 4+ messages in thread
From: Michael S. Tsirkin @ 2010-03-16 14:48 UTC (permalink / raw)
To: Jiri Slaby; +Cc: netdev, LKML
On Tue, Mar 16, 2010 at 03:01:51PM +0100, Jiri Slaby wrote:
> On 03/16/2010 02:58 PM, Jiri Slaby wrote:
>> I don't see how the lock is unlocked on the error paths and as it is not
>> on none of the them maybe I'm missing something?
>
> And there is one more issue in vhost_set_vring, several returns from
> VHOST_SET_VRING_KICK, VHOST_SET_VRING_CALL, VHOST_SET_VRING_ERR with the
> vq->mutex held.
Thanks!
I have patches for these that I'll push out shortly.
> --
> js
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: locking issue in vhost_net_set_backend
2010-03-16 13:58 locking issue in vhost_net_set_backend Jiri Slaby
2010-03-16 14:01 ` Jiri Slaby
@ 2010-03-16 16:11 ` Jeff Dike
1 sibling, 0 replies; 4+ messages in thread
From: Jeff Dike @ 2010-03-16 16:11 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Michael S. Tsirkin, netdev, LKML
On Tue, Mar 16, 2010 at 02:58:23PM +0100, Jiri Slaby wrote:
> I don't see how the lock is unlocked on the error paths and as it is not
> on none of the them maybe I'm missing something?
I sent Michael a patch for this a couple of weeks ago.
Jeff
--
Work email - jdike at linux dot intel dot com
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-03-16 16:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-16 13:58 locking issue in vhost_net_set_backend Jiri Slaby
2010-03-16 14:01 ` Jiri Slaby
2010-03-16 14:48 ` Michael S. Tsirkin
2010-03-16 16:11 ` Jeff Dike
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).