Date: Fri, 20 May 2016 21:33:22 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Evans <brde@optusnet.com.au> Cc: Konstantin Belousov <kostikbel@gmail.com>, fs@freebsd.org Subject: Re: fix for per-mount i/o counting in ffs Message-ID: <20160520212839.E1436@besplex.bde.org> In-Reply-To: <20160520194427.W1170@besplex.bde.org> References: <20160518061040.D5948@besplex.bde.org> <20160518070252.F6121@besplex.bde.org> <20160517220055.GF89104@kib.kiev.ua> <20160518084931.T6534@besplex.bde.org> <20160518110834.GJ89104@kib.kiev.ua> <20160519065714.H1393@besplex.bde.org> <20160519094901.O1798@besplex.bde.org> <20160519120557.A2250@besplex.bde.org> <20160519104128.GN89104@kib.kiev.ua> <20160520074427.W1151@besplex.bde.org> <20160520092348.GV89104@kib.kiev.ua> <20160520194427.W1170@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
PS (sigh): On Fri, 20 May 2016, Bruce Evans wrote: > On Fri, 20 May 2016, Konstantin Belousov wrote: > >> On Fri, May 20, 2016 at 09:27:38AM +1000, Bruce Evans wrote: >>> ... >>> I now see another cleanup: don't goto out when g_vfs_open() fails. This >>> depends on it setting cp to NULL and leaving nothing to clean when it >>> fails. It has no man page and this detail is documented in its source >>> code. >> Then I would need to add another NULL assignment, VOP_UNLOCK etc. > > g_vfs_open() already sets cp to NULL when it fails, and the cleanup > depends on that now, but it is just as good to depend on no cleanup > being needed on failure. You do need another dev_rel(). Oops, you mean another NULL assignment (atomic op) for cleaning up si_mountpt. I got that right at the end where I moved things to g_vfs_open(). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160520212839.E1436>