> > 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
> > > > > 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
Alan Stern writes:
> In answer to both questions: We need the freezer in order to implement
> hibernate. Even if we take your advice and stop using the freezer
> during suspend, these issues would still remain and would need to be
> solved.
Stepping back for a minute, let's think about what t
> > Well... 2 things here. Either you have a freezer in which case the
> > chances of the above scenario are increased,
>
> How so? :-)
I meant you have a freezer that freezes uninterruptible tasks.
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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
On Saturday, 7 July 2007 14:08, Pavel Machek wrote:
> Hi!
>
> > > Now, if kernel needs FUSE services for some reason (that's the problem
> > > we hit in s2ram case, right?), we have a deadlock.
> > >
> > > So main problem still seems to be "kernel should not depend on
> > > userland services duri
> 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.
Look at it this way: the task of the freezer is to
On Saturday, 7 July 2007 04:44, Benjamin Herrenschmidt wrote:
> On Fri, 2007-07-06 at 11:31 +0200, Oliver Neukum wrote:
> > Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> > > On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
> > > >
> > > > The only reason (I know of) why we
> > One task doing ptrace() can basically do whatever it wants with the
> > task being traced. This is not an exact analogy to what fuse does,
> > but close.
>
> Well, IMO userland tasks should not have power to grab VFS mutexes for
> indefinite ammount of time. ("fused is allowed to deadlock ker
On Fri 2007-07-06 09:07:38, Miklos Szeredi wrote:
> > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > syscall may not be restarted.
> >
> > Okay, and you should handle refrigerator in the same paths where you
> > handle SIGKILL. Just add try_to_freeze() there...
>
> It's
Hi!
> > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > syscall may not be restarted.
> >
> > I think you want to stick try_to_freeze() at the same places where you
> > do SIGKILL handling. That should solve the 'syslogd is unfreezeable'
> > problem.
>
> I could, but it
On Thu 2007-07-05 10:15:01, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > This is incompatible with the code in kernel/power/main.c, since we only
> > disable the nonboot CPUs after devices have been suspended. Do you think
> > that
> > your framework can be modified to work without di
Hi!
> > Now, if kernel needs FUSE services for some reason (that's the problem
> > we hit in s2ram case, right?), we have a deadlock.
> >
> > So main problem still seems to be "kernel should not depend on
> > userland services during suspend", refrigerator or not.
>
> And also "Userland should n
Hi!
> > > > You have processes that don't react to signals, because some
> > > > other user land task is misbehaving. I'd call that ugly at the
> > > > very least.
> > >
> > > It already happens with, say, NFS. Don't think about it in terms of a
> > > userland task misbehaving - think of it in
Hi!
> > > And also "Userland should not depend on userland services", which is
> > > rather more of a problem.
> >
> > I think you're oversimplifying it, as far as FUSE is concerned.
> >
> > Namely, if there are two userland tasks, A and B, and B is uninterruptible,
> > because A is blocked, th
Hi!
> > How will that help? Block the kernel thread in the freezer or block it
> > in the driver -- either way it is blocked. So how do your deadlocks
> > get resolved?
>
> Because nobody is waiting on that kernel thread anyway without a freezer
> so there is no deadlock anymore.
In the dead
On Fri, 2007-07-06 at 11:53 +0200, Rafael J. Wysocki wrote:
>
> Moreover, I claim that, in the context of your example, _if_ the task
> is stuck
> at the wait_event_uninterruptible(), _then_ the freezerless suspend
> will
> deadlock with the task.
Why would the task be stuck there if it's not bec
On Fri, 2007-07-06 at 11:31 +0200, Oliver Neukum wrote:
> Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> > On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
> > >
> > > The only reason (I know of) why we don't handle uninterruptible tasks in
> > > the
> > > freezer is that w
On Fri, 6 Jul 2007, Benjamin Herrenschmidt wrote:
> Why are you guys working so hard and spending so much energy to try to
> avoid doing the right thing is beyond my understanding...
>
> > It _does_ apply to kernel threads. That's exactly why I wrote above
> > that kernel threads which try to d
Am Freitag, 6. Juli 2007 schrieb Benny Amorsen:
> > "ON" == Oliver Neukum <[EMAIL PROTECTED]> writes:
>
> ON> Because we will be unable to escape that job. Let's assume that we
> ON> remove the freezer from the STR path. The next complaint would be
> ON> that we cannot do STD with fuse. "Then
> "ON" == Oliver Neukum <[EMAIL PROTECTED]> writes:
ON> Because we will be unable to escape that job. Let's assume that we
ON> remove the freezer from the STR path. The next complaint would be
ON> that we cannot do STD with fuse. "Then don't do that" would not be
ON> taken kindly as answer.
A
On Friday, 6 July 2007 11:31, Oliver Neukum wrote:
> Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> > On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
> > >
> > > The only reason (I know of) why we don't handle uninterruptible tasks in
> > > the
> > > freezer is that we're
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
> >
> > The only reason (I know of) why we don't handle uninterruptible tasks in the
> > freezer is that we're afraid of the suspend process deadlocking with an
> > uninterruptibl
On Fri, 2007-07-06 at 09:13 +0200, Rafael J. Wysocki wrote:
>
> The only reason (I know of) why we don't handle uninterruptible tasks in the
> freezer is that we're afraid of the suspend process deadlocking with an
> uninterruptible task holding a lock, but AFAICS the probability of such an
> even
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
> > Yes, fuse could handle being frozen there. However that would only
> > solve part of the problem: an operation waiting for a reply could be
> > holding a VFS mutex and some other task may be blocked on that mutex.
> >
> > How would you
Am Freitag, 6. Juli 2007 schrieb Benjamin Herrenschmidt:
>
> > There is that.
> >
> > OK, bite the bullet. Tasks involved in fuse are special. Give them a flag
> > and teach the freezer to put them on ice only after all other task are
> > frozen. In a way they are kernel, there's no use denying t
On Friday, 6 July 2007 00:59, Benjamin Herrenschmidt wrote:
> On Thu, 2007-07-05 at 10:23 -0400, Alan Stern wrote:
> >
> > How will that help? Block the kernel thread in the freezer or block it
> > in the driver -- either way it is blocked. So how do your deadlocks
> > get resolved?
>
> Becau
On Friday, 6 July 2007 00:04, Pavel Machek wrote:
> Hi!
>
> > > > > > > I have discussed the benefits elsewhere. As for the deadlocks --
> > > > > > > do
> > > > > > > you still observe them if you use the version of the freezer
> > > > > > > which
> > > > > > > doesn't freeze kernel threads?
> > Actually fuse allows SIGKILL, because it's always fatal, and the
> > syscall may not be restarted.
>
> Okay, and you should handle refrigerator in the same paths where you
> handle SIGKILL. Just add try_to_freeze() there...
It's the fourth time I'm repeating this in this thread:
Yes adding t
On Thursday, 5 July 2007 23:37, Oliver Neukum wrote:
> Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> > On Thu, 5 Jul 2007, Miklos Szeredi wrote:
> >
> > > I fear, that your efforts to "save" the freezer are in vain. It is
> > > already moderately hackish with that PF_FREEZER_SKIP and the kern
On Friday, 6 July 2007 00:38, Benjamin Herrenschmidt wrote:
>
> > There is that.
> >
> > OK, bite the bullet. Tasks involved in fuse are special. Give them a flag
> > and teach the freezer to put them on ice only after all other task are
> > frozen. In a way they are kernel, there's no use denyin
Matthew Garrett <[EMAIL PROTECTED]> writes:
> On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
>> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
>> > I have a model for STD that avoids the need to freeze the entirity of
>> > userspace, but I need to find some more time to
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
[snip]
> At the end of the day, I stand my ground, the freezer cannot be made
> reliable without massive infrastructure changes or giving up on very
> useful features such as fuse among others. Besides, it only partially
> "hides" the problem of
> Yes, fuse could handle being frozen there. However that would only
> solve part of the problem: an operation waiting for a reply could be
> holding a VFS mutex and some other task may be blocked on that mutex.
>
> How would you solve freezing those tasks?
That task is implicitely frozen... bu
On Thu, 2007-07-05 at 10:23 -0400, Alan Stern wrote:
>
> How will that help? Block the kernel thread in the freezer or block it
> in the driver -- either way it is blocked. So how do your deadlocks
> get resolved?
Because nobody is waiting on that kernel thread anyway without a freezer
so the
> There is that.
>
> OK, bite the bullet. Tasks involved in fuse are special. Give them a flag
> and teach the freezer to put them on ice only after all other task are
> frozen. In a way they are kernel, there's no use denying that.
Yet another ugly hack to work around the fact that the freezer
Hi!
> > > > > > I have discussed the benefits elsewhere. As for the deadlocks --
> > > > > > do
> > > > > > you still observe them if you use the version of the freezer which
> > > > > > doesn't freeze kernel threads?
> > > > >
> > > > > In general the only way to guarantee there are no deadl
Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> On Thu, 5 Jul 2007, Miklos Szeredi wrote:
>
> > I fear, that your efforts to "save" the freezer are in vain. It is
> > already moderately hackish with that PF_FREEZER_SKIP and the kernel
> > dotted randomly with try_to_freeze() calls, but adding b
> > On Thu, 5 Jul 2007, Oliver Neukum wrote:
> >
> > > > Obviously. Â But I wasn't about the server trying to acquire a lock
> > > > held by a client. Â I was talking about a client trying to acquire a
> > > > lock held by _another_ client.
> > > >
> > > > If this coincides with the server (or so
> > I fear, that your efforts to "save" the freezer are in vain. It is
> > already moderately hackish with that PF_FREEZER_SKIP and the kernel
> > dotted randomly with try_to_freeze() calls, but adding bandaids to try
> > to order freezing userspace processes in the right order would just
> > make
Am Donnerstag, 5. Juli 2007 schrieb Alan Stern:
> On Thu, 5 Jul 2007, Oliver Neukum wrote:
>
> > > Obviously. Â But I wasn't about the server trying to acquire a lock
> > > held by a client. Â I was talking about a client trying to acquire a
> > > lock held by _another_ client.
> > >
> > > If thi
On Thu, 5 Jul 2007, Miklos Szeredi wrote:
> I fear, that your efforts to "save" the freezer are in vain. It is
> already moderately hackish with that PF_FREEZER_SKIP and the kernel
> dotted randomly with try_to_freeze() calls, but adding bandaids to try
> to order freezing userspace processes in
> > > > Yes, fuse could handle being frozen there. However that would only
> > > > solve part of the problem: an operation waiting for a reply could be
> > > > holding a VFS mutex and some other task may be blocked on that mutex.
> > > >
> > > > How would you solve freezing those tasks?
> > >
>
On Thu, 5 Jul 2007, Oliver Neukum wrote:
> > Obviously. Â But I wasn't about the server trying to acquire a lock
> > held by a client. Â I was talking about a client trying to acquire a
> > lock held by _another_ client.
> >
> > If this coincides with the server (or some other task which the serv
On Thursday, 5 July 2007 22:38, Miklos Szeredi wrote:
> > > > > > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > > > > > syscall may not be restarted.
> > > > > >
> > > > > > I think you want to stick try_to_freeze() at the same places where
> > > > > > you
> > > > > > d
Am Donnerstag, 5. Juli 2007 schrieb Oliver Neukum:
> Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > Yes, fuse could handle being frozen there. However that would only
> > > > solve part of the problem: an operation waiting for a reply could be
> > > > holding a VFS mutex and some othe
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > Yes, fuse could handle being frozen there. However that would only
> > > solve part of the problem: an operation waiting for a reply could be
> > > holding a VFS mutex and some other task may be blocked on that mutex.
> > >
> > > How would
> > Yes, fuse could handle being frozen there. However that would only
> > solve part of the problem: an operation waiting for a reply could be
> > holding a VFS mutex and some other task may be blocked on that mutex.
> >
> > How would you solve freezing those tasks?
>
> OK, you made me reach fo
> > > > > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > > > > syscall may not be restarted.
> > > > >
> > > > > I think you want to stick try_to_freeze() at the same places where you
> > > > > do SIGKILL handling. That should solve the 'syslogd is unfreezeable'
> > > > >
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > > > syscall may not be restarted.
> > > >
> > > > I think you want to stick try_to_freeze() at the same place
On Thursday, 5 July 2007 21:44, Miklos Szeredi wrote:
> > Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > > > syscall may not be restarted.
> > > >
> > > > I think you want to stick try_to_freeze() at the same pla
> Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > > syscall may not be restarted.
> > >
> > > I think you want to stick try_to_freeze() at the same places where you
> > > do SIGKILL handling. That should solve the '
Am Donnerstag, 5. Juli 2007 schrieb Miklos Szeredi:
> > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > syscall may not be restarted.
> >
> > I think you want to stick try_to_freeze() at the same places where you
> > do SIGKILL handling. That should solve the 'syslogd is u
Matthew Garrett <[EMAIL PROTECTED]> writes:
> On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
>> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
>> > I have a model for STD that avoids the need to freeze the entirity of
>> > userspace, but I need to find some more time t
> > > You have processes that don't react to signals, because some
> > > other user land task is misbehaving. I'd call that ugly at the
> > > very least.
> >
> > It already happens with, say, NFS. Don't think about it in terms of a
> > userland task misbehaving - think of it in terms of a resour
On Thursday, 5 July 2007 17:03, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 05:04:47PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> > > Why?
> >
> > You have processes that don't react to signals, because some other user land
> > task is misbeha
On Thu, Jul 05, 2007 at 05:04:47PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> > Why?
>
> You have processes that don't react to signals, because some other user land
> task is misbehaving. I'd call that ugly at the very least.
It already happens wi
On Thu, Jul 05, 2007 at 07:46:01AM -0700, Ray Lee wrote:
> Hmm, careful. There are a bunch of people who use suspend2 exactly
> because it saves and restores the page cache, leaving the system in a
> usable state without waiting for the universe to swap back in from
> disk. It makes a big differen
On Thursday, 5 July 2007 16:39, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 04:41:39PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> > > On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > > > On Thursday, 5 July 2007 15:57, Mat
On Thursday, 5 July 2007 16:23, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
> > > I have a model for STD that avoids the need to freeze the entirity of
> > > userspace, but I need to find som
On 7/5/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
> > I have a model for STD that avoids the need to freeze the entirity of
> > userspace, but I need to find some more t
On Thu, 5 Jul 2007, Paul Mackerras wrote:
> Alan Stern writes:
>
> > > > Yes, the code could be changed to keep track of the reason for a device
> > > > suspend. But that just raises the old problem of what to do when
> > > > there's an I/O request for a suspended device during STR.
> > >
> > >
On Thu, Jul 05, 2007 at 04:41:39PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> > On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > > On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > > > And also "Userland should not depen
On Thursday, 5 July 2007 16:26, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> > On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > > And also "Userland should not depend on userland services", which is
> > > rather more of a problem.
> >
> >
On Thu, Jul 05, 2007 at 04:28:11PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> > And also "Userland should not depend on userland services", which is
> > rather more of a problem.
>
> I think you're oversimplifying it, as far as FUSE is concerned.
>
On Thu, Jul 05, 2007 at 04:09:24PM +0200, Rafael J. Wysocki wrote:
> On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
> > I have a model for STD that avoids the need to freeze the entirity of
> > userspace, but I need to find some more time to flesh it out.
>
> You can just describe it, as
On Thu, 5 Jul 2007, Paul Mackerras wrote:
> Alan Stern writes:
>
> > Let's agree the kernel threads and the freezer are a separate issue.
>
> No, I don't think they are a separate issue, because I think the
> distinction the freezer makes between kernel threads and user threads
> is a false an
On Thursday, 5 July 2007 15:57, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 11:15:26AM +0200, Pavel Machek wrote:
>
> > Now, if kernel needs FUSE services for some reason (that's the problem
> > we hit in s2ram case, right?), we have a deadlock.
> >
> > So main problem still seems to be "ker
> > I guess I know your answer. But it ain't gonna work. Suspend code
> > really doesn't belong in VFS, and I'm pretty sure the maintainers of
> > that little piece of code would agree with me on this.
>
> Surprise, surprise. Not that I'm scared of the VFS maintainers, though. ;-)
Probably yo
On Thursday, 5 July 2007 15:50, Miklos Szeredi wrote:
> > > > Don't you think, however, that it can be modified a little to play well,
> > > > for example, with the freezer?
> > >
> > > I could stick a couple of try_to_freeze()s into fuse, and that would
> > > make suspend failure less likely. Bu
On Thursday, 5 July 2007 15:46, Matthew Garrett wrote:
> On Thu, Jul 05, 2007 at 03:28:33PM +0200, Oliver Neukum wrote:
>
> > If, at a minimum, we can determine that we can STD without a freezer.
> > It makes no sense to invest a lot of work to face the same problem
> > again with STD.
>
> I have
On Thu, Jul 05, 2007 at 11:15:26AM +0200, Pavel Machek wrote:
> Now, if kernel needs FUSE services for some reason (that's the problem
> we hit in s2ram case, right?), we have a deadlock.
>
> So main problem still seems to be "kernel should not depend on
> userland services during suspend", refri
On Thursday, 5 July 2007 15:28, Oliver Neukum wrote:
> Am Donnerstag, 5. Juli 2007 schrieb Rafael J. Wysocki:
> > > It seems pretty clear cut. Whining about how much problems this will
> > > cause won't get us nearer to a solution.
> >
> > Yes, that's pretty clear cut, but we should start from fi
> > > Don't you think, however, that it can be modified a little to play well,
> > > for example, with the freezer?
> >
> > I could stick a couple of try_to_freeze()s into fuse, and that would
> > make suspend failure less likely. But making problems less easy to
> > reproduce is not a good thing
On Thu, Jul 05, 2007 at 03:28:33PM +0200, Oliver Neukum wrote:
> If, at a minimum, we can determine that we can STD without a freezer.
> It makes no sense to invest a lot of work to face the same problem
> again with STD.
I have a model for STD that avoids the need to freeze the entirity of
user
Am Donnerstag, 5. Juli 2007 schrieb Rafael J. Wysocki:
> > It seems pretty clear cut. Whining about how much problems this will
> > cause won't get us nearer to a solution.
>
> Yes, that's pretty clear cut, but we should start from fixing the drivers. :-)
If, at a minimum, we can determine that
On Thursday, 5 July 2007 14:24, Miklos Szeredi wrote:
> > Don't you think, however, that it can be modified a little to play well,
> > for example, with the freezer?
>
> I could stick a couple of try_to_freeze()s into fuse, and that would
> make suspend failure less likely. But making problems le
On Thursday, 5 July 2007 14:07, Miklos Szeredi wrote:
> > > Actually fuse allows SIGKILL, because it's always fatal, and the
> > > syscall may not be restarted.
> >
> > I think you want to stick try_to_freeze() at the same places where you
> > do SIGKILL handling. That should solve the 'syslogd is
On Thursday, 5 July 2007 13:54, Miklos Szeredi wrote:
> > > Limiting what a userspace filesystem can do would defeat the whole
> > > purpose of the bloody thing. This is not negotiable ;)
> >
> > Which doesn't change the fact that FUSE _is_ special, because it adds
> > dependencies between proces
> > Actually fuse allows SIGKILL, because it's always fatal, and the
> > syscall may not be restarted.
>
> I think you want to stick try_to_freeze() at the same places where you
> do SIGKILL handling. That should solve the 'syslogd is unfreezeable'
> problem.
I could, but it would not solve the g
> > Limiting what a userspace filesystem can do would defeat the whole
> > purpose of the bloody thing. This is not negotiable ;)
>
> Which doesn't change the fact that FUSE _is_ special, because it adds
> dependencies between processed that were not present before.
OK, fuse is special. So is t
Hi!
> > > > In which way can user space tasks depend on each other in a way that
> > > > allows a them members of that cycle to be in uninterruptible sleep?
> > >
> > > - process A calls rename() on a fuse fs
> > > - process B, the fuse server, starts to process the rename request
> > > - proc
From: David Howells <[EMAIL PROTECTED]>
Be (self-)consistent and use CONFIG_GDB_CONSOLE everywhere rather than using
CONFIG_GDBSTUB_CONSOLE in some places and not others. This is also then
consistent with other archs.
Also remove the gdbstub condole device() op which doesn't seem to be necessary
On Thursday, 5 July 2007 02:15, Paul Mackerras wrote:
> Rafael J. Wysocki writes:
>
> > This is incompatible with the code in kernel/power/main.c, since we only
> > disable the nonboot CPUs after devices have been suspended. Do you think
> > that
> > your framework can be modified to work withou
On Thursday, 5 July 2007 12:14, Miklos Szeredi wrote:
> > > > > And teach VFS to block suspension, while waiting on a mutex held by
> > > > > another process performing a fuse operation.
> > > > >
> > > > > I can already hear the beautiful praise from Al Viro at the sight of
> > > > > that ;)
> >
1 - 100 of 176 matches
Mail list logo
