From: Herbert Poetzl <herbert@13thfloor.at>
To: Christoph Hellwig <hch@infradead.org>,
Linus Torvalds <torvalds@osdl.org>, Andrew Morton <akpm@osdl.org>,
Al Viro <viro@ftp.linux.org.uk>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
linu-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/6] vfs: extend loopback (bind) mounts by mnt_flags
Date: Thu, 26 Jan 2006 22:08:53 +0100 [thread overview]
Message-ID: <20060126210853.GB22020@MAIL.13thfloor.at> (raw)
In-Reply-To: <20060124190632.GB14201@infradead.org>
On Tue, Jan 24, 2006 at 07:06:32PM +0000, Christoph Hellwig wrote:
> On Sat, Jan 21, 2006 at 09:38:43AM +0100, Herbert Poetzl wrote:
> >
> > The following set of patches extends the per device
> > 'noatime', 'nodiratime' and last but not least the
> > 'ro' (read only) mount option to the vfs --bind mounts,
> > allowing them to behave like any other mount, by
> > honoring those mount flags (which are silently ignored
> > by the current implementation in 2.4.x and 2.6.x)
> >
> > the patch makes the following syscall variations behave
> > as expected:
> >
> > - open (read/write/trunc), create
> > - link, symlink, unlink
> > - mknod (reg/block/char/fifo)
> > - mkfifo, mkdir, rmdir, rename
> > - (f,l)chown, (f)chmod, utime
> > - access, truncate, mmap
> > - ioctl (gen/ext2/ext3/reiser)
> > - (f,l)setxattr, (f,l)removexattr
> >
> > an older version of this patch was included in
> > 2.6.0-test6-mm2, and v2.6.4-wolk2.0, the patches are
> > in use by several people, without any issues ...
> >
> > please consider inclusion (in -mm ?) and/or let me know
> > what needs to be changed to get this functionality into
> > mainline ...
>
> Please see the original mail from Al on this subject. We need to
> split the "am I allowed to write to the fs" part out of permission().
> Once we're at it we can pair it with the "don't need to write to fs
> anymore" even and get saner unmount/remount semantics.
could you point me to this thread/email, so that I can
(re)read it?
> To get there we will still need the vfsmount propagatios, so these
> should come first in the series. Then the get/release write access
> helpers and last the actual per-mount ro bit. Your mnt_flags
> propagation fix is fine on it's own and should go in asap.
>
> And please send the patches to -fsdevel and in the proper patch
will do so, once I figure out what was improper ...
(as I tried to follow Andrew's tpp document in the first palce)
> format. I have planned to look at this again in February, tell me if
> you want to finish it before or at the same time, then I won't spend
> time on it.
once I figured out what is desired/wanted/acceptable, I'm
willing to do it ...
best,
Herbert
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
prev parent reply other threads:[~2006-01-26 21:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-21 8:38 [PATCH 0/6] vfs: extend loopback (bind) mounts by mnt_flags Herbert Poetzl
2006-01-21 8:40 ` [PATCH 1/6] vfs: add missing MNT_RDONLY and macro to check Herbert Poetzl
2006-01-21 8:40 ` [PATCH 2/6] vfs: propagate mnt_flags into do_loopback/vfsmount Herbert Poetzl
2006-01-22 10:06 ` Suleiman Souhlal
2006-01-22 10:59 ` Suleiman Souhlal
2006-01-24 19:02 ` Christoph Hellwig
2006-01-26 21:04 ` Herbert Poetzl
2006-01-27 20:03 ` Herbert Poetzl
2006-04-01 17:02 ` Christoph Hellwig
2006-01-21 8:41 ` [PATCH 3/6] vfs: propagate vfsmount into chown_common() Herbert Poetzl
2006-01-21 8:42 ` [PATCH 4/6] vfs: propagate the nameidata into the relevant vfs_*() Herbert Poetzl
2006-01-21 8:43 ` [PATCH 5/6] vfs: propagate the vfsmount into *xattr() Herbert Poetzl
2006-01-21 8:43 ` [PATCH 6/6] vfs: extend IS_RDONLY() checks to MNT_IS_RDONLY() Herbert Poetzl
2006-01-24 19:06 ` [PATCH 0/6] vfs: extend loopback (bind) mounts by mnt_flags Christoph Hellwig
2006-01-26 21:08 ` Herbert Poetzl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060126210853.GB22020@MAIL.13thfloor.at \
--to=herbert@13thfloor.at \
--cc=akpm@osdl.org \
--cc=hch@infradead.org \
--cc=linu-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).