From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: [PATCH] [8/18] BKL-removal: Remove BKL from remote_llseek Date: Sun, 27 Jan 2008 12:56:02 -0500 Message-ID: <1201456562.7346.13.camel@heimdal.trondhjem.org> References: <20080127317.043953000@suse.de> <20080127021714.A223614D2E@wotan.suse.de> <524f69650801270857i6610e736q4189dc6af9b22360@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain 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: Steve French Return-path: Received: from mx1.netapp.com ([216.240.18.38]:12880 "EHLO mx1.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757066AbYA0Spv (ORCPT ); Sun, 27 Jan 2008 13:45:51 -0500 In-Reply-To: <524f69650801270857i6610e736q4189dc6af9b22360@mail.gmail.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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