Re: cifs: ls of mount point gives input/output error (probablyrelated to CIFS: getdents() broken for large dirs)

From: Jeff Layton
Date: Fri Dec 30 2011 - 08:11:38 EST


On Fri, 30 Dec 2011 11:04:59 +0200
Konstantinos Skarlatos <k.skarlatos@xxxxxxxxx> wrote:

> On 29/12/2011 3:54 ÎÎ, Konstantinos Skarlatos wrote:
> > On ÎÎÎÏÏÎ, 29 ÎÎÎÎÎÎÏÎÎÏ 2011 3:39:30 ÎÎ, Jeff Layton wrote:
> >> On Thu, 29 Dec 2011 12:30:18 +0200
> >> Konstantinos Skarlatos<k.skarlatos@xxxxxxxxx> wrote:
> >>
> >>> On 29/12/2011 4:04 ÏÎ, Jeff Layton wrote:
> >>>> On Thu, 29 Dec 2011 02:08:57 +0200
> >>>> Konstantinos Skarlatos<k.skarlatos@xxxxxxxxx> wrote:
> >>>>
> >>>>> I mount via cifs a windows XP share, df gives me correct sizes,
> >>>>> but when
> >>>>> I ls the mount point i get input/output error.
> >>>>> strace: http://pastebin.com/WXf8M1nu
> >>>>>
> >>>>> mount --verbose -t cifs -o username=administrator,password=blahblah
> >>>>> //192.168.0.11/jobs /mnt/backups/montaz/jobs
> >>>>> mount.cifs kernel mount options:
> >>>>> ip=192.168.0.11,unc=\\192.168.0.11\jobs,,ver=1,user=administrator,pass=********
> >>>>>
> >>>>>
> >>>>> df
> >>>>> //192.168.0.11/jobs 114464
> >>>>> 105196 9268 92% /mnt/backups/montaz/jobs
> >>>>>
> >>>>> ls /mnt/backups/montaz/jobs/
> >>>>> ls: reading directory /mnt/backups/montaz/jobs/: Input/output error
> >>>>> total 0
> >>>>>
> >>>>> the fun thing is that i can cd to a lower level directory, and ls
> >>>>> works
> >>>>> fine there! only the mount point has the problem
> >>>>>
> >>>>> ls /mnt/backups/montaz/jobs/test
> >>>>> total 44K
> >>>>> drwxr-xr-x 1 root root 0 Apr 30 2010 blah blah/
> >>>>> ......
> >>>>>
> >>>>> kernel version 3.2rc7
> >>>>>
> >>>>> this seems to be related to :
> >>>>> https://lkml.org/lkml/2011/8/1/427
> >>>>> Re: [3.0.0+][Regression][Bisected] CIFS: getdents() broken for
> >>>>> large dirs
> >>>>>
> >>>> Hmmm, maybe. What makes you think that it's related? What sort of
> >>>> server are you seeing this against?
> >>> Windows XP service pack 2 (greek)
> >>
> >>
> >> How many files are in the directory?
> >>
> > 140 folders and 20 files
> >
> Attached is a tcp dump of my session.

I tried reproducing this here, but wasn't able to. Testing against my
xp box worked fine.

Most likely, the FIND_FILE responses are falling afoul of the code in
coalesce_t2 or check2ndT2. Unfortunately that code is pretty
complicated and I'm not certain what the problem actually is...

One thing that's interesting is that the total data being sent in the
request is rather large (16336 bytes). I think that's legit, but maybe
it's exceeding the end of the buffer once we try to coalesce it.

Would it be possible to get the cFYI output from this test?

Is this a regression? Did it work with earlier kernels and only
recently start failing?

--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/