Description of problem: The leaf optimization algorithm in find does not seem to handle the case of "/" as the starting point for the find. Find emits a warning message about the hard link count being incorrect and exits with a status of 1. Version-Release number of selected component (if applicable): findutils-4.2.27-3.2 How reproducible: Always Steps to Reproduce: Use any of the following commands (shell syntax shown): find / -name \*.rpmnew -print find / -type f -name \*.rpmnew -print find / \( -wholename /proc -prune \) -o \( -name \*.rpmnew -print \) Actual results: find: WARNING: Hard link count is wrong for /: 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. find exits with status 1. Expected results: No warning message, and a zero exit status. I would expect find to be able to handle its optimizations properly in / (I know it's ugly because in /, . and .. point to the same thing). I do not get this error in FC4 (but I don't know if noleaf is on by default in FC4). I should not have to turn on -noleaf when performing a find in /. Additional info: My / is an ext3 filesystem on an lvm volume on an md (RAID1) device. kernel-2.6.15-1.1955_FC5 cd / ; find . -name \*.rpmnew also has a similar problem.
I am finding that this is a problem with a filesystem called /selinux on my machine, not the leaf optimization. The odd thing is that the error is being reported on /, and / has link count of 23 and 21 subdirectories: # ls -lia / total 182 2 drwxr-xr-x 23 root root 4096 Feb 18 08:28 . 2 drwxr-xr-x 23 root root 4096 Feb 18 08:28 .. 98306 -rw-r--r-- 1 root root 0 Feb 18 08:27 .autofsck 98321 -rw------- 1 root root 610 Feb 17 19:43 .bash_history 1474561 drwxr-xr-x 2 root root 4096 Feb 18 09:45 bin 2 drwxr-xr-x 4 root root 1024 Feb 18 01:26 boot 766 drwxr-xr-x 13 root root 4040 Feb 18 08:37 dev 196609 drwxr-xr-x 93 root root 12288 Feb 18 15:09 etc 2 drwxr-xr-x 4 root root 4096 Feb 18 08:36 home 98313 -rw------- 1 root root 35 Feb 17 19:42 .lesshst 262145 drwxr-xr-x 11 root root 4096 Feb 18 09:39 lib 11 drwx------ 2 root root 16384 Jan 30 10:06 lost+found 2621441 drwxr-xr-x 2 root root 4096 Feb 11 12:16 media 3702785 drwxr-xr-x 2 root root 4096 Feb 10 22:06 misc 3080193 drwxr-xr-x 2 root root 4096 Feb 11 12:16 mnt 5142 drwxr-xr-x 2 root root 0 Feb 18 08:28 net 2 drwxr-xr-x 3 root root 4096 Feb 11 12:16 opt 1 dr-xr-xr-x 116 root root 0 Feb 18 08:27 proc 327681 drwxr-x--- 17 root root 4096 Feb 18 10:07 root 2949121 drwxr-xr-x 2 root root 12288 Feb 18 09:46 sbin 269 drwxr-xr-x 2 root root 0 Feb 18 08:27 selinux 3112961 drwxr-xr-x 2 root root 4096 Feb 11 12:16 srv 1 drwxr-xr-x 11 root root 0 Feb 18 08:27 sys 2 drwxrwxrwt 12 root root 4096 Feb 18 15:21 tmp 1736705 drwxr-xr-x 13 root root 4096 Feb 13 22:40 usr 2 drwxr-xr-x 26 root root 4096 Feb 13 22:40 var
/selinux is definitely the problem. If I umount it, everything works fine. And in /selinux, "." shows 2 links, but there are two subdirectories. So, if /selinux is the problem, then why is find reporting that / is the problem?
Thanks, I have fixed find to report the correct directory in findutils-4.2.27-4. Reassigning to kernel to fix st_nlink on /selinux.
Created attachment 124870 [details] Fix for the hard link count in selinuxfs This patch fixes the problem: we were not correctly accounting for the number of links for directories created under /selinux, which was throwing out the count for /selinux and the directories. (A couple of other fixes are needed for selinuxfs, which will be sent upstream separately).
These bugs are being closed since a large number of updates have been released after the FC5 test1 and test2 releases. Kindly update your system by running yum update as root user or try out the third and final test version of FC5 being released in a short while and verify if the bugs are still present on the system .Reopen or file new bug reports as appropriate after confirming the presence of this issue. Thanks
fixed in cvs.
Verification of the findutils fix... I updated to findutils-4.2.27-4 and the error is now properly reported (and the link count for selinux was still incorrect (had not tried to update the kernel yet to get the st_nlink fix): root@obscured# find / -name \*.rpmnew -print find: WARNING: Hard link count is wrong for /selinux: 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. root@obscured# echo $? 1 root@obscured# find / -noleaf -name \*.rpmnew -print root@obscured# echo $? 0 root@obscured# find /selinux -noleaf -type d -ls 269 0 drwxr-xr-x 2 root root 0 Feb 21 11:01 /selinux 285 0 dr-xr-xr-x 1 root root 0 Feb 21 11:01 /selinux/avc 283 0 dr-xr-xr-x 1 root root 0 Feb 21 11:01 /selinux/booleans
kernel in rawhide should have this fixed
I have installed the newest kernel via yum, and the problem is partially fixed. The subdirectories of the selinux filesystem are fixed. However, note that the link count is still incorrect on the root of the /selinux filesystem (shows 2, but there are two subdirectories, so I believe it should be 4): root@obscured# uname -srvmpi Linux 2.6.15-1.1977_FC5 #1 Thu Feb 23 14:53:53 EST 2006 i686 athlon i386 root@obscured# find /selinux -name \*.rpmnew -print find: WARNING: Hard link count is wrong for /selinux: 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. root@obscured# find /selinux -noleaf -type d -ls 269 0 drwxr-xr-x 2 root root 0 Feb 25 11:24 /selinux 285 0 dr-xr-xr-x 2 root root 0 Feb 25 11:24 /selinux/avc 283 0 dr-xr-xr-x 2 root root 0 Feb 25 11:24 /selinux/booleans root@obscured# ls -ldi /selinux /selinux/. 269 drwxr-xr-x 2 root root 0 Feb 25 11:24 /selinux 269 drwxr-xr-x 2 root root 0 Feb 25 11:24 /selinux/. Am I missing an update or another fix that is necessary?
Created attachment 125254 [details] Additional patch, to fix hard link count on root This should finally fix it. Stephen: please review.
(In reply to comment #10) > Created an attachment (id=125254) [edit] > Additional patch, to fix hard link count on root > > This should finally fix it. > > Stephen: please review. Acked-by: Stephen Smalley <sds.gov>
that caused a reject in the last hunk for some reason (probably because it appears to be against -mm). James, I fixed it up by hand and it looks right to me, but can you give it the once over ? http://cvs.fedora.redhat.com/viewcvs/devel/kernel/linux-2.6-selinux-selinuxfs-hard-link-count.patch should update soon (I only just checked it in)
(In reply to comment #12) Yep, looks ok.
*** Bug 183973 has been marked as a duplicate of this bug. ***
I am still expecting the link count to be 4 not 3 on "/selinux". The count changed from two to three in kernel-2.6.15-1.2008_FC5. I updated to 2009 (and it is still 3). I am assuming the the mentioned fixes are in 2008 and forward because the link count did change. /selinux should have links counted for /selinux /selinux/. /selinux/avc/.. /selinux/booleans/.. root@obscured# uname -srvmpi Linux 2.6.15-1.2009.4.2_FC5 #1 Thu Mar 2 18:10:16 EST 2006 i686 athlon i386 root@obscured# find /selinux -name \*.rpmnew -print find: WARNING: Hard link count is wrong for /selinux: 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. root@obscured# find /selinux -noleaf -type d -ls 270 0 drwxr-xr-x 3 root root 0 Mar 5 11:58 /selinux 286 0 dr-xr-xr-x 2 root root 0 Mar 5 11:58 /selinux/avc 284 0 dr-xr-xr-x 2 root root 0 Mar 5 11:58 /selinux/booleans root@obscured# ls -liad /selinux /selinux/. \ > /selinux/avc/.. /selinux/booleans/.. 270 drwxr-xr-x 3 root root 0 Mar 5 11:58 /selinux 270 drwxr-xr-x 3 root root 0 Mar 5 11:58 /selinux/. 270 drwxr-xr-x 3 root root 0 Mar 5 11:58 /selinux/avc/.. 270 drwxr-xr-x 3 root root 0 Mar 5 11:58 /selinux/booleans/..
Looks ok to me in 2.6.16-rc4-mm2, might be a problem with our kernel patch.
Just installed the kernel update (2.6.16-1.2080_FC5) (on FC5 now, not test 3) and the link count for the root directory of the /selinux filesystem still says three. root@obscured# uname -srvmpi Linux 2.6.16-1.2080_FC5 #1 Tue Mar 28 03:38:34 EST 2006 i686 athlon i386 root@obscured# find /selinux -name \*.rpmnew -print find: WARNING: Hard link count is wrong for /selinux: 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. root@obscured# ls -liad /selinux /selinux/. \ > /selinux/avc/.. /selinux/booleans/.. 270 drwxr-xr-x 3 root root 0 Mar 29 23:49 /selinux 270 drwxr-xr-x 3 root root 0 Mar 29 23:49 /selinux/. 270 drwxr-xr-x 3 root root 0 Mar 29 23:49 /selinux/avc/.. 270 drwxr-xr-x 3 root root 0 Mar 29 23:49 /selinux/booleans/..
I don't understand how this is happening. Works for me: 2.6.16-1.2102_FC6smp # ls -liad /selinux /selinux/. /selinux/avc/.. /selinux/booleans/.. 318 drwxr-xr-x 4 root root 0 Mar 29 11:17 /selinux 318 drwxr-xr-x 4 root root 0 Mar 29 11:17 /selinux/. 318 drwxr-xr-x 4 root root 0 Mar 29 11:17 /selinux/avc/.. 318 drwxr-xr-x 4 root root 0 Mar 29 11:17 /selinux/booleans/..
selinuxfs fixes went in after 2.6.16, so they might not be included in the FC5 kernel yet. They are now in Linus' git tree, so they would start showing up in rawhide kernels.
Looks like this is fixed in my 2.6.17-1.2157_FC5smp kernel: # find /selinux -type d -ls 349 0 drwxr-xr-x 4 root root 0 Jul 27 07:34 /selinux 365 0 dr-xr-xr-x 2 root root 0 Jul 27 07:34 /selinux/avc 363 0 dr-xr-xr-x 2 root root 0 Jul 27 07:34 /selinux/booleans
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.