On Sun 2007-07-15 15:06:59, Miklos Szeredi wrote:
> > > SIGKILL won't work on a stopped task. Neither on a traced task.
> >
> > Why do you think so? It works in both cases (ptracer can use
> > PT_TRACE_EXIT, but the task is killed anyway).
>
> Just from experience with tasks stuck in "T" state.
> > SIGKILL won't work on a stopped task. Neither on a traced task.
>
> Why do you think so? It works in both cases (ptracer can use
> PT_TRACE_EXIT, but the task is killed anyway).
Just from experience with tasks stuck in "T" state. After for example
an UML dies, some of the processes only rea
I am sorry for being completely off-topic, but
Miklos Szeredi wrote:
>
> SIGKILL won't work on a stopped task. Neither on a traced task.
Why do you think so? It works in both cases (ptracer can use
PT_TRACE_EXIT, but the task is killed anyway).
> Neither on a zombie (how many newbies are thorou
> > Ok, I'll just blame fuse here. 'You have to write to /sys
> > files for SIGKILL to work' is not funny.
>
> SIGKILL won't work on a stopped task. Neither on a traced task.
> Neither on a zombie (how many newbies are thoroughly confused about
> that ;)
>
> And it won't work on a task that is h
> > 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
> >
Hi!
> > 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 reque
> > > 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 hand
> > In that case the "we need suspend to be invisible to userspace" as a
> > reason to use the freezer would also be moot, since if you don't
> > schedule userspace after offlining the CPUs, it can't notice this.
>
> After? Can you do the offlining atomically?
Don't know. Wait for all CPUs to re
Am Montag, 9. Juli 2007 schrieb Miklos Szeredi:
> In that case the "we need suspend to be invisible to userspace" as a
> reason to use the freezer would also be moot, since if you don't
> schedule userspace after offlining the CPUs, it can't notice this.
After? Can you do the offlining atomically?
> Please have a look at the documentation update at the bottom of this patch:
>
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc7/patches/15-freezer-make-kernel-threads-nonfreezable-by-default.patch
>
> It says what the freezer is for in the first place. :-)
Thanks, good description
On Sunday, 8 July 2007 21:50, Miklos Szeredi wrote:
> > > > Well, fix userspace filesystems and maybe NFS. If they react to
> > > > sigstop in timely manner, they will work with suspend properly, too.
> > >
> > > Which is pretty much impossible, given the unix filesystem API. To be
> > > able to
> > > Well, fix userspace filesystems and maybe NFS. If they react to
> > > sigstop in timely manner, they will work with suspend properly, too.
> >
> > Which is pretty much impossible, given the unix filesystem API. To be
> > able to react to sigstop, the operations in question need to be
> > re
On Sun, Jul 08, 2007 at 08:08:56PM +0200, Rafael J. Wysocki wrote:
> Well, the system that cannot access its filesystems is not in a consistent
> state, so it generally is not reasonable to suspend or hibernate it.
>
> In fact, NFS and similar filesystems should always be unmounted before the
> su
On Sunday, 8 July 2007 16:23, Miklos Szeredi wrote:
> > > > > > 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 th
On Sunday 08 July 2007, Al Viro wrote:
> On Sun, Jul 08, 2007 at 12:37:48PM +, Pavel Machek wrote:
> > I'm talking malicious _filesystems_ here, and yes, fuse is first of
> > this kind. We want to handle unresponding NFS, but I believe handling
> > malicious NFS server nicely is slightly out of
Pavel Machek wrote:
> We are stuck with refrigerator for now, and at least for hibernation,
> I don't see any feasible alternative.
Feasible alternative?
Freezing is the only way to successfully suspend, in kernel space that is.
The problem here is: Why do we freeze in kernel space?
APM didn'
> > > > > 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.
> >
On Sun, Jul 08, 2007 at 12:37:48PM +, Pavel Machek wrote:
> I'm talking malicious _filesystems_ here, and yes, fuse is first of
> this kind. We want to handle unresponding NFS, but I believe handling
> malicious NFS server nicely is slightly out of scope.
If your variant doesn't handle comprom
On Sunday, 8 July 2007 09:21, Miklos Szeredi wrote:
> > > > 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 on
Hi!
> > > > 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.
> >
> > S
> > > 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 hand
Hi!
> > 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 _malicio
22 matches
Mail list logo
