>Number: 182963 >Category: kern >Synopsis: [smbfs]Changeset r255138 broke smbfs in head and stable/10 >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Oct 14 09:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Tomoaki AOKI >Release: head, stable/10 >Organization: >Environment: FreeBSD ***.***.*** 10.0-BETA1 FreeBSD 10.0-BETA1 #1 r256425M: Sun Oct 13 19:56:57 JST 2013 ***@***.***.***:/usr/obj/usr/src/sys/GENERIC amd64 >Description: After r255138, access to smb/cifs shares stops working correctly.
First I tried FreeBSD-10.0-ALPHA5-amd64-memstick.img to evaluate for future transfer to stable/10 and noticed accessing to mounted smbfs share is quite unstable. If all directories in path contains a few entries, ls worked OK. But if accessing any directories contains abouto 100 or more entries, ls works abnormally. For example, running even %ls /path/to/directory/containing/100_or_more/files erroneously traverses to target's subdirectores, drops many entries randomly, and needs quite long times. So I installed ALPHA5 to a VirtualBox VM, configured smbfs-related same as my stable/9 host for testing. Latest modifications in sys/fs/smbfs and sys/netsmb is r254627 and r255219 each, so I tested r254627 and r255218, and resulted in OK for r254627 and NG for r255218. After testing for some suspicious revisions, I finally determined the error is reproduced in r255138, while r255136 works OK. If any questions, please contact me via The FreeBSD Forums, as my email address is filled with SPAMs and non white-listed mail should be missed, results in no response. I have registerd The FreeBSD Forums as T-Aoki. Replying to thread I created http://forums.freebsd.org/showthread.php?t=42502 is OK. >How-To-Repeat: Boot from affected revision and ls somewhere in smb/cifs share containing about 100 files/directories in it. Even if directory contents are 10 or less, large file, such as .tgz, cannot read correctly (stops transferring in some points). All ALPHA1 to 5 and BETA1 should be sufficient to repeat. Even if ALPHA with debugging options, no errors are logged. >Fix: Case 1: Revert r255138 and buildkernel / installkernel. Case 2: Alternatively to Case 1, apply changes in attached diff to sys/netsmb/smb_trantcp.c Maybe, the cause is smb_trantcp.c does not chase struct sockbuf modification. Patch attached with submission follows: Index: /usr/src/sys/netsmb/smb_trantcp.c =================================================================== --- /usr/src/sys/netsmb/smb_trantcp.c (revision 256425) +++ /usr/src/sys/netsmb/smb_trantcp.c (working copy) @@ -155,8 +155,8 @@ SOCKBUF_LOCK(&so->so_rcv); soupcall_set(so, SO_RCV, nb_upcall, nbp); SOCKBUF_UNLOCK(&so->so_rcv); - so->so_rcv.sb_timeo = (5 * hz); - so->so_snd.sb_timeo = (5 * hz); + so->so_rcv.sb_timeo = (5 * SBT_1S); + so->so_snd.sb_timeo = (5 * SBT_1S); error = soreserve(so, nbp->nbp_sndbuf, nbp->nbp_rcvbuf); if (error) goto bad; >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
