From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: Andrew Morton <akpm@osdl.org>,
Christoph Hellwig <hch@infradead.org>,
Al Viro <viro@ftp.linux.org.uk>,
Linux Kernel ML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] vfs: cleanup of permission()
Date: Wed, 01 Mar 2006 15:42:43 -0800 [thread overview]
Message-ID: <1141256563.26382.8.camel@netapplinux-10.connectathon.org> (raw)
In-Reply-To: <20060301131149.GD26837@MAIL.13thfloor.at>
On Wed, 2006-03-01 at 14:11 +0100, Herbert Poetzl wrote:
> the second part is actually a hack to help nfs and fuse
> to get the 'required' information until there is a proper
> interface (at the vfs not inode level) to pass relevant
> information (probably dentry/vfsmount/flags)
The nameidata _IS_ the vfs structure for storing path context
information. You seem to be suggesting we need yet another one. Why?
> > > this is in two parts, the first one does the
> > > removal and the second one fixes up nfs and fuse
> > > by passing the relevant nd_flags via the mask
> > >
> > > Note: this is just a suggestion, so please let
> > > us know what you think
> >
> > Firstly, the fact that the lookup intent flags happen not to collide
> > with MAY_* is a complete fluke, not a design. The numerical values of
> > either set of flags could change tomorrow for all you know.
> >
> > Secondly, an intent is _not_ a permissions mask by any stretch of the
> > imagination.
>
> see above
>
> > IOW: at the very least make that intent flag a separate parameter.
>
> IMHO it would be good to remove them completely form the
> current permission() checks.
Vetoed!
Redundant RPC calls have performance costs to the client, the server and
the network. That intent information is there in order to allow the
filesystem to figure out whether or not it needs to do the permissions
check, or if that check is already being done by other operations.
Removing the intents are therefore not an option.
Cheers,
Trond
next prev parent reply other threads:[~2006-03-01 23:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-28 5:26 [RFC] vfs: cleanup of permission() Herbert Poetzl
2006-02-28 5:29 ` [RFC 1/2] vfs: remove nameidata from *_permission() Herbert Poetzl
2006-02-28 5:30 ` [RFC 2/2] vfs: fixup nfs and fuse by passing nd_flags via mask Herbert Poetzl
2006-03-01 8:45 ` [RFC] vfs: cleanup of permission() Trond Myklebust
2006-03-01 12:28 ` tvrtko.ursulin
2006-03-01 12:37 ` Arjan van de Ven
2006-03-01 12:59 ` tvrtko.ursulin
2006-03-01 21:20 ` Sam Vilain
2006-03-01 13:06 ` Herbert Poetzl
2006-03-01 21:18 ` Sam Vilain
2006-03-01 13:11 ` Herbert Poetzl
2006-03-01 23:42 ` Trond Myklebust [this message]
2006-03-02 1:35 ` Sam Vilain
2006-03-02 2:26 ` Trond Myklebust
2006-03-01 22:11 ` Sam Vilain
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=1141256563.26382.8.camel@netapplinux-10.connectathon.org \
--to=trond.myklebust@fys.uio.no \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ftp.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 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.