From: Ram <linuxram@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: dhowells@redhat.com, jamie@shareable.org,
viro@parcelfarce.linux.theplanet.co.uk,
Andrew Morton <akpm@osdl.org>,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fix race in mark_mounts_for_expiry()
Date: Wed, 18 May 2005 13:35:15 -0700 [thread overview]
Message-ID: <1116448514.24560.209.camel@localhost> (raw)
In-Reply-To: <E1DYU4Z-0001U5-00@dorka.pomaz.szeredi.hu>
On Wed, 2005-05-18 at 12:19, Miklos Szeredi wrote:
> > First of all the reason this race exists implies Al Viro may have had
> > assertion in his mind that "All tasks that have access to a namespace
> > has a refcount on that namespace". If that was what he was thinking,
> > than the I would stick with that assertion being true. The overall idea
> > I am thinking off is:
> >
> > 1) have the automounter hold a refcount on any new namespace created
> > the mounts in which the automounter has interest in.
> > 2) have a refcount on the namespace when a new task gains access to
> > a namespace through the file descriptor or any other
> > similar mechanisms and remove the reference
> > once the fd gets closed. (bit tricky to implement)
> >
> > Do you agree with the overall idea?
>
> I don't really understand it.
>
> A reference count usually means, the number of references (pointers)
> to an object. You can sometimes get away with schemes that deviate
> from this in various ways, but it's usually asking for trouble.
Ok. One more attempt to be clear.
All the places where get_namespace() is called currently except
in mark_mounts_for_expiry() are safe because they are called in
places where it is guaranteed that they will not race with
__put_namespace().
For example in clone_namespace(), get_namespace() will not race
because the task that called the clone has a refcount on the
namespace and since that task is currently in the kernel, there is
no chance for the task to go away decrementing the refcount
on that namespace.
But the case where the call to get_namespace() is buggy in
mark_mounts_for_expiry() is because:
it is called in a timer context, and the last process referring
the namespace may just disapper right than.
So what I am proposing is:
in automouter, while the automount takes place in
afs_mntpt_follow_link() increment the refcount of the namespace,
by calling get_namespace(). This call will not race with __put_namespace
because the process that is trying to access the
mountpoint already has a refcount on the namespace and it won't be
able to decrement the refcount currently. agree?
Now later when the automounter tries to unmount the mount
call put_namespace() after unmounting. I mean do it in
mark_mounts_for_expiry(). Also delete the call to get_namespace())
So the race will not happen at all.
Makes sense?
That was the easiest part, but the difficult part is how to call
get_namespace() on a forign namespace in do_loopback()?
thinking about it,
RP
>
> The usage in mark_mounts_for_expiry() deviated from it so much, that
> the result was a subtle race.
>
> Doing some tricky thing like what you propose will just likely
> introduce more subtle problems.
>
> Miklos
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2005-05-18 20:35 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-13 10:44 [PATCH] namespace.c: fix bind mount from foreign namespace Miklos Szeredi
2005-05-13 16:49 ` Ram
2005-05-13 17:06 ` Al Viro
2005-05-13 17:17 ` Miklos Szeredi
2005-05-13 17:25 ` Al Viro
2005-05-13 17:34 ` Miklos Szeredi
2005-05-13 17:29 ` Ram
2005-05-13 18:40 ` Miklos Szeredi
[not found] ` <1116012287.6248.410.camel@localhost>
[not found] ` <E1DWfqJ-0004eP-00@dorka.pomaz.szeredi.hu>
[not found] ` <1116013840.6248.429.camel@localhost>
2005-05-14 6:11 ` Miklos Szeredi
2005-05-16 15:11 ` Ram
2005-05-16 8:44 ` Miklos Szeredi
2005-05-16 8:59 ` Miklos Szeredi
2005-05-16 11:26 ` Jamie Lokier
2005-05-16 13:23 ` Miklos Szeredi
2005-05-16 11:14 ` Jamie Lokier
2005-05-17 3:50 ` Ram
2005-05-16 20:15 ` Miklos Szeredi
2005-05-17 1:28 ` Jamie Lokier
2005-05-17 5:34 ` Miklos Szeredi
[not found] ` <1116360352.24560.85.camel@localhost>
[not found] ` <E1DYI0m-0000K5-00@dorka.pomaz.szeredi.hu>
[not found] ` <1116399887.24560.116.camel@localhost>
[not found] ` <1116400118.24560.119.camel@localhost>
2005-05-18 9:51 ` [PATCH] fix race in mark_mounts_for_expiry() Miklos Szeredi
2005-05-18 10:32 ` David Howells
2005-05-18 10:37 ` Miklos Szeredi
2005-05-18 10:46 ` David Howells
2005-05-18 10:53 ` Miklos Szeredi
2005-05-18 11:07 ` Trond Myklebust
2005-05-18 11:32 ` Miklos Szeredi
2005-05-18 12:50 ` Jamie Lokier
2005-05-18 13:21 ` Miklos Szeredi
2005-05-18 17:34 ` Jamie Lokier
2005-05-18 19:05 ` Miklos Szeredi
2005-05-18 19:52 ` Jamie Lokier
2005-05-19 12:41 ` Miklos Szeredi
2005-05-18 10:59 ` David Howells
2005-05-18 11:14 ` Miklos Szeredi
2005-05-18 11:51 ` David Howells
2005-05-18 12:08 ` Miklos Szeredi
2005-05-18 12:33 ` Miklos Szeredi
2005-05-18 16:53 ` Miklos Szeredi
2005-05-18 18:47 ` Ram
2005-05-18 19:19 ` Miklos Szeredi
2005-05-18 20:35 ` Ram [this message]
2005-05-19 12:52 ` Miklos Szeredi
2005-05-17 18:48 ` [PATCH] namespace.c: fix bind mount from foreign namespace Ram
2005-05-17 0:00 ` Jamie Lokier
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=1116448514.24560.209.camel@localhost \
--to=linuxram@us.ibm.com \
--cc=akpm@osdl.org \
--cc=dhowells@redhat.com \
--cc=jamie@shareable.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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).