From: Matthew Mitchell <matthew@geodev.com>
To: Ian Kent <raven@themaw.net>
Cc: autofs@linux.kernel.org
Subject: Re: "simultaneous" mounts causing weird behavior
Date: Wed, 05 Nov 2003 10:57:43 -0600 [thread overview]
Message-ID: <1068051462.2640.181.camel@aluminum> (raw)
In-Reply-To: <Pine.LNX.4.33.0311050836180.8092-100000@wombat.indigo.net.au>
On Tue, 2003-11-04 at 18:46, Ian Kent wrote:
> The /tmp entry is caused by mount failing to handle overlapping requests.
> Aaron Ogden and I have been there recently with autofs v4.
>
> The overlapping mount problem is likely causing the other problem as well.
> I put some altogether ugly code, which shouldn't work at all, but seems
> to, into autofs v4 to deal with this. In fact I hated it so much, I
> removed it at one point and Aaron was horrified to find everything broken
> again.
Looking at the 4.1.0-beta2 code, I don't see any mutex-looking code in
handle_packet_missing. Isn't that where it should be? Or are you
taking care of it elsewhere? (Or are you allowing the bind mounts to go
through in the odd case where you get past the lstat() test while still
waiting on the lookup_mount to finish?)
My memory of signal gymnastics is fuzzy, but would this work?
(pseudocode)
if (lstat tests fail) {
if (mount is pending) {
/* someone is already trying to mount this path */
spin && retry from start;
} else {
set mount is pending;
f = fork();
if (f == -1) { couldn't fork, error case; }
if (!f) {
/* child */
close fds;
attempt mount;
if (mount succeeds) { exit 0 };
else if (mount fails) { exit 1 };
}
else {
/* parent */
success = wait(f);
unset mount is pending;
}
} else {
/* already there */
}
I just am not seeing how you can properly guarantee that you don't end
up with an unnecessary bind mount without waiting to see if the mount
succeeds or not. I do realize you might not want to wait forever if
there is a problem mounting the device...
Am I missing something?
-m
next prev parent reply other threads:[~2003-11-05 16:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-04 14:42 "simultaneous" mounts causing weird behavior Matthew Mitchell
2003-11-04 17:02 ` H. Peter Anvin
2003-11-04 20:56 ` Matthew Mitchell
2003-11-04 21:03 ` H. Peter Anvin
2003-11-05 0:51 ` Ian Kent
2003-11-05 0:49 ` Ian Kent
2003-11-05 0:46 ` Ian Kent
2003-11-05 16:57 ` Matthew Mitchell [this message]
2003-11-06 3:53 ` Ian Kent
2003-11-10 16:57 ` Matthew Mitchell
2003-11-11 13:33 ` [autofs] " Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2003-11-05 18:45 Ogden, Aaron A.
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=1068051462.2640.181.camel@aluminum \
--to=matthew@geodev.com \
--cc=autofs@linux.kernel.org \
--cc=raven@themaw.net \
/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.