Date: Wed, 5 Jun 2019 12:58:21 -0600 From: alan somers <asomers@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Alan Somers <asomers@freebsd.org>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: Regression test for vn_io_fault Message-ID: <CAOtMX2h7M%2BmMgsyBNgKQdf6g-x76qF=tyrxovT0_LCbH9G-GPw@mail.gmail.com> In-Reply-To: <20190605180552.GX75280@kib.kiev.ua> References: <CAOtMX2hocYE0qwhMttO3T0ZK4ghoXZxcFYO=ZzxTRiuWCCWCmw@mail.gmail.com> <20190605180552.GX75280@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -Alan On Wed, Jun 5, 2019, 12:06 PM Konstantin Belousov <kostikbel@gmail.com> 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2h7M%2BmMgsyBNgKQdf6g-x76qF=tyrxovT0_LCbH9G-GPw>