Bug 211070 - Kernel 2.6.18-1.2200.fc5 Breaks CIFS Shares
Kernel 2.6.18-1.2200.fc5 Breaks CIFS Shares
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
x86_64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
: 206103 211582 211832 213308 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-17 00:33 EDT by Ryan Wagoner
Modified: 2008-01-17 09:25 EST (History)
21 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-12 00:45:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace 2.6.17-1.2187_FC5 (10.11 KB, application/octet-stream)
2006-10-17 00:56 EDT, Ryan Wagoner
no flags Details
strace 2.6.18-1.2200.fc5 (10.28 KB, text/plain)
2006-10-17 00:57 EDT, Ryan Wagoner
no flags Details
proposed fix (420 bytes, patch)
2006-10-19 23:16 EDT, Steve French
no flags Details | Diff
strace with -F option (6.50 KB, text/plain)
2007-01-16 11:12 EST, Jorge Escobar
no flags Details
New strace with -f option (1.63 KB, text/plain)
2007-01-16 13:32 EST, Jorge Escobar
no flags Details
Directory contents snapshot (424.47 KB, image/jpeg)
2007-01-16 13:51 EST, Jorge Escobar
no flags Details
Cat dump (1.30 KB, text/plain)
2007-01-16 15:06 EST, Jorge Escobar
no flags Details

  None (edit)
Description Ryan Wagoner 2006-10-17 00:33:11 EDT
Description of problem:
I just upgraded to the 2.6.18-1.2200.fc5 kernel from 2.6.17-1.2187_FC5. I have
some shares mounted from a windows 2003 server using cifs. When browsing the
share certain directories show no files when using the ls command. I receive the
error "ls: reading directory .: Invalid argument". If I reboot with the older
kernel I can successful browse those directorys.

How reproducible:
Always. I even tried Fedora Core 6 Test 3 and I receive the same error message
when trying to ls on certain directories in the share.

Additional info:
I tried to find something in common with the directorys that give the error on
the ls command but don't notice anything common between them. I have other
directories with just as many files that ls with no problem.
Comment 1 Ryan Wagoner 2006-10-17 00:56:33 EDT
Created attachment 138655 [details]
strace 2.6.17-1.2187_FC5
Comment 2 Ryan Wagoner 2006-10-17 00:57:33 EDT
Created attachment 138656 [details]
strace 2.6.18-1.2200.fc5
Comment 3 Ryan Wagoner 2006-10-17 01:00:43 EDT
I added two attachements. One from each kernel version running an strace ls on
the same directory in the cifs mounted share. strace 2.6.17-1.2187_FC5 shows a
successful ls and strace 2.6.18-1.2200.fc5 shows the unsuccessful ls.
Comment 4 Steve 2006-10-17 06:45:48 EDT
same here. when a shared folders have more then a few hundred folders or files
inside, this one can not be read.

ls: reading directory /mnt/share/: Invalid argument

the same problem has fc6 (rawhide) since the last (about)10-20 kernels.
Comment 5 Dave Thomas 2006-10-18 20:46:00 EDT
I have the same issue when connecting a FC5 box with kernel 2.6.18-1.2200 to a
FC5 server. I can mount the share but listing the dir results in 'Invalid argument'.
Comment 6 Steve French 2006-10-19 10:34:13 EDT
I was able to update to the same kernel and reproduce the problem.

filldir is returning rc=22, partway through a directory listing (on entry 113
out   of 317).  cifs is not expecting filldir to fail with this error and it
works with other kernels and similar versions of the cifs readdir code.

It may be an SELinux interaction.
Comment 7 Ryan Wagoner 2006-10-19 10:57:09 EDT
I have SELinux disabled on my box so I don't think SELinux is the problem.
Comment 8 Steve 2006-10-19 11:05:24 EDT
Same here, SELinux disabled on FC5 and Rawhide, the problem exists further.
Comment 9 Dave Thomas 2006-10-19 11:38:33 EDT
Ditto....SELinux is also disabled on the workstation that we have this issue 
with.
Comment 10 Steve French 2006-10-19 16:32:30 EDT
I am looking at this section of fs/readdir.c for the likely source of the -22 error:

static int filldir64(void * __buf, const char * name, int namlen, loff_t offset,
                    u64 ino, unsigned int d_type)
{
        struct linux_dirent64 __user *dirent;
        struct getdents_callback64 * buf = (struct getdents_callback64 *) __buf;
        int reclen = ROUND_UP64(NAME_OFFSET(dirent) + namlen + 1);

        buf->error = -EINVAL;   /* only used if we fail.. */
        if (reclen > buf->count)
                return -EINVAL;
Comment 11 Steve French 2006-10-19 16:38:27 EDT
Am downloading, modifying with some trace code, and rebuilding the matching
kernel source for this fc5 kernel now
Comment 12 Steve French 2006-10-19 22:37:25 EDT
in fs/readdir.c in filldir64 (2.6.18-FC5)

the vfs is checking
    if (reclean > buf->count)
          return -EINVAL


In this case, reclen is 40 and count is zero  (this is called from ls going to
vfs_readdir to cifs_readdir to cifs_filldir which is calling filldir, which is
failing
Comment 13 Steve French 2006-10-19 23:16:45 EDT
Created attachment 138936 [details]
proposed fix
Comment 14 Thorsten Leemhuis 2006-10-20 01:09:24 EDT
This is probably a dupe of Bug 206103
Comment 15 Steve French 2006-10-20 08:46:11 EDT
Yes that bug is a duplicate but I don't seem to have authority to dup it to this.

The fix is fairly obvious, the only thing bothering me is figuring out what changed
Comment 16 Steve French 2006-10-20 08:48:33 EDT
(since this did not use to fail, and doesn't fail on mainline kernel at the same
kernel level to the same directory in my tests, and this section of cifs_readdir
did not change I am curious)
Comment 17 Thorsten Leemhuis 2006-10-20 11:01:57 EDT
*** Bug 211582 has been marked as a duplicate of this bug. ***
Comment 18 Thorsten Leemhuis 2006-10-20 11:02:46 EDT
*** Bug 206103 has been marked as a duplicate of this bug. ***
Comment 19 Thorsten Leemhuis 2006-10-20 11:03:47 EDT
(In reply to comment #15)
> Yes that bug is a duplicate but I don't seem to have authority to dup it to this.

I did -- we just need to remember that this bug needs to be fixed in devel, fc6
and fc5!
Comment 20 Dave Jones 2006-10-20 15:28:05 EDT
I've merged this to all Fedora branches, and will get updates out soon.

As for why this broke in Fedora but not mainline.. We do have some cachefs
patches, and some funky 64bit inode patches (though I believe all of these are
in -mm, so that may be similarly affected).  CC'ing the usual suspects who may
have additional clues.
Comment 23 Ryan Wagoner 2006-10-20 16:14:19 EDT
Thanks for getting this fixed. Will be looking forward to the updates. Will this
be included in the iso files when FC6 is released?
Comment 24 Dave Jones 2006-10-20 17:34:45 EDT
No, the FC6 ISOs already got created and started pushing out to the mirror
servers, so it's too late.   It'll get into the first update thats available for
it though, which shouldn't be too far away.
Comment 25 Eric Sandeen 2006-10-20 18:51:06 EDT
I was curious too about why this doesn't seem to fail upstream (not that I've
tested it upstream, but I'll take Steve's word for it..!)

In my setup, some directories will return many entries before an EINVAL.

For example one directory comes up with num_to_fill == 128 in cifs_readdir(),
and successfully fills those.  Then it comes back for another 128 and on
the last couple iterations of the loop:

loop: i == 126
calling filldir with i_ino 8416 name seq len 3 f_pos 384
reclen 24 buf->count 32
namlen 3 NAME_OFFSET(dirent) 19
cifs_filldir got 0

loop: i == 127
calling filldir with i_ino 8417 name kfile len 5 f_pos 385
reclen 32 buf->count 8
namlen 5 NAME_OFFSET(dirent) 19
reclen > buf->count
filldir rc = -22
cifs_filldir got -22

So, is this possibly a miscalculation of num_to_fill, and an unexpected error?

Otherwise it looks like a normal "we ran out of room so return" sort of error,
but then why wouldn't it behave the same upstream?
Comment 26 Eric Sandeen 2006-10-21 23:53:14 EDT
So, this seems to be related to
"linux-2.6-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch"
if I did my patch bisection right :)

The patch doesn't much touch cifs, it just removes this line:

-       cifs_inode->vfs_inode.i_blksize = CIFS_MAX_MSGSIZE;

since i_blksize doesn't exist anymore.  I'm not sure at first glance why this
would change cifs' behavior...?

Ohhhh ok, one more tidbit, 2.6.19-rc2's generic_fillattr does:

+       stat->blksize = (1 << inode->i_blkbits);

while fc6 does:

+       stat->blksize = PAGE_CACHE_SIZE;

so fc6 is doing getdents to cifs in 4k chunks instead of 16k.

cifs should probably still cope, though.  But anyway, 99% sure that's the change
that matters.  I'll give it a test when I have a bit more time.
Comment 27 Eric Sandeen 2006-10-22 00:57:01 EDT
confirmed, that change to generic_filldir makes things work as before.
Comment 28 Konstantin Ryabitsev 2006-10-23 10:27:56 EDT
*** Bug 211832 has been marked as a duplicate of this bug. ***
Comment 29 Brian Daniels 2006-10-23 17:09:30 EDT
This looks to be the same issue?
http://lists.samba.org/archive/linux-cifs-client/2006-September/001483.html
Comment 30 Eric Sandeen 2006-10-23 17:18:22 EDT
Brian, yep, same issue.  Guess I re-discovered a known issue.  :)
Comment 31 Ludek 2006-10-27 04:19:50 EDT
This is only repot:
In 2.6.18-1.2798.fc6 kernel is this problem too.
Shared directory which contain more then 100 files (I am sorry, i don't know
exactly number) show no files and looks like empty.
Comment 32 Graham 2006-10-27 21:01:04 EDT
Adding my symptom as others seem to get slightly different manifestation.
Using CIFS from FC5 to access and backup win server 03 user files, after update
to 2.6.18 was missing about 1/3 files which turned out to various directories
completely skipped. Researched a few and found the access to folders failed if
the folder 'file' size was > 56MB. 56MB as reported by windows if there were no
subdirectories. Using different files allowed different number of files - but
not more than 56MB. If there were subdirectories then the windows reported size
could be bigger but the top directory was still limited. If I added a
subdirectory then I needed to remove a file from folder - I am assuming here
that a directory entry had a similar effect to a small file, but the size of
files in that directory had no affect. 
I am using 32bit intel system - methinks platform tag for this bug needs to be
relaxed.
Comment 33 Thomas Groß 2006-10-28 14:01:50 EDT
I see the same bug as the original Bug report (ls: reading directory .: Invalid
argument".) on two FC5 ia32 Systems. With kernel Version 2.17 everything worked
fine.
Comment 34 Steve French 2006-10-28 17:36:05 EDT
Just to summarize - 
readdir (ls) will fail on cifs with 2.6.18-fc6, and similar fc5 versions for
directories which contain about 120 files or more (it depends on the length of
the file names)

As Eric found (see above) the bug shows up because the Fedora kernel now sets
the recommended i/o size on cifs inodes incorrectly (it was set based on blkbits
which for cifs is 16K - but that was removed and it now is incorrectly set to
the smaller value of page size).  This causes filldir to run out of space, and
cifs was incorrectly returning errors on filldir - causing readdir to fail, when
it was simply temporarily out of space in the buffer.

There is a patch (see above) attached for cifs (to not pass back the return code
on filldir) which addresses the problem which has been reported.   Ideally there
should be a second change, as Shaggy and Eric noted, ie cifs_getattr also should
override the incorrect value of stat->blksize, but this is tricky because
presumably that patch is not needed in mainline (which still uses the value of
blkbits to set blksize).   Without that second change, fc will be significantly
slower on sequential operations on fast networks for certain cases (e.g. cifs
mount with forcedirectio option, and somewhat slower on readdir).   I don't know
whether it is worth making the 2nd change to cifs (to set the blocksize) until
we determine whether fc5 is going to keep the

"linux-2.6-inode-diet-eliminate-i_blksize-and-use-a-per-superblock-default.patch"

In any case - if problems with readdir on either of these fc releases - the
attached patch should address them (which if I read the comments above correctly
apparently will be included in the next fc update).
Comment 35 Eric Sandeen 2006-10-28 20:00:58 EDT
Steve, thanks for the summary.

It seems to me that we should do all 3 things:

a) update the inode diet patch to set the default VFS IO size to use blkbits in
FC, as it is upstream
b) fix cifs readdir to cope with smaller buffers just in case, since the IO size
is only a "hint" not a requirement, and
c) change cifs_getattr to set the optimal cifs IO size hint to CIFS_MAX_MSGSIZE
regardless of the VFS default, in case the VFS changes again...

sound reasonable?  My change noted in comment #26 does a), Steve - your original
attached patch does b), and c) could be changed at any later point, since w/ a)
and b) cifs should be in good shape for now.

-Eric
Comment 36 Dave Jones 2006-10-31 17:28:21 EST
*** Bug 213308 has been marked as a duplicate of this bug. ***
Comment 37 Ryan Wagoner 2006-11-02 18:21:33 EST
Any idea when this fix is going to be available as an update? This is a show
stopper from moving to FC6, which I would like to do.
Comment 38 Ryan Wagoner 2006-11-02 19:14:22 EST
Or if somebody could point me in the direction to recompiling the kernel as I
looked in to /usr/src/kernels/2.6.18-1.2200.fc5-x86_64/fs/cifs and the readdir.c
file is not there.

Sorry if this is a newbie question however I haven't recompiled a kernel before.
Comment 39 Thorsten Leemhuis 2006-11-05 06:17:18 EST
seems to be fixed in latest kernel in updates-testing for FC5 & 6
Comment 40 Steve 2006-11-11 16:12:44 EST
great work, thx!
Comment 41 Dave Jones 2006-11-12 00:45:40 EST
should be fixed in 2.6.18-1.2239.fc5 now in updates.
Comment 42 Brian Daniels 2006-11-13 15:06:44 EST
2239 seems to have fixed it on my system.
Comment 43 Jorge Escobar 2007-01-12 16:27:04 EST
Hi guys,

I am running into the same issue with 2.6.18-1.2798.fc6

Do I need to apply a patch or am I the only one?

Thanks,

Jorge
Comment 44 Steve 2007-01-12 16:43:49 EST
2.6.18-1.2869.fc6 is the actual kernel and the issue is fixed since 2.6.18-1.2239.
Comment 45 Eric Sandeen 2007-01-12 16:50:13 EST
Hmm yep should be fixed.  Can you strace the failing command, for a start?
Comment 46 Jorge Escobar 2007-01-12 17:14:58 EST
I had Fedora Core 4 and this was all working fine.

Basically I have a dev server with mounted Windows partitions:
mount -t cifs //10.1.1.4/Videos /mnt/mediavideos -o
username=Administrator,password=******,rw,domain=expotv

Then I do:
cd /mnt/mediavideos

And then "ls", I get the proper directory:
[root@dev mediavideos]# ls
Downloads  logs  Raw Files on Stor1.lnk  Transcoding

I did an strace of this command, though, and I get these messages:
execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0
chdir(0x8)                              = 6377472
link(0x1000, 0xffffffff)                = -1431654400
dup2(-453835200, -1)                    = 0
mount(NULL, 0xffffffff, 0xe761ad20, MS_NODEV, 0xe74179a0) = -1 ENOENT (No such
file or directory)
fork()                                  = 3
open(0xffffffff, 0, 034474576460)       = 0
link(0xffffffff, 0xffffffff)            = -1431650304
read(-1431650304, 0xffffffff, 1)        = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576560)       = 0
link(0x1000, 0xffffffff)                = -1431572480
link(0xe4f30118, 0xffffffff)            = -390070272
unlink(0xe4f2fb10)                      = 0
link(0xe4f2fb40, 0xffffffff)            = -387944448
read(1879047935, 0xffffffff, 3907026696) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576500)       = 0
link(0xe4f30008, 0xffffffff)            = -394264576
unlink(0xe4f2fba0)                      = 0
link(0xe4f2fbd0, 0xffffffff)            = -392146944
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576420)       = 0
link(0xe4f30048, 0xffffffff)            = -381681664
unlink(0xe4f2fb10)                      = 0
link(0xe4f2fb40, 0xffffffff)            = -379502592
link(0xe4f2fb40, 0xffffffff)            = -379494400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 034474576340)       = 0
link(0x1000, 0xffffffff)                = -1431568384
link(0xe4f300c0, 0xffffffff)            = -411041792
unlink(0xe4f2fa50)                      = 0
link(0xe4f2fa80, 0xffffffff)            = -407617536
link(0xe4f2fa80, 0xffffffff)            = -407597056
read(1879047935, 0xffffffff, 3887365296) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf000, 0, 034474575640)       = 0
link(0xe4f2ff48, 0xffffffff)            = -398458880
unlink(0xe4f2f940)                      = 0
link(0xe4f2f970, 0xffffffff)            = -396279808
link(0xe4f2f970, 0xffffffff)            = -396271616
read(1879047935, 0xffffffff, 3898691320) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf4b8, 0, 034474575120)       = 0
link(0xe4f2fd18, 0xffffffff)            = -356515840
unlink(0xe4f2f8b0)                      = 0
link(0xe4f2f8e0, 0xffffffff)            = -354406400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 034474574460)       = 0
link(0x1000, 0xffffffff)                = -1431564288
link(0xe4f2fcd8, 0xffffffff)            = -406847488
unlink(0xe4f2f6d0)                      = 0
link(0xe4f2f700, 0xffffffff)            = -404742144
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 034474574400)       = 0
link(0xe4f2fbc8, 0xffffffff)            = -377487360
unlink(0xe4f2f760)                      = 0
link(0xe4f2f790, 0xffffffff)            = -375148544
link(0xe4f2f790, 0xffffffff)            = -375144448
read(1879047935, 0xffffffff, 0)         = 0
link(0x1000, 0xffffffff)                = -1431560192
link(0x1000, 0xffffffff)                = -1431556096
sched_yield()                           = 0
unlink(0xaaabf000)                      = 0
unlink(0xaaabfe28)                      = 0
unlink(0xaaac02e0)                      = 0
unlink(0xe761a5e8)                      = 0
unlink(0xaaac0cd0)                      = 0
execve(NULL, [0xffffffff], [/* 0 vars */]) = 0
mincore(0xaaac02e0, 4294967295, 0xe4f30988) = 2560
vserver(0xaaac02e0, 0xffffffff, 0xe4f30988, 0x18, 0xaaac2c70) = 0
time(0xe4f30690)                        = 0
time(0xe4f30690)                        = 0
mknod(0xaaac02e0, 037777777777)         = 0
setpriority(0xaaac02e0 /* PRIO_??? */, 4294967295, 15) = 0
mount(0xe9614d98, 0xffffffff, 0xe4f30988, 0, 0xe9412648) = 0
chdir(0xe7b4a9f0)                       = 6377472
chdir(0x615000)                         = 6512640
fork()                                  = 3
open("ˆ¤­û", 0, 034474603440)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 511
restart_syscall(<... resuming interrupted call ...>) = 0
read(6377488, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open("ˆ$­û", 0, 034474603400)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 968
restart_syscall(<... resuming interrupted call ...>) = 0
read(6378704, 0xffffffff, 4222428184)   = 0
execve(".$­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open(0xe4f30410, 0, 034755107700)       = 0
link(0x34f2da0, 0xffffffff)             = -1431552000
read(55520672, 0xffffffff, 80884)       = 0
lchown(0xe7619bc0, -1, 3841132256)      = 0
lchown(NULL, -1, 3841132624)            = 0
fork()                                  = 3
open(0x3, 0, 034474601460)              = 0
sigsuspend([HUP])                       = 0
gettimeofday({3, 0}, {...})             = 184
gettimeofday({3, 0}, {...})             = 0
read(0, 0xffffffff, 3887372768)         = 0
open(0xe7b48780, 0, 034474533200)       = 0
link(0x1000, 0xffffffff)                = -1376030720
_exit(53)                               = ?

But I get the directory anyway.

If I now change to:
[root@dev mediavideos]# cd Transcoding/AOL\ 3\ Formats/Output/

and do ls:
[root@dev Output]# ls
ls: reading directory .: Invalid argument

This is the strace for this one:
execve("/bin/ls", ["ls"], [/* 23 vars */]) = 0
chdir(0x8)                              = 6377472
link(0x1000, 0xffffffff)                = -1431654400
dup2(-609889984, -1)                    = 0
mount(NULL, 0xffffffff, 0xe761ad20, MS_NODEV, 0xe74179a0) = -1 ENOENT (No such
file or directory)
fork()                                  = 3
open(0xffffffff, 0, 033351344060)       = 0
link(0xffffffff, 0xffffffff)            = -1431650304
read(-1431650304, 0xffffffff, 1)        = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344160)       = 0
link(0x1000, 0xffffffff)                = -1431572480
link(0xdba5cc18, 0xffffffff)            = -390070272
unlink(0xdba5c610)                      = 0
link(0xdba5c640, 0xffffffff)            = -387944448
read(1879047935, 0xffffffff, 3907026696) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344100)       = 0
link(0xdba5cb08, 0xffffffff)            = -394264576
unlink(0xdba5c6a0)                      = 0
link(0xdba5c6d0, 0xffffffff)            = -392146944
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351344020)       = 0
link(0xdba5cb48, 0xffffffff)            = -381681664
unlink(0xdba5c610)                      = 0
link(0xdba5c640, 0xffffffff)            = -379502592
link(0xdba5c640, 0xffffffff)            = -379494400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaaab000, 0, 033351343740)       = 0
link(0x1000, 0xffffffff)                = -1431568384
link(0xdba5cbc0, 0xffffffff)            = -411041792
unlink(0xdba5c550)                      = 0
link(0xdba5c580, 0xffffffff)            = -407617536
link(0xdba5c580, 0xffffffff)            = -407597056
read(1879047935, 0xffffffff, 3887365296) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf000, 0, 033351343240)       = 0
link(0xdba5ca48, 0xffffffff)            = -398458880
unlink(0xdba5c440)                      = 0
link(0xdba5c470, 0xffffffff)            = -396279808
link(0xdba5c470, 0xffffffff)            = -396271616
read(1879047935, 0xffffffff, 3898691320) = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf4b8, 0, 033351342520)       = 0
link(0xdba5c818, 0xffffffff)            = -356515840
unlink(0xdba5c3b0)                      = 0
link(0xdba5c3e0, 0xffffffff)            = -354406400
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 033351342060)       = 0
link(0x1000, 0xffffffff)                = -1431564288
link(0xdba5c7d8, 0xffffffff)            = -406847488
unlink(0xdba5c1d0)                      = 0
link(0xdba5c200, 0xffffffff)            = -404742144
read(1879047935, 0xffffffff, 0)         = 0
fork()                                  = 3
restart_syscall(<... resuming interrupted call ...>) = 832
open(0xaaabf970, 0, 033351342000)       = 0
link(0xdba5c6c8, 0xffffffff)            = -377487360
unlink(0xdba5c260)                      = 0
link(0xdba5c290, 0xffffffff)            = -375148544
link(0xdba5c290, 0xffffffff)            = -375144448
read(1879047935, 0xffffffff, 0)         = 0
link(0x1000, 0xffffffff)                = -1431560192
link(0x1000, 0xffffffff)                = -1431556096
sched_yield()                           = 0
unlink(0xaaabf000)                      = 0
unlink(0xaaabfe28)                      = 0
unlink(0xaaac02e0)                      = 0
unlink(0xe761a5e8)                      = 0
unlink(0xaaac0cd0)                      = 0
execve(NULL, [0xffffffff], [/* 0 vars */]) = 0
mincore(0xaaac02e0, 4294967295, 0xdba5d488) = 2525
vserver(0xaaac02e0, 0xffffffff, 0xdba5d488, 0x18, 0xaaac2c70) = 0
time(0xdba5d190)                        = 0
time(0xdba5d190)                        = 0
mknod(0xaaac02e0, 037777777777)         = 0
setpriority(0xaaac02e0 /* PRIO_??? */, 4294967295, 15) = 0
mount(0xe9614d98, 0xffffffff, 0xdba5d488, 0, 0xe9412648) = 0
chdir(0xe7b4a9f0)                       = 6377472
chdir(0x615000)                         = 6512640
fork()                                  = 3
open("ˆ¤­û", 0, 033351351040)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 511
restart_syscall(<... resuming interrupted call ...>) = 0
read(6377488, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open("ˆ$­û", 0, 033351351000)           = 0
link(0x1000, 0xffffffff)                = -1431650304
restart_syscall(<... resuming interrupted call ...>) = 968
restart_syscall(<... resuming interrupted call ...>) = 0
read(6378704, 0xffffffff, 4222428184)   = 0
execve(".$­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = 3
open(0xdba5cf10, 0, 034755107700)       = 0
link(0x34f2da0, 0xffffffff)             = -1431552000
read(55520672, 0xffffffff, 80884)       = 0
lchown(0xe7619bc0, -1, 3685077472)      = 0
lchown(NULL, -1, 3685077840)            = 0
fork()                                  = 3
open(0x3, 0, 033351347060)              = 0
sigsuspend([HUP])                       = 0
gettimeofday(0x61b070, 0xffffffff)      = -1 EINVAL (Invalid argument)
fork()                                  = 4
open("ˆ¤­û", 0, 033351344360)           = 0
link(0x1000, 0xffffffff)                = -1376030720
restart_syscall(<... resuming interrupted call ...>) = 2528
restart_syscall(<... resuming interrupted call ...>) = 0
read(6406320, 0xffffffff, 4222460952)   = 0
execve(".¤­û", [0xffffffff], [/* 0 vars */]) = 0
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
fork()                                  = -1 ENOENT (No such file or directory)
_exit(4)                                = ?
Comment 47 Eric Sandeen 2007-01-13 16:10:37 EST
Ok, that's a bit odd, the only EINVAL I see is from gettimeofday... and the args
to it look a bit suspicious.

Can you try again with the -f argument to strace, lots of forks in there. 
Please add it as an attachment, thanks.

-Eric
Comment 48 Jorge Escobar 2007-01-16 11:12:21 EST
Created attachment 145702 [details]
strace with -F option

Hi Eric,

Thanks for your help. Here's the strace.

Jorge
Comment 49 Eric Sandeen 2007-01-16 12:01:53 EST
Hi, need -f not -F please.

Thanks,
-Eric
Comment 50 Jorge Escobar 2007-01-16 13:32:12 EST
Created attachment 145713 [details]
New strace with -f option

Sorry, here goes.
Comment 51 Eric Sandeen 2007-01-16 13:46:02 EST
Unfortunately that's even less info, I'm not sure why.  And your ls strace
output doesn't look anything like what I see when I strace LS on fc6, at least.

I need some indication of -what- is failing when you run ls... I may have to do
some testing myself here when I get some time.

Is anyone else on this bug seeing the problem on recent kernels?
Comment 52 Jorge Escobar 2007-01-16 13:51:17 EST
Created attachment 145717 [details]
Directory contents snapshot

This is the listing of files in that directory. Basically, when I had Fedora
Core 4 in that server, I can do ls and, most importantly, fetch the directory
contents from some PHP scripts I have running in there.

Now when I navigate to that folder and type ls I get:
[root@dev AOL 3 Formats]# ls
ls: reading directory .: Invalid argument
Comment 53 Akemi Yagi 2007-01-16 14:41:38 EST
This may or may not help but just in case your problem is related to Bug 211672.
While the remote share is mounted, what do you get by this command?

cat /proc/fs/cifs/DebugData

Do you see any garbled characters?

Akemi
Comment 54 Jorge Escobar 2007-01-16 15:06:18 EST
Created attachment 145726 [details]
Cat dump

Hi Akemi,

I do see a lot of garbled characters...

I saw something about a patch for cifs on that bug you sent, but didn't quite
get why these are related.

Can you point me in the right direction?

Thanks!
Comment 55 Akemi Yagi 2007-01-16 15:21:51 EST
I do not know if the problem you are having is related to that bug.  I only
wondered what if...

However, there is a way to find out the answer.  That is to apply the patch to
your cifs and see if your problem goes away.  In any case, cifs 1.45 and newer
has this bug and it is indeed a good idea for anyone to be running the patched
version.

Akemi
Comment 56 Jorge Escobar 2007-01-16 16:07:41 EST
Hi Akemi,

Can you email me how exactly to apply this patch?

I'm experienced but not too much on patches... :)

Thanks!
Comment 57 Steve French 2007-01-16 16:41:02 EST
getting "invalid argument" on ls over cifs mounts, and only getting it after
putting on fc5 is almost certainly the same problem as was fixed by this bugfix.

Doesn't FC5 service update include this fix?   Certainly more recent kernels
have the fix.
Comment 58 Eric Sandeen 2007-01-16 17:06:51 EST
Ok, Jorge, reading back through the comments, I'm confused about which kernel
you are actually running here.

Can you be sure you are actually running the latest kernel (uname -r to check)
from FC updates, and give it another try please.  This should have been fixed
long ago.
Comment 59 Akemi Yagi 2007-01-16 17:12:49 EST
Now I see.  Jorge is running 2.6.18-1.2798.fc6 (comment #43) which is the
original FC6 kernel (without this bugfix).
Comment 60 Jorge Escobar 2007-01-16 17:15:49 EST
Right --
[root@dev corey]# uname -r
2.6.18-1.2798.fc6
Comment 61 Eric Sandeen 2007-01-16 17:28:47 EST
Right, so Jorge, please get the latest kernel from updates.

Sorry, I should have caught that a -long- time ago, misread the kernel he was
running.
Comment 62 Jorge Escobar 2007-01-24 13:27:22 EST
Hi guys,

I finally solved the problem -- the issue was that I had Fedora Core 5 with the
32 bit install, and we upgraded to the 64 bit version of Fedora Core 6, which
created a myriad of issues with different versions of libraries, etc. etc.

I did a clean install of Fedora Core 6, 32 bit, and the server is finally
running very well and so far no issues with the SATA drives freezing or the 128+
ls bug.

Thanks so much for the help, very specially to Akemi and Eric!

Keep on Fedorin'
Comment 63 idtechnology 2008-01-08 11:38:49 EST
I have the same issue on 2.6.18-1.2798.fc6, anybody can help?

tnx
Comment 64 Jon Stanley 2008-01-08 13:28:13 EST
Unfortunately, Fedora Core 6 is no longer maintained.  Could you attempt to
reproduce this on Fedora 8? 
Comment 65 Ryan Wagoner 2008-01-08 16:27:11 EST
On my FC5 box I just use the smfs kernel module and built the smbmount,
smbumount, and smbmnt binaries. You can follow the directions on this site.

http://www-user.tu-chemnitz.de/~tott/FC5-smbfs-HOWTO.html

Then just mount them as smfs shares vs cifs. This should work for FC6 with
slight modifications of the source rpms to download.
Comment 66 idtechnology 2008-01-17 09:03:14 EST
(In reply to comment #64)
> Unfortunately, Fedora Core 6 is no longer maintained.  Could you attempt to
> reproduce this on Fedora 8? 

We installed FC8, kernel 2.6.23.

On this version CIFS share works fine, thanks!

Note You need to log in before you can comment on or make changes to this bug.