Date: Tue, 18 Oct 2016 17:09:39 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 90815] [smbfs] [patch] SMBFS with character conversions sometimes hangs Message-ID: <bug-90815-3630-m5Ax6dNY43@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-90815-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-90815-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D90815 --- Comment #8 from Andrey V. Elsukov <ae@FreeBSD.org> --- (In reply to Tomoaki AOKI from comment #6) > (In reply to Andrey V. Elsukov from comment #5) >=20 > With my patch, if smb_copy_iconv() is called recursively, you're right. > If not, my patch can be better, as whole src is kept unchanged if > iconv_conv() returns -1. >=20 > *According to the prototype of iconv_conv() in src/sys/sys/iconv.h, > src is constant, so shouldn't be changed at all by iconv_conv(). >=20 > With my patch, if modified code path is executed, cp would copy with > original filename unchanged and succeeds, while with yours the file is > skipped. mb_put_mem() can allocate new mbuf and link it with existent. Imagine that = one mbuf will be not enough to store converted name. In such case smb_copy_icon= v() will be called several times for one name (to convert parts of name stored = in different mbufs). So, it is possible, that first part will be converted correctly, but second call will fail. In such case I think it is not correc= t to just copy part of name as is. But I don't know how real this scenario can be :) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-90815-3630-m5Ax6dNY43>