From owner-freebsd-fs@freebsd.org Wed Jun 5 19:13:17 2019 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6600115B64B6 for ; Wed, 5 Jun 2019 19:13:17 +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) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7CF5F8F385; Wed, 5 Jun 2019 19:13:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x55JD8ra055514 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 5 Jun 2019 22:13:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x55JD8ra055514 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x55JD8sS055513; Wed, 5 Jun 2019 22:13:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 5 Jun 2019 22:13:08 +0300 From: Konstantin Belousov To: alan somers Cc: Alan Somers , freebsd-fs Subject: Re: Regression test for vn_io_fault Message-ID: <20190605191308.GY75280@kib.kiev.ua> References: <20190605180552.GX75280@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.0 (2019-05-25) 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 19:13:17 -0000 On Wed, Jun 05, 2019 at 12:58:21PM -0600, alan somers wrote: > Thanks for the link. But I can't tell what the expected failure mode is. > Is it supposed to run until it deadlocks? My idea is to rely on witness. > It would just run once, and then query witness to see if there was a LOR. Yes, the failure is a deadlock. I doubt that witness can catch it at all, with the current structure of page fault handler. Try to turn use of vn_io_fault off and see witness warnings with upsdl. > -Alan > > On Wed, Jun 5, 2019, 12:06 PM Konstantin Belousov > wrote: > > > On Wed, Jun 05, 2019 at 10:29:35AM -0600, Alan Somers wrote: > > > r236321 added vn_io_fault(), a mechanism for avoiding lock order > > > reversals when a process reads from one file into a mmap()ed buffer > > > backed by another file. From the description in the comments of > > > vn_io_fault() it seems like it would be possible to write a reliable > > > test that would trigger the LOR. But I can't find any evidence in > > > svn, or bugzilla of such a test program. None in Phabricator either, > > > which probably wasn't even running when that commit was made. Did > > > anybody ever write a test program? If so, I volunteer to ATFify it. > > The test program is in tools/test/upsdl. I object against removing > > non-atf version on principle, atf tests are not debuggable. Also this is > > racing test, so it is not as simple as doing N runs where N is fixed. > > > > Anyway, test for the ups@ race is included into stress2, where it belongs. > >