From: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Warren Togami <wtogami-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: initramfs <initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Race condition? /tmp/net.ifaces and pre-pivot
Date: Fri, 24 Jul 2009 09:21:07 +0200 [thread overview]
Message-ID: <4A6960E3.4080807@redhat.com> (raw)
In-Reply-To: <4A6928EE.6090707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 07/24/2009 05:22 AM, Warren Togami wrote:
> On 07/23/2009 05:37 PM, Warren Togami wrote:
>> I am running into an odd issue that is supposedto be impossible.
>>
>> pre-pivot/20write-ifcfg.sh is often being run but fails to write
>> net.*.ifcfg files because /tmp/net.ifaces does not exist at that moment.
>> The mount was otherwise successful, and rdbreak before switch_root sees
>> that /tmp/net.ifaces exists.
>>
>> With plain "root=dhcp" with a NFS rootfs, it seems to never happen.
>> However with "root=dhcp bridge", perhaps 25-75% of the time it is
>> failing to write ifcfg files.
>>
>> Some kind of race going on? An inspection of the code seems to me that
>> /tmp/net.ifaces should have already been created prior to pre-pivot?
>>
>
> <dillow> warren: if you don't have any ip= lines on the command line,
> /tmp/net.ifaces gets created by netroot after the handler successfully
> completes
> <dillow> warren: I think that races with the check loop in init
> <dillow> warren: single processor box?
> <dillow> warren: it looks like you could get scheduled away from netroot
> and the init command loop could notice that root is mounted and make it
> to the pre-pivot hook during a single quantum
> <dillow> warren: as a test, you could move the line '[ ! -f
> /tmp/net.ifaces ] && echo $netif > /tmp/net.ifaces' in netroot in front
> of the handler call
> <dillow> warren: that should work around your issue. I don't think it is
> a long term fix, though -- the multiple NIC case would need some work to
> be clean
> <dillow> warren: this would only affect NFS, as the other devices would
> create /dev/root and exit that way to the mount loop
> <dillow> so they wouldn't sail through the mount loop due to the
> existence of $NEWROOT/proc
> <warren> dillow: single processor qemu VM
> <warren> dillow: so this race was happening before, only we didn't
> notice it since we weren't relying on anything
> <warren> dillow: any suggestions of a substitution that wont break dash?
> <dillow> warren: I think it got introduced with the initqueue stuff or a
> combination of that and changing the loops
>
> Harald, any ideas?
if you rely on a udev event to complete the solution is to place a
udevadm settle
before doing anything
--
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
next prev parent reply other threads:[~2009-07-24 7:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 21:37 Race condition? /tmp/net.ifaces and pre-pivot Warren Togami
[not found] ` <4A68D828.40506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-24 3:22 ` Warren Togami
[not found] ` <4A6928EE.6090707-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2009-07-24 7:21 ` Harald Hoyer [this message]
2009-08-07 7:35 ` Seewer Philippe
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=4A6960E3.4080807@redhat.com \
--to=harald-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=initramfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=wtogami-H+wXaHxf7aLQT0dZR+AlfA@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.