All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare-l3A5Bk7waGM@public.gmane.org>
To: Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>
Cc: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: initqueue
Date: Thu, 02 Jul 2009 14:51:59 +0200	[thread overview]
Message-ID: <4A4CAD6F.6080201@suse.de> (raw)
In-Reply-To: <4A4CAA92.9000401-omB+W0Dpw2o@public.gmane.org>

Hi all,

Seewer Philippe wrote:
> Harald Hoyer wrote:
[ .. ]
> 
> Please don't do that. That way we actually loose the benefit of doing as
> much in parallel as possible. Instead please consider the patch below.
> I've been fiddling with this for a few weeks now. It basically replaces
> the current "wait-for-root" loop with a loop that queries the udev-queue
> and only exits if either root is available or all udev events have been
> processed.
> 
D'accord.

> It works, except if a udev event takes longer than the default 180s as is
> the case with an unpatches cryptsetup and/or if we do user-interaction
> from within udev which we shouldn't do anyway.
> 
> Thank you,
> Philippe
> 
> diff --git a/modules.d/99base/init b/modules.d/99base/init
> index 27c4dad..e14dc20 100755
> --- a/modules.d/99base/init
> +++ b/modules.d/99base/init
> @@ -46,6 +46,11 @@ mkdir /dev/shm
> mkdir /dev/pts
> mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts >/dev/null 2>&1
> 
> +# Set version specific udevadm options
> +UDEVVERSION=$(udevadm --version)
> +UDEVADMOPTS=""
> +[ $UDEVVERSION -ge 143 ] && UDEVADMOPTS="--exit-if-exists=$NEWROOT/proc"
> +
> # run scriptlets to parse the command line
> getarg 'rdbreak=cmdline' && emergency_shell
> source_all cmdline
> @@ -76,7 +81,7 @@ source_all pre-trigger
> 
> # then the rest
> udevadm trigger $udevtriggeropts  >/dev/null 2>&1
> -udevadm settle --timeout=30 >/dev/null 2>&1
> +udevadm settle --timeout=30 $UDEVADMOPTS >/dev/null 2>&1
> 
> # pre-mount happens before we try to mount the root filesystem,
> # and happens once.
> @@ -86,18 +91,23 @@ getarg 'rdbreak=mount' && emergency_shell
> 
> # mount scripts actually try to mount the root filesystem, and may
> # be sourced any number of times. As soon as one suceeds, no more are
> sourced.
> -i=0
> -while :; do
> -    [ -d "$NEWROOT/proc" ] && break;
> -
> +while [ ! -d "$NEWROOT/proc" ] ; do
>     for f in /mount/*.sh; do
>        [ -x "$f" ] && . "$f";
>        [ "$ROOTFS_MOUNTED" ] && break;
>     done
> 
> -    sleep 0.5
> -    i=$(($i+1))
> -    { flock -s 9 ; [ $i -gt 20 ] && emergency_shell; } 9>/.console_lock
> +    # If the queue was empty and mount scripts failed as well, bail out
> +    [ -n "$EMPTYQUEUE" ] && break;
> +
> +    # Give udev events some time before we try anything. If the queue
> +    # is empty, give mount-scripts another chance to get the root
> +    udevadm settle --timeout 5 $UDEVADMOPTS && EMPTYQUEUE="1"
> +done
> +
> +# udev queue is empty, no root? Let the user figure this out
> +while [ ! -d "$NEWROOT/proc" ] ; do
> +    { flock -s 9 ; emergency_shell; } 9>/.console_lock
> done
> 
> # pre pivot scripts are sourced just before we switch over to the new root.
> 
Ah, if it were so easy.

This approach work perfectly for any device which does synchronous scanning.

For a device doing asynchronous scan you're out of luck here as the device
might start spitting out udev events at any time, even after the udev
queue is empty.

EG usb or qla2xxx have a habit of doing so. So either you implement
checks for each device (-type) which detects if the device is still
scanning or you indeed just wait until the device appears.

There actually is no problem with the latter, as all the design
goal here is to have _every_ device initialization in the background
/ asynchronously by udev.
So in foreground we indeed just have to wait for the device node
to appear. Even the udev queue check is pointless here; either
we have a device node, in which case we can continue regardless
of how many events are still in the udev queue;
or we don't have one, in which case it quite irrelevant if
udev has still events to process or not.
Think of multipath taking it's time to setup the multipath
environment; it's being notified by udev via a socket, so
udev is done with the event. But the device node is still
not present or not useable as multipath is still setting
up the topology.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2009-07-02 12:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-02 10:11 initqueue Harald Hoyer
     [not found] ` <4A4C87DF.10904-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 12:39   ` initqueue Seewer Philippe
     [not found]     ` <4A4CAA92.9000401-omB+W0Dpw2o@public.gmane.org>
2009-07-02 12:51       ` Hannes Reinecke [this message]
     [not found]         ` <4A4CAD6F.6080201-l3A5Bk7waGM@public.gmane.org>
2009-07-02 13:45           ` initqueue Seewer Philippe
2009-07-02 12:52       ` initqueue Harald Hoyer
     [not found]         ` <4A4CAD9B.10503-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 13:08           ` initqueue Seewer Philippe
     [not found]             ` <4A4CB136.6000109-omB+W0Dpw2o@public.gmane.org>
2009-07-02 13:12               ` initqueue Harald Hoyer
     [not found]                 ` <4A4CB241.8080406-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-02 13:20                   ` initqueue Seewer Philippe
     [not found]                     ` <4A4CB434.1010001-omB+W0Dpw2o@public.gmane.org>
2009-07-02 14:10                       ` initqueue Harald Hoyer
     [not found]                         ` <4A4CBFEE.2020500-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-03  0:04                           ` initqueue Victor Lowther
     [not found]                             ` <1246579473.3339.96.camel-76q0VzFBGGr21HsLBtNmTckMGDeJXHgy@public.gmane.org>
2009-07-03  8:06                               ` initqueue Harald Hoyer
     [not found]                                 ` <4A4DBBF7.8010501-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-03  9:10                                   ` initqueue Daniel Drake

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=4A4CAD6F.6080201@suse.de \
    --to=hare-l3a5bk7wagm@public.gmane.org \
    --cc=harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=philippe.seewer-omB+W0Dpw2o@public.gmane.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.