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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 24 Oct 2017, Boris Ostrovsky wrote:
> 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>

Thank you!

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