On 25 Aug 2000, Chris G. Demetriou wrote:

> w.knowles@niwa.cri.nz (Wayne Knowles) writes:
> > I'm pretty confident it is mmap related as the following patch to dump
> > which fills the mmap'ed region to 255 also changes the 0 to 255 in the
> > corrupted region:
> 
> i think i disagree with your diagnosis.
> 
> you mmap it and fill it (or it's zero-filled by mmap), and that's
> pretty much where the involvement of mmap() ends.  it's just a mapped
> writable region of your address space then, with contents, like your
> heap and your program data segment.
> 
> the fact that you've filled it the a value and that value 'sticks'
> means that the subsequent actions on the buffer, e.g. read(), aren't
> filling the buffer properly, or the writes from the buffer aren't
> copying the data correctly to the file.
> 
> Personally, i'd suspect copyin and/or copyout.  I'd guess a boundary
> condition error -- note that all the errors you mentioned (unless i
> goofed my calculation) hit the last few bytes of a block before an 2K
> byte boundary.  2K is BLKDEV_IOSIZE, on most (all?) ports, though that
> may just be a red herring...
> 
> 
> one thing you might do is create a bunch of files of random data,
> which contain no words which are all zero, and check after reading.

Thanks for the suggestions Chris.

After adding extra tests around the read(2) calls in dump that fill the
last 4 bytes with a known value (0xbadface) and checking after the call
prove that read is not filling the buffer in the last 4 bytes. 
Plus, the returned byte count is the same as the requested count.

If the read is repeated then there is a 90% chance that is succeedes (I
write a different value for the retry in case my magic number was in fact
the correct value)

In doing this test I observered a very useful peice of information:

  The buffer addresses that dump reads into are not aligned - in fact they
  are offset by 4 bytes from an aligned address.  It also fails when I set
  it to 8 (see below)
  This is because the mmaped segment has 2 structures it allocates at the
  start of the buffer and it destroys the alignment.

suspect read: buf=0x20011808 len=2048 -- repeat read worked
suspect read: buf=0x2000e808 len=2048 -- repeat read worked
suspect read: buf=0x20011808 len=2048 -- repeat read worked
suspect read: buf=0x20013808 len=2048 -- repeat read worked
suspect read: buf=0x20018808 len=2048 -- repeat read failed
suspect read: buf=0x2002a808 len=2048 -- repeat read worked
suspect read: buf=0x20038808 len=2048 -- repeat read worked
suspect read: buf=0x2003d808 len=2048 -- repeat read worked
suspect read: buf=0x20044808 len=2048 -- repeat read failed


The result is an unaligned copyout - which fails if it is in the last 2k
of the hardware pages (half of NBPG)
Thinking of a unaligned copyout bug I checked the code there and couldn't
see any bugs.  It falls down to use bcopy (written in assembler) and it
isolate that I replaced it with the kernel bcopy.c implemention.  No
change in the fault.

In the above case if buf=0x20044804 or 08 or 0c and we do a 2k read it
will fail.

My current feeling is that the second page of the buffer is not being
mapped correctly due to a miscalculation in the number of pages required
to perform the kernel<->userland copyout.   2k+4bytes in the last 2k of a
page is probably the worst case senario....

It appears to have a context swittch related look to it as well - I
cannot duplicate the problem using a simple C program, and if the repeat
reads work.... the problem isn't there every time!

Perhaps when the processes is restored after a context switch (when
read wakes up) it isn't restoring all of the memory map entries correctly?
Another possibility it the memory mappings are there when a larger (8k is
common in dump) runs, but they are trimmed after another context runs.

Does this sounds like a likely cause???
Where do we start looking ??  (I'm no expert in this area!)

Wayne
-- 
  _____	   	Wayne Knowles,  Systems Manager
 / o   \/   	National Institute of Water & Atmospheric Research Ltd
 \/  v /\   	P.O. Box 14-901 Kilbirnie, Wellington, NEW ZEALAND
  `---'     	Email:   w.knowles@niwa.cri.nz