Hi,
2.6.26-rc4 seems to exhibit the following (new since at least 2.6.24)
warning when running find /proc/1:
find: WARNING: Hard link count is wrong for /proc/1: this may be a bug
in your filesystem driver. Automatically turning on find's -noleaf
option. Earlier results may have failed to include directories that
should have been searched.
# ls -l /proc/1
total 0
-r-------- 1 root root 0 Jun 2 02:20 auxv
--w------- 1 root root 0 Jun 2 02:20 clear_refs
-r--r--r-- 1 root root 0 Jun 2 02:20 cmdline
-rw-r--r-- 1 root root 0 Jun 2 02:20 coredump_filter
lrwxrwxrwx 1 root root 0 Jun 2 02:20 cwd -> /
-r-------- 1 root root 0 Jun 2 02:20 environ
lrwxrwxrwx 1 root root 0 Jun 2 02:20 exe -> /bin/bash
dr-x------ 2 root root 0 Jun 2 02:20 fd
dr-x------ 2 root root 0 Jun 2 02:20 fdinfo
-r-------- 1 root root 0 Jun 2 02:20 limits
-r--r--r-- 1 root root 0 Jun 2 02:20 maps
-rw------- 1 root root 0 Jun 2 02:20 mem
-r--r--r-- 1 root root 0 Jun 2 02:20 mountinfo
-r--r--r-- 1 root root 0 Jun 2 02:20 mounts
-r-------- 1 root root 0 Jun 2 02:20 mountstats
dr-xr-xr-x 5 root root 0 Jun 2 02:20 net
-rw-r--r-- 1 root root 0 Jun 2 02:20 oom_adj
-r--r--r-- 1 root root 0 Jun 2 02:20 oom_score
-r-------- 1 root root 0 Jun 2 02:20 pagemap
lrwxrwxrwx 1 root root 0 Jun 2 02:20 root -> /
-r--r--r-- 1 root root 0 Jun 2 02:20 smaps
-r--r--r-- 1 root root 0 Jun 2 02:20 stat
-r--r--r-- 1 root root 0 Jun 2 02:20 statm
-r--r--r-- 1 root root 0 Jun 2 02:20 status
dr-xr-xr-x 3 root root 0 Jun 2 02:20 task
-r--r--r-- 1 root root 0 Jun 2 02:20 wchan
# stat /proc/1
File: `/proc/1'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 39 Links: 5
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2008-06-02 02:19:07.418398897 -0400
Modify: 2008-06-02 02:19:07.418398897 -0400
Change: 2008-06-02 02:19:07.418398897 -0400
The other /proc/pid entries seem to have the same problem.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
On Mon, Jun 2, 2008 at 8:31 AM, Vegard Nossum <[email protected]> wrote:
> Hi,
>
> 2.6.26-rc4 seems to exhibit the following (new since at least 2.6.24)
> warning when running find /proc/1:
>
> find: WARNING: Hard link count is wrong for /proc/1: this may be a bug
> in your filesystem driver. Automatically turning on find's -noleaf
> option. Earlier results may have failed to include directories that
> should have been searched.
My prime suspect is
commit e9720acd728a46cb40daa52c99a979f7c4ff195c
Author: Pavel Emelyanov <[email protected]>
Date: Fri Mar 7 11:08:40 2008 -0800
[NET]: Make /proc/net a symlink on /proc/self/net (v3)
as this patch introduces a new directory entry without bumping the nlink count.
Will this do? (Untested)
Vegard
>From a43ef05a8c1f8d45ca88e00fdd31c00ddfdba1b8 Mon Sep 17 00:00:00 2001
From: Vegard Nossum <[email protected]>
Date: Mon, 2 Jun 2008 08:57:45 +0200
Subject: [PATCH] proc: fix /proc/<pid> link count
commit e9720acd728a46cb40daa52c99a979f7c4ff195c
Author: Pavel Emelyanov <[email protected]>
Date: Fri Mar 7 11:08:40 2008 -0800
[NET]: Make /proc/net a symlink on /proc/self/net (v3)
introduced /proc/net without bumping the link count on /proc/self.
Signed-off-by: Vegard Nossum <[email protected]>
---
fs/proc/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index c447e07..10ee4a2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2589,6 +2589,9 @@ static struct dentry
*proc_pid_instantiate(struct inode *dir,
#ifdef CONFIG_SECURITY
inode->i_nlink += 1;
#endif
+#ifdef CONFIG_NET
+ inode->i_nlink += 1;
+#endif
dentry->d_op = &pid_dentry_operations;
--
1.5.4.1
On Mon, Jun 2, 2008 at 9:00 AM, Vegard Nossum <[email protected]> wrote:
...
> Will this do? (Untested)
>
> Vegard
>
>
> From a43ef05a8c1f8d45ca88e00fdd31c00ddfdba1b8 Mon Sep 17 00:00:00 2001
> From: Vegard Nossum <[email protected]>
> Date: Mon, 2 Jun 2008 08:57:45 +0200
> Subject: [PATCH] proc: fix /proc/<pid> link count
>
> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
> Author: Pavel Emelyanov <[email protected]>
> Date: Fri Mar 7 11:08:40 2008 -0800
>
> [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>
> introduced /proc/net without bumping the link count on /proc/self.
Oops ---^
Should say /proc/self/net. Sorry for the spamming.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
> On Mon, Jun 2, 2008 at 8:31 AM, Vegard Nossum <[email protected]> wrote:
> > Hi,
> >
> > 2.6.26-rc4 seems to exhibit the following (new since at least 2.6.24)
> > warning when running find /proc/1:
> >
> > find: WARNING: Hard link count is wrong for /proc/1: this may be a bug
> > in your filesystem driver. Automatically turning on find's -noleaf
> > option. Earlier results may have failed to include directories that
> > should have been searched.
>
> My prime suspect is
>
> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
> Author: Pavel Emelyanov <[email protected]>
> Date: Fri Mar 7 11:08:40 2008 -0800
>
> [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>
>
> as this patch introduces a new directory entry without bumping the nlink count.
>
> Will this do? (Untested)
>
> Vegard
>
>
> >From a43ef05a8c1f8d45ca88e00fdd31c00ddfdba1b8 Mon Sep 17 00:00:00 2001
> From: Vegard Nossum <[email protected]>
> Date: Mon, 2 Jun 2008 08:57:45 +0200
> Subject: [PATCH] proc: fix /proc/<pid> link count
>
> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
> Author: Pavel Emelyanov <[email protected]>
> Date: Fri Mar 7 11:08:40 2008 -0800
>
> [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>
> introduced /proc/net without bumping the link count on /proc/self.
Looks fine to me :).
Honza
> Signed-off-by: Vegard Nossum <[email protected]>
> ---
> fs/proc/base.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c447e07..10ee4a2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2589,6 +2589,9 @@ static struct dentry
> *proc_pid_instantiate(struct inode *dir,
> #ifdef CONFIG_SECURITY
> inode->i_nlink += 1;
> #endif
> +#ifdef CONFIG_NET
> + inode->i_nlink += 1;
> +#endif
>
> dentry->d_op = &pid_dentry_operations;
>
--
Jan Kara <[email protected]>
SuSE CR Labs
On Mon, Jun 2, 2008 at 10:00 AM, Vegard Nossum <[email protected]> wrote:
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c447e07..10ee4a2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2589,6 +2589,9 @@ static struct dentry
> *proc_pid_instantiate(struct inode *dir,
> #ifdef CONFIG_SECURITY
> inode->i_nlink += 1;
> #endif
> +#ifdef CONFIG_NET
#if defined(CONFIG_SECURITY) || defined(CONFIG_NET) ?
> + inode->i_nlink += 1;
> +#endif
>
> dentry->d_op = &pid_dentry_operations;
>
> --
> 1.5.4.1
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Mon, Jun 2, 2008 at 7:11 PM, Pekka Enberg <[email protected]> wrote:
> On Mon, Jun 2, 2008 at 10:00 AM, Vegard Nossum <[email protected]> wrote:
>> diff --git a/fs/proc/base.c b/fs/proc/base.c
>> index c447e07..10ee4a2 100644
>> --- a/fs/proc/base.c
>> +++ b/fs/proc/base.c
>> @@ -2589,6 +2589,9 @@ static struct dentry
>> *proc_pid_instantiate(struct inode *dir,
>> #ifdef CONFIG_SECURITY
>> inode->i_nlink += 1;
>> #endif
>> +#ifdef CONFIG_NET
>
> #if defined(CONFIG_SECURITY) || defined(CONFIG_NET) ?
Oh, forget it. I need to start thinking before posting.
Vegard Nossum wrote:
> Hi,
>
> 2.6.26-rc4 seems to exhibit the following (new since at least 2.6.24)
> warning when running find /proc/1:
>
> find: WARNING: Hard link count is wrong for /proc/1: this may be a bug
> in your filesystem driver. Automatically turning on find's -noleaf
> option. Earlier results may have failed to include directories that
> should have been searched.
>
> # ls -l /proc/1
> total 0
> -r-------- 1 root root 0 Jun 2 02:20 auxv
> --w------- 1 root root 0 Jun 2 02:20 clear_refs
> -r--r--r-- 1 root root 0 Jun 2 02:20 cmdline
> -rw-r--r-- 1 root root 0 Jun 2 02:20 coredump_filter
> lrwxrwxrwx 1 root root 0 Jun 2 02:20 cwd -> /
> -r-------- 1 root root 0 Jun 2 02:20 environ
> lrwxrwxrwx 1 root root 0 Jun 2 02:20 exe -> /bin/bash
> dr-x------ 2 root root 0 Jun 2 02:20 fd
> dr-x------ 2 root root 0 Jun 2 02:20 fdinfo
> -r-------- 1 root root 0 Jun 2 02:20 limits
> -r--r--r-- 1 root root 0 Jun 2 02:20 maps
> -rw------- 1 root root 0 Jun 2 02:20 mem
> -r--r--r-- 1 root root 0 Jun 2 02:20 mountinfo
> -r--r--r-- 1 root root 0 Jun 2 02:20 mounts
> -r-------- 1 root root 0 Jun 2 02:20 mountstats
> dr-xr-xr-x 5 root root 0 Jun 2 02:20 net
> -rw-r--r-- 1 root root 0 Jun 2 02:20 oom_adj
> -r--r--r-- 1 root root 0 Jun 2 02:20 oom_score
> -r-------- 1 root root 0 Jun 2 02:20 pagemap
> lrwxrwxrwx 1 root root 0 Jun 2 02:20 root -> /
> -r--r--r-- 1 root root 0 Jun 2 02:20 smaps
> -r--r--r-- 1 root root 0 Jun 2 02:20 stat
> -r--r--r-- 1 root root 0 Jun 2 02:20 statm
> -r--r--r-- 1 root root 0 Jun 2 02:20 status
> dr-xr-xr-x 3 root root 0 Jun 2 02:20 task
> -r--r--r-- 1 root root 0 Jun 2 02:20 wchan
>
> # stat /proc/1
> File: `/proc/1'
> Size: 0 Blocks: 0 IO Block: 1024 directory
> Device: 3h/3d Inode: 39 Links: 5
> Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
> Access: 2008-06-02 02:19:07.418398897 -0400
> Modify: 2008-06-02 02:19:07.418398897 -0400
> Change: 2008-06-02 02:19:07.418398897 -0400
>
> The other /proc/pid entries seem to have the same problem.
>
>
> Vegard
>
The same warning shows up on linux 2.6.25.4.
$ sudo stat /proc/1
File: `/proc/1'
Size: 0 Blocks: 0 IO Block: 1024 directory
Device: 3h/3d Inode: 111976 Links: 5
Access: (0555/dr-xr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2008-06-02 19:23:41.728134046 -0300
Modify: 2008-06-02 19:23:41.728134046 -0300
Change: 2008-06-02 19:23:41.728134046 -0300
This is the output of find before the warning shows up (it always happen
right after /proc/1/fdinfo/10):
$ sudo find /proc/1
/proc/1
/proc/1/task
/proc/1/task/1
/proc/1/task/1/fd
/proc/1/task/1/fd/10
/proc/1/task/1/fdinfo
/proc/1/task/1/fdinfo/10
/proc/1/task/1/environ
/proc/1/task/1/auxv
/proc/1/task/1/status
/proc/1/task/1/limits
/proc/1/task/1/cmdline
/proc/1/task/1/stat
/proc/1/task/1/statm
/proc/1/task/1/maps
/proc/1/task/1/mem
/proc/1/task/1/cwd
/proc/1/task/1/root
/proc/1/task/1/exe
/proc/1/task/1/mounts
/proc/1/task/1/clear_refs
/proc/1/task/1/smaps
/proc/1/task/1/pagemap
/proc/1/task/1/wchan
/proc/1/task/1/oom_score
/proc/1/task/1/oom_adj
/proc/1/fd
/proc/1/fd/10
/proc/1/fdinfo
/proc/1/fdinfo/10
find: WARNING: Hard link count is wrong for /proc/1: this may be a bug
in your filesystem driver. Automatically turning on find's -noleaf
option. Earlier results may have failed to include directories that
should have been searched.
From: Vegard Nossum <[email protected]>
Date: Mon, 2 Jun 2008 08:57:45 +0200
Subject: [PATCH] proc: fix /proc/<pid> link count
commit e9720acd728a46cb40daa52c99a979f7c4ff195c
Author: Pavel Emelyanov <[email protected]>
Date: Fri Mar 7 11:08:40 2008 -0800
[NET]: Make /proc/net a symlink on /proc/self/net (v3)
introduced /proc/net without bumping the link count on /proc/self.
Signed-off-by: Vegard Nossum <[email protected]>
Acked-by: "Eric W. Biederman" <[email protected]>
---
fs/proc/base.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index c447e07..10ee4a2 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2589,6 +2589,9 @@ static struct dentry
*proc_pid_instantiate(struct inode *dir,
#ifdef CONFIG_SECURITY
inode->i_nlink += 1;
#endif
+#ifdef CONFIG_NET
+ inode->i_nlink += 1;
+#endif
dentry->d_op = &pid_dentry_operations;
--
1.5.4.1
On Mon, 02 Jun 2008 18:59:46 -0700 [email protected] (Eric W. Biederman) wrote:
>
> From: Vegard Nossum <[email protected]>
> Date: Mon, 2 Jun 2008 08:57:45 +0200
> Subject: [PATCH] proc: fix /proc/<pid> link count
>
> commit e9720acd728a46cb40daa52c99a979f7c4ff195c
> Author: Pavel Emelyanov <[email protected]>
> Date: Fri Mar 7 11:08:40 2008 -0800
>
> [NET]: Make /proc/net a symlink on /proc/self/net (v3)
>
> introduced /proc/net without bumping the link count on /proc/self.
>
> Signed-off-by: Vegard Nossum <[email protected]>
> Acked-by: "Eric W. Biederman" <[email protected]>
>
> ---
> fs/proc/base.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index c447e07..10ee4a2 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -2589,6 +2589,9 @@ static struct dentry
> *proc_pid_instantiate(struct inode *dir,
> #ifdef CONFIG_SECURITY
> inode->i_nlink += 1;
> #endif
> +#ifdef CONFIG_NET
> + inode->i_nlink += 1;
> +#endif
>
> dentry->d_op = &pid_dentry_operations;
A bit more explanation would be nice.
I assume that here we're accounting for a reference which net applies
to this dentry. But it would be clearer and more robust to do that at
the site where that reference is really taken, not over in
proc_pid_instantiate(). Possible?
On Tue, Jun 3, 2008 at 5:46 AM, Eric W. Biederman <[email protected]> wrote:
> Andrew Morton <[email protected]> writes:
>>> #ifdef CONFIG_SECURITY
>>> inode->i_nlink += 1;
>>> #endif
>>> +#ifdef CONFIG_NET
>>> + inode->i_nlink += 1;
>>> +#endif
>>>
>>> dentry->d_op = &pid_dentry_operations;
>>
>> A bit more explanation would be nice.
>>
>> I assume that here we're accounting for a reference which net applies
>> to this dentry. But it would be clearer and more robust to do that at
>> the site where that reference is really taken, not over in
>> proc_pid_instantiate(). Possible?
>
> Yes. Potentially we can read through the tid_base_stuff and
> count the total number of directories at runtime whenever we
> open a /proc/<pid> directory. It is a smallish table and walking the
> entire table is likely to be lost in the noise, and that would
> certainly improve the maintainability of the code.
>
> Currently what we do is:
> inode->i_nlink = 5;
> #ifdef CONFIG_SECURITY
> inode->i_nlink += 1;
> #endif
>
> To get the hard link count of /proc/<pid> correct.
> With /proc/<pid>/net we have added one more optional possibly absent
> directory.
>
> So the above patch is trivially correct in the current form of the
> code but does not improve maintenance.
>
> I am tired and all I have the energy to do today is to review the
> patch and say: "Yes. The patch works for the correct reasons, let's
> fix this bug."
I can try for the counting fix if you give me a bit of time. I have an
exam today and tomorrow, so I'll likely be able to submit a fix after
that :-)
Maybe you can apply the fix for now and I can follow up with the nicer
counting patch afterwards? (Or if anybody else wants to write it
that's also fine :-))
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036