From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754763AbZHUCJZ (ORCPT ); Thu, 20 Aug 2009 22:09:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752313AbZHUCJZ (ORCPT ); Thu, 20 Aug 2009 22:09:25 -0400 Received: from mga10.intel.com ([192.55.52.92]:48808 "EHLO fmsmga102.fm.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751488AbZHUCJY (ORCPT ); Thu, 20 Aug 2009 22:09:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.44,248,1249282800"; d="scan'208";a="719071737" Subject: Re: v2.6.31-rc6: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 From: "Zhang, Yanmin" To: Xiaotian Feng Cc: "Eric W. Biederman" , linux-kernel@vger.kernel.org, x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Linus Torvalds , Alan Cox , Greg Kroah-Hartman In-Reply-To: <7b6bb4a50908200223r2fd66e62sf659561bcf097c46@mail.gmail.com> References: <7b6bb4a50908200010h1c60d007p4fa017fd97c87c19@mail.gmail.com> <7b6bb4a50908200223r2fd66e62sf659561bcf097c46@mail.gmail.com> Content-Type: text/plain Date: Fri, 21 Aug 2009 10:09:20 +0800 Message-Id: <1250820560.2560.1004.camel@ymzhang> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 (2.22.1-2.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-08-20 at 17:23 +0800, Xiaotian Feng wrote: > I got following on 2.6.31-rc5 and rc6 ..... I didn't run into such issues on my 2 stoakley machines and 1 Nehalem machine. Perhaps kernel config bypasses this issue. What's the kernel config file you used? > > ------------[ cut here ]------------ > kernel BUG at kernel/workqueue.c:287! > invalid opcode: 0000 [#1] SMP > last sysfs file: /sys/devices/pci0000:00/0000:00:19.0/irq > CPU 2 > Modules linked in: fuse sco bridge stp llc bnep l2cap bluetooth sunrpc > ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 > dm_multipath uinput radeon snd_hda_codec_analog ttm drm snd_hda_intel > i2c_algo_bit i2c_i801 snd_hda_codec snd_hwdep snd_pcm wmi dcdbas > i2c_core ppdev parport_pc parport snd_timer e1000e snd soundcore > snd_page_alloc iTCO_wdt iTCO_vendor_support pcspkr serio_raw > ata_generic pata_acpi [last unloaded: speedstep_lib] > Pid: 17, comm: events/2 Not tainted 2.6.31-rc5 #51 OptiPlex 760 > RIP: 0010:[] [] worker_thread+0x1bc/0x31d > RSP: 0000:ffff88022ec61de0 EFLAGS: 00010286 > RAX: ffff88021200d238 RBX: ffff88003598ec00 RCX: 000000000000009f > RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff88022edf22f0 > RBP: ffff88022ec61eb0 R08: 0000000000000000 R09: ffff88003598ec00 > R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021200d230 > R13: ffff88003598ec40 R14: 0000000000000000 R15: ffff88003598ec50 > FS: 0000000000000000(0000) GS:ffff8800357b8000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > CR2: 0000000001af7aa8 CR3: 00000001fd0d3000 CR4: 00000000000406e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process events/2 (pid: 17, threadinfo ffff88022ec60000, task ffff88022edf22f0) > Stack: > ffffffff81060945 ffffffff81415f34 ffff88022ec61e00 ffff88022ec61e20 > <0> ffff88022ec61e20 ffffffff810739bb ffff88021200d238 ffff88022edf22f0 > <0> 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > Call Trace: > [] ? worker_thread+0x1c0/0x31d > [] ? thread_return+0x3e/0xaf > [] ? lock_release_holdtime+0x2c/0x11d > [] ? autoremove_wake_function+0x0/0x39 > [] ? worker_thread+0x0/0x31d > [] kthread+0x8a/0x92 > [] child_rip+0xa/0x20 > [] ? restore_args+0x0/0x30 > [] ? kthread+0x0/0x92 > [] ? child_rip+0x0/0x20 > Code: 08 48 89 31 48 89 52 08 48 89 12 48 89 85 60 ff ff ff e8 66 74 > 3b 00 48 8b 85 60 ff ff ff 48 8b 50 f8 48 83 e2 fc 48 39 d3 74 04 <0f> > 0b eb fe f0 80 60 f8 fe 48 8b bb a8 00 00 00 45 31 c9 31 c9 > RIP [] worker_thread+0x1bc/0x31d > RSP > ---[ end trace 4d8a59030f36f167 ]--- > > > > On Thu, Aug 20, 2009 at 3:33 PM, Eric W. Biederman > wrote: > > > > Xiaotian Feng writes: > > > > > On Thu, Aug 20, 2009 at 2:07 PM, Eric W. Biederman > > > wrote: > > > > > > > > > ebiederm@xmission.com (Eric W. Biederman) writes: > > > > > > > I'm not certain who I should route this too, but I just had 2.6.31-rc6 > > > > fall over on me. I don't know how reproducible this will be but > > > > I have a full crash dump if someone is interested in looking into this. > > > > > > Looks like I was wrong. This is appears trivial to reproduce, > > > I have just reproduced it two more times in a row. I think > > > the problem is pty related. > > > > > > I was looking into a change in behavior on 2.6.31-rc6 where > > > data was being lost, and it appears one variant of my test program > > > kills the kernel. > > > > > > The following program run as an unprivileged user causes a kernel > > > panic in about a minute: > > > > > > aka > > > > > > while :; do ./KernelTtyTest ; done > > > > > > > > > oops.... It panics my x86_64 machine..... > > > > I guess I forgot to mention that detail. Thanks for confirming this > > bug isn't just me. > > > > Eric