> > > > > We can just wait for all fuse requests to be serviced before
Which is pretty much impossible, given the unix filesystem API. To be
able to react to sigstop, the operations in question need to be
restartable. Which they are not, so they can't react to sigstop. End
of story.
Sorry, didn't mean to offend you.
No, I don't think we need to redesign the VFS, and also I think the
malicious filesystem thing has been adequately taken care of in fuse.
You may not like the fact that one process can cause another to go
into uninterruptible sleep, but in fact there's nothing wrong with
that. The effects are localized to the mount owner, it won't cause
any system-wide ill, it's in fact no worse than a malicious process
doing ptrace().
And as explained above it's unavoidable due to the well established
userspace API. The _point_ of fuse is to let this API be used by
unmodified programs and the filesystem be provided by a userspace
process. After showing me the right way to do this with Podfuk, this
should not come as a surprise to you.
So the fact that the freezer can't handle this is unfortunate, but
it's just a symptom of the brokenness of it, not something that fuse
introduced. Not being able to suspend with NFS (or other network
filesystems) when the network is lost shows that this is a deeper
problem.
And for some reason you seem not to accept that. You think that the
problem is with fuse, NFS, CIFS, whatever, and not the freezer, when
in fact it's quite clear, that neither of the above should have
anything to do with power management. Even if it was possible to fix
them, it would still be just fixing the symptoms.
Even for hibernation, I don't see, why we would need all processes
being effectively in a stopped state.
As stated otherwise in the thread, suspend2 in fact allowed processes
to be in uninterruptible sleep instead, without negative side effects.
The current freezer does too much for suspend and for hibernate too.
It doesn't have to be malicious, it's enough if the server crashes, or
the network connection is lost.
Do we want to maintain the status quo, just because we can live with
it?
Which is what, 10% of all the drivers? Then it really not as bad as
you try to make it sound. And with the late suspend call (whatever it
does) that can take care of most of those, it really becomes just a
few drivers and subsystems to fix.
Miklos
-
