Re: [Xen-devel] [PATCH 08/18] xen: Add DOMID_SELF support to rcu_lock_domain_by_id

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.08.12 at 18:38, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> On 08/06/2012 11:50 AM, Jan Beulich wrote:
>>>>> On 06.08.12 at 17:19, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>> On 08/06/2012 11:07 AM, Jan Beulich wrote:
>>>>>>> On 06.08.12 at 16:32, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>>>> Callers that want to prevent use of DOMID_SELF already need to ensure
>>>>> the calling domain does not pass its own domain ID. This removes the
>>>>> need for the caller to manually support DOMID_SELF, which many already
>>>>> do.
>>>>
>>>> I'm not really sure this is correct. At the very least it changes the
>>>> return value of rcu_lock_remote_target_domain_by_id() when
>>>> called with DOMID_SELF (from -ESRCH to -EPERM).
>>>
>>> This series ends up eliminating that function in patch #18, so that
>>> part is taken care of.
>> 
>> But may, in case of problems, then not be fully bi-sectable.
> 
> Do we depend on the exact error return codes in non-error code paths?
> I would think most attempts to bisect would work just fine as the
> function will still be returning an error. I'm not sure ESRCH is
> really the best error to return here anyway: the problem is not that
> a domain with my_own_domid or DOMID_SELF couldn't be found, it's that
> you can't specify that domain for this operation.

I'm not aware of any such dependency, but I also cannot exclude
them (some testsuites tend to check for specific error codes for
example). These adjustments generally claim that they don't
actually change any behavior, yet here they clearly do. Hence
what I'm asking that if that behavioral change is unavoidable, it
should be mentioned in the description, so that whoever runs
across this can be easily aware of this not immediately obvious
effect of the patch without having to analyze it.

Jan


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