smbfs broken in 2.4.25? (Too many open files in system)

smbfs broken in 2.4.25? (Too many open files in system)

[Alain Fauconnet]

Hello,

Hope I won't get flamed for this, I've spent a  fair  amount  of  time
searching archives and news without finding anything close enough.

Since I've updated my Slackware 8.0 desktop to the 2.4.25 kernel (from
source, loaded .config from .24)  I  can't  access  shares  off  Win9x
systems reliably (98/98SE tested). smbfs is loaded as a module.

I get random 'Too many open files in system'. E.g.:

# /usr/local/samba/bin/smbmount //w98box/c /dosc -o password=xxxxx
# ls /dosc
/bin/ls: /dosc: Too many open files in system
(command repeated several times: hit up arrow and enter... and then:)
# ls /dosc
ASD.LOG*       BIN/          CONFIG.TXT*  MSDOS.SYS*       SUHDLOG.---*
AUTOEXEC.001*  BOOTLOG.DMA*  CONFIG.W95*  MSDOS.W95*       SUHDLOG.BAK*
(...works!)

It seems to randomly succeed or fail, with a majority of failures.
I've been able to catch messages like the following in syslog:

Feb 26 13:42:27 alain kernel: smb_lookup: find windows/MSDFMAP.INI failed, error=-23

This used to work flawlessly in 2.4.24.
The Gods of Linux forgive me, I've copied ./fs/smbfs/* and
./include/linux/smb*.h from the 2.4.24 tree, "make modules" and
reloaded smbfs.o: now it works all the time!

Some background: Samba is v2.2.8a built from source.

Any hints? I've tried rebuilding smbfs with debug options in the
Makefile, SMBFS_PARANOIA on and off, I haven't been able to
make much sense out of it. It keeps failing in every configuration.

Greets,
_Alain_

Re: smbfs broken in 2.4.25? (Too many open files in system)

[Urban Widmark]

On Thu, 26 Feb 2004, Alain Fauconnet wrote:

> I get random 'Too many open files in system'. E.g.:
> 
> # /usr/local/samba/bin/smbmount //w98box/c /dosc -o password=xxxxx
> # ls /dosc
> /bin/ls: /dosc: Too many open files in system
> (command repeated several times: hit up arrow and enter... and then:)
> # ls /dosc
> ASD.LOG*       BIN/          CONFIG.TXT*  MSDOS.SYS*       SUHDLOG.---*
> AUTOEXEC.001*  BOOTLOG.DMA*  CONFIG.W95*  MSDOS.W95*       SUHDLOG.BAK*
> (...works!)

The "too many files" part is what smbfs translates the server error into.
ethereal calls it a "Non specific error code" (ERRSRV/ERRerror).

The problem here is that for some reason win98 doesn't always handle that 
a client requests info on the / inode with too short interval. It 
often understands the request (for me about 14 times out of 15), but 
sometimes it just fails.


2.4.25 has some code that was backported from 2.6, where the "win95" 
codepath was changed. I need to check that, but it probably doesn't work 
there either.

Patch below works for me. It is copied from the smbfs readdir code that 
happens to have the same problem with win9x.
(Well, it's the same request so ... :)

/Urban


diff -urN -X exclude linux-2.4.25-orig/fs/smbfs/proc.c linux-2.4.25-smbfs/fs/smbfs/proc.c
--- linux-2.4.25-orig/fs/smbfs/proc.c	Thu Feb 26 17:41:19 2004
+++ linux-2.4.25-smbfs/fs/smbfs/proc.c	Thu Feb 26 20:21:21 2004
@@ -2615,9 +2615,18 @@
 	struct inode *inode = dir->d_inode;
 	int result;
 
+ retry:
 	result = smb_proc_getattr_trans2_std(server, dir, attr);
-	if (result < 0)
+	if (result < 0) {
+		if (server->rcls == ERRSRV && server->err == ERRerror) {
+			/* a damn Win95 bug - sometimes it clags if you 
+			   ask it too fast */
+			current->state = TASK_INTERRUPTIBLE;
+			schedule_timeout(HZ/5);
+			goto retry;
+		}
 		goto out;
+	}
 
 	/*
 	 * None of the other getattr versions here can make win9x

Re: smbfs broken in 2.4.25? (Too many open files in system)

[Alain Fauconnet]

On Thu, Feb 26, 2004 at 08:24:08PM +0100, Urban Widmark wrote:
> On Thu, 26 Feb 2004, Alain Fauconnet wrote:
> 
> > I get random 'Too many open files in system'. E.g.:
> > 
> > # /usr/local/samba/bin/smbmount //w98box/c /dosc -o password=xxxxx
> > # ls /dosc
> > /bin/ls: /dosc: Too many open files in system
> > (command repeated several times: hit up arrow and enter... and then:)
> > # ls /dosc
> > ASD.LOG*       BIN/          CONFIG.TXT*  MSDOS.SYS*       SUHDLOG.---*
> > AUTOEXEC.001*  BOOTLOG.DMA*  CONFIG.W95*  MSDOS.W95*       SUHDLOG.BAK*
> > (...works!)
> 
> The "too many files" part is what smbfs translates the server error into.
> ethereal calls it a "Non specific error code" (ERRSRV/ERRerror).
> 
> The problem here is that for some reason win98 doesn't always handle that 
> a client requests info on the / inode with too short interval. It 
> often understands the request (for me about 14 times out of 15), but 
> sometimes it just fails.
> 
> 
> 2.4.25 has some code that was backported from 2.6, where the "win95" 
> codepath was changed. I need to check that, but it probably doesn't work 
> there either.
> 
> Patch below works for me. It is copied from the smbfs readdir code that 
> happens to have the same problem with win9x.
> (Well, it's the same request so ... :)
>
[patch edited out for brievety, see archives]

Thanks Urban, that did it.

I however  observe  the  following:  when  using  the  patched  2.4.25
module,  a  "ls  /dosc" (where /dosc is the dir I mount the shared C:
drive  of  a  WIN98  box  into)  sometimes shows a noticeable delay. I
suspect it is when the patched code does a retry. E.g.:

# time ls /dosc >/dev/null
0.000u 0.000s 0:00.20 0.0%      0+0k 0+0io 157pf+0w
(noticeable delay)
# time ls /dosc > /dev/null
0.000u 0.010s 0:00.00 0.0%      0+0k 0+0io 157pf+0w
(normal)
# time ls /dosc > /dev/null
0.010u 0.000s 0:00.80 1.2%      0+0k 0+0io 157pf+0w
(even more noticeable delay)

This happens at most 1 time out of 5, so the sample above
doesn't match reality.

If I load the module build from 2.4.24 sources instead:
# umount /dosc
# rmmod smbfs
# insmod ../smbfs.2.4.24/smbfs.o
# /usr/local/samba/bin/smbmount //w98box/c /dosc -o password=xxxxx

this delay goes away:
# time ls /dosc > /dev/null
0.000u 0.000s 0:00.00 0.0%      0+0k 0+0io 157pf+0w
(normal, consistently)

Not  a  big deal probably, and I'm not sure that kernel developers are
that  much motivated to work around bugs in Win9x, but somehow I think
that the 2.4.24 smbfs code didn't trigger this bug at all, whereas the
new  code  does  trigger  it  and  thus  needs  these delayed retries.

Looking   at   the   code   of   both   versions,   it   seems    that
smb_proc_getattr_95()  (where  the  patch  you've  posted  lies)  uses
smb_proc_getattr_trans2_std()  whereas  the   old   code   seemed   to
completely avoid it in the W95 code path:

>From 2.4.24's ./fs/smbfs/proc.c:
========================================================================
        /*
         * Select whether to use core or trans2 getattr.
         * Win 95 appears to break with the trans2 getattr.
         */
        if (server->opt.protocol < SMB_PROTOCOL_LANMAN2 ||
            (server->mnt->flags & (SMB_MOUNT_OLDATTR|SMB_MOUNT_WIN95)) ) {  
                result = smb_proc_getattr_core(server, dir, fattr);
        } else {
                if (server->mnt->flags & SMB_MOUNT_DIRATTR)
                        result = smb_proc_getattr_ff(server, dir, fattr);
                else
                        result = smb_proc_getattr_trans2(server, dir, fattr);
        }
========================================================================

Am I completely off track here?

Greets,
_Alain_

Re: smbfs broken in 2.4.25? (Too many open files in system)

[Urban Widmark]

On Fri, 27 Feb 2004, Alain Fauconnet wrote:

> Looking   at   the   code   of   both   versions,   it   seems    that
> smb_proc_getattr_95()  (where  the  patch  you've  posted  lies)  uses
> smb_proc_getattr_trans2_std()  whereas  the   old   code   seemed   to
> completely avoid it in the W95 code path:
> 
> >From 2.4.24's ./fs/smbfs/proc.c:
> ========================================================================
>         /*
>          * Select whether to use core or trans2 getattr.
>          * Win 95 appears to break with the trans2 getattr.
>          */
>         if (server->opt.protocol < SMB_PROTOCOL_LANMAN2 ||
>             (server->mnt->flags & (SMB_MOUNT_OLDATTR|SMB_MOUNT_WIN95)) ) {  
>                 result = smb_proc_getattr_core(server, dir, fattr);
>         } else {
>                 if (server->mnt->flags & SMB_MOUNT_DIRATTR)
>                         result = smb_proc_getattr_ff(server, dir, fattr);
>                 else
>                         result = smb_proc_getattr_trans2(server, dir, fattr);
>         }
> ========================================================================

Yes, I know.

Unfortunately we want the trans2 version when reading directories, the
core version does not understand "long" filenames. The previous 2.4 code
does that, but uses the "core" version for getting file attributes.

The problem with using two different requests is that they have different
resolutions on file modification times. The core can only return odd- or
even-numbered seconds (I forget which). This makes programs like 'tar'
complain if the date they read from the dir does not always match the date
they read from getattr.


Now, when looking at the output of ethereal it re-reads attributes for the
/ inode a lot. It's not supposed to do a refresh if it thinks it has a
fairly recent copy, see smb_revalidate_inode and SMB_MAX_AGE. That could 
be making this problem worse.


> Am I completely off track here?

No, but you didn't know the background.

Btw, if you mount using the "oldattr" mount option you should get the
"core" behaviour back.

/Urban