From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: [RFC][PATCH 14/27] tricky: elevate write count files are open()ed Date: Thu, 08 Jun 2006 08:12:52 -0700 Message-ID: <1149779572.4097.48.camel@localhost.localdomain> References: <20060608001013.0D041507@localhost.localdomain> <20060608001025.B1665091@localhost.localdomain> <20060608105448.GH11996@MAIL.13thfloor.at> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk, hch@infradead.org, trond.myklebust@fys.uio.no Return-path: Received: from e33.co.us.ibm.com ([32.97.110.151]:11989 "EHLO e33.co.us.ibm.com") by vger.kernel.org with ESMTP id S964868AbWFHPNt (ORCPT ); Thu, 8 Jun 2006 11:13:49 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k58FDnbX018398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 8 Jun 2006 11:13:49 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k58FDmYe310922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Jun 2006 09:13:48 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k58FDlpb029589 for ; Thu, 8 Jun 2006 09:13:47 -0600 To: Herbert Poetzl In-Reply-To: <20060608105448.GH11996@MAIL.13thfloor.at> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 2006-06-08 at 12:54 +0200, Herbert Poetzl wrote: > > There is also an elevated count around the vfs_create() > > call in open_namei(). The count does not need to be > > kept elevated all the way into the may_open() call because > > after creation, the write bits of the acc_mode are cleared. > > This keeps may_open() from ever failing. Howver, this may > > open one potential race where a change from a r/w to a r/o > > mount could occur between the mnt_drop_write() and may_open() > > allowing a user to obtain a r/w file on what is now a r/w > > probably means 'read only mount' > > what about using atomic_dec_and_test() to avoid > having such cases (or a lock if required)? I thought about that, but it isn't that simple. Such a case needs to have controlled transitions away from when the counter is at '0'. It is a similar problem as i_writecount and put/deny_write_access(), which end up having to use a spinlock. I don't think we can do it with simple atomics. -- Dave