linux-ext4 - Re: [RESEND] [PATCH] lseek: change i

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: <20090115164003.09c8c918.akpm@linux-foundation.org>
Date:	Thu, 15 Jan 2009 16:40:03 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Theodore Tso <tytso@....edu>
Cc:	matthew@....cx, hifumi.hisashi@....ntt.co.jp,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [RESEND] [PATCH] lseek: change i_mutex usage.

On Thu, 15 Jan 2009 09:21:13 -0500
Theodore Tso <tytso@....edu> wrote:

> On Thu, Jan 15, 2009 at 06:22:52AM -0700, Matthew Wilcox wrote:
> > 
> > Of course if you have multiple threads, they will share a struct file,
> > and you're updating f_pos and f_version without locking.  Maybe that's
> > OK, but it's soemthing you didn't discuss.
> 
> f_pos is updated by sys_write(), and friends without locking, so we're
> fine on that front, or at least no worse off.

bug ;)

>  SUSv3 doesn't seem to
> say one way or another what should happen if two threads try to
> write() to a file at the same time using the same file descriptor in
> terms of whether or not f_pos gets updated intelligently.  We've opted
> for speed over determinism already.

I think our thinking was that if two threads are racily updating f_pos
with different values, then it should end up with one of those values.

>From a quality-of-implementation POV (what _is_ that, anyway) it would
be bad if the kernel were to set f_pos to the upper 32 bits of position
A and the lower 32 bits of position B.  Which could happen if we remove
the i_mutex protection on 32-bits.

We could perhaps omit some locking if CONFIG_64BIT.  There's probably
quite a bit of locking which could be omitted in that case.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html