On Mon, Jun 25, 2007 at 11:27:25AM -0700, Dave Hansen wrote:
> I've got this in the next set:
>
> -
> - if(IS_RDONLY(nd.dentry->d_inode))
> + /*
> + * This is a rare case where using __mnt_is_readonly()
> + * is OK without a mnt_want/drop_write() pair. Since
> + * not actual write to the fs is performed here, we do
> + * not need to telegraph to that to anyone. Also, we
> + * accept that access is inherently racy, and know that
> + * the fs might be remounted between this syscall, and
> + * any action taken because of its result.
> + */
> + if (__mnt_is_readonly(nd.mnt))
> res = -EROFS;
Looks good.
> diff -puN fs/namei.c~numa_mnt_want_write fs/namei.c
> --- lxc/fs/namei.c~numa_mnt_want_write 2007-06-25 11:05:50.000000000 -0700
> +++ lxc-dave/fs/namei.c 2007-06-25 11:05:50.000000000 -0700
> @@ -230,10 +230,12 @@ int permission(struct inode *inode, int
> int retval, submask;
>
> if (mask & MAY_WRITE) {
> -
> /*
> - * Nobody gets write access to a read-only fs.
> + * If this WARN_ON() is hit, it likely means that
> + * there was a missed mnt_want_write() on the path
> + * leading here.
> */
> + WARN_ON(__mnt_is_readonly(nd->mnt));
> if (IS_RDONLY(inode) &&
I might be missing something, but wouldn't this trip an
access("/foo/bar", W_OK);
On a readonly filesystem?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
