On Thu, Dec 13, 2001 at 02:58:28AM -0800, Matthew Dillon wrote: > > @#$@#$ crap. I think I found a dirty-mmap edge case with truncation. > It requires a change to vm_page_set_validclean(), which of course is > one of the core routines in the VM system. > > Basically what happens is that ftruncate() calls vnode_pager_setsize() > which eventually calls vm_page_set_validclean(). > > If you happened to mmap() the truncation point shared R+W and > dirty it, then truncate to something that isn't a multiple DEV_BSIZE.. > for example, if you were to truncate to an offset of '10', and a buffer
Matt, what the hell, this seems to very near by a problem I wanted to report since a week: in a data acquisition I have a write process writing to a file backed shared mmapped ringbuffer. There can be several reader processes on this this ringbuffer. Now once i killed the writer for resizing of the ringbuffer and forgot about the readers. The writer truncated the database without unlinking it before. This lead the readers to be running for ever, it seemed so at least. After attaching with gdb I saw, that they were only page faulting nothing more, for ever.... Something similar I saw with netscape going mad. cheers, Thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
