From: Andrew Morton <akpm@linux-foundation.org>
To: Ian Kent <raven@themaw.net>
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: Thu, 7 Aug 2008 14:10:41 -0700 [thread overview]
Message-ID: <20080807141041.e0d5cccc.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080807114030.4142.76568.stgit@web.messagingengine.com>
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.
> +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?
> +/*
> + * 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.
> + }
> +
> + 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.
next prev parent reply other threads:[~2008-08-07 21:31 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 [this message]
2008-08-08 3:39 ` Ian Kent
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=20080807141041.e0d5cccc.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=autofs@linux.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox