Date: Sat, 25 Jul 1998 22:52:34 -0400 (EDT) From: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> To: Karl Denninger <karl@mcs.net> Cc: Dan Swartzendruber <dswartz@druber.com>, current@FreeBSD.ORG Subject: Re: MMAP problems Message-ID: <199807260252.WAA05646@khavrinen.lcs.mit.edu> In-Reply-To: <19980725163243.36509@mcs.net> References: <19980725155148.43084@mcs.net> <3.0.5.32.19980725172640.00944ac0@mail.kersur.net> <19980725163243.36509@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Sat, 25 Jul 1998 16:32:43 -0500, Karl Denninger <karl@mcs.net> said: > I can verify that CAM is not related to this; it happens with NON-CAM > kernels as well. I've been seeing it for several months. I believe it to be a coherency problem. The relevant operations here are: 1) A diablo server process appends to a spool file using explicit I/O. (Note that the file is not opened in O_APPEND mode.) 2) A boatload of dnewslink processes simultaneously mmap the pages of the spool file containing the article in question, suck the article out of it, and blast it over to the remote feed. Here's my particular guess... I think this happens when the dnewslink processes are reading another, short, article in the last page of the file, while a diablo server is writing a new article. Somewhere, there is a race condition in which the kernel has copied the new data into the buffer, but blocks before it updates the valid length; this then allows one of the mmaps to succeed, and since that part of the buffer is marked invalid, it gets zeroed. Then the diablo process resumes, and marks the end of the buffer valid, although the data it was writing has just gotten clobbered. It looks, from an inspection of the relevant code in ufs_readwrite.c and ffs_balloc.c, that this cannot happen, because the data are always copied in last. It does appear that there are potential windows, if ffs_balloc() blocks, where other processes might see invalid data in the file through mmap as a result of vnode_pager_setsize() having already been run, but it does not appear such garbage could possibly persist and be written back to disk, and I certainly see it directly on the disk, not just in memory. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick 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?199807260252.WAA05646>