Re: FW: Linux kernel file offset pointer races

[Andrey Savochkin]

BTW, f_pos assignments are non-atomic on IA-32 since it's a 64-bit value.
The file position is protected by the BKL in llseek(), but I do not see any
serialization neither in sys_read() nor in generic_file_read() and other
methods.

Have we accepted that the file position may be corrupted after crossing 2^32
boundary by 2 processes reading in parallel from the same file?
Or am I missing something?

	Andrey

On Sat, Aug 07, 2004 at 02:15:00PM -0300, Marcelo Tosatti wrote:
> On Thu, Aug 05, 2004 at 12:30:23PM +0200, Jirka Kosina wrote:
> > On Thu, 5 Aug 2004, Giuliano Pochini wrote:
> > 
> > > I don't remember if this issue has already been discussed here:
> > > -----FW: <Pine.LNX.4.44.0408041220550.26961-100000@xxxxxxx>-----
> > > Date: Wed, 4 Aug 2004 12:22:42 +0200 (CEST)
> > > From: Paul Starzetz <ihaquer@xxxxxxx>
> > > To: bugtraq@xxxxxxxxxxxxxxxxx, vulnwatch@xxxxxxxxxxxxx,
> > >  full-disclosure@xxxxxxxxxxxxxxxx
> > > Subject: Linux kernel file offset pointer races
> > 
> > It hasn't been discussed here, but at 
> > http://linux.bkbits.net:8080/linux-2.4/gnupatch@411064f7uz3rKDb73dEb4vCqbjEIdw 
> > you can find a patchset fixing (some of) the mentioned problems. This 
> > patchset is from 2.4.27-rc5
> 
> "some of" ? 
> 
> Do you know any unfixed still broken piece of driver code ? 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/