> > > We can just wait for all fuse requests to be serviced before > > > proceeding further with freeze, right? > > > > Right. Nice way to slow down or stop the suspend with an unprivileged > > process. Avoiding that sort of DoS is one of the design goals of > > fuse. > > So you want me to handle _malicious_ filesystems now? > > That should be easy... :-). You already have nasty deadlocks in FUSE, > and you solve them by "root can echo 1 > abort"... so allow me the > same possibility. > > We can tell fused we are freezing, and if all the requests are not > serviced within, say, 30 seconds, we call the filesystem malicious and > do echo 1 > abort. > > Not ideal, but neither is allowing malicious filesystems in the first > place...
Actually there's also a non-malicious case in which waiting for requests to finish won't work: when one fuse filesystem is accessing another. Since we are blocking new fuse requests, that might block a fuse daemon, which in turn makes it impossible to finish the pending request. And this is not at all theoretical, I know that encfs is used over various other fuse filesystems like sshfs or ntfs-3g. Yeah, stacking userspace filesystems could be done entirely in userspace, and I'm actually working on that (with fuse-2.7.0 already supporting some basic stacking). But the point is, that the "wait for fuse to quiescence" hack would not work in todays environment. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
