From: Pavel Machek <pavel@ucw.cz>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: Jan Kara <jack@suse.cz>, Bodo Eggert <7eggert@gmx.de>,
Diego Calleja <diegocg@gmail.com>, Jiri Kosina <jkosina@suse.cz>,
Michal Hocko <mhocko@suse.cz>, Meelis Roos <mroos@linux.ee>,
Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: file offset corruption on 32-bit machines?
Date: Tue, 15 Apr 2008 21:12:38 +0200 [thread overview]
Message-ID: <20080415191238.GC4994@elf.ucw.cz> (raw)
In-Reply-To: <20080415182453.GR7385@csclub.uwaterloo.ca>
Hi!
> > Yes, kernel bugs are confusing ;-).
>
> I only see an application bug so far.
Really?
> The lseek() function repositions the offset of the open file
> associated with
> the file descriptor fildes to the argument offset according to
>the directive
> whence as follows:
It does not say "repositions the offset to the random number" nor
"under certain conditions repositions the offsets" nor "it repositions
the offset unless you are unlucky and hit kernel race". More
seriously, it does not contain note "not safe from multithreaded
programs" nor "multithreaded behaviour is undefined".
So this pretty clearly is application bug.
> > 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.
Really? I see an application to detecting if I'm being debugged. Try
to hit the race 1000 times, if you hit it, you are probably not
debugged (because debugger would be very likely to make that race hard
to hit). Will only work on multicores, but...
[Plus, there's "strace seen it writing to either offset A or offset B,
but I see the data at offset C, WTF?]
> > 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
> 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'm not saying this kernel bug is likely to hit in practice. It is
still a kernel bug.
Is the slowdown of lseek worth getting rid of this minor bug? Not
sure, probably yes.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2008-04-15 19:12 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <agh4d-6yc-35@gated-at.bofh.it>
[not found] ` <ah5tY-3lR-7@gated-at.bofh.it>
[not found] ` <ah5DA-3X9-9@gated-at.bofh.it>
[not found] ` <ah5X5-4tl-13@gated-at.bofh.it>
[not found] ` <ah66A-4Nk-7@gated-at.bofh.it>
[not found] ` <ah7vN-7Wz-9@gated-at.bofh.it>
2008-04-11 12:24 ` file offset corruption on 32-bit machines? Bodo Eggert
2008-04-11 12:24 ` Bodo Eggert
2008-04-11 13:55 ` Lennart Sorensen
2008-04-11 16:59 ` Bryan Henderson
2008-04-11 17:15 ` Lennart Sorensen
2008-04-11 21:29 ` Bryan Henderson
2008-04-12 8:48 ` Pavel Machek
2008-04-14 16:20 ` Jan Kara
2008-04-14 16:22 ` Lennart Sorensen
2008-04-14 16:53 ` Jan Kara
2008-04-14 16:54 ` Alan Cox
2008-04-14 18:34 ` Alexey Dobriyan
2008-04-14 17:06 ` Lennart Sorensen
2008-04-14 19:03 ` Jan Kara
2008-04-14 19:29 ` Lennart Sorensen
2008-04-14 19:42 ` Jan Kara
2008-04-14 19:45 ` Lennart Sorensen
2008-04-15 8:57 ` Pavel Machek
2008-04-15 15:32 ` Lennart Sorensen
2008-04-15 17:34 ` Pavel Machek
2008-04-15 18:24 ` Lennart Sorensen
2008-04-15 19:12 ` Pavel Machek [this message]
2008-04-15 19:49 ` Lennart Sorensen
2008-04-15 20:06 ` Pavel Machek
2008-04-15 20:28 ` Peter Zijlstra
2008-04-16 8:15 ` Pavel Machek
2008-04-16 8:20 ` Peter Zijlstra
2008-04-16 10:54 ` Alan Cox
2008-04-16 13:57 ` Lennart Sorensen
2008-04-15 20:29 ` Lennart Sorensen
2008-04-15 22:11 ` Bryan Henderson
2008-04-16 9:40 ` Jamie Lokier
2008-04-08 8:05 Meelis Roos
2008-04-10 13:55 ` Michal Hocko
2008-04-10 14:01 ` Jiri Kosina
2008-04-10 14:27 ` Jan Kara
2008-04-10 14:31 ` Jiri Kosina
2008-04-10 14:48 ` Matthew Wilcox
2008-04-10 15:22 ` Jan Kara
2008-04-10 15:30 ` Matthew Wilcox
2008-04-10 15:19 ` Jan Kara
2008-04-10 15:37 ` Michal Hocko
2008-04-10 15:56 ` Jan Kara
2008-04-10 16:03 ` Diego Calleja
2008-04-10 16:03 ` Diego Calleja
2008-04-10 16:15 ` Jan Kara
2008-04-11 19:26 ` Pavel Machek
2008-04-14 16:25 ` Jan Kara
2008-04-10 14:31 ` Michal Hocko
2008-04-10 14:35 ` Jiri Kosina
2008-04-10 14:11 ` Martin Mares
2008-04-10 15:12 ` Jan Kara
2008-04-10 15:14 ` Jamie Lokier
2008-04-10 15:21 ` Matthew Wilcox
2008-04-10 15:28 ` Jan Kara
2008-04-10 15:33 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080415191238.GC4994@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=7eggert@gmx.de \
--cc=diegocg@gmail.com \
--cc=jack@suse.cz \
--cc=jkosina@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=mhocko@suse.cz \
--cc=mroos@linux.ee \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.