public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <haveblue@us.ibm.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: akpm@linux-foundation.org, hch@infradead.org, serue@us.ibm.com,
	viro@ftp.linux.org.uk, ebiederm@xmission.com, kzak@redhat.com,
	linux-fsdevel@vger.kernel.org, containers@lists.osdl.org,
	util-linux-ng@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [patch 5/9] unprivileged mounts: allow unprivileged bind mounts
Date: Tue, 08 Jan 2008 10:26:26 -0800	[thread overview]
Message-ID: <1199816786.9834.70.camel@localhost> (raw)
In-Reply-To: <20080108113626.895583537@szeredi.hu>

On Tue, 2008-01-08 at 12:35 +0100, Miklos Szeredi wrote:
> @@ -510,10 +533,16 @@ static struct vfsmount *clone_mnt(struct
>                                         int flag)
>  {
>         struct super_block *sb = old->mnt_sb;
> -       struct vfsmount *mnt = alloc_vfsmnt(old->mnt_devname);
> +       struct vfsmount *mnt;
> 
> +       if (flag & CL_SETUSER) {
> +               int err = reserve_user_mount();
> +               if (err)
> +                       return ERR_PTR(err);
> +       }
> +       mnt = alloc_vfsmnt(old->mnt_devname);
>         if (!mnt)
> -               return ERR_PTR(-ENOMEM);
> +               goto alloc_failed;
> 
>         mnt->mnt_flags = old->mnt_flags;
>         atomic_inc(&sb->s_active); 

I think there's a little race here.  We could have several users racing
to get to this point when nr_user_mounts==max_user_mounts-1.  One user
wins the race and gets their mount reserved.  The others get the error
out of reserve_user_mount(), and return.

But, the winner goes on to error out on some condition further down in
clone_mnt() and never actually instantiates the mount.

Do you think this is a problem?

I think just about the one solution is to block new mounters on a
sleepable lock until the race winner actually finishes their mount
operation.  

-- Dave


  parent reply	other threads:[~2008-01-08 18:26 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-08 11:35 [patch 0/9] mount ownership and unprivileged mount syscall (v6) Miklos Szeredi
2008-01-08 11:35 ` [patch 1/9] unprivileged mounts: add user mounts to the kernel Miklos Szeredi
2008-01-08 21:34   ` Pavel Machek
2008-01-08 21:47   ` Pavel Machek
2008-01-14 21:46   ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 2/9] unprivileged mounts: allow unprivileged umount Miklos Szeredi
2008-01-14 21:48   ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 3/9] unprivileged mounts: account user mounts Miklos Szeredi
2008-01-08 18:18   ` Dave Hansen
2008-01-08 19:18     ` Miklos Szeredi
2008-01-14 21:53   ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 4/9] unprivileged mounts: propagate error values from clone_mnt Miklos Szeredi
2008-01-14 22:23   ` Serge E. Hallyn
2008-01-15 10:15     ` Miklos Szeredi
2008-01-08 11:35 ` [patch 5/9] unprivileged mounts: allow unprivileged bind mounts Miklos Szeredi
2008-01-08 18:12   ` Dave Hansen
2008-01-08 19:08     ` Miklos Szeredi
2008-01-08 19:15       ` Dave Hansen
2008-01-08 20:44       ` Szabolcs Szakacsits
2008-01-09 12:45       ` Jan Engelhardt
2008-01-09 13:26         ` Karel Zak
2008-01-09 13:32           ` Miklos Szeredi
2008-01-08 18:26   ` Dave Hansen [this message]
2008-01-08 19:21     ` Miklos Szeredi
2008-01-10  4:47   ` Serge E. Hallyn
2008-01-14 22:42   ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 6/9] unprivileged mounts: allow unprivileged mounts Miklos Szeredi
2008-01-09 11:11   ` Karel Zak
2008-01-09 12:41     ` Miklos Szeredi
2008-01-14 22:58   ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 7/9] unprivileged mounts: allow unprivileged fuse mounts Miklos Szeredi
2008-01-08 21:46   ` Pavel Machek
2008-01-08 22:42     ` Miklos Szeredi
2008-01-08 22:58       ` Pavel Machek
2008-01-09  9:11         ` Miklos Szeredi
2008-01-09 11:33           ` Pavel Machek
2008-01-09 13:16             ` Miklos Szeredi
2008-01-09 13:35               ` Pavel Machek
2008-01-09 13:48                 ` Miklos Szeredi
2008-01-09 14:00                   ` Pavel Machek
2008-01-09 14:14                     ` Miklos Szeredi
2008-01-08 23:56       ` Nigel Cunningham
2008-01-09  8:47         ` Miklos Szeredi
2008-01-09  9:29           ` Nigel Cunningham
2008-01-09 11:12           ` Pavel Machek
2008-01-09  9:19         ` Szabolcs Szakacsits
2008-01-14 23:24   ` Serge E. Hallyn
2008-01-15 10:29     ` Miklos Szeredi
2008-01-15 13:35       ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 8/9] unprivileged mounts: propagation: inherit owner from parent Miklos Szeredi
2008-01-14 23:13   ` Serge E. Hallyn
2008-01-15 10:39     ` Miklos Szeredi
2008-01-15 14:21       ` Serge E. Hallyn
2008-01-15 14:37         ` Miklos Szeredi
2008-01-15 14:59           ` Serge E. Hallyn
2008-01-08 11:35 ` [patch 9/9] unprivileged mounts: add "no submounts" flag Miklos Szeredi
2008-01-14 23:39   ` Serge E. Hallyn
2008-01-15 10:41     ` Miklos Szeredi
2008-01-15 10:53       ` A. C. Censi
2008-01-15 10:58         ` Miklos Szeredi
2008-01-15 13:47           ` Serge E. Hallyn
2008-01-16  9:43             ` Miklos Szeredi

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=1199816786.9834.70.camel@localhost \
    --to=haveblue@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=ebiederm@xmission.com \
    --cc=hch@infradead.org \
    --cc=kzak@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=serue@us.ibm.com \
    --cc=util-linux-ng@vger.kernel.org \
    --cc=viro@ftp.linux.org.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