do_domctl and EAGAIN

do_domctl and EAGAIN

[Juergen Gross]

Hi,

certain domctl hypercalls (and possibly others as well) might fail with errno
EAGAIN. This case seems to be tested only in very few places, e.g. in
xc_domain_destroy.

Is there any reason why this case isn't handled in do_domctl?
Shouldn't EINTR be handled as well?

The other solution would be to have two versions of do_domctl, one of them
looping in case of EAGAIN or EINTR.

I suspect this lack of errno-testing could lead to very sporadic failures...


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: do_domctl and EAGAIN

[Keir Fraser]

Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.

 -- Keir

On 07/04/2009 08:04, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> Hi,
> 
> certain domctl hypercalls (and possibly others as well) might fail with errno
> EAGAIN. This case seems to be tested only in very few places, e.g. in
> xc_domain_destroy.
> 
> Is there any reason why this case isn't handled in do_domctl?
> Shouldn't EINTR be handled as well?
> 
> The other solution would be to have two versions of do_domctl, one of them
> looping in case of EAGAIN or EINTR.
> 
> I suspect this lack of errno-testing could lead to very sporadic failures...
> 
> 
> Juergen

Re: do_domctl and EAGAIN

[Juergen Gross]

Keir Fraser wrote:
> Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.

do_domctl uses ioctl.
ioctl can return EINTR if a signal is caught.

Other hypercalls do return EAGAIN.

Juergen

> 
>  -- Keir
> 
> On 07/04/2009 08:04, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
>> Hi,
>>
>> certain domctl hypercalls (and possibly others as well) might fail with errno
>> EAGAIN. This case seems to be tested only in very few places, e.g. in
>> xc_domain_destroy.
>>
>> Is there any reason why this case isn't handled in do_domctl?
>> Shouldn't EINTR be handled as well?
>>
>> The other solution would be to have two versions of do_domctl, one of them
>> looping in case of EAGAIN or EINTR.
>>
>> I suspect this lack of errno-testing could lead to very sporadic failures...

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: do_domctl and EAGAIN

[Keir Fraser]

On 07/04/2009 08:41, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> Keir Fraser wrote:
>> Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.
> 
> do_domctl uses ioctl.
> ioctl can return EINTR if a signal is caught.
>
> Other hypercalls do return EAGAIN.

Which ones?

 -- Keir

Re: do_domctl and EAGAIN

[Keir Fraser]

On 07/04/2009 08:41, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> Keir Fraser wrote:
>> Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.
> 
> do_domctl uses ioctl.
> ioctl can return EINTR if a signal is caught.

Our privcmd hypercall ioctl() is non-blocking and hence I don't think can
return EINTR. In fact ioctl() is used in loads of places throughout our
toolstack and in qemu, and I don't think EINTR is checked by any caller, nor
is EINTR mentioned in the ioctl man page.

 -- Keir

Re: do_domctl and EAGAIN

[Juergen Gross]

Keir Fraser wrote:
> On 07/04/2009 08:41, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
>> Keir Fraser wrote:
>>> Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.
>> do_domctl uses ioctl.
>> ioctl can return EINTR if a signal is caught.
> 
> Our privcmd hypercall ioctl() is non-blocking and hence I don't think can
> return EINTR. In fact ioctl() is used in loads of places throughout our
> toolstack and in qemu, and I don't think EINTR is checked by any caller, nor
> is EINTR mentioned in the ioctl man page.

On my system the ioctl man page does mention it:

ERRORS
       Under the following general conditions, ioctl() shall fail if:

       EBADF  The fildes argument is not a valid open file descriptor.

       EINTR  A signal was caught during the ioctl() operation.


In the non-blocking case this might be irrelevant. Are you sure this is no
issue in any case?


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: do_domctl and EAGAIN

[Juergen Gross]

Keir Fraser wrote:
> On 07/04/2009 08:41, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:
> 
>> Keir Fraser wrote:
>>> Only DOMCTL_destroydomain returns EAGAIN. No domctl returns EINTR.
>> do_domctl uses ioctl.
>> ioctl can return EINTR if a signal is caught.
>>
>> Other hypercalls do return EAGAIN.
> 
> Which ones?

XEN_SYSCTL_pm_op (this one is tested by caller)
xenstore calls (tested by caller)
mmuext_op (NOT always checked by caller)


Juergen

-- 
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions               e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
D-81739 Muenchen                 Company details: ts.fujitsu.com/imprint.html

Re: do_domctl and EAGAIN

[Keir Fraser]

On 07/04/2009 09:36, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

> XEN_SYSCTL_pm_op (this one is tested by caller)

Yes, and indeed has to be checked by the caller, rather than hidden, since
it's an odd EAGAIN-with-side-effects.

> xenstore calls (tested by caller)

Not really hypercalls as such.

> mmuext_op (NOT always checked by caller)

Nah, that doesn't return EINTR. EAGAIN/EINTR is used a lot in Xen's mm.c,
but shouldn't leak into hypercall return values. That'd be a
non-backward-compatible bug.

 -- Keir

Re: do_domctl and EAGAIN

[Keir Fraser]

On 07/04/2009 09:19, "Juergen Gross" <juergen.gross@ts.fujitsu.com> wrote:

>> Our privcmd hypercall ioctl() is non-blocking and hence I don't think can
>> return EINTR. In fact ioctl() is used in loads of places throughout our
>> toolstack and in qemu, and I don't think EINTR is checked by any caller, nor
>> is EINTR mentioned in the ioctl man page.
> 
> In the non-blocking case this might be irrelevant. Are you sure this is no
> issue in any case?

Yes, our ioctls are all non-blocking (or at least, they don't interruptibly
block -- they might block due to paging, memory allocations, and the like,
but that's never visible to userspace).

 -- Keir