Re: [Xen-devel] [PATCH v5 08/13] xen/pvcalls: implement accept command

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 10/23/2017 07:03 PM, Stefano Stabellini wrote:
> On Tue, 17 Oct 2017, Boris Ostrovsky wrote:
>> On 10/06/2017 08:30 PM, Stefano Stabellini wrote:
>>> +   /*
>>> +    * Backend only supports 1 inflight accept request, will return
>>> +    * errors for the others
>>> +    */
>>> +   if (test_and_set_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
>>> +                        (void *)&map->passive.flags)) {
>>> +           req_id = READ_ONCE(map->passive.inflight_req_id);
>>> +           if (req_id != PVCALLS_INVALID_ID &&
>>> +               READ_ONCE(bedata->rsp[req_id].req_id) == req_id) {
>>
>> READ_ONCE (especially the second one)? I know I may sound fixated on
>> this but I really don't understand how compiler may do anything wrong if
>> straight reads were used.
>>
>> For the first case, I guess, theoretically the compiler may decide to
>> re-fetch map->passive.inflight_req_id. But even if it did, would that be
>> a problem? Both of these READ_ONCE targets are updated below before
>> PVCALLS_FLAG_ACCEPT_INFLIGHT is cleared so there should not be any
>> change between re-fetching, I think. (The only exception is the noblock
>> case, which does WRITE_ONCE that don't understand either)
> READ_ONCE is reasonably cheap: do we really want to have this kind of
> conversation every time we touch this code in the future? Personally, I
> would have used READ/WRITE_ONCE everywhere for inflight_req_id and
> req_id, because it makes the code easier to understand.

I guess it's a matter of opinion. I actually think it's harder to read.

But it doesn't make the code wrong so...

>
> We have already limited their usage, but at least we have followed a set
> of guidelines. Doing further optimizations on this code seems
> unnecessary and prone to confuse the reader.
>
>

>>> +   ret =  create_active(map2, &evtchn);
>>> +   if (ret < 0) {
>>> +           kfree(map2);
>>> +           clear_bit(PVCALLS_FLAG_ACCEPT_INFLIGHT,
>>> +                     (void *)&map->passive.flags);
>>> +           spin_unlock(&bedata->socket_lock);
>>> +           pvcalls_exit();
>>> +           return -ENOMEM;
>> Why not ret?
> yes, good idea.

With that fixed (and extra space removed in 'ret =  create_active(map2,
&evtchn);')

Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>



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