lkml.org 
[lkml]   [2006]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] vfs: cleanup of permission()
From
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-02 00:45    [W:0.225 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site