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 - 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
