On Thu, 2 May 2002, Paul Menage wrote:
> Since exec_permission_lite() is now basically an inlined and
> constant-propagated duplicate of vfs_permission(), this patch drops
> exec_permission_lite() and makes vfs_permission() inlined (but not
> static) and calls it from link_path_walk() if the inode doesn't have an
> i_op->permission() method.
IMO it's a bad idea. In many cases we have ->permission() but it's
perfectly OK with being called under dcache_lock - either always or
in (fs-specific) "fast case".
I would prefer ->permission_light() that would always be called
under dcache_lock and besides the usual values could return -EAGAIN.
In that case ->permission() would be called in a normal way.
Corresponding permission_light(9) and permission(9) would be used
in obvious way.
vfs_permission() is just a default value of ->permission() - in effect
you are doing an equivalent of
if (inode->i_op->permission == vfs_permission)
/* we know it's OK to call under dcache_lock */
- just that we represent vfs_permission as NULL in i_op. The reason
why it's Not Nice(tm) should be obvious...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 07 2002 - 22:00:18 EST