From owner-svn-src-all@FreeBSD.ORG Sun Sep 22 20:49:37 2013
Return-Path: <owner-svn-src-all@FreeBSD.ORG>
Delivered-To: svn-src-all@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by hub.freebsd.org (Postfix) with ESMTP id 6798E7D3;
Sun, 22 Sep 2013 20:49:37 +0000 (UTC)
(envelope-from asmrookie@gmail.com)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com
[IPv6:2a00:1450:400c:c00::229])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by mx1.freebsd.org (Postfix) with ESMTPS id 85BFD25D3;
Sun, 22 Sep 2013 20:49:36 +0000 (UTC)
Received: by mail-wg0-f41.google.com with SMTP id l18so1456494wgh.0
for <multiple recipients>; Sun, 22 Sep 2013 13:49:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:reply-to:sender:in-reply-to:references:date:message-id
:subject:from:to:cc:content-type;
bh=TemLH2bN4ERmQ5+laFADrJ9yDxQMGCt9LF2frcks2YI=;
b=AjtR8Obw1HwNJ3Gf2Dt796xSCU3KesFAgOKKFsRuhbYVnzdYis2Plj5/eOafzaiMDA
6KnxS1wCxpPOAV0/1NRzu22Aj2JvAQIs8rUIuPFibhW0YHUyL1LKzt+xgt9kJ3Zee3c9
QCY5UByobVC6kik2ao0ca8TFwUBcVZTrlTi12AZJIEQpbRe0CB5DHU1HRPcEYp2mqZa4
r52H+Omzzm9t97EjcleRzUmhSz2OiIFU/0XS9sauFQgIO2XYBEF45KXTqUxVmddAhI6b
L6Bm3dKWKP6QgXpSC6BY71cpqkOO93kPJ2f5miJXqIovHi04KjsPb68NBdkmn74Gjs2M
QU3Q==
MIME-Version: 1.0
X-Received: by 10.181.12.104 with SMTP id ep8mr10772969wid.54.1379882974909;
Sun, 22 Sep 2013 13:49:34 -0700 (PDT)
Sender: asmrookie@gmail.com
Received: by 10.216.189.129 with HTTP; Sun, 22 Sep 2013 13:49:34 -0700 (PDT)
In-Reply-To: <20130922203426.GM41229@kib.kiev.ua>
References: <201309221923.r8MJNm3u021657@svn.freebsd.org>
<CAMBSHm_RYzVVm7cEEqntfChgC+2sC6CEonZgLob-nRKCUoLmQg@mail.gmail.com>
<20130922201916.GL41229@kib.kiev.ua>
<20130922203426.GM41229@kib.kiev.ua>
Date: Sun, 22 Sep 2013 21:49:34 +0100
X-Google-Sender-Auth: 8E3RDbGZ_YqeqT-4uL_AF04XxdA
Message-ID: <CAJ-FndDHC03f==+_N_m2gQ==LKF9LNs=Jyf-nYjFyikuoum7Sg@mail.gmail.com>
Subject: Re: svn commit: r255797 - head/sys/kern
From: Attilio Rao <attilio@freebsd.org>
To: Konstantin Belousov <kostikbel@gmail.com>
Content-Type: text/plain; charset=UTF-8
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>
X-BeenThere: svn-src-all@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: attilio@FreeBSD.org
List-Id: "SVN commit messages for the entire src tree \(except for "
user" and " projects" \)" <svn-src-all.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all>
List-Post: <mailto:svn-src-all@freebsd.org>
List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-all>,
<mailto:svn-src-all-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Sep 2013 20:49:37 -0000
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.
Attilio