Re: file offset corruption on 32-bit machines?

[lsorense@csclub.uwaterloo.ca (Lennart Sorensen)]

On Tue, Apr 15, 2008 at 07:34:30PM +0200, Pavel Machek wrote:
> Yes, kernel bugs are confusing ;-).

I only see an application bug so far.

> The "application" could be malware trying to confuse debugger, for
> example.

If you can't do it on demand (which I can't see any way to do) then I
don't think malware can take advantage of it.

> The "application" could be something you are trying to debug.

True, but even without this behaviour doing seeks and read/writes from
multiple threads without locking will already show plenty of problems
even if you somehow manage to hit this issue, and not only that you have
to have threads writing to different 4GB aligned chunks of the file to
cause a problem, since otherwise they would all be setting the top bits
the same.  I would hope anyone doing multithreaded work on a file that
big would like to avoid the locking issue by using pread and pwrite
instead in which case there is no problem either.

> I did brief reading on lseek man pages, and it does not mention
> "kernel may seek to random place if you attempt to seek  from two
> threads at the same time". So this is a kernel or manpages bug.

Does it say anything about what happens if you try to seek from two
places at once?

> Maybe you can take a look at POSIX if it permits this behaviour? 

The parts I can find for posix don't say one way or the other.

-- 
Len Sorensen