From: "Roger Pau Monné" <roger.pau@citrix.com>
To: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Race condition on device add hanling in xl devd
Date: Mon, 17 Dec 2018 10:40:59 +0100 [thread overview]
Message-ID: <20181217094059.rvoptuzp6im52jyp@mac> (raw)
In-Reply-To: <20181216014743.GA5040@mail-itl>
On Sun, Dec 16, 2018 at 02:47:43AM +0100, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I've found a race condition with handling new devices in driver domain.
> xl devd calls hotplug script when new device is detected in xenstore. At
> the same time, asynchronously, kernel create actual backend device (vif
> in my case). In rare circumstances (especially under high system load)
> it may happen that hotplug script is executed before kernel create the
> device, and the hotplug script fails. When hotplug scripts were called
> by udev, that race didn't existed as udev was informed about the device
> by the kernel.
> I'm not sure if the race applies to backend in dom0 - haven't happened
> to me, but that doesn't really prove anything.
>
> Can you remind me why in driver domain xl devd is used now, instead of
> udev?
udev is Linux specific, while the current code works for Linux, NetBSD
and FreeBSD.
>
> A workaround could be implemented in hotplug script itself - wait for
> the device there. I'm not sure how proper solution could look like. Some
> synchronization between xl devd and the kernel (like xl devd monitoring
> uevents)?
There's already a synchronization mechanism, libxl waits for the
backend to switch to state 2 (XenbusStateInitWait) before running the
hotplug scripts [0].
Maybe netback sets state 2 before creating the backend device?
It looks to me like the backend needs to be sure everything needed by
the hotplug script is in place before switching to state 2.
Thanks, Roger.
[0] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_device.c;h=a4a8e9ac323e9d3804d36573181c74b7b5c63bc6;hb=refs/heads/staging#l934
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-12-17 9:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-16 1:47 Race condition on device add hanling in xl devd Marek Marczykowski-Górecki
2018-12-17 9:40 ` Roger Pau Monné [this message]
2018-12-17 12:00 ` Marek Marczykowski-Górecki
2018-12-17 12:18 ` Roger Pau Monné
2018-12-17 12:23 ` Marek Marczykowski-Górecki
2018-12-17 13:05 ` Roger Pau Monné
2018-12-17 13:11 ` Paul Durrant
2018-12-17 14:32 ` Roger Pau Monné
2018-12-17 14:42 ` Paul Durrant
2018-12-17 16:09 ` Roger Pau Monné
2019-02-24 23:14 ` Marek Marczykowski-Górecki
2019-02-28 10:08 ` Roger Pau Monné
2019-02-28 12:38 ` Marek Marczykowski-Górecki
2018-12-17 13:23 ` Marek Marczykowski-Górecki
2018-12-17 14:44 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181217094059.rvoptuzp6im52jyp@mac \
--to=roger.pau@citrix.com \
--cc=marmarek@invisiblethingslab.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.