Date: Fri, 16 Feb 2018 21:44:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 225960] zfs: g_access leak when unmounting UFS on a zvol Message-ID: <bug-225960-8-oIvLJBZGy1@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-225960-8@https.bugs.freebsd.org/bugzilla/> References: <bug-225960-8@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=225960 --- Comment #5 from Andriy Gapon <avg@FreeBSD.org> --- I now think that this could be a / the deep problem in GEOM. The problem is that g_access() must be called with the GEOM topology lock held. And that gives a false impression that the lock is indeed held across the call. But this isn't true because many classes, ZVOL being one of the many, need to perform I/O in their access method. So, they must drop and pick up the topology lock. That, of course, can break many assumptions. Specifically, looking at g_slice_access() we can see that the code assumes that all invocations are serialized. Indeed, if another call to g_slice_access() is permitted while the consumer's access bits are not updated yet, then the following condition can be true multiple times: /* On first open, grab an extra "exclusive" bit */ if (cp->acr == 0 && cp->acw == 0 && cp->ace == 0) de++; And if that ever happens and we have extra grabs on cp->ace, then the following condition will never be true (because cp->ace + de > 1): /* ... and let go of it on last close */ if ((cp->acr + dr) == 0 && (cp->acw + dw) == 0 && (cp->ace + de) == 1) de--; -- 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-225960-8-oIvLJBZGy1>