From mboxrd@z Thu Jan 1 00:00:00 1970 From: Herbert Poetzl Subject: Re: [RFC][PATCH 14/27] tricky: elevate write count files are open()ed Date: Thu, 8 Jun 2006 18:07:29 +0200 Message-ID: <20060608160729.GC14325@MAIL.13thfloor.at> References: <20060608001013.0D041507@localhost.localdomain> <20060608001025.B1665091@localhost.localdomain> <20060608105448.GH11996@MAIL.13thfloor.at> <1149779572.4097.48.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk, hch@infradead.org, trond.myklebust@fys.uio.no Return-path: Received: from MAIL.13thfloor.at ([212.16.62.50]:33697 "EHLO mail.13thfloor.at") by vger.kernel.org with ESMTP id S964899AbWFHQHb (ORCPT ); Thu, 8 Jun 2006 12:07:31 -0400 To: Dave Hansen Content-Disposition: inline In-Reply-To: <1149779572.4097.48.camel@localhost.localdomain> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Jun 08, 2006 at 08:12:52AM -0700, Dave Hansen wrote: > 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. hmm, care to elaborate? IIRC, certain parts like the entire md subsystem,as well as parts of the procfs use it quite fine ... TIA, Herbert > -- Dave