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=3D225960 --- 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 h= eld. And that gives a false impression that the lock is indeed held across the c= all. 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 =3D=3D 0 && cp->acw =3D=3D 0 && cp->ace =3D=3D 0) de++; And if that ever happens and we have extra grabs on cp->ace, then the follo= wing condition will never be true (because cp->ace + de > 1): /* ... and let go of it on last close */ if ((cp->acr + dr) =3D=3D 0 && (cp->acw + dw) =3D=3D 0 && (cp->ace = + de) =3D=3D 1) de--; --=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-225960-8-oIvLJBZGy1>