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

Re: [Xen-devel] [PATCH 3/4] VT-d/qinval: clean up error handling

  • To: Jan Beulich <JBeulich@xxxxxxxx>
  • From: "Zhang, Yang Z" <yang.z.zhang@xxxxxxxxx>
  • Date: Fri, 20 Jun 2014 11:30:12 +0000
  • Accept-language: en-US
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Delivery-date: Fri, 20 Jun 2014 11:30:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xen.org>
  • Thread-index: AQHPiWFa0Yj9eKHDk0uOrlL1qNhydJt5RdOg///TnQCAAMlRQA==
  • Thread-topic: [PATCH 3/4] VT-d/qinval: clean up error handling

Jan Beulich wrote on 2014-06-20:
>>>> On 20.06.14 at 04:12, <yang.z.zhang@xxxxxxxxx> wrote:
>> Jan Beulich wrote on 2014-06-16:
>>> - neither qinval_update_qtail() nor qinval_next_index() can fail: make
>>>   the former return "void", and drop caller error checks for the latter
>>>   (all of which would otherwise return with a spin lock still held)
>> I saw lots of other functions are never fail too, e.g.,
>> gen_cc_inv_dsc(), gen_iotlb_inv_dsc(), gen_wait_dsc() and others.
>> Any reason only changes the above two and keeps others?
> I wanted to leave the gen_* function family aside for the moment, as
> they're having more problems than just their return types: Their use
> of qinval_lock is completely bogus, as in all cases the callers already hold 
> iommu->register_lock.
> The former lock therefore could go away altogether. And then it
> becomes rather questionable whether these single-use functions really
> need to be separate ones or wouldn't better be integrated into their callers.

I see. 

For this patch:

Acked-by: Yang Zhang <yang.z.zhang@xxxxxxxxx>

> Jan

Best regards,

Xen-devel mailing list



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