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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel