From: Michal Hocko <mhocko@suse.cz>
To: Meelis Roos <mroos@linux.ee>
Cc: Linux Kernel list <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: file offset corruption on 32-bit machines?
Date: Thu, 10 Apr 2008 15:55:58 +0200 [thread overview]
Message-ID: <200804101555.58643.mhocko@suse.cz> (raw)
In-Reply-To: <Pine.SOC.4.64.0804081101430.28938@math.ut.ee>
[Adding fsdevel list]
On Tuesday 08 April 2008 10:05:47 am Meelis Roos wrote:
> Jeff Robertson analyzes the behaviour of different operating systems'
> 64-bit file offset implementation and concludes that on 32-bit
> machines, Linux and Solaris lack any locking to keep the two 32-bit
> halves in sync and this could cause rare file offset corruption.
>
> http://jeffr-tech.livejournal.com/21014.html
AFAICS, this race is theoretically possible, but it is very hard (almost
impossible) to trigger with a sane file usage pattern.
Note that you have to access shared struct file (same file descriptor) in
different threads which should be synchronized by caller anyway (*).
I also don't see any security implications from this race, but maybe someone
with more knowlage about fs can see (f_pos is used at many places in the
kernel code).
I think that it is better to live with tiny-race-on-broken-patterns rather
than paying for synchronization which is not needed for correct paths.
[*] file_pos_{read,write} (fs/read_write.c) are not called under lock (in
sys_read, sys_write, ...), so even if f_pos is written atomically, you will
be able to get races when accessing shared descriptor from different threads.
I think that POSIX states, that behavior is undefined under these conditions.
Best regards
--
Michal Hocko
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9
Czech Republic
next prev parent reply other threads:[~2008-04-10 13:56 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-08 8:05 file offset corruption on 32-bit machines? Meelis Roos
2008-04-10 13:55 ` Michal Hocko [this message]
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
[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 ` 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
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
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=200804101555.58643.mhocko@suse.cz \
--to=mhocko@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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.