Date: Fri, 19 Jul 2013 13:21:19 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-fs@FreeBSD.org, zfs-devel@FreeBSD.org Subject: Re: zfs_rename: another zfs+vfs deadlock Message-ID: <51E9131F.1060707@FreeBSD.org> In-Reply-To: <20130717194557.GU5991@kib.kiev.ua> References: <51E679FD.3040306@FreeBSD.org> <20130717194557.GU5991@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 17/07/2013 22:45 Konstantin Belousov said the following: > On Wed, Jul 17, 2013 at 02:03:25PM +0300, Andriy Gapon wrote: >> A scenario to reproduce this bug could be like this. >> mkdir a >> mkdir a/b >> mv some-file a/b/ (in parallel with) stat a/b >> Of course it would have to be repeated many times to hit the right timing >> window. Also, namecache could interfere with this scenario, but I am not sure. >> > > There is no questions or proposals on how to approach the fix, JFYI mail ? I was just reporting the problem and my analysis of it. A question of "how to fix" was implied. > I recommend you to look at the ufs_checkpath() and its use in the > ufs_rename(). Thank you. That code is enlightening. I do not think that the approach is directly applicable to zfs_rename, unfortunately. But I will try to see if the same kind of approach could be used. Also, I noticed that ufs_rename() checks for cross-device rename. Should all filesystems do that or should that check belong to VFS layer (if not already done there)? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51E9131F.1060707>