From owner-freebsd-current Mon Mar 6 17:14:22 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id RAA26255 for current-outgoing; Mon, 6 Mar 1995 17:14:22 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id RAA26248 for ; Mon, 6 Mar 1995 17:14:20 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA21179; Mon, 6 Mar 95 18:07:55 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503070107.AA21179@cs.weber.edu> Subject: Re: Page fault panics during make world in -current To: davidg@root.com, current@freebsd.org Date: Mon, 6 Mar 95 18:07:55 MST X-Mailer: ELM [version 2.4dev PL52] Sender: current-owner@freebsd.org Precedence: bulk > >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.