Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 646d944c authored by Stefano Stabellini's avatar Stefano Stabellini Committed by Boris Ostrovsky
Browse files

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



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: default avatarDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: default avatarStefano Stabellini <sstabellini@kernel.org>
Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
parent 24e7f84d

drivers/xen/pvcalls-front.c

+5 −6
Original line number Diff line number Diff line
@@ -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);