Re: A patch for the file kernel/fork.c

[André Pereira de Almeida <andre@cachola.com.br>]

Andrew Morton wrote:

> Alexander Nyberg <alexn@dsv.su.se> wrote:
>  
>
> > > [4300748.423000] Call Trace:
> > > [4300748.423000]  [<c0104bfa>] show_stack+0x7a/0x90
> > > [4300748.423000]  [<c0104d7d>] show_registers+0x14d/0x1b0
> > > [4300748.423000]  [<c0104fcc>] die+0x14c/0x2c0
> > > [4300748.423000]  [<c0118b6f>] do_page_fault+0x31f/0x638
> > > [4300748.423000]  [<c01046df>] error_code+0x4f/0x54
> > > [4300748.423000]  [<c02b88fd>] tty_wakeup+0x5d/0x60
> > >
> > > I think that maybe it's good to put a:
> > >       WARN_ON(!mm);
> > > but a BUG_ON or without this patch, the kernel will halt, even if the 
> > > problem is not so severe.
> > >      
> > Patching up the kernel hiding things that must not happen is not the way
> > to go. All kernel bugs are severe (as you just showed us!). Adding extra
> > checks like your original patch did may even cause much more harm
> > because it may hide other problems causing silent problems.
> >    
>
> If I understand Andre correctly, his patch will prevent infinite recursion
> in the oops path - if some process oopses after having run exit_mm().
>
> If so then it's a reasonable debugging aid.  Although there might be better
> places to do it, such as
>
> 	if (!current->i_tried_to_exit++)
> 		return;
>
> in do_exit().   Dunno.
>
>  
I agree. If you need this patch, the you are in already in trouble, your 
kernel had already oopsed, your system is halted and you can't even send 
a bug report because you can't read read the call trace (it's an 
infinite recursion) and you can see only the end of it. It's not 
intended to hide the problem, the problem will be already in your screen.
André.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/