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=90815 --- 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) > > 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. > > *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(). > > 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_iconv() 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 correct to just copy part of name as is. But I don't know how real this scenario can be :) -- 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>