Return-Path: <linux-kernel-owner+willy=40w.ods.org-S261398AbVEDTR1@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S261398AbVEDTR1 (ORCPT <rfc822;willy@w.ods.org>);
	Wed, 4 May 2005 15:17:27 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261389AbVEDTR1
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Wed, 4 May 2005 15:17:27 -0400
Received: from mailfe06.swip.net ([212.247.154.161]:22965 "EHLO swip.net")
	by vger.kernel.org with ESMTP id S261398AbVEDTRK (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 4 May 2005 15:17:10 -0400
X-T2-Posting-ID: jLUmkBjoqvly7NM6d2gdCg==
Subject: Re: A patch for the file kernel/fork.c
From: Alexander Nyberg <alexn@dsv.su.se>
To: =?ISO-8859-1?Q?Andr=E9?= Pereira de Almeida <andre@cachola.com.br>
Cc: Chris Wedgwood <cw@f00f.org>, linux-kernel@vger.kernel.org
In-Reply-To: <42791CD2.5070408@cachola.com.br>
References: <4278E03A.1000605@cachola.com.br>
	 <20050504175457.GA31789@taniwha.stupidest.org>
	 <427913E4.3070908@cachola.com.br>
	 <20050504184318.GA644@taniwha.stupidest.org>
	 <42791CD2.5070408@cachola.com.br>
Content-Type: text/plain
Date: Wed, 04 May 2005 21:16:53 +0200
Message-Id: <1115234213.2562.28.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2243
Lines: 62

> >>In a preemptible kernel with the serport module and a serial port try to
> >>run the following program:
> >>
> >>int main(int argc, char **argv)
> >>{
> >>       int ldisc,fd;
> >>
> >>       fd = open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NONBLOCK);
> >>       ldisc = N_MOUSE;
> >>       ioctl(fd, TIOCSETD, &ldisc);
> >>       read(fd, NULL, 0);
> >>       return 0;
> >>}
> >>
> >>and kill it.  In my case it will hang the computer. I think this is
> >>a problem with the serport module. With this patch, the serial mouse
> >>stop working, but the computer don't hang.
> >>    
> >>
> >
> >then above something like:
> >
> >     BUG_ON(!mm);
> >
> >or something might be better and eyeball the stack trace.
> >  
> >
> In my example, a stack trace will be already generated by an oops:
> [4300748.423000] Unable to handle kernel paging request at virtual 
> address 6b6b6b7b
> [4300748.423000]  printing eip:
> [4300748.423000] d0927366
> [4300748.423000] *pde = 00000000
> [4300748.423000] Oops: 0000 [#1]
> [4300748.423000] PREEMPT
> and so on, with a call trace:
> [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.

The kernel should scream as loudly as possible when something goes
wrong. Please get the underlying problem fixed instead.

-
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/