Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)

[Larry McVoy <lm@bitmover.com>]

On Sun, May 16, 2004 at 07:42:16PM -0700, Linus Torvalds wrote:
> On Sun, 16 May 2004, Larry McVoy wrote:
> > Be aware that how BK does I/O is with write() on the way out but with 
> > mmap on the way in.  The process which forked renumber has just written
> > the file and the renumber process is reading it with mmap.
> > 
> > If there are still any problems with mixing read/write and mmap then that
> > may be a prolem but I would have expected to see things start going 
> > wrong on a page boundary and the one core dump I saw was page aligned 
> > at the tail but not at the head, it started in the middle of the page.
> 
> The kernel should have no problems with mixed read/write and mmap usage, 
> although user space obviously needs to synchronize the accesses on its own 
> some way. There is no implicit synchronization otherwise, and the mmap 
> user can see a partial write at any stage of the write.

You can strace BK and see what it does but I'll save you the trouble.
We never hold a mapping open to a file being written because we never
rewrite a file in place (that's a really bad thing for an SCM to do).
What we do is to write the file to SCCS/x.<filename> and then when it is
written we rename it to SCCS/s.<filename>.  Any process which wants to
map it is either going to get the old s.<filename> or the new s.<filename>
but there is no chance that we are extending the file while someone has it
mapped.  Famous last words and all that notwithstanding, that's my belief.

So unless I'm more dimwitted than normal we don't have any synchronization
problems by design.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com