From: Damjan L. <dam...@he...> - 2006-11-24 12:52:55
|
Hi! We at Plasmon are using FUSE to enable access to our UDO devices which have a 8k block size and as such can't be mounted by the kernel directly. We have discovered a problem with the unmount procedure: umount returns to command line before the userspace process has time to cleanup it's own caches and unlock the drive. So if another mount is run immediately after the umount then the device is still busy. Also the shutdown procedure is not safe as we might be still flushing caches but be killed too soon, instead the system waiting for us at the umount time. We saw that all the needed functionality is already in place since FUSE version 2.6.0, but it's meant for swap to underlying block device, which we can't use and don't want to either. So we would like to have a mount option that would force the umount to wait for userspace. Therefor we have written a patch (attached) that we hope you will consider for inclusion. The synchronous umount is enabled by specifying sync_umount option at mount time. Or would you consider changing the behavior of FUSE to always wait for userspace not just when using the block device? Regards, Damjan |
From: Damjan L. <dam...@he...> - 2006-11-24 13:09:40
|
I guess the mailing list is stripping attachments, so here is the patch as plain text: diff -ru fuse-2.6.0/kernel/fuse_i.h fuse-2.6.0-syncumount/kernel/fuse_i.h --- fuse-2.6.0/kernel/fuse_i.h 2006-10-15 14:52:12.000000000 +0200 +++ fuse-2.6.0-syncumount/kernel/fuse_i.h 2006-11-21 14:29:49.000000000 +0100 @@ -92,6 +92,10 @@ doing the mount will be allowed to access the filesystem */ #define FUSE_ALLOW_OTHER (1 << 1) +/** If the FUSE_SYNC_UMOUNT flag is given, then umount will wait for + userspace confirmation that the fs can be unmounted */ +#define FUSE_SYNC_UMOUNT (1 << 2) + /** List of active connections */ extern struct list_head fuse_conn_list; diff -ru fuse-2.6.0/kernel/inode.c fuse-2.6.0-syncumount/kernel/inode.c --- fuse-2.6.0/kernel/inode.c 2006-10-15 19:03:07.000000000 +0200 +++ fuse-2.6.0-syncumount/kernel/inode.c 2006-11-21 14:50:49.000000000 +0100 @@ -319,6 +319,7 @@ OPT_ALLOW_OTHER, OPT_MAX_READ, OPT_BLKSIZE, + OPT_SYNC_UMOUNT, OPT_ERR }; @@ -331,6 +332,7 @@ {OPT_ALLOW_OTHER, "allow_other"}, {OPT_MAX_READ, "max_read=%u"}, {OPT_BLKSIZE, "blksize=%u"}, + {OPT_SYNC_UMOUNT, "sync_umount"}, {OPT_ERR, NULL} }; @@ -398,7 +400,11 @@ d->blksize = value; break; - default: + case OPT_SYNC_UMOUNT: + d->flags |= FUSE_SYNC_UMOUNT; + break; + + default: return 0; } } @@ -683,7 +689,7 @@ if (!init_req) goto err_put_root; - if (is_bdev) { + if (is_bdev || (d.flags & FUSE_SYNC_UMOUNT)) { fc->destroy_req = fuse_request_alloc(); if (!fc->destroy_req) goto err_put_root; Only in fuse-2.6.0-syncumount/kernel: Module.symvers Only in fuse-2.6.0-syncumount/kernel: tags diff -ru fuse-2.6.0/lib/mount.c fuse-2.6.0-syncumount/lib/mount.c --- fuse-2.6.0/lib/mount.c 2006-09-30 16:44:42.000000000 +0200 +++ fuse-2.6.0-syncumount/lib/mount.c 2006-11-21 14:42:48.000000000 +0100 @@ -52,6 +52,7 @@ FUSE_OPT_KEY("blkdev", KEY_KERN), FUSE_OPT_KEY("blksize=", KEY_KERN), FUSE_OPT_KEY("default_permissions", KEY_KERN), + FUSE_OPT_KEY("sync_umount", KEY_KERN), FUSE_OPT_KEY("fsname=", KEY_KERN), FUSE_OPT_KEY("large_read", KEY_KERN), FUSE_OPT_KEY("max_read=", KEY_KERN), @@ -87,6 +88,7 @@ " -o fsname=NAME set filesystem name\n" " -o large_read issue large read requests (2.4 only)\n" " -o max_read=N set maximum size of read requests\n" + " -o sync_umount wait for userspace at unmount \n" "\n" ); } On Fri, 2006-11-24 at 13:49 +0100, Damjan Lango wrote: > Hi! > > We at Plasmon are using FUSE to enable access to our UDO devices which > have a 8k block size and as such can't be mounted by the kernel > directly. We have discovered a problem with the unmount procedure: > umount returns to command line before the userspace process has time to > cleanup it's own caches and unlock the drive. So if another mount is run > immediately after the umount then the device is still busy. Also the > shutdown procedure is not safe as we might be still flushing caches but > be killed too soon, instead the system waiting for us at the umount > time. We saw that all the needed functionality is already in place since > FUSE version 2.6.0, but it's meant for swap to underlying block device, > which we can't use and don't want to either. So we would like to have a > mount option that would force the umount to wait for userspace. Therefor > we have written a patch (attached) that we hope you will consider for > inclusion. The synchronous umount is enabled by specifying sync_umount > option at mount time. Or would you consider changing the behavior of > FUSE to always wait for userspace not just when using the block device? > > Regards, > Damjan > |
From: Miklos S. <mi...@sz...> - 2006-11-25 09:19:16
|
> We at Plasmon are using FUSE to enable access to our UDO devices which > have a 8k block size and as such can't be mounted by the kernel > directly. We have discovered a problem with the unmount procedure: > umount returns to command line before the userspace process has time to > cleanup it's own caches and unlock the drive. So if another mount is run > immediately after the umount then the device is still busy. What if another mount is run _before_ the other is unmounted? Isn't that an analogous situation? > Also the shutdown procedure is not safe as we might be still > flushing caches but be killed too soon, instead the system waiting > for us at the umount time. Yup, that was one of the problems for which synchronous unmount was added. > We saw that all the needed functionality is already in place since > FUSE version 2.6.0, but it's meant for swap to underlying block > device, which we can't use and don't want to either. So we would > like to have a mount option that would force the umount to wait for > userspace. Therefor we have written a patch (attached) that we hope > you will consider for inclusion. The synchronous umount is enabled > by specifying sync_umount option at mount time. Or would you > consider changing the behavior of FUSE to always wait for userspace > not just when using the block device? The problem with uncoditionally enabling synchronous unmount is that the filesystem would be able to block umount indefinitely. This can't be allowed for unprivileged mounts. But making it a privileged mount option makes sense. Thanks, Miklos |
From: Damjan L. <dam...@he...> - 2006-11-27 13:46:36
|
On Sat, 2006-11-25 at 10:18 +0100, Miklos Szeredi wrote: > > We at Plasmon are using FUSE to enable access to our UDO devices which > > have a 8k block size and as such can't be mounted by the kernel > > directly. We have discovered a problem with the unmount procedure: > > umount returns to command line before the userspace process has time to > > cleanup it's own caches and unlock the drive. So if another mount is run > > immediately after the umount then the device is still busy. > > What if another mount is run _before_ the other is unmounted? Isn't > that an analogous situation? No, because you know you have unmounted the filesystem, you would not expect the device to still be busy/locked when it has been unmounted. Also if you are using scripting you can't rely on umount, for example if you: $ mount $ do something $ umount $ mount -> error: device busy. Or another example, if you have a hardware library and want to exchange the medium between mounts (mount, do something, umount, exchange medium -> error), with the current situation you can't rely that the device/medium is free when the filesystem has been unmounted. > > Also the shutdown procedure is not safe as we might be still > > flushing caches but be killed too soon, instead the system waiting > > for us at the umount time. > > Yup, that was one of the problems for which synchronous unmount was > added. > > > We saw that all the needed functionality is already in place since > > FUSE version 2.6.0, but it's meant for swap to underlying block > > device, which we can't use and don't want to either. So we would > > like to have a mount option that would force the umount to wait for > > userspace. Therefor we have written a patch (attached) that we hope > > you will consider for inclusion. The synchronous umount is enabled > > by specifying sync_umount option at mount time. Or would you > > consider changing the behavior of FUSE to always wait for userspace > > not just when using the block device? > > The problem with uncoditionally enabling synchronous unmount is that > the filesystem would be able to block umount indefinitely. This can't > be allowed for unprivileged mounts. > > But making it a privileged mount option makes sense. Good. Will you include the proposed patch, or are there some more changes required? > Thanks, > Miklos Regards, Damjan |
From: Miklos S. <mi...@sz...> - 2006-11-28 12:40:54
|
> > The problem with uncoditionally enabling synchronous unmount is that > > the filesystem would be able to block umount indefinitely. This can't > > be allowed for unprivileged mounts. > > > > But making it a privileged mount option makes sense. > > Good. Will you include the proposed patch, or are there some more > changes required? The patch is fine. But there's a catch: how to prohibit the use of this option to normal users? A new version of fusermount could do it, but previous versions would be vulnerable, which is bad from a security POV. So it cannot be just a normal mount option. But then what? Miklos |
From: Russ C. <rs...@sw...> - 2006-11-28 13:10:48
|
> > Good. Will you include the proposed patch, or are there some more > > changes required? > > The patch is fine. But there's a catch: how to prohibit the use of > this option to normal users? A new version of fusermount could do it, > but previous versions would be vulnerable, which is bad from a > security POV. > > So it cannot be just a normal mount option. But then what? You could add another mount option, call it FUSE_ROOT, that fusermount only sends if it is being invoked by root (e.g., not when running setuid-root on behalf of a regular user), and then reject the new sync unmount option if FUSE_ROOT is not set. Since the old fusermount does not send FUSE_ROOT, it could not successfully send the sync unmount option either. Russ |
From: Miklos S. <mi...@sz...> - 2006-11-28 13:41:10
|
> > > Good. Will you include the proposed patch, or are there some more > > > changes required? > > > > The patch is fine. But there's a catch: how to prohibit the use of > > this option to normal users? A new version of fusermount could do it, > > but previous versions would be vulnerable, which is bad from a > > security POV. > > > > So it cannot be just a normal mount option. But then what? > > You could add another mount option, call it FUSE_ROOT, > that fusermount only sends if it is being invoked by root > (e.g., not when running setuid-root on behalf of a regular user), > and then reject the new sync unmount option if FUSE_ROOT > is not set. > > Since the old fusermount does not send FUSE_ROOT, it could > not successfully send the sync unmount option either. The problem is that the old fusermount does not filter out FUSE_ROOT either, so the user could add this option just the same as sync_umount. Miklos |