mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: autofs@linux.kernel.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
Date: Fri, 08 Aug 2008 11:39:19 +0800	[thread overview]
Message-ID: <1218166760.17093.69.camel@raven.themaw.net> (raw)
In-Reply-To: <20080807141041.e0d5cccc.akpm@linux-foundation.org>


On Thu, 2008-08-07 at 14:10 -0700, Andrew Morton wrote:
> On Thu, 07 Aug 2008 19:40:31 +0800
> Ian Kent <raven@themaw.net> wrote:
> >
> > Subject: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls
> 
> I fixed that spello
> 
> > Patch to add a miscellaneous device to the autofs4 module for routing
> > ioctls. This provides the ability to obtain an ioctl file handle for
> > an autofs mount point that is possibly covered by another mount.
> > 
> > The actual problem with autofs is that it can't reconnect to existing
> > mounts. Immediately one things of just adding the ability to remount
> > autofs file systems would solve it, but alas, that can't work. This is
> > because autofs direct mounts and the implementation of "on demand mount
> > and expire" of nested mount trees have the file system mounted on top of
> > the mount trigger dentry.
> > 
> > To resolve this a miscellaneous device node for routing ioctl commands
> > to these mount points has been implemented in the autofs4 kernel module
> > and a library added to autofs. This provides the ability to open a file
> > descriptor for these over mounted autofs mount points.
> > 
> > Please refer to Documentation/filesystems/autofs4-mount-control.txt for
> > a discussion of the problem, implementation alternatives considered and
> > a description of the interface.
> > 
> >
> > ...
> >
> > +
> > +#define AUTOFS_DEV_IOCTL_SIZE	sizeof(struct autofs_dev_ioctl)
> > +
> > +typedef int (*ioctl_fn)(struct file *,
> > +struct autofs_sb_info *, struct autofs_dev_ioctl *);
> 
> Weird layout, which I fixed.

Auuuhh .. didn't want to do this. I personally like declarations like
this to be on a single line but checkpatch.pl complained about it.

> 
> > +static int check_name(const char *name)
> > +{
> > +	if (!strchr(name, '/'))
> > +		return -EINVAL;
> > +	return 0;
> > +}
> > +
> > +/*
> > + * Check a string doesn't overrun the chunk of
> > + * memory we copied from user land.
> > + */
> > +static int invalid_str(char *str, void *end)
> > +{
> > +	while ((void *) str <= end)
> > +		if (!*str++)
> > +			return 0;
> > +	return -EINVAL;
> > +}
> 
> What is this?  gWwe copy strings in from userspace in 10000 different
> places without needing checks such as this?

Yeah, that's true.
Since you recommend I get rid of I'll do so.

> 
> > +/*
> > + * Check that the user compiled against correct version of autofs
> > + * misc device code.
> > + *
> > + * As well as checking the version compatibility this always copies
> > + * the kernel interface version out.
> > + */
> > +static int check_dev_ioctl_version(int cmd, struct autofs_dev_ioctl *param)
> > +{
> > +	int err = 0;
> > +
> > +	if ((AUTOFS_DEV_IOCTL_VERSION_MAJOR != param->ver_major) ||
> > +	    (AUTOFS_DEV_IOCTL_VERSION_MINOR < param->ver_minor)) {
> > +		AUTOFS_WARN("ioctl control interface version mismatch: "
> > +		     "kernel(%u.%u), user(%u.%u), cmd(%d)",
> > +		     AUTOFS_DEV_IOCTL_VERSION_MAJOR,
> > +		     AUTOFS_DEV_IOCTL_VERSION_MINOR,
> > +		     param->ver_major, param->ver_minor, cmd);
> > +		err = -EINVAL;
> > +	}
> > +
> > +	/* Fill in the kernel version. */
> > +	param->ver_major = AUTOFS_DEV_IOCTL_VERSION_MAJOR;
> > +	param->ver_minor = AUTOFS_DEV_IOCTL_VERSION_MINOR;
> > +
> > +	return err;
> > +}
> > +
> > +/*
> > + * Copy parameter control struct, including a possible path allocated
> > + * at the end of the struct.
> > + */
> > +static struct autofs_dev_ioctl *copy_dev_ioctl(struct autofs_dev_ioctl __user *in)
> > +{
> > +	struct autofs_dev_ioctl tmp, *ads;
> 
> Variables called `tmp' get me upset, but it seems appropriate here.
> 
> > +	if (copy_from_user(&tmp, in, sizeof(tmp)))
> > +		return ERR_PTR(-EFAULT);
> > +
> > +	if (tmp.size < sizeof(tmp))
> > +		return ERR_PTR(-EINVAL);
> > +
> > +	ads = kmalloc(tmp.size, GFP_KERNEL);
> > +	if (!ads)
> > +		return ERR_PTR(-ENOMEM);
> > +
> > +	if (copy_from_user(ads, in, tmp.size)) {
> > +		kfree(ads);
> > +		return ERR_PTR(-EFAULT);
> > +	}
> > +
> > +	return ads;
> > +}
> > +
> > +static inline void free_dev_ioctl(struct autofs_dev_ioctl *param)
> > +{
> > +	kfree(param);
> > +	return;
> > +}
> > +
> > +/*
> > + * Check sanity of parameter control fields and if a path is present
> > + * check that it has a "/" and is terminated.
> > + */
> > +static int validate_dev_ioctl(int cmd, struct autofs_dev_ioctl *param)
> > +{
> > +	int err = -EINVAL;
> > +
> > +	if (check_dev_ioctl_version(cmd, param)) {
> > +		AUTOFS_WARN("invalid device control module version "
> > +		     "supplied for cmd(0x%08x)", cmd);
> > +		goto out;
> 
> check_dev_ioctl_version() carefully returned a -EFOO value, but this
> caller dropped it on the floor.

Will fix.

> 
> > +	}
> > +
> > +	if (param->size > sizeof(*param)) {
> > +		err = check_name(param->path);
> > +		if (err) {
> > +			AUTOFS_WARN("invalid path supplied for cmd(0x%08x)",
> > +				    cmd);
> > +			goto out;
> > +		}
> > +
> > +		err = invalid_str(param->path,
> > +				 (void *) ((size_t) param + param->size));
> > +		if (err) {
> > +			AUTOFS_WARN("invalid path supplied for cmd(0x%08x)",
> > +				    cmd);
> > +			goto out;
> > +		}
> > +	}
> > +
> > +	err = 0;
> > +out:
> > +	return err;
> > +}
> > +
> >
> > ...
> >
> > +static void autofs_dev_ioctl_fd_install(unsigned int fd, struct file *file)
> > +{
> > +	struct files_struct *files = current->files;
> > +	struct fdtable *fdt;
> > +
> > +	spin_lock(&files->file_lock);
> > +	fdt = files_fdtable(files);
> > +	BUG_ON(fdt->fd[fd] != NULL);
> > +	rcu_assign_pointer(fdt->fd[fd], file);
> > +	FD_SET(fd, fdt->close_on_exec);
> > +	spin_unlock(&files->file_lock);
> > +}
> 
> urgh, it's bad to have done a copy-n-paste on fd_install() here.  It
> means that if we go and change the locking in core kernel (quite
> possible) then people won't udpate this code.
> 
> Do we have alternative here?  Can we set close_on_exec outside the lock
> and just call fd_install()?  Probably not.
> 
> Can we export set_close_on_exec() then call that after having called
> fd_install()?  I think so.
> 
> But not this, please.

No problem.
You mentioned this last time as well.

Since there are a couple of possible approaches and I wasn't sure which
way to go I thought I'd post it as is and get feedback then make it a
followup patch.

Could the pthreads user space daemon exec something between fd_install()
and set_close_on_exec()? 

Perhaps there are some other alternative approaches to this.

Suggestions?

Ian



  reply	other threads:[~2008-08-08  3:43 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-07 11:40 [PATCH 1/4] autofs4 - cleanup autofs mount type usage Ian Kent
2008-08-07 11:40 ` [PATCH 2/4] autofs4 - track uid and gid of last mount requester Ian Kent
2008-08-07 20:46   ` Andrew Morton
2008-08-07 22:12     ` Serge E. Hallyn
2008-08-08  3:48       ` Ian Kent
2008-08-08  4:44         ` Ian Kent
2008-08-08 14:58           ` Serge E. Hallyn
2008-08-09  6:05             ` Ian Kent
2008-08-09 13:31               ` Serge E. Hallyn
2008-08-25 18:05                 ` Serge E. Hallyn
2008-08-07 22:15     ` Serge E. Hallyn
2008-08-08  3:13       ` Ian Kent
2008-08-08 15:23         ` Serge E. Hallyn
2008-08-08  3:25     ` Ian Kent
2008-08-08  5:37       ` Ian Kent
2008-08-07 11:40 ` [PATCH 3/4] autofs4 - devicer node ioctl docoumentation Ian Kent
2008-08-09 13:00   ` Christoph Hellwig
2008-08-07 11:40 ` [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Ian Kent
2008-08-07 21:10   ` Andrew Morton
2008-08-08  3:39     ` Ian Kent [this message]
2008-08-08  5:31       ` Andrew Morton
2008-08-08  6:12         ` Ian Kent
2008-08-08  6:33           ` Andrew Morton
2008-08-09 12:59   ` Christoph Hellwig
2008-08-09 15:29     ` Ian Kent
2008-08-09 17:18       ` Christoph Hellwig
2008-08-10  5:20         ` Ian Kent
2008-08-09 12:47 ` [PATCH 1/4] autofs4 - cleanup autofs mount type usage Christoph Hellwig
2008-08-09 15:17   ` Ian Kent
  -- strict thread matches above, loose matches on Subject: below --
2008-02-26  3:21 [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Ian Kent
2008-02-26  3:23 ` [PATCH 4/4] autofs4 - add " Ian Kent
2008-02-28  5:17   ` Andrew Morton
2008-02-28  6:18     ` Ian Kent
2008-02-29 16:24     ` Ian Kent
2008-04-11  7:02       ` Ian Kent
2008-04-12  4:03         ` Andrew Morton
2008-04-14  4:45           ` Ian Kent

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=1218166760.17093.69.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=akpm@linux-foundation.org \
    --cc=autofs@linux.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®