All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.