[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20040618013028.GA8252@openwall.com>
Date: Fri, 18 Jun 2004 05:30:28 +0400
From: Solar Designer <solar@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: crash
On Wed, Jun 16, 2004 at 07:20:43PM +0400, Michael Tokarev wrote:
> (BTW, what will set_current_state(TASK_UNINTERRUPTIBLE) do
> with the whole kernel in case SECOND retry will be successeful?
> Shouldn't there be set_current_state(TASK_INTERRUPTIBLE) somewhere
> too?)
No, it's OK. The call to schedule_timeout() will take care of that:
* You can set the task state as follows -
*
* %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
* pass before the routine returns. The routine will return 0
*
* %TASK_INTERRUPTIBLE - the routine may return early if a signal is
* delivered to the current task. In this case the remaining time
* in jiffies will be returned, or 0 if the timer expired in time
*
* The current task state is guaranteed to be TASK_RUNNING when this
* routine returns.
> >Thank you for pointing out the problem with this and also for sharing
> >your approach to replacing kernels with owl-users.
>
> Heh. I think the approach is quite logical thing to do...
Indeed.
> At least I was doing it that way for ages, and it saved
> me numerous times in the past from all sorts of various
> mistakes i'm doing all the time... ;)
I've been using "lilo -R" a lot too, but not the reboot on panic.
> Ok. I think the attached 3-liner should do the trick,
Yes. I've re-done it slightly differently, though, to better preserve
the unpatched kernel's behavior when all 10 retries fail.
Thanks again,
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
