LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net> To: Andrew Morton <akpm@linux-foundation.org> Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>, autofs mailing list <autofs@linux.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, Christoph Hellwig <hch@lst.de>, Al Viro <viro@zeniv.linux.org.uk> Subject: Re: [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Date: Sat, 01 Mar 2008 01:24:10 +0900 [thread overview] Message-ID: <1204302250.19890.22.camel@raven.themaw.net> (raw) In-Reply-To: <20080227211723.d5d27c09.akpm@linux-foundation.org> On Wed, 2008-02-27 at 21:17 -0800, Andrew Morton wrote: > On Tue, 26 Feb 2008 12:23:55 +0900 (WST) Ian Kent <raven@themaw.net> wrote: > > > Hi Andrew, > > > > Patch to add miscellaneous device to autofs4 module for > > ioctls. > > Could you please document the new kernel interface which you're proposing? > In Docmentation/ or in the changelog? > > We seem to be passing some string into a miscdevice ioctl and getting some > results back. Be aware that this won't be a terribly popular proposal, so > I'd suggest that you fully describe the problem which it's trying to solve, > and how it solves it, and why the various alternatives (sysfs, netlink, > mount options, etc) were judged unsuitable. It appears I could do this with the generic netlink subsystem. I'll have a go at it. > > > > > > ... > > > > +/* > > + * Get the autofs super block info struct from the file opened on > > + * the autofs mount point. > > + */ > > +static struct autofs_sb_info *autofs_dev_ioctl_sbi(struct file *f) > > +{ > > + struct autofs_sb_info *sbi = NULL; > > + struct inode *inode; > > + > > + if (f) { > > `f' cannot be NULL here. And, will still be in the netlink implementation and will still return an appropriate error. > > > + inode = f->f_path.dentry->d_inode; > > + sbi = autofs4_sbi(inode->i_sb); > > + } > > + > > + return sbi; > > +} > > + > > +/* Return autofs module protocol version */ > > +static inline int autofs_dev_ioctl_protover(struct file *fp, > > + struct autofs_sb_info *sbi, > > + struct autofs_dev_ioctl *param) > > +{ > > + param->arg1 = sbi->version; > > + return 0; > > +} > > + > > +/* Return autofs module protocol sub version */ > > +static inline int autofs_dev_ioctl_protosubver(struct file *fp, > > + struct autofs_sb_info *sbi, > > + struct autofs_dev_ioctl *param) > > +{ > > + param->arg1 = sbi->sub_version; > > + return 0; > > +} > > Don't bother inlining things - the compiler will do it. > > > +/* > > + * Walk down the mount stack looking for an autofs mount that > > + * has the requested device number (aka. new_encode_dev(sb->s_dev). > > + */ > > +static int autofs_dev_ioctl_find_super(struct nameidata *nd, dev_t devno) > > +{ > > + struct dentry *dentry; > > + struct inode *inode; > > + struct super_block *sb; > > + dev_t s_dev; > > + unsigned int err; > > + > > + err = -ENOENT; > > + > > + /* Lookup the dentry name at the base of our mount point */ > > + dentry = d_lookup(nd->path.dentry, &nd->last); > > + if (!dentry) > > + goto out; > > + > > + dput(nd->path.dentry); > > + nd->path.dentry = dentry; > > + > > + /* And follow the mount stack looking for our autofs mount */ > > + while (1) { > > + inode = nd->path.dentry->d_inode; > > + if (!inode) > > + continue; > > + > > + sb = inode->i_sb; > > + s_dev = new_encode_dev(sb->s_dev); > > + if (devno == s_dev) { > > + if (sb->s_magic == AUTOFS_SUPER_MAGIC) { > > + err = 0; > > + break; > > + } > > + } > > + > > + if (!follow_down(&nd->path.mnt, &nd->path.dentry)) > > + goto out; > > + } > > + > > +out: > > + return err; > > +} > > hm. possibly-interested parties cc'ed. Agian, will still be in the netlink implementation. Speak up if it's not right. > > > +/* > > + * Install the file opened for autofs mount point control functions > > + * and set close on exec. > > + */ > > +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); > > +} > > That's fd_install() plus an add-on. It's not autofs-specific. Should be > in fs/open.c, methinks? OK, I'll do that if someone speaks up. > > > > > ... > > > > +/* Close file descriptor allocated above (user can also use close(2)). */ > > +static inline int autofs_dev_ioctl_closemount(struct file *fp, > > + struct autofs_sb_info *sbi, > > + struct autofs_dev_ioctl *param) > > +{ > > + return sys_close(param->ioctlfd); > > +} > > hm. Also, still in the netlink implementation, with a comment a bit more informative than the one above. > > > > > ... > > > > +/* > > + * Set the pipe fd for kernel communication to the daemon. > > + * > > + * Normally this is set at mount using an option but if we > > + * are reconnecting to a busy mount then we need to use this > > + * to tell the autofs mount about the new kernel pipe fd. In > > + * order to protect mounts against incorrectly setting the > > + * pipefd we also require that the autofs mount be catatonic. > > + * > > + * This also sets the process group id used to identify the > > + * controlling process (eg. the owning automount(8) daemon). > > + */ > > +static int autofs_dev_ioctl_setpipefd(struct file *fp, > > + struct autofs_sb_info *sbi, > > + struct autofs_dev_ioctl *param) > > +{ > > + int pipefd; > > + int err = 0; > > + > > + if (param->arg1 == -1) > > + return -EINVAL; > > + > > + pipefd = param->arg1; > > + > > + if (!sbi->catatonic) > > + return -EBUSY; > > + else { > > + struct file *pipe = fget(pipefd); > > + if (!pipe->f_op || !pipe->f_op->write) { > > + err = -EPIPE; > > + fput(pipe); > > + goto out; > > + } > > + sbi->oz_pgrp = task_pgrp_nr(current); > > + sbi->pipefd = pipefd; > > + sbi->pipe = pipe; > > + sbi->catatonic = 0; > > + } > > +out: > > + return err; > > +} > > We have a new filesystem type, a misc device with a mysterious ioctl, > hand-rolled mountpoint chasing, hand-rolled fd installation and now pipes > too. That's not going to change. There's nothing new here at all. This is merely an re-implementation of the existing autofs ioctl interface with two additional calls, nothing more. > > This is a complex interface. We really need to see the overall > problem > statement, design and interface description, please. I'll add a document describing this, as previously agreed. snip ... > > + > > +/* > > + * Call repeatedly until it returns -EAGAIN, meaning there's nothing > > + * more that can be done. > > + */ > > +static int autofs_dev_ioctl_expire(struct file *fp, > > + struct autofs_sb_info *sbi, > > + struct autofs_dev_ioctl *param) > > +{ > > + struct dentry *dentry; > > + struct vfsmount *mnt; > > + int err = -EAGAIN; > > + int when; > > + > > + when = param->arg1; > > + mnt = fp->f_path.mnt; > > + > > + if (sbi->type & AUTOFS_TYPE_DIRECT) > > + dentry = autofs4_expire_direct(sbi->sb, mnt, sbi, when); > > + else > > + dentry = autofs4_expire_indirect(sbi->sb, mnt, sbi, when); > > + > > + if (dentry) { > > + struct autofs_info *ino = autofs4_dentry_ino(dentry); > > + > > + /* > > + * This is synchronous because it makes the daemon a > > + * little easier > > + */ > > + ino->flags |= AUTOFS_INF_EXPIRING; > > + err = autofs4_wait(sbi, dentry, NFY_EXPIRE); > > + ino->flags &= ~AUTOFS_INF_EXPIRING; > > Are there races around the modification of ino->flags here? I haven't had any problems with this over time. I've always thought that this was because the flag is only set during an expire, of which there is only ever one going for a given mount, is synchronous, and mount requests only read the flag to check status. But I could be wrong since it may have been OK because the existing autofs ioctl holds the BKL for its operations. I'll think about it. snip ....
next prev parent reply other threads:[~2008-02-29 16:28 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-02-26 3:21 [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Ian Kent 2008-02-26 3:22 ` [PATCH 1/4] autofs4 - check for invalid dentry in getpath Ian Kent 2008-02-26 3:23 ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Ian Kent 2008-02-26 5:14 ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor - correction Ian Kent 2008-02-28 4:45 ` [PATCH 3/4] autofs4 - track uid and gid of last mount requestor Andrew Morton 2008-02-28 6:22 ` Ian Kent 2008-02-28 6:37 ` Andrew Morton 2008-02-28 7:08 ` Ian Kent 2008-02-28 7:23 ` Andrew Morton 2008-02-28 8:00 ` Ian Kent 2008-02-28 17:13 ` Jeff Moyer 2008-02-28 19:51 ` Serge E. Hallyn 2008-02-29 3:32 ` Ian Kent 2008-02-29 16:09 ` Serge E. Hallyn 2008-02-29 16:20 ` Pavel Emelyanov 2008-02-29 17:42 ` Serge E. Hallyn 2008-03-02 0:49 ` Eric W. Biederman 2008-03-02 1:13 ` Eric W. Biederman 2008-03-03 15:28 ` Serge E. Hallyn 2008-03-04 22:16 ` Eric W. Biederman 2008-02-28 7:51 ` Pavel Emelyanov 2008-02-28 7:59 ` Andrew Morton 2008-02-28 8:06 ` Ian Kent 2008-02-28 12:31 ` [autofs] " Fabio Olive Leite 2008-02-28 20:33 ` Eric W. Biederman 2008-02-26 3:23 ` [PATCH 4/4] autofs4 - add miscelaneous device for ioctls Ian Kent 2008-02-28 5:17 ` Andrew Morton 2008-02-28 6:18 ` Ian Kent 2008-03-13 7:00 ` [RFC] " Ian Kent 2008-03-14 2:45 ` Ian Kent 2008-03-14 12:45 ` Thomas Graf 2008-03-14 14:10 ` Ian Kent 2008-02-29 16:24 ` Ian Kent [this message] 2008-04-11 7:02 ` Ian Kent 2008-04-12 4:03 ` Andrew Morton 2008-04-14 4:45 ` Ian Kent 2008-02-26 4:29 ` [PATCH 2/4] autofs4 - add mount option to display mount device Ian Kent 2008-02-28 5:17 ` Andrew Morton 2008-02-28 4:40 ` [PATCH 0/4] autofs4 - autofs needs a miscelaneous device for ioctls Andrew Morton 2008-02-28 6:07 ` Ian Kent 2008-08-07 11:40 [PATCH 1/4] autofs4 - cleanup autofs mount type usage Ian Kent 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 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
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=1204302250.19890.22.camel@raven.themaw.net \ --to=raven@themaw.net \ --cc=akpm@linux-foundation.org \ --cc=autofs@linux.kernel.org \ --cc=hch@lst.de \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=viro@zeniv.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: linkBe 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).