linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jim Paris <jim@jtan.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-hotplug@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: udev missing events?
Date: Sun, 22 Apr 2012 16:54:01 +0000	[thread overview]
Message-ID: <20120422165401.GA16163@psychosis.jim.sh> (raw)
In-Reply-To: <m14nsbwy1c.fsf@fess.ebiederm.org>

Eric W. Biederman wrote:
> > I'm not using them on purpose, but it's caused by a probing clone() in
> > libvirt's lxcContainerAavilable, followed by a "ip link set lo netns -1"
> > in lxcCheckNetNsSupport.  It can be recreated with just:
> >
> >   #include <unistd.h>
> >   #include <sched.h>
> >   static int dummy(void *argv) { _exit(0); }
> >   main() {
> >           char stack[4096];
> >           clone(dummy, stack+4096, CLONE_NEWNET, NULL);
> >           wait();
> >           system("ip link set lo netns -1");
> >   }
> >
> > Running that program causes "udevadm settle" to stop working due to
> > the filtered events.
> 
> By stop working you mean "udevadm settle" waits because it thinks there
> are unprocessed events but those events are never found, and eventually
> "udevadm settle" times out?

Yeah.

> I'm sorry I don't see the problem.
> 
> I think the most we could do would be to have a per network namespace
> sequence number, but I don't get see the problem with skipping a sequence
> number or two.  Does that cause udev to explode or something?  It
> doesn't sound like udev has problems.
> 
> It does look like we aren't filtering all of the events for the new
> loopback device properly.  We should be filtering the events for
> /sys/devices/virtual/net/lo/queues/rx-0 and friends.  But fixing that
> problem looks like it will only make the gap in sequence numbers
> larger, and if anything make the "udevadm settle" problem worse.
> 
> What precisely is the problem you are seeing?

The specific problem is that virt-manager loses its connection to
libvirt.  Libvirt triggers this situation, and then later executes
"udevadm settle" after some of virt-manager's storage requests.  I
think that happens in one thread, while another libvirt thread then
kills the virt-manager connection for stalling for so long.

I can certainly ask the libvirt guys to add a shorter --timeout
parameter, at the very least, if this isn't considered a bug from the
udev point of view.  But libvirt isn't the only thing that calls
"udevadm settle" -- having to wait 2-3 minutes for each settle call
during an initramfs build or similar would also be annoying.

> Of course in this instance I can't see how the version of libvirt you
> are playing with would ever have worked.  It is relying on features to
> act in a way the simply don't act.

I upgraded libvirt and the kernel lately, so either some of this lxc
probing code in libvirt is new, or maybe my kernel didn't support net
namespaces before.  Libvirt has called udevadm settle for a while,
though.

Thanks,
-jim

  reply	other threads:[~2012-04-22 16:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-22  4:36 udev missing events? Jim Paris
     [not found] ` <ef67a489-94bc-4f97-903d-907ab974537c@email.android.com>
2012-04-22 14:11   ` Jim Paris
2012-04-22 16:07     ` Eric W. Biederman
2012-04-22 16:54       ` Jim Paris [this message]
2012-04-27 13:59 ` Frank Ch. Eigler

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=20120422165401.GA16163@psychosis.jim.sh \
    --to=jim@jtan.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).