Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Jul 1998 22:28:08 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        mike@smith.net.au (Mike Smith)
Cc:        karl@mcs.net, wollman@khavrinen.lcs.mit.edu, dswartz@druber.com, current@FreeBSD.ORG
Subject:   Re: MMAP problems
Message-ID:  <199807262228.PAA18917@usr01.primenet.com>
In-Reply-To: <199807261647.JAA10667@antipodes.cdrom.com> from "Mike Smith" at Jul 26, 98 09:47:54 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > The data which gets written is usually a block of zeros, but it may not be;
> > it can also be random trash.  Its also not always one block (it could be
> > more than one), but it IS always, at least from what I'm seeing here, a
> > multiple of 512 bytes (disk blocksize).
> 
> The significant question in light of Garrett's description seem to be 
> whether the trash that's written is actually being written by the 
> process in error because that's what it got from a previous read, or 
> whether the process is actually writing the right stuff and it's being 
> corrupted on the way down.

See other postings.

Because the corrupt data can be non-zero, I do not believe Garrett's
explanation is the correct one; instead, I believe the same page is
being pointed to by two mappings at the same time because I don't
believe that mmap() references are being revoked correctly.

If the data were always zero, then Garret would be discussing the
correct problem.

The problem Garrett notes is, IMO, "pilot error" and has to do with
the failure to call msync() when it is necessary.  Per the discussion,
it can be made possible to not need to call msync().

Note that I have seen the bug I am describing on both 2.2.6 and 3.0
systems.  These are production systems that open and hild open the
password file a long time, and which access the crontabe with an
annoyingly (and probably undesirably) high frequency.  This results
in corrupt crontabs.  On the other hand, corrupt crontabs are much
better than silently corrupted user data... 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?199807262228.PAA18917>