linux-kernel - Re: file offset corruption on 32-bit machines?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2008 22:06:47 +0200
From:	Pavel Machek <pavel@....cz>
To:	Lennart Sorensen <lsorense@...lub.uwaterloo.ca>
Cc:	Jan Kara <jack@...e.cz>, Bodo Eggert <7eggert@....de>,
	Diego Calleja <diegocg@...il.com>,
	Jiri Kosina <jkosina@...e.cz>, Michal Hocko <mhocko@...e.cz>,
	Meelis Roos <mroos@...ux.ee>,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org
Subject: Re: file offset corruption on 32-bit machines?

Hi!

> So other than that, is there any case in which lseek being not atomic
> can cause an application to break if it wasn't already broken (due to
> having a race condition by trying to do 2 or more seeks on the same file
> handle at the same time)?  If not, I think adding any kind of locking to
> seek in the kernel (which would I think have to cause a slight slow
> down) is a bad move.  But hey that's just my opinion. :)  I won't be
> upset either way.

Of course I can write an application that will be broken by this, and
was not broken before. It will be slightly nasty code. Come on, you
can do this too ;-).


> > 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...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/