Date: Mon, 17 Aug 1998 05:01:20 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dg@root.com Cc: tlambert@primenet.com, current@FreeBSD.ORG, karl@mcs.net Subject: Re: Better VM patches (was Tentative fix for VM bug) Message-ID: <199808170501.WAA18680@usr09.primenet.com> In-Reply-To: <199808161506.IAA02398@implode.root.com> from "David Greenman" at Aug 16, 98 08:05:59 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >To elaborate: I think that the behaviour I am seeing in the "mmap'ed > >file contents, on a page boundary, written to another file" case is a > >result of a single page being in multiple maps. > > Uh, what does "single page being in multiple maps" mean exactly? What map? > Pages belong to objects. A page can belong to only one object (there's only > one set of list pointers, so nothing else is possible. :-)). This precisely what is happening in the cases I have observed in deployed machines: The contents of the cron tab are being overwritten with the contents of a dbm file which the dbm routines mmap'ed. The new content of the file begins on a page boundary beginning. > If you see some > of one file show up in another, then this suggests to me that a bzero isn't > happening when it needs to, resulting in stale cached file data being > considered valid. This would be true if the file data was intact up to the EOF, then contained the cached data. This is not what is happening. What is happening suggests that when mmap'ed backing store is discarded, an object alias remains after the discard, and the physical page is reused while it is still referenced. > I have a suggestion. Let's not throw out random guesses about what may or > may not be a problem. Let's actually understand the issue thoroghly, come up > with a fix, and then tell people all about it. The case I am worried about with the setsize fix is the case where the file was mmap'ed. The file did not end on an even page boundary. The file is extended, either below or exactly on a page boundary. The first "if" in "setsize" is true because the file length was erroneously saved in the object. A subsequent read reference on the mmap'ed section, which is believed to be swapped out, results in a page reactivation. The perfectly valid data (written via normal file I/O) in the extended area is lost. So the setsize code fixes a real bug, even if it breaks an abstraction. The race window from my comment refers to a read completion interrupt from a disk controller being processed in the time between the bogus value being set in the alloc, and the value being corrected. The XXX comment I pointed to is an indication that orphaned objects can and do exist. This is a seperate problem, and can't result in the "mmap'ed file contents overwrite valid file contents" corruption that got me interested in this in the first place. Neither could John's orphaned object fix for invalidation of good pages, and my order fix on the protection before the invalidation. All that said, I think that my fix does not resolve all of the problems, only some of them. The "backup one if you can" kludge I originally posted was more diagnostic than anything else; it was very informative to me that (1) it didn't result in more "freeing free page" panics, and (2) it didn't help the mmap bug in the news server, which I think is a more repeatable version of the crontab corruption bug I am suffering. So anyway, I hope I've convinced you that there is actually an error in the allocate code setting the size to a page boundary; the valid = 0 bug is so obvious (once John Dyson pointed it out after looking at my "backup one" patch 8-)) that it doesn't need more justification. Anyway, I'm currently looking for similar order of operation things; if I can come up with patches that fix Karl Denniger's news server, I'm pretty convinced my problem will go away as well. If you would prefer I target my patches instead of posting to the list, I'll post asking for people who have problems and restrict the distribution. Should I do this? I'd really prefer that diagnostic patches get the widest possible audience, especially if they make things worse. Getting a limited set of positive responses is the worst thing that could happen if there is a negative effect that goes undiscovered. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808170501.WAA18680>