davidlt/kernel-ark
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

xen/pvcalls: fix potential endless loop in pvcalls-front.c

Browse Source 
mutex_trylock() returns 1 if you take the lock and 0 if not. Assume you
take in_mutex on the first try, but you can't take out_mutex. Next times
you call mutex_trylock() in_mutex is going to fail. It's an endless
loop.

Solve the problem by waiting until the global refcount is 1 instead (the
refcount is 1 when the only active pvcalls frontend function is
pvcalls_front_release).

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
This commit is contained in:
Stefano Stabellini 2017-11-15 13:20:21 -08:00 committed by Boris Ostrovsky
parent 24e7f84db0
commit 646d944c2e
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
drivers/xen/pvcalls-front.c
View File

@ -1041,13 +1041,12 @@ int pvcalls_front_release(struct socket *sock)
wake_up_interruptible(&map->active.inflight_conn_req);
/*
* Wait until there are no more waiters on the mutexes.
* We know that no new waiters can be added because sk_send_head
* is set to NULL -- we only need to wait for the existing
* waiters to return.
* We need to make sure that sendmsg/recvmsg on this socket have
* not started before we've cleared sk_send_head here. The
* easiest (though not optimal) way to guarantee this is to see
* that no pvcall (other than us) is in progress.
*/
while (!mutex_trylock(&map->active.in_mutex) ||
!mutex_trylock(&map->active.out_mutex))
while (atomic_read(&pvcalls_refcount) > 1)
cpu_relax();
pvcalls_front_free_map(bedata, map);