vfs: Add ->statfs callback for pipefs
PATCH RESEND 1/1 vfs: Add ->statfs callback for pipefs
From: Pavel Emelyanov <[email protected]>
This is done to make it possible to distinguish pipes from fifos when opening one via /proc/<pid>/fd/ link.
--- fs/pipe.c | 1 + 1 file changed, 1 insertion(+)
Any objections to this one? It was a part of a patchset but can be treated independently so I'm re-sending it alone.
fs/pipe.c +1 -0
@@ -1254,6 +1254,7 @@ out:static const struct super_operations pipefs_ops = { .destroy_inode = free_inode_nonrcu, + .statfs = simple_statfs, };/*
Quoted 21 lines · On Wed, 24 Aug 2011 12:09:24 +0400 Cyrill Gorcunov <[email protected]> wrote:
From: Pavel Emelyanov <[email protected]>
This is done to make it possible to distinguish pipes from fifos when opening one via /proc/<pid>/fd/ link.
Signed-off-by Pavel Emelyanov <[email protected]>Reviewed-by Tejun Heo <[email protected]>Acked-by Serge Hallyn <[email protected]>Signed-off-by Cyrill Gorcunov <[email protected]>--- fs/pipe.c | 1 + 1 file changed, 1 insertion(+)Any objections to this one? It was a part of a patchset but can be treated independently so I'm re-sending it alone.
Index:
linux-2.6.git/fs/pipe.c
===================================================================
fs/pipe.c out: · line 1260
Quoted 7 lines
fs/pipe.c +1
-0@@ -1254,6 +1254,7 @@ out:static const struct super_operations pipefs_ops = { .destroy_inode = free_inode_nonrcu, + .statfs = simple_statfs, };/*
OK, I give up - how does it work?
<goes off and reads the kernel>
So it appears that the statfs call would previously return -ENOSYS, but with this change the statfs will succeed and userspace can then inspect f_type. Yes? I will fix your changelog by adding a description along these lines.
And I'll ask you to fix it further by telling us why we want to do this? The kernel has had this issue for a long time - why does it now matter?
Quoted 33 lines · Andrew Morton
Quoted 21 lines · On Wed, 24 Aug 2011 12:09:24 +0400 Cyrill Gorcunov <[email protected]> wrote:
From: Pavel Emelyanov <[email protected]>
This is done to make it possible to distinguish pipes from fifos when opening one via /proc/<pid>/fd/ link.
Signed-off-by Pavel Emelyanov <[email protected]>Reviewed-by Tejun Heo <[email protected]>Acked-by Serge Hallyn <[email protected]>Signed-off-by Cyrill Gorcunov <[email protected]>--- fs/pipe.c | 1 + 1 file changed, 1 insertion(+)Any objections to this one? It was a part of a patchset but can be treated independently so I'm re-sending it alone.
Index:
linux-2.6.git/fs/pipe.c
===================================================================fs/pipe.c out: · line 1260
Quoted 7 lines
fs/pipe.c +1
-0@@ -1254,6 +1254,7 @@ out:static const struct super_operations pipefs_ops = { .destroy_inode = free_inode_nonrcu, + .statfs = simple_statfs, };/* OK, I give up - how does it work?
Quoted 6 lines
<goes off and reads the kernel>
So it appears that the statfs call would previously return
-ENOSYS, but with this change the statfs will succeed and userspace can then inspectf_type. Yes? I will fix your changelog by adding a description along these lines.
Yes, it allows to distinguish pipes from anything else. Initially this patch was a part of early rfc on checkpoint/restore facility (mostly implemented in userspace). So we need to distinguish somehow pipes when we dump data from /proc/pid/fd. That's the main reason. BUT since this patch can be used without any other c/r bits and can be treated separately I've sent it alone without any mention of c/r at all.
Quoted 4 lines
And I'll ask you to fix it further by telling us why we want to do this? The kernel has had this issue for a long time - why does it now matter?
Cyrill
Quoted 9 lines
OK, I give up - how does it work?
<goes off and reads the kernel>
So it appears that the statfs call would previously return
-ENOSYS, but with this change the statfs will succeed and userspace can then inspectf_type. Yes? I will fix your changelog by adding a description along these lines.
Yes, the primary intention is to get the f_type.
Quoted 3 lines
And I'll ask you to fix it further by telling us why we want to do this? The kernel has had this issue for a long time - why does it now matter?
This is required by checkpoint-restart in the userspace to make it possible to distinguish pipes from fifos. In more details:
When we dump information about task's open files we use the /proc/pid/fd directoy's symlinks and the fact that opening any of them gives us exactly the same dentry->inode pair as the original process has. Now if a task we're dumping has opened pipe and fifo we need to detect this and act accordingly. Knowing that an fd with type S_ISFIFO resides on a pipefs is the most precise way.
Thanks,
Pavel