[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [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
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.