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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
