Date: Sun, 22 Sep 2013 23:59:25 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, Matthew Fleming <mdf@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r255797 - head/sys/kern Message-ID: <20130922205925.GN41229@kib.kiev.ua> In-Reply-To: <CAJ-FndDHC03f==%2B_N_m2gQ==LKF9LNs=Jyf-nYjFyikuoum7Sg@mail.gmail.com> References: <201309221923.r8MJNm3u021657@svn.freebsd.org> <CAMBSHm_RYzVVm7cEEqntfChgC%2B2sC6CEonZgLob-nRKCUoLmQg@mail.gmail.com> <20130922201916.GL41229@kib.kiev.ua> <20130922203426.GM41229@kib.kiev.ua> <CAJ-FndDHC03f==%2B_N_m2gQ==LKF9LNs=Jyf-nYjFyikuoum7Sg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sun, Sep 22, 2013 at 09:49:34PM +0100, Attilio Rao wrote: > On Sun, Sep 22, 2013 at 9:34 PM, Konstantin Belousov > <kostikbel@gmail.com> wrote: > > On Sun, Sep 22, 2013 at 11:19:16PM +0300, Konstantin Belousov wrote: > >> On Sun, Sep 22, 2013 at 01:14:21PM -0700, Matthew Fleming wrote: > >> > On Sun, Sep 22, 2013 at 12:23 PM, Konstantin Belousov <kib@freebsd.org>wrote: > >> >> > > Author: kib > >> > > Date: Sun Sep 22 19:23:48 2013 > >> > > New Revision: 255797 > >> > > URL: http://svnweb.freebsd.org/changeset/base/255797 > >> > > > >> > > Log: > >> > > Increase the chance of the buffer write from the bufdaemon helper > >> > > context to succeed. If the locked vnode which owns the buffer to be > >> > > written is shared locked, try the non-blocking upgrade of the lock to > >> > > exclusive. > >> > > > >> > > PR: kern/178997 > >> > > Reported and tested by: Klaus Weber < > >> > > fbsd-bugs-2013-1@unix-admin.de> > >> > > Sponsored by: The FreeBSD Foundation > >> > > MFC after: 1 week > >> > > Approved by: re (marius) > >> > > > >> > > Modified: > >> > > head/sys/kern/vfs_bio.c > >> > > > >> > > Modified: head/sys/kern/vfs_bio.c > >> > > > >> > > ============================================================================== > >> > > --- head/sys/kern/vfs_bio.c Sun Sep 22 19:15:24 2013 (r255796) > >> > > +++ head/sys/kern/vfs_bio.c Sun Sep 22 19:23:48 2013 (r255797) > >> > > @@ -2624,6 +2624,8 @@ flushbufqueues(struct vnode *lvp, int ta > >> > > int hasdeps; > >> > > int flushed; > >> > > int queue; > >> > > + int error; > >> > > + bool unlock; > >> > > > >> > > flushed = 0; > >> > > queue = QUEUE_DIRTY; > >> > > @@ -2699,7 +2701,16 @@ flushbufqueues(struct vnode *lvp, int ta > >> > > BUF_UNLOCK(bp); > >> > > continue; > >> > > } > >> > > - if (vn_lock(vp, LK_EXCLUSIVE | LK_NOWAIT | LK_CANRECURSE) > >> > > == 0) { > >> > > + if (lvp == NULL) { > >> > > + unlock = true; > >> > > + error = vn_lock(vp, LK_EXCLUSIVE | LK_NOWAIT); > >> > > + } else { > >> > > + ASSERT_VOP_LOCKED(vp, "getbuf"); > >> > > + unlock = false; > >> > > + error = VOP_ISLOCKED(vp) == LK_EXCLUSIVE ? 0 : > >> > > + vn_lock(vp, LK_UPGRADE | LK_NOWAIT); > >> > > > >> > > >> > I don't think this is quite right. > >> > > >> > When the lock is held shared, and VOP_LOCK is implemented by lockmgr(9), > >> > (i.e. all in-tree filesystems?), LK_UPGRADE may drop the lock, and not > >> > reacquire it. This would happen when the vnode is locked shared, the > >> > upgrade fails (2 shared owners), then lockmgr(9) will try to lock EX, which > >> > will also fail (still one shared owner). The caller's lock is no longer > >> > held. > >> > > >> > Doesn't that scenario (LK_UPGRADE failing) cause problems both for the > >> > caller (unexpected unlock) and for flushbufqueues(), which expects the > >> > vnode lock to be held since lvp is non-NULL? > >> > >> Does it ? If the lock is dropped, the code is indeed in trouble. > >> Please note that LK_NOWAIT is specified for upgrade, and I believe > >> that this causes lockmgr to return with EBUSY without dropping > >> the lock. > > > > Yes, you are right, I reverted the patch. Thank you for noting this. > > > > I am bitten by unreasonable behaviour of non-blocking upgrade once more. > > It has a history. > > > > Some time ago I proposed the following patch, which was turned down. > > That time, I was able to work-around the case. For the bufdaemon helper, > > I do not see any way to avoid this, except of sometimes locking the > > reader vnode exclusive in anticipation of the too high dirty buffer > > mark. > > If you are speaking about me, you are mistaken, I never turned out this patch. > What I said is completely different: I said that LK_UPGRADE is a > completely wrong semantic because it can hide wrong things like the > one you hit today. > I wanted to see it removed and replaced by explicit LK_RELEASE + > LK_EXCLUSIVE operations. > Note that this would have avoided this patch. > > I'm completely in favour of LK_TRYUPGRADE. Excellent, I will expedite the LK_TRYUPGRADE into tree and then reinstantiate the bufdaemon helper patch. Thank you. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSP1osAAoJEJDCuSvBvK1BbjYP/2XleBxWaB+GZXZAHiyGY1Hc 3Zkn1lfOKHGJWe+a+qeGpuvEtFki4JZJbuoiW1nmT60ljksJPDmQuhVpSgsTIaH4 HfIKqDFgaGrcrKUk2nMLuHYGKjivY65/sMTMAD4EQxk7OGby25ejmS4cY7NvnuVE jbQ3YijrbsVthJrb7BkXUfZB2GBoZ9AYC+/EJfJDZuJeEPZxsLSjcQTFligIhMjQ t96N/dHpxpbSg935sN86LvKpW1W2ttsznrdxlJaNcUbofLlNpapXEx6TovUd5dS2 K6Co6EnV26RAhSZtMylM7fcEBfyy9Bpllxe/dP4xdDlwuWjLMXMzwXN6ZduySalU UoCXJcGD7q0eflEPWq88ehgKyr9ty0Cn+eMMgY/tNkbuckPxcztdCESkBmseDgAg CfuNGI3jKQAUk3Fh0bFuN4gwk1p5Z0I9iSQNmvwx8d1S7Ec8ImW3VvEoDFy30gKW lpFRI61WK8N3Sd6hBse/C3nr/bYLb1+rF4mMr1Lqf+uidaOJsnbSltSJtYc4DKwc zKwcZaPOHGAfuRsyYB82vtT+xUfDs0dJGqj9tBBV3ToSCWOqaLqivYF9M67Qhzrn InAG+iKtjLioqgOsOfNWozWIryVe/YgCshbI38yMI7uAGp3qu+HMmqHBKs8E00J9 SDlmIjtYNnU/WxbpGh3s =donU -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130922205925.GN41229>