Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/24, Eric W. Biederman wrote:
>>
>> I don't know if this is the problem but it certainly needs to be fixed.
>
> I guess you will re-submit these patches soon. May I suggest you to put
> this
>
>> +spin_lock_irq(&tsk->sighand->siglock);
>> +
On 04/24, Eric W. Biederman wrote:
>
> I don't know if this is the problem but it certainly needs to be fixed.
I guess you will re-submit these patches soon. May I suggest you to put
this
> + spin_lock_irq(&tsk->sighand->siglock);
> + signal_wake_up(tsk, 1);
> + spin_unlock_irq(&tsk-
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/24, Oleg Nesterov wrote:
>>
>> Hm, mm_release() clears ->vfork_done before complete().
Duh. Yes somehow I had a blind spot there. I clearly
need to handle that case.
>> mm_release:
>>
>> struct completion *vfork_done = tsk->v
On 04/24, Oleg Nesterov wrote:
>
> Hm, mm_release() clears ->vfork_done before complete().
>
> mm_release:
>
> struct completion *vfork_done = tsk->vfork_done;
>
> if (vfork_done) {
> tsk->vfork_done = NULL;
> complete
On 04/24, Eric W. Biederman wrote:
>
> The NULL vfork_done is really weird as exec is the only thing that sets
> vfork_done to NULL.
Hm, mm_release() clears ->vfork_done before complete().
mm_release:
struct completion *vfork_done = tsk->vfork_done;
if (v
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> Yes, it was fairly early in boot. I didn't check what we're oopsing on.
Thanks.
It was definitely vfork_done == NULL from what I can read of the Oops and
the code.
> That was on a Fedora Core 3 machine. One of those older distros I keep
> around t
On Tue, 24 Apr 2007 04:30:22 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > On Fri, 13 Apr 2007 21:13:13 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> > wrote:
> >
> >> This patch reworks kthread_stop so it is more flexible and it causes
> >>
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Fri, 13 Apr 2007 21:13:13 -0600 [EMAIL PROTECTED] (Eric W. Biederman)
> wrote:
>
>> This patch reworks kthread_stop so it is more flexible and it causes
>> the target kthread to abort interruptible sleeps. Allowing a larger
>> class of kernel threads
On Fri, 13 Apr 2007 21:13:13 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> This patch reworks kthread_stop so it is more flexible and it causes
> the target kthread to abort interruptible sleeps. Allowing a larger
> class of kernel threads to use to the kthread API.
>
> The changes start
On 04/14, Eric W. Biederman wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> writes:
>
> > On 04/13, Eric W. Biederman wrote:
> >>
> >> +static inline int __kthread_should_stop(struct task_struct *tsk)
> >> +{
> >> + return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
> >> +}
> >
> > Am I blind? Wher
Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 04/13, Eric W. Biederman wrote:
>>
>> +static inline int __kthread_should_stop(struct task_struct *tsk)
>> +{
>> +return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
>> +}
>
> Am I blind? Where does copy_process/dup_task_struct clears unwanted
> f
On 04/13, Eric W. Biederman wrote:
>
> +static inline int __kthread_should_stop(struct task_struct *tsk)
> +{
> + return test_tsk_thread_flag(tsk, TIF_KTHREAD_STOP);
> +}
Am I blind? Where does copy_process/dup_task_struct clears unwanted
flags in thread_info->flags ?
> +int kthread_stop(stru
This patch reworks kthread_stop so it is more flexible and it causes
the target kthread to abort interruptible sleeps. Allowing a larger
class of kernel threads to use to the kthread API.
The changes start by defining TIF_KTHREAD_STOP on all architectures.
TIF_KTHREAD_STOP is a per process flag
13 matches
Mail list logo
