Bug 202419

Summary:	Opening files hangs calling openat() while CWD is on a smbfs mount
Product:	Base System	Reporter:	martin
Component:	kern	Assignee:	Bugmeister <bugmeister>
Status:	Closed Overcome By Events
Severity:	Affects Only Me	CC:	xelalex_maker
Priority:	---
Version:	10.1-RELEASE
Hardware:	amd64
OS:	Any

Description martin 2015-08-18 15:08:07 UTC

Scenario:

- server serves files with Samba 3.6
- client mounts with smbfs

Problem description:

- change directory to the smbfs-mounted filesystem on client
- try to start vim (not vi!), evince, libreoffice or similar (you don't need to open a file from smbfs!)
- truss shows that it hangs calling openat in infinite loop

truss output:

openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3)
openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3)
openat(0xffffff9c,0x7fffffffc6b0,0x100000,0x0,0x7ff7fe43c39f,0x8080808080808080) = 499 (0x1f3)
[ repeating infinitely ]

Further details:

- while current working directory is inside a smbfs-mountpoint, it is also not possible to open files on locally mounted filesystems

Mount description in /etc/fstab:

//username@servername/remotefs   /net/server/remotefs  smbfs   rw,noauto,-N,-W=DOMAIN,-u=username,-g=groupname    0       0

(*) remark: I use noauto because there is a race condition with the network initialization which forces me to mount after a 10s sleep in /etc/rc.local (I think this problem is not related with the one described here)


Disclaimer:

It might be a samba misconfiguration. I am not fully sure what happens here.

--
Martin

Comment 1 Alexander Klein 2016-10-25 06:33:54 UTC

This has been a problem for me since early 2015, and it appears quite reliably with vi from /usr/bin, too.

My SMBFS-Options are:

rw,noexec,nosuid,-f=0666,-d=0777,-u=nobody,-g=nobody

and the share is provided by Samba version 3.6.12-1.fc17 with no problems whatsoever when connecting from Linux or Windows.

Truss gives me an infinite stream of identical messages like:

openat(AT_FDCWD,"�.db",O_CLOEXEC,00)             = 499 (0x1f3)

Attaching gdb to the locked process produces the following backtrace:

#0  0x2822b0a1 in _openat () from /lib/libc.so.7
#1  0x281d8ac8 in open () from /lib/libc.so.7
#2  0x281d6f34 in _citrus_map_file () from /lib/libc.so.7
#3  0x281d31d0 in _citrus_mapper_set_persistent () from /lib/libc.so.7
#4  0x281d33c5 in _citrus_mapper_set_persistent () from /lib/libc.so.7
#5  0x281a8951 in _citrus_lookup_factory_convert () from /lib/libc.so.7
#6  0x281a65d5 in __bsd_iconv_open () from /lib/libc.so.7
#7  0x281a6543 in __bsd_iconv_open () from /lib/libc.so.7
#8  0x08052826 in conv_enc (sp=0x28834a00, option=23, enc=0x288331c8 "UTF-8")
            at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:405
#9  0x080520be in conv_init (orig=0x28834400, sp=0x28834a00)
                              at /usr/src/usr.bin/vi/../../contrib/nvi/common/conv.c:360
#10 0x0806df71 in screen_init (gp=0x28803000, orig=0x28834400, spp=0x28803018)
                                                                  at /usr/src/usr.bin/vi/../../contrib/nvi/common/screen.c:118
#11 0x080a20c9 in v_ecl_init (sp=0x28834400) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:638
#12 0x080a1a32 in v_ecl_log (sp=0x28834400, tp=0x28862100)

       at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:587
#13 0x080a17ec in v_ex (sp=0x28834400, vp=0xbfbfe538)

              at /usr/src/usr.bin/vi/../../contrib/nvi/vi/v_ex.c:376
#14 0x080b9174 in vi (spp=0xbfbfe838) at /usr/src/usr.bin/vi/../../contrib/nvi/vi/vi.c:230
#15 0x08060e23 in editor (gp=0x28803000, argc=0, argv=0xbfbfe954)

                   at /usr/src/usr.bin/vi/../../contrib/nvi/common/main.c:422
#16 0x0804d5e0 in main (argc=1, argv=0xbfbfe950)

                         at /usr/src/usr.bin/vi/../../contrib/nvi/cl/cl_main.c:119


Digging deeper into the issue, I also linked vi against a temporary libc built with debug-information, but gdb threw an error related to the format of the symbol table, so the following information may have to be taken with a grain of salt:

(gdb) bt
#0  0x2822b0a1 in ?? ()
#1  0x281d8ac8 in ?? ()
#2  0xffffff9c in ?? ()
#3  0xbfbfc958 in ?? ()
#4  0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=0x8, node=0x282d2dc0)
    at /usr/src/lib/libc/jemalloc_extent.c:25
#5  0x281d6f34 in ?? ()
#6  0xbfbfc958 in ?? ()
#7  0x00100000 in __jemalloc_extent_tree_szad_remove (rbtree=0x282d2b88, node=0x284000c8)
    at /usr/src/lib/libc/jemalloc_extent.c:25
#8  0x281d31d0 in ?? ()
#9  0xbfbfc950 in ?? ()
#10 0xbfbfc958 in ?? ()
#11 0x2829aac0 in ?? ()
#12 0xbfbfcddc in ?? ()
#13 0x288a700c in ?? ()
#14 0x080e3b30 in optarg@@FBSD_1.0 ()
#15 0x00000000 in ?? ()

Comment 2 Alexander Klein 2016-10-25 06:42:54 UTC

P.s.: This bug persists on 10.3-RELEASE-p7 FreeBSD 10.3-RELEASE-p7 i386, and does it really belong to the "kern" category?

Comment 3 Alexander Klein 2016-12-01 10:12:41 UTC

See also the penultimate comment regarding a hang in vim made on 18th August 2015:

https://github.com/vim/vim/issues/330

The backtrace is very similar to mine.

Comment 4 Mark Linimon freebsd_committer

2025-01-26 19:05:09 UTC

^Triage: I'm sorry that this PR did not get addressed in a timely fashion.

By now, the version that it was created against is long out of support.
Please re-open if it is still a problem on a supported version.