lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 24 Aug 2006 11:27:11 -0700 From: Greg KH <greg@...ah.com> To: Maneesh Soni <maneesh@...ibm.com> Cc: Mike Galbraith <efault@....de>, LKML <linux-kernel@...r.kernel.org> Subject: Re: 2.6.18-rc3-mm2: oops in sysfs_follow_link() On Thu, Aug 24, 2006 at 05:14:52PM +0530, Maneesh Soni wrote: > On Mon, Aug 14, 2006 at 02:06:57PM -0700, Greg KH wrote: > > On Sun, Aug 13, 2006 at 09:54:53AM +0000, Mike Galbraith wrote: > > > (resend with corrected cc) > > > > > > Greetings, > > > > > > I just got the below double warning from lib/kref.c:32 followed by oops. > > > > > > I had just rebooted after upping my printk buffer to 20 (to be able to > > > see a complete boot despite the spam), and was poking Ctrl+Alt+F1 trying > > > to get to a vt to watch. > > > > Maneesh, any thoughts? > > > > Original messages left below... > > > > > > Sorry, took lot of time for this due to vaccations. No problem, I haven't heard of anyone else hitting this problem. > > > DEV: registering device: ID = 'vcs6' > > > PM: Adding info for No Bus:vcs6 > > > DEV: registering device: ID = 'vcsa6' > > > PM: Adding info for No Bus:vcsa6 > > > DEV: Unregistering device. ID = 'vcs6' > > > PM: Removing info for No Bus:vcs6 > > > device_create_release called for vcs6 > > > DEV: Unregistering device. ID = 'vcsa6' > > > PM: Removing info for No Bus:vcsa6 > > > device_create_release called for vcsa6 > > > BUG: warning at lib/kref.c:32/kref_get() > > > [<c1003eba>] show_trace_log_lvl+0x16e/0x191 > > > [<c1004647>] show_trace+0x12/0x14 > > > [<c1004768>] dump_stack+0x19/0x1b > > > [<c11d3f28>] kref_get+0x41/0x43 > > > [<c11d3416>] kobject_get+0x12/0x17 > > > [<c10b0dea>] sysfs_follow_link+0x1d0/0x245 > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > [<b7d309c4>] 0xb7d309c4 > > > [<c1004647>] show_trace+0x12/0x14 > > > [<c1004768>] dump_stack+0x19/0x1b > > > [<c11d3f28>] kref_get+0x41/0x43 > > > [<c11d3416>] kobject_get+0x12/0x17 > > > [<c10b0dea>] sysfs_follow_link+0x1d0/0x245 > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > BUG: warning at lib/kref.c:32/kref_get() > > > [<c1003eba>] show_trace_log_lvl+0x16e/0x191 > > > [<c1004647>] show_trace+0x12/0x14 > > > [<c1004768>] dump_stack+0x19/0x1b > > > [<c11d3f28>] kref_get+0x41/0x43 > > > [<c11d3416>] kobject_get+0x12/0x17 > > > [<c10b0ccd>] sysfs_follow_link+0xb3/0x245 > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > [<b7d309c4>] 0xb7d309c4 > > > [<c1004647>] show_trace+0x12/0x14 > > > [<c1004768>] dump_stack+0x19/0x1b > > > [<c11d3f28>] kref_get+0x41/0x43 > > > [<c11d3416>] kobject_get+0x12/0x17 > > > [<c10b0ccd>] sysfs_follow_link+0xb3/0x245 > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 > > > printing eip: > > > c10b0d1f > > > *pde = 00000000 > > > Oops: 0000 [#3] > > > 4K_STACKS PREEMPT SMP > > > last sysfs file: /class/net/lo/address > > > Modules linked in: ip6t_REJECT xt_tcpudp ipt_REJECT xt_state iptable_mangle iptable_nat ip_nat iptable_filter ip6table_mangle ip_conntrack nfnetlink ip_tables ip6table_filter ip6_tables x_tables nls_iso8859_1 nls_cp437 nls_utf8 sd_mod ir_kbd_i2c prism54 bt878 ohci1394 bttv video_buf ir_common btcx_risc tveeprom ieee1394 snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401 snd_mpu401_uart snd_rawmidi snd_seq_device i2c_i801 snd soundcore > > > CPU: 0 > > > EIP: 0060:[<c10b0d1f>] Not tainted VLI > > > EFLAGS: 00010246 (2.6.18-rc3-mm2-smp #182) > > > EIP is at sysfs_follow_link+0x105/0x245 > > > eax: 00000000 ebx: 00000001 ecx: ffffffff edx: ffffffff > > > esi: 00000000 edi: 00000000 ebp: dff85ec4 esp: dff85e94 > > > ds: 007b es: 007b ss: 0068 > > > Process hald (pid: 4133, ti=dff85000 task=c24a3030 task.ti=dff85000) > > > Stack: f8b0e078 dff85ed8 f7bca000 00000001 dff0d704 f7c15e40 ffffffea f8b0e078 > > > f8b0e168 c14b19a0 f7bc9800 00000100 dff85f34 c107d187 c10824d1 0809ab00 > > > c10822f8 dff0d77c 00001000 08096f54 00000070 dff85fb4 f7811000 44dee880 > > > Call Trace: > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > [<b7d309c4>] 0xb7d309c4 > > > [<c1003f83>] show_stack_log_lvl+0xa6/0xcb > > > [<c1004180>] show_registers+0x1d8/0x286 > > > [<c100437f>] die+0x151/0x333 > > > [<c10197f9>] do_page_fault+0x26b/0x51f > > > [<c13e1a99>] error_code+0x39/0x40 > > > [<c107d187>] generic_readlink+0x28/0x70 > > > [<c10796de>] sys_readlinkat+0x7c/0xa1 > > > [<c107972a>] sys_readlink+0x27/0x29 > > > [<c10030db>] syscall_call+0x7/0xb > > > Code: dc 00 00 00 00 83 45 dc 01 8b 40 24 85 c0 75 f5 8b 45 ec 89 45 d0 bb 01 00 00 00 31 f6 ba ff ff ff ff 8b 4d d0 8b 39 89 d1 89 f0 <f2> ae f7 d1 49 83 c1 01 01 cb 8b 4d d0 8b 49 24 89 4d d0 85 c9 > > > EIP: [<c10b0d1f>] sysfs_follow_link+0x105/0x245 SS:ESP 0068:dff85e94 > > > <7>DEV: registering device: ID = 'vcs2' > > > > > > > > I guess that earlier WARN_ON's are related to the oops we are seeing. > The oops has oocured becaure the target kobject->k_name is NULL? > Somehow the target kobjcet is getting freed while sysfs_follow_link() even > though sysfs takes ref for the the target kobject at the time of symlink > creation. Can there be some mispatch in kref_get()/kref_put() or kobject_get() > /kobject_put() in higher layers? Possibly, I really don't know. As no one else has reported this, it might have been an odd bug with something else in the -mm patchset. thanks for the response. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists