[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71b5ef48-c3d4-3e46-cc2c-c1a64a4de71d@oracle.com>
Date: Fri, 22 Sep 2017 18:48:42 -0400
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Stefano Stabellini <sstabellini@...nel.org>,
xen-devel@...ts.xen.org
Cc: linux-kernel@...r.kernel.org, jgross@...e.com,
Stefano Stabellini <stefano@...reto.com>
Subject: Re: [PATCH v4 12/13] xen/pvcalls: implement release command
>> + */
>> + map->active.ring->in_error = -EBADF;
>> + 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.
>> + */
>> + while (!mutex_trylock(&map->active.in_mutex) ||
>> + !mutex_trylock(&map->active.out_mutex))
>> + cpu_relax();
>
> What if you manage to grab the locks before waiters get to run? for
> example, in recvmsg:
>
> while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
> wait_event_interruptible(map->active.inflight_conn_req,
> pvcalls_front_read_todo(map));
> }
> ret = __read_ring(map->active.ring, &map->active.data,
> &msg->msg_iter, len, flags);
>
> map will be freed (by pvcalls_front_free_map() below) before __read_ring
> is passed the just-freed ring.
Actually, since you don't drop the locks I am not sure recvmsg side will
even get there.
-boris
>
>
>> +
>> + pvcalls_front_free_map(bedata, map);
>> + kfree(map);
>
> -boris
>
>
Powered by blists - more mailing lists