lkml.org 
[lkml]   [2008]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: file offset corruption on 32-bit machines?
From
Date
On Wed, 2008-04-16 at 10:15 +0200, Pavel Machek wrote:
> On Tue 2008-04-15 22:28:55, Peter Zijlstra wrote:
> > On Tue, 2008-04-15 at 22:06 +0200, Pavel Machek wrote:
> >
> > > > > 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.
> > > >
> > > > I think a slow down is the worse choice. Adding a note to the
> > > > documentation saying that "By the way, on 32bit systems the seek call is
> > > > not atomic for 64bit file offsets, so if you happen to issue two at
> > >
> > > That would be very wrong addition to documentation. If you really
> > > wanted to do something like this, you would probably want to say
> > > something like
> > >
> > > "Doing concurrent seeks on one file is undefined. Kernel may end up
> > > with seeking to some other place."
> > >
> > > Unfortunately, you'd have to get this addition into POSIX standard...
> >
> > Is not treating the point not similar to undefined? And undefined
> > semantics cover pretty much anything, including the current behaviour.
> >
> > FWIW I really think this issue is a non-issue; one cannot expect sane
> > behaviour of unsynchronized usage of a shared resource.
>
> Why not? Kernel syscalls are traditionally atomic, and Lennard seems
> to have found sentence in POSIX that says so.

Ah, ok missed that part.



\
 
 \ /
  Last update: 2008-04-16 10:23    [W:1.145 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site