Oleg Nesterov <[EMAIL PROTECTED]> writes:
> On 01/17, Eric W. Biederman wrote:
>>
>> Cedric Le Goater <[EMAIL PROTECTED]> writes:
>> >
>> > your first analysis was correct : exit_task_namespaces() should be moved
>> > above exit_notify(tsk). It will require some extra fixes for nsproxy
>> > thou
On 01/17, Eric W. Biederman wrote:
>
> Cedric Le Goater <[EMAIL PROTECTED]> writes:
> >
> > your first analysis was correct : exit_task_namespaces() should be moved
> > above exit_notify(tsk). It will require some extra fixes for nsproxy
> > though.
>
> I think the only issue is the child_reaper
On Wed, 2007-01-17 at 15:30 -0700, Eric W. Biederman wrote:
> Cedric Le Goater <[EMAIL PROTECTED]> writes:
> >
> > your first analysis was correct : exit_task_namespaces() should be moved
> > above exit_notify(tsk). It will require some extra fixes for nsproxy
> > though.
>
> I think the only is
Cedric Le Goater <[EMAIL PROTECTED]> writes:
>
> your first analysis was correct : exit_task_namespaces() should be moved
> above exit_notify(tsk). It will require some extra fixes for nsproxy
> though.
I think the only issue is the child_reaper and currently we only have one of
those. When we
Oleg Nesterov wrote:
> On 01/17, Cedric Le Goater wrote:
>> Oleg Nesterov wrote:
>>> On 01/17, Daniel Hokka Zakrisson wrote:
It was the only semi-plausible explanation I could come up with. I added a
printk in do_exit right before exit_task_namespaces, where sighand was
still set, an
On 01/17, Cedric Le Goater wrote:
>
> Oleg Nesterov wrote:
> > On 01/17, Daniel Hokka Zakrisson wrote:
> >> It was the only semi-plausible explanation I could come up with. I added a
> >> printk in do_exit right before exit_task_namespaces, where sighand was
> >> still set, and one right before the
Oleg Nesterov wrote:
> On 01/17, Daniel Hokka Zakrisson wrote:
Call Trace:
[] _spin_lock_irqsave+0x20/0x90
[] lockd_down+0x125/0x190
[] nfs_free_server+0x6d/0xd0
[] nfs_kill_super+0xc/0x20
[] deactivate_super+0x7d/0xa0
[] release_mounts+0x6e/0x80
[] __
On 01/17, Daniel Hokka Zakrisson wrote:
>
> >> Call Trace:
> >> [] _spin_lock_irqsave+0x20/0x90
> >> [] lockd_down+0x125/0x190
> >> [] nfs_free_server+0x6d/0xd0
> >> [] nfs_kill_super+0xc/0x20
> >> [] deactivate_super+0x7d/0xa0
> >> [] release_mounts+0x6e/0x80
> >> [] __put_mnt_ns+0x66/0x80
Eric W. Biederman wrote:
> "Daniel Hokka Zakrisson" <[EMAIL PROTECTED]> writes:
>
>> The test-case at the bottom causes the following recursive Oopsing on
>> 2.6.20-rc5:
>
> A few more people added to the CC who might have a clue.
>
>>
>> BUG: unable to handle kernel NULL pointer dereference at vir
"Daniel Hokka Zakrisson" <[EMAIL PROTECTED]> writes:
> The test-case at the bottom causes the following recursive Oopsing on
> 2.6.20-rc5:
A few more people added to the CC who might have a clue.
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 0504
> printing
10 matches
Mail list logo