Date: Mon, 6 Mar 95 18:07:55 MST From: terry@cs.weber.edu (Terry Lambert) To: davidg@root.com, current@freebsd.org Subject: Re: Page fault panics during make world in -current Message-ID: <9503070107.AA21179@cs.weber.edu>
next in thread | raw e-mail | index | archive | help
> >You don't really mean "truncates and rewrites" do you? This would be > >an incredibly bogus violation of mmap semantics, I'd think. > > I don't care what the result is, as long as the system doesn't crash. > The idea would be to exercise potential synchronization bugs between > the page fault handler and file system. Well, I think the first bug that it will exercise if this is allowed to happen is the one that allows it to happen. 8-). Personally, I'd return an EPERM on an attempted truncate of an mmap'ed file. This would definitely exercise zero-fill errors, which it would also be responsible for introducing -- mmap is not permitted to map past the end of a file, and the truncation would invalidate the legitimacy of the existing mmap if it were permitted. A less drastic test that does not rely on a bug allowing the truncation of an mmap'ed file is probably called for. I'd suggest synchronized I/O and mmap'ed access to the same file instead using two or more processes to defeat write-behind error masking (if it exists). Read-faulting of 0 blocks is more of a stress test with regard to create/truncate large/read randomly/close, and any failure there would likely be a panic. Really you can't use semantically incorrect code to prove anything other than that the system (incorrectly) allows semantically incorrect code. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503070107.AA21179>