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

Linus Torvalds
2004-05-17T02:42:24Z

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.

Some architectures may have cache coherency issues that makes this
"interesting", but that's not the case on x86 (or indeed anything else
remotely sane - virtual caches are just stupid in this day and age).

> I've told my team to drop this unless someone can show that it happens
> on other kernels, this smells like a kernel bug to me, if it were a BK
> bug we should have been getting hundreds of complaints by now. We can
> jump back on it if need be, let us know if you think it is a BK problem
> after all.

Yeah, I agree. The only other possibility I see is that BK just doesn't
synchronize, and expects writes to be atomically visible to other
processes. They aren't. Preemption might just make this a whole lot more
visible, but on the other hand, so should SMP, so this sounds unlikely.

Linus