public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Josef Sipek <jsipek@fsl.cs.sunysb.edu>
Cc: linux-kernel@vger.kernel.org, John Johansen <jjohansen@suse.de>,
	Jan Blunck <jblunck@suse.de>, Erez Zadok <ezk@cs.sunysb.edu>,
	"Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
Subject: Re: [RFC 04/10] Temporary struct vfs_lookup in file_permission
Date: Wed, 8 Aug 2007 20:56:20 +0200	[thread overview]
Message-ID: <200708082056.20442.agruen@suse.de> (raw)
In-Reply-To: <20070808175807.GA31221@filer.fsl.cs.sunysb.edu>

On Wednesday 08 August 2007 19:58, Josef Sipek wrote:
> On Wed, Aug 08, 2007 at 07:16:26PM +0200, Andreas Gruenbacher wrote:
> > Create a temporary struct vfs_lookup in file_permission() instead of
> > passing a NULL value.
> > 
> > Signed-off-by: Andreas Gruenbacher <ag@bestbits.at>
> > 
> > ---
> >  fs/namei.c |   11 ++++++-----
> >  1 file changed, 6 insertions(+), 5 deletions(-)
> > 
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -292,14 +292,15 @@ int vfs_permission(struct vfs_lookup *lo
> >   *
> >   * Used to check for read/write/execute permissions on an already opened
> >   * file.
> > - *
> > - * Note:
> > - *	Do not use this function in new code.  All access checks should
> > - *	be done using vfs_permission().
> 
> Should this comment be removed?

IMO yes. If vfs_permission() works for a piece of code it's the obvious 
preference. If on the other hand you really need to check permissions on a 
file, then why not use this function?

> >   */
> >  int file_permission(struct file *file, int mask)
> >  {
> > -	return permission(file->f_path.dentry->d_inode, mask, NULL);
> > +	struct vfs_lookup lookup;
> > +
> > +	lookup.path = file->f_path;
> > +	lookup.flags = 0;
> 
> I tend to find this little bit cleaner:
> 
> struct vfs_lookup lookup = {
> 	.path	= file->f_path,
> 	.flags	= 0,
> };

I didn't use initializers because they initialize the entire data structure. 
In case of struct vfs_lookup, unless the LOOKUP_OPEN flag is set, then the 
open_intent doesn't need initialization. We could use a DEFINE_... macro; not 
sure this would improve anything though.

> > +
> > +	return permission(file->f_path.dentry->d_inode, mask, &lookup);
> >  }
> >  
> >  /*

Thanks,
Andreas

  reply	other threads:[~2007-08-08 18:57 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 17:16 [RFC 00/10] Split up struct nameidata (take 3) Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 01/10] Split up struct nameidata Andreas Gruenbacher
2007-08-08 19:32   ` Christoph Hellwig
2007-08-09  8:26     ` atomic open (was Re: [RFC 01/10] Split up struct nameidata) Miklos Szeredi
2007-08-10 14:42     ` [RFC 01/10] Split up struct nameidata Andreas Gruenbacher
2007-08-10 14:22       ` [patch 1/4] Introduce pathput Andreas Gruenbacher
2007-08-29 19:07         ` Christoph Hellwig
2007-09-14 16:36           ` Christoph Hellwig
2007-08-10 14:22       ` [patch 2/4] Use pathput in a few more places Andreas Gruenbacher
2007-08-29 19:08         ` Christoph Hellwig
2007-08-30 15:01           ` [FIX] mntput called before dput in afs Andreas Gruenbacher
2007-08-30 15:15             ` David Howells
2007-08-30 15:56             ` David Howells
2007-08-10 14:22       ` [patch 3/4] Introduce pathget Andreas Gruenbacher
2007-08-29 19:09         ` Christoph Hellwig
2007-08-10 14:22       ` [patch 4/4] Switch to struct path in fs_struct Andreas Gruenbacher
2007-08-29 19:12         ` Christoph Hellwig
2007-08-08 17:16 ` [RFC 02/10] Switch from nd->{mnt,dentry} to nd->lookup.path.{mnt,dentry} Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 03/10] Pass no unnecessary information to iop->permission Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 04/10] Temporary struct vfs_lookup in file_permission Andreas Gruenbacher
2007-08-08 17:58   ` Josef Sipek
2007-08-08 18:56     ` Andreas Gruenbacher [this message]
2007-08-08 19:25   ` Christoph Hellwig
2007-08-08 21:41     ` Andreas Gruenbacher
2007-08-08 23:24       ` Christoph Hellwig
2007-08-09 17:23         ` Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 05/10] Use vfs_permission instead of file_permission in sys_fchdir Andreas Gruenbacher
2007-08-08 19:26   ` Christoph Hellwig
2007-08-08 17:16 ` [RFC 06/10] Use vfs_permission instead of file_permission in do_path_lookup Andreas Gruenbacher
2007-08-08 19:27   ` Christoph Hellwig
2007-08-08 17:16 ` [RFC 07/10] Pass no unnecessary information to iop->create Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 08/10] Pass no NULL vfs_lookup to vfs_create Andreas Gruenbacher
2007-08-08 19:36   ` Christoph Hellwig
2007-08-08 17:16 ` [RFC 09/10] Pass no unnecessary information to dop->d_revalidate Andreas Gruenbacher
2007-08-08 17:16 ` [RFC 10/10] Pass no unnecessary information to iop->lookup Andreas Gruenbacher

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=200708082056.20442.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=ezk@cs.sunysb.edu \
    --cc=jblunck@suse.de \
    --cc=jjohansen@suse.de \
    --cc=jsipek@cs.sunysb.edu \
    --cc=jsipek@fsl.cs.sunysb.edu \
    --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