On Mon, Feb 03, 2014 at 10:31:27PM +, Al Viro wrote:
And the fact is, filesystems with hardlinks and path-name-based
operations do exist. cifs with the unix extensions is one of them.
Pox on Tridge...
Actually you have to blame me for that. Tridge always
*HATED* the UNIX extensions
On Mon, 2014-02-03 at 22:40 +, Al Viro wrote:
+static int gfs2_vfs_permission(struct dentry *dentry, struct inode
*inode, int mask)
+{
+ return gfs2_permission(inode, mask);
+}
Er... You do realize that callers of gfs2_permission() tend to have
the dentry in
On Tue, Feb 04, 2014 at 11:33:35AM +, Steven Whitehouse wrote:
To diverge from that topic for a moment, this thread has also brought
together some discussion on another issue which I've been pondering
recently that of whether the inode operations for get/set_xattr
should take a dentry
On Tue, Feb 4, 2014 at 3:33 AM, Steven Whitehouse swhit...@redhat.com wrote:
The other question that I have relating to that side of things, is why
security_inode_permission() is called from __inode_permission() rather
than from generic_permission() ? Maybe there is a good reason, but I
can't
On Thu, Jan 30, 2014 at 02:01:38PM -0800, Linus Torvalds wrote:
In the end, all the original call-sites should have a dentry, and none
of this is fundamental. But you're right, it looks like an absolute
nightmare to add the dentry pointer through the whole chain. Damn.
So I'm not thrilled
On Mon, Feb 03, 2014 at 02:29:43AM -0800, Christoph Hellwig wrote:
On Thu, Jan 30, 2014 at 02:01:38PM -0800, Linus Torvalds wrote:
In the end, all the original call-sites should have a dentry, and none
of this is fundamental. But you're right, it looks like an absolute
nightmare to add the
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
What do you think? I guess this patch could be split up into two: one
that does the vfs_xyz() helper functions, and another that does the
inode_permission() change. I tied them together mainly because I
started with the
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
Now, to be honest, pushing it down one more level (to
generic_permission()) will actually start causing some trouble. In
particular, gfs2_permission() fundamentally does not have a dentry for
several of the callers.
Looking over
On Mon, Feb 03, 2014 at 09:19:55PM +, Al Viro wrote:
Result *is* a function of inode alone; the problem with 9P is that we
are caching FIDs in the wrong place.
I don't think that's true for CIFS unfortunately, which is path based.
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Feb 03, 2014 at 01:24:47PM -0800, Christoph Hellwig wrote:
On Mon, Feb 03, 2014 at 09:19:55PM +, Al Viro wrote:
Result *is* a function of inode alone; the problem with 9P is that we
are caching FIDs in the wrong place.
I don't think that's true for CIFS unfortunately, which is
On Mon, Feb 3, 2014 at 1:19 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Please, don't do that. Half of that is pointless (e.g. what you are
doing with vfs_rmdir() - if anything, we could get rid of the first
argument completely, it's always victim-d_parent-d_inode and we are
holding enough
On Mon, Feb 03, 2014 at 09:31:53PM +, Al Viro wrote:
Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
is just fine.
It does have hardlinks, look at cifs_hardlink and functions called from
it.
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
On Mon, Feb 3, 2014 at 1:31 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
is just fine.
Hmm? I'm pretty sure cifs can actually have hardlinks.
Linus
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Feb 03, 2014 at 01:31:19PM -0800, Linus Torvalds wrote:
If the protocol is path-based (and it happens, and it's actually the
*correct* thing to do for a network filesystem, rather than the
idiotic file handle crap that tries to emulate the unix inode
semantics in the protocol), then
On Mon, Feb 03, 2014 at 09:39:26PM +, Al Viro wrote:
Which fs are you talking about? For 9P it *is* a function of inode alone.
For CIFS there's no wrong dentry to pick - it doesn't have links to start
with.
Except that apparently it does ;-/ Bugger...
--
To unsubscribe from this list:
On Mon, Feb 03, 2014 at 01:37:03PM -0800, Linus Torvalds wrote:
On Mon, Feb 3, 2014 at 1:31 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Yes, and...? CIFS also doesn't have hardlinks, so _there_ d_find_alias()
is just fine.
Hmm? I'm pretty sure cifs can actually have hardlinks.
*UGH*
On Mon, Feb 3, 2014 at 1:39 PM, Al Viro v...@zeniv.linux.org.uk wrote:
If we really have hardlinks, the result of permission check would better
be a function of inode itself - as in, if it gives different results
for two pathnames reachable for the same user, we have a bug.
No. You're wrong.
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
- err = vfs_mkdir(path.dentry-d_inode, dentry, mode);
+ err = vfs_mkdir(path.dentry, dentry, mode);
Pointless - path.dentry == dentry-d_parent anyway.
- err = vfs_mknod(path.dentry-d_inode, dentry, mode, dev-devt);
On Mon, Feb 3, 2014 at 1:59 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Feb 03, 2014 at 01:03:32PM -0800, Linus Torvalds wrote:
- err = vfs_mkdir(path.dentry-d_inode, dentry, mode);
+ err = vfs_mkdir(path.dentry, dentry, mode);
Pointless - path.dentry == dentry-d_parent
On Mon, Feb 03, 2014 at 01:44:22PM -0800, Linus Torvalds wrote:
On Mon, Feb 3, 2014 at 1:39 PM, Al Viro v...@zeniv.linux.org.uk wrote:
If we really have hardlinks, the result of permission check would better
be a function of inode itself - as in, if it gives different results
for two
On Mon, Feb 03, 2014 at 02:12:00PM -0800, Linus Torvalds wrote:
-int afs_permission(struct inode *inode, int mask)
+int afs_permission(struct dentry *dentry, struct inode *inode, int mask)
Oh, _lovely_. So not only do we pass dentry, the arguments are redundant
as well.
Note that
On Mon, Feb 3, 2014 at 2:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
Umm... Point, but that actually means that we get an extra pitfall for
filesystem writers here. foo_permission() passes dentry (now that it
has one) to foo_wank_a_lot(), with the latter using dentry-d_inode at
some
On Wed, Jan 29, 2014 at 11:54 PM, Christoph Hellwig h...@infradead.org wrote:
For -set_acl that's fairly easily doable and I actually had a version
doing that to be able to convert 9p. But for -get_acl the path walking
caller didn't seem easily feasible. -get_acl actually is an invention
of
On Thu, 30 Jan 2014, Linus Torvalds wrote:
On Wed, Jan 29, 2014 at 11:54 PM, Christoph Hellwig h...@infradead.org
wrote:
For -set_acl that's fairly easily doable and I actually had a version
doing that to be able to convert 9p. But for -get_acl the path walking
caller didn't seem
From: Sage Weil s...@inktank.com
The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
dropping the now-generic functions and setting the set_acl inode op.
Signed-off-by: Sage Weil s...@inktank.com
---
v2:
On Wed, Jan 29, 2014 at 8:37 AM, Ilya Dryomov ilya.dryo...@inktank.com wrote:
From: Sage Weil s...@inktank.com
The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
dropping the now-generic functions and
On Wed, Jan 29, 2014 at 6:37 PM, Ilya Dryomov ilya.dryo...@inktank.com wrote:
From: Sage Weil s...@inktank.com
The merge of 7221fe4c2 raced with upstream changes in the generic POSIX
ACL code (2aeccbe95). Update Ceph to use the new helpers as well by
dropping the now-generic functions and
On Wed, Jan 29, 2014 at 11:09:18AM -0800, Linus Torvalds wrote:
So attached is the incremental diff of the patch by Sage and Ilya, and
I'll apply it (delayed a bit to see if I can get the sign-off from
Ilya), but I also think we should fix the (non-cached) ACL functions
that call down to the
28 matches
Mail list logo
