From owner-svn-src-all@freebsd.org Thu Jul 30 22:33:11 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F2CF5368B44; Thu, 30 Jul 2020 22:33:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BHlYM3QwCz42sw; Thu, 30 Jul 2020 22:33:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 06UMWvvj056787 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 31 Jul 2020 01:33:00 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 06UMWvvj056787 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 06UMWvm3056786; Fri, 31 Jul 2020 01:32:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 31 Jul 2020 01:32:57 +0300 From: Konstantin Belousov To: Conrad Meyer Cc: src-committers , svn-src-all , svn-src-head Subject: Re: svn commit: r363482 - in head/sys: kern sys Message-ID: <20200730223257.GL2551@kib.kiev.ua> References: <202007241734.06OHY53J080448@repo.freebsd.org> <20200728184152.GH2551@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4BHlYM3QwCz42sw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2020 22:33:12 -0000 On Thu, Jul 30, 2020 at 03:13:19PM -0700, Conrad Meyer wrote: > Hi Konstantin, > > On Tue, Jul 28, 2020 at 11:42 AM Konstantin Belousov > wrote: > > > > On Fri, Jul 24, 2020 at 05:34:05PM +0000, Conrad Meyer wrote: > > > ... > > > --- head/sys/kern/vfs_bio.c Fri Jul 24 17:32:10 2020 (r363481) > > > +++ head/sys/kern/vfs_bio.c Fri Jul 24 17:34:04 2020 (r363482) > > > @@ -3849,7 +3849,7 @@ getblkx(struct vnode *vp, daddr_t blkno, daddr_t dblkn > > > ... > > > + /* Attempt lockless lookup first. */ > > > + bp = gbincore_unlocked(bo, blkno); > > > + if (bp == NULL) > > > + goto newbuf_unlocked; > > > + > > > + lockflags = LK_EXCLUSIVE | LK_SLEEPFAIL | > > > + ((flags & GB_LOCK_NOWAIT) ? LK_NOWAIT : 0); > > > + > > > + error = BUF_TIMELOCK(bp, lockflags, NULL, "getblku", slpflag, > > > + slptimeo); > > I realized that this is not safe. There is an ordering between buffer > > types that defines which order buffer locks should obey. For instance, > > on UFS the critical order is inode buffer -> snaplk -> cg buffer, or > > data block -> indirect data block. Since buffer identity can change under > > us, we might end up waiting for a lock of type that is incompatible with > > the currently owned lock. > > > > I think the easiest fix is to use LK_NOWAIT always, after all it is lockless > > path. ERESTART/EINTR checks below than can be removed. > > Thanks, that makes sense to me. Please see https://reviews.freebsd.org/D25898 . > > (For the UFS scenario, I think this requires an on-disk sector > changing identity from one kind to another? I believe lblknos are > mostly statically typed in UFS, but it could happen with data blocks > and indirect blocks? Of course, UFS is not the only filesystem.) For UFS, it is enough for buffer to change its identity due to reclaim. We do not pin buffers to device/block number for their lifetime. So buffer might be freed and reassigned to different block under us.