[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1201456562.7346.13.camel@heimdal.trondhjem.org>
Date: Sun, 27 Jan 2008 12:56:02 -0500
From: Trond Myklebust <Trond.Myklebust@...app.com>
To: Steve French <smfrench@...il.com>
Cc: Andi Kleen <ak@...e.de>, swhiteho@...hat.com, sfrench@...ba.org,
vandrove@...cvut.cz, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, akpm@...l.org
Subject: Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek
On Sun, 2008-01-27 at 10:57 -0600, Steve French wrote:
> Don't you need to a spinlock/spinunlock(i_lock) or something similar
> (there isn't a spinlock in the file struct unfortunately) around the
> reads and writes from f_pos in fs/read_write.c in remote_llseek with
> your patch since the reads/writes from that field are not necessarily
> atomic and threads could be racing in seek on the same file struct?
Where does is state in POSIX or SUS that we need to cater to that kind
of application?
In any case, the current behaviour of f_pos if two threads are sharing
the file struct is undefined no matter whether you spinlock or not,
since there is no special locking around sys_read() or sys_write().
Trond
--
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/
Powered by blists - more mailing lists