From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve French" Subject: Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek Date: Sun, 27 Jan 2008 16:18:26 -0600 Message-ID: <524f69650801271418s16f88928xc58dcbe9f5ede9e4@mail.gmail.com> References: <20080127317.043953000@suse.de> <20080127021714.A223614D2E@wotan.suse.de> <524f69650801270857i6610e736q4189dc6af9b22360@mail.gmail.com> <1201456562.7346.13.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Andi Kleen" , swhiteho@redhat.com, sfrench@samba.org, vandrove@vc.cvut.cz, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, akpm@osdl.org To: "Trond Myklebust" Return-path: Received: from py-out-1112.google.com ([64.233.166.182]:53457 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753650AbYA0WS2 (ORCPT ); Sun, 27 Jan 2008 17:18:28 -0500 Received: by py-out-1112.google.com with SMTP id u52so2086982pyb.10 for ; Sun, 27 Jan 2008 14:18:27 -0800 (PST) In-Reply-To: <1201456562.7346.13.camel@heimdal.trondhjem.org> Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: If two seeks overlap, can't you end up with an f_pos value that is different than what either thread seeked to? or if you have a seek and a read overlap can't you end up with the read occurring in the midst of an update of f_pos (which takes more than one instruction on various architectures), e.g. reading an f_pos, which has only the lower half of a 64 bit field updated? I agree that you shouldn't have seeks racing in parallel but I think it is preferable to get either the updated f_pos or the earlier f_pos not something 1/2 updated. On Jan 27, 2008 11:56 AM, Trond Myklebust wrote: > > 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 > -- Thanks, Steve