From: Frederic Weisbecker <fweisbec@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Tyler Hicks <tyhicks@linux.vnet.ibm.com>,
Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Dustin Kirkland <kirkland@canonical.com>,
Ecryptfs <ecryptfs-devel@lists.launchpad.net>,
Thomas Gleixner <tglx@linutronix.de>,
John Kacur <jkacur@redhat.com>,
Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] vfs/eCryptfs: Handle ioctl calls with unlocked and compat functions
Date: Fri, 21 May 2010 09:03:25 +0200 [thread overview]
Message-ID: <20100521070322.GA5327@nowhere> (raw)
In-Reply-To: <201005210825.32819.arnd@arndb.de>
On Fri, May 21, 2010 at 08:25:32AM +0200, Arnd Bergmann wrote:
> On Friday 21 May 2010, Tyler Hicks wrote:
> > Lower filesystems that only implement unlocked_ioctl aren't being
> > passed ioctl calls because eCryptfs only checked for
> > lower_file->f_op->ioctl and returned -ENOTTY if it was NULL.
> >
> > eCryptfs shouldn't implement ioctl(), since it doesn't require the BKL.
> > Instead, unlocked_ioctl() should be used and vfs_ioctl() can be called
> > on the lower file since it handles locking, if necessary. This requires
> > vfs_ioctl() to be exported.
>
> Calling vfs_ioctl doesn't help you at all here, you could simply call
> the ->unlocked_ioctl function of the lower fs directly to do the same,
> because ->ioctl will be gone soon.
Yeah. Nothing is left pending in the fs tree wrt ioctl pushdown so this
is safe.
> You are howevers still missing a few calls that are done through do_vfs_ioctl
> or file_ioctl. To implement these, you need to add the file and super operations
> that these call and forward the functions to the lower fs.
>
> > +#ifdef CONFIG_COMPAT
> > +static long
> > +ecryptfs_compat_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
> > +{
> > + long rc = -ENOTTY;
> > + struct file *lower_file = NULL;
> > +
> > + if (ecryptfs_file_to_private(file))
> > + lower_file = ecryptfs_file_to_lower(file);
> > + if (lower_file && lower_file->f_op && lower_file->f_op->compat_ioctl)
> > + rc = lower_file->f_op->compat_ioctl(lower_file, cmd, arg);
> > + return rc;
> > +}
> > +#endif
>
> You need to return -ENOIOCTLCMD here, not ENOTTY to cover the case where
> the lower file system does not have a ->compat_ioctl function but has its
> calls listed in fs/compat_ioctl.c.
>
> Arnd
Right.
So I'll drop the pushdown from my tree and let Tyler handle that.
Thanks.
next prev parent reply other threads:[~2010-05-21 7:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 17:24 [PATCH 0/8] Another set of ioctl bkl pushdown, almost the end Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 1/8] ecryptfs: Pushdown the bkl from ioctl Frederic Weisbecker
2010-05-20 23:39 ` Tyler Hicks
2010-05-20 23:42 ` [PATCH] vfs/eCryptfs: Handle ioctl calls with unlocked and compat functions Tyler Hicks
2010-05-21 6:25 ` Arnd Bergmann
2010-05-21 7:03 ` Frederic Weisbecker [this message]
2010-05-19 17:24 ` [PATCH 2/8] autofs: Pushdown the bkl from ioctl Frederic Weisbecker
2010-05-19 18:02 ` H. Peter Anvin
2010-05-19 18:08 ` Frederic Weisbecker
2010-05-19 18:13 ` H. Peter Anvin
2010-05-19 18:22 ` Frederic Weisbecker
2010-05-19 19:03 ` Frederic Weisbecker
2010-05-19 20:04 ` H. Peter Anvin
2010-05-20 11:35 ` Ian Kent
2010-05-19 17:24 ` [PATCH 3/8] autofs4: " Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 4/8] sunrpc: " Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 5/8] sunrpc: Pushdown the bkl from sunrpc cache ioctl Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 6/8] uml: Pushdown the bkl from harddog_kern ioctl Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 7/8] cris: Pushdown the bkl from ioctl Frederic Weisbecker
2010-05-19 17:24 ` [PATCH 8/8] ia64: Use unlocked_ioctl from perfmon Frederic Weisbecker
2010-05-20 11:26 ` [PATCH 0/8] Another set of ioctl bkl pushdown, almost the end Jan Kara
2010-05-20 11:28 ` Frederic Weisbecker
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=20100521070322.GA5327@nowhere \
--to=fweisbec@gmail.com \
--cc=arnd@arndb.de \
--cc=ecryptfs-devel@lists.launchpad.net \
--cc=jkacur@redhat.com \
--cc=kirkland@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=tyhicks@linux.vnet.ibm.com \
--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: 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).