ROOT_DEV usage in hostfs
Could someone explain why hosts does thnings like:
if((ino-i_sb-s_dev == ROOT_DEV) (ino-i_uid == getuid()))
ino-i_uid = 0;
(in fs/hostfs/hostfs_kern.c:read_name())
and
if(attr-ia_valid ATTR_UID){
if((dentry-d_inode-i_sb-s_dev == ROOT_DEV)
(attr-ia_uid == 0))
attr-ia_uid = getuid();
attrs.ia_valid |= HOSTFS_ATTR_UID;
attrs.ia_uid = attr-ia_uid;
}
if(attr-ia_valid ATTR_GID){
if((dentry-d_inode-i_sb-s_dev == ROOT_DEV)
(attr-ia_gid == 0))
attr-ia_gid = getuid();
attrs.ia_valid |= HOSTFS_ATTR_GID;
attrs.ia_gid = attr-ia_gid;
}
(hostfs_getattr)
A filesystems shouldn't have special casing for the rootfs, and
chowning files from root to the current user sounds like an extremly
bad idea to me aswell.
It's also the last thing preventing us from exporting ROOT_DEV
-
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
Re: ROOT_DEV usage in hostfs
It's also the last thing preventing us from exporting ROOT_DEV unexporting - 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
Re: ROOT_DEV usage in hostfs
Dear diary, on Tue, Jan 25, 2005 at 10:10:39AM CET, I got a letter,
where Christoph Hellwig [EMAIL PROTECTED] told me, that...
Could someone explain why hosts does thnings like:
if((ino-i_sb-s_dev == ROOT_DEV) (ino-i_uid == getuid()))
ino-i_uid = 0;
(in fs/hostfs/hostfs_kern.c:read_name())
and
if(attr-ia_valid ATTR_UID){
if((dentry-d_inode-i_sb-s_dev == ROOT_DEV)
(attr-ia_uid == 0))
attr-ia_uid = getuid();
attrs.ia_valid |= HOSTFS_ATTR_UID;
attrs.ia_uid = attr-ia_uid;
}
if(attr-ia_valid ATTR_GID){
if((dentry-d_inode-i_sb-s_dev == ROOT_DEV)
(attr-ia_gid == 0))
attr-ia_gid = getuid();
attrs.ia_valid |= HOSTFS_ATTR_GID;
attrs.ia_gid = attr-ia_gid;
}
(hostfs_getattr)
A filesystems shouldn't have special casing for the rootfs, and
chowning files from root to the current user sounds like an extremly
bad idea to me aswell.
It's also the last thing preventing us from exporting ROOT_DEV
Hmm, I pretty much forgot it all, but it seems to do a trick that if you
run UML with a non-root UID (if that's actually possible), the files
owned by you on the host system are owned by root inside of the UML
(which does not seem to be so unreasonable, but should be probably
configurable if it's the case) - depends on what context getuid() runs
in, which I'm not sure of anymore neither.
The gid handling is clearly buggy. It should test that in read_name()
too and use getgid().
I don't know why it happens only on ROOT_DEV, perhaps some heuristic.
Anyway, this comes (almost) verbatim from the 2.4.19 version by Jeff
Dike, so he will hopefully come with a better explanation :-).
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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
[PATCH] fat: fix writev(), add aio support
This patch fixes vectored write support on fat to do the nessecary
non-standard action done in write() aswell.
Also adds aio support and makes read/write wrappers around the aio
version.
--- 1.28/fs/fat/file.c 2005-01-21 06:02:08 +01:00
+++ edited/fs/fat/file.c2005-01-25 14:10:05 +01:00
@@ -12,13 +12,28 @@
#include linux/smp_lock.h
#include linux/buffer_head.h
-static ssize_t fat_file_write(struct file *filp, const char __user *buf,
- size_t count, loff_t *ppos)
+static ssize_t fat_file_aio_write(struct kiocb *iocb, const char __user *buf,
+ size_t count, loff_t pos)
+{
+ struct inode *inode = iocb-ki_filp-f_dentry-d_inode;
+ int retval;
+
+ retval = generic_file_aio_write(iocb, buf, count, pos);
+ if (retval 0) {
+ inode-i_mtime = inode-i_ctime = CURRENT_TIME_SEC;
+ MSDOS_I(inode)-i_attrs |= ATTR_ARCH;
+ mark_inode_dirty(inode);
+ }
+ return retval;
+}
+
+static ssize_t fat_file_writev(struct file *filp, const struct iovec *iov,
+ unsigned long nr_segs, loff_t *ppos)
{
struct inode *inode = filp-f_dentry-d_inode;
int retval;
- retval = generic_file_write(filp, buf, count, ppos);
+ retval = generic_file_writev(filp, iov, nr_segs, ppos);
if (retval 0) {
inode-i_mtime = inode-i_ctime = CURRENT_TIME_SEC;
MSDOS_I(inode)-i_attrs |= ATTR_ARCH;
@@ -29,12 +44,14 @@
struct file_operations fat_file_operations = {
.llseek = generic_file_llseek,
- .read = generic_file_read,
- .write = fat_file_write,
+ .read = do_sync_read,
+ .write = do_sync_write,
+ .readv = generic_file_readv,
+ .writev = fat_file_writev,
+ .aio_read = generic_file_aio_read,
+ .aio_write = fat_file_aio_write,
.mmap = generic_file_mmap,
.fsync = file_fsync,
- .readv = generic_file_readv,
- .writev = generic_file_writev,
.sendfile = generic_file_sendfile,
};
-
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
Re: [PATCH] fat: fix writev(), add aio support
Christoph Hellwig [EMAIL PROTECTED] writes: This patch fixes vectored write support on fat to do the nessecary non-standard action done in write() aswell. Also adds aio support and makes read/write wrappers around the aio version. The fatfs doesn't have the -direct_IO(), so the AIO stuff seems to be not useful for now. However, patch itself looks good. Thanks, I'll submit. -- OGAWA Hirofumi [EMAIL PROTECTED] - 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
Re: [RFC] shared subtrees
On Tue, Jan 25, 2005 at 04:47:04PM -0500, Mike Waychison wrote: Although Al hasn't explicitly defined the semantics for mount - --make-shared, I think the idea is that 'only' that mountpoint becomes tagged as shared (becomes a member of a p-node of size 1). On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote: * we can mark a subtree sharable. Every vfsmount in the subtree that is not already in some p-node gets a single-element p-node of its own. Also, note that mount automatically sets up propagation that mirrors that of the mounted on vfsmount, so by default new mounts anywhere in the subtree will also be tagged as shared. --b. - 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
Re: [RFC] shared subtrees
On Tue, 2005-01-25 at 13:47, Mike Waychison wrote: ...snip... Question 2: When a mount gets propogated to a slave, but the slave has mounted something else at the same place, and hence that mount point is masked, what will happen? Concrete example: mount device1 /tmp/mnt1 mkdir -p /tmp/mnt1/a/b mount --rbind /tmp/mnt1 /tmp/mnt2 mount --make-slave /tmp/mnt2 EINVAL. You should only be able to demote a mountpoint to a slave if it was part of a p-node (shared). oops. I had the following in mind. mount device1 /tmp/mnt1 ** mount --make-shared /tmp/mnt1 ** mkdir -p /tmp/mnt1/a/b mount --rbind /tmp/mnt1 /tmp/mnt2 mount --make-slave /tmp/mnt2 In this case it cannot be EINVAL, because /tmp/mnt1 and /tmp/mnt2 will both be part of a pnode and hence /tmp/mnt2 can be demoted to be a slave. mount device2 /tmp/mnt2/a rm -f /tmp/mnt2/a/* what happens when a mount is attempted on /tmp/mnt1/a/b? will that be reflected in /tmp/mnt2/a ? I believe the answer is 'no', because that part of the subtree in /tmp/mnt2 no more mirrors its parent subtree. RP - 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 - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9r5YdQs4kOxk3/MRApT3AJ9xxpdacU0mp8IvsY395MDtEktJ+wCeOvRT /g7qXO9nGxMT/iFAZoUO8F4= =9D2G -END PGP SIGNATURE- - 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 - 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
Re: [RFC] shared subtrees
On Mon, 2005-01-17 at 09:32, J. Bruce Fields wrote: On Mon, Jan 17, 2005 at 06:11:50AM +, Al Viro wrote: No - I have been missing a typo. Make that if mountpoint of what we are moving OK, got it, so the point is that its not clear how you'd propagate the removal of the subtree from the vfsmount of the source mountpoint. By the way, I wrote up some notes this weekend in an attempt to explain the shared subtrees RFC to myself. They may or may not be helpful to anyone else: http://www.fieldses.org/~bfields/kernel/viro_mount_propagation.txt Question 1: If there exists a private subtree in a larger shared subtree, what happens when the larger shared subtree is rbound to some other place? Is a new private subtree created in the new larger shared subtree? or will that be pruned out in the new larger subtree? Concrete example: mount device1 /tmp/mnt1 mount device2 /tmp/mnt1/mnt1.1 mount device3 /tmp/mnt1/mnt1.1/mnt1.1.1 make --make-shared /tmp/mnt1 mount --make-private /tmp/mnt1/mnt1.1 make --rbind /tmp/mnt1 /tmp/mnt2 Question: will I see the mount at /tmp/mnt2/mnt1.1/mnt1.1.1 ? My guess is since /tmp/mnt1/mnt1.1 is private that subtree should not be even seen under /tmp/mnt2/mnt1.1 , Is that the case? Or does the subtree get mirrored in /tmp/mnt2/mnt1.1; however propogation is not set between the vfsstruct of /mnt/mnt1/mnt1.1 and /mnt/mnt2/mnt1.1 ? I believe its the former case. Question 2: When a mount gets propogated to a slave, but the slave has mounted something else at the same place, and hence that mount point is masked, what will happen? Concrete example: mount device1 /tmp/mnt1 mkdir -p /tmp/mnt1/a/b mount --rbind /tmp/mnt1 /tmp/mnt2 mount --make-slave /tmp/mnt2 mount device2 /tmp/mnt2/a rm -f /tmp/mnt2/a/* what happens when a mount is attempted on /tmp/mnt1/a/b? will that be reflected in /tmp/mnt2/a ? I believe the answer is 'no', because that part of the subtree in /tmp/mnt2 no more mirrors its parent subtree. RP - 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
Re: [RFC] shared subtrees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 J. Bruce Fields wrote: On Tue, Jan 25, 2005 at 04:47:04PM -0500, Mike Waychison wrote: Although Al hasn't explicitly defined the semantics for mount - --make-shared, I think the idea is that 'only' that mountpoint becomes tagged as shared (becomes a member of a p-node of size 1). On Thu, Jan 13, 2005 at 10:18:51PM +, Al Viro wrote: * we can mark a subtree sharable. Every vfsmount in the subtree that is not already in some p-node gets a single-element p-node of its own. Also, note that mount automatically sets up propagation that mirrors that of the mounted on vfsmount, so by default new mounts anywhere in the subtree will also be tagged as shared. Why not simply call this --make-rshared and keep --make-shared only share a single mount then? - -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice ~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9tzDdQs4kOxk3/MRAp3jAJ9CjPjEQs1jvcm92Q2jAizYvnBOSgCeJ9A0 Jt0d1v7iLB3EPbEWq9r6zik= =3u5S -END PGP SIGNATURE- - 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
