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]

Message-ID: <OFC3001709.7CCFA2A6-ON88257428.0071C5A5-88257428.00760BEE@us.ibm.com>
Date:	Fri, 11 Apr 2008 14:29:21 -0700
From:	Bryan Henderson <hbryan@...ibm.com>
To:	lsorense@...lub.uwaterloo.ca (Lennart Sorensen)
Cc:	Bodo Eggert <7eggert@....de>, Diego Calleja <diegocg@...il.com>,
	Jan Kara <jack@...e.cz>, Jiri Kosina <jkosina@...e.cz>,
	linux-fsdevel@...r.kernel.org,
	Linux Kernel list <linux-kernel@...r.kernel.org>,
	Michal Hocko <mhocko@...e.cz>, Meelis Roos <mroos@...ux.ee>
Subject: Re: file offset corruption on 32-bit machines?

>What is the difference between doing:
>
>threadA: seek(positionA)
>threadB: seel(positionB)
>threadA: write
>threadB: write
>
>versus
>
>threadA: seek(posisionA) but only set half the 64bits
>threadB: seek(positionB) set all 64bits
>threadA: complete seek operation setting the other half of the bits
>threadA: write
>threadB: write
>
>either way you end up writing to the wrong file location

Only if you make an assumption about what this program considers the right 
location.  One difference is that in the first case, data gets written 
only at a place to which the program seeked, while in the second, it gets 
written to a totally illogical place.  Another is that in the first, the 
data gets written as specified in standards and in the second, it doesn't. 
 I can imagine a program that would be satisfied with the first and not 
the second, and for such a program, I cannot use the word "incorrect" or 
"broken" or say the programmer doesn't understand shared resources.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

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