Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 6 Mar 2003 22:23:28 -0800 | From | Andrew Morton <> | Subject | Re: Oops: 2.5.64 check_obj_poison for 'size-64' |
| |
Zwane Mwaikambo <zwane@linuxpower.ca> wrote: > > This just popped up on my screen, seems to have been triggered by sar/cron > (i'll probably have to reboot the box soon) > > slab error in check_poison_obj(): cache `size-64': object was modified after freeing > Call Trace: > [<c0142226>] check_poison_obj+0x66/0x70 > [<c0143b92>] kmalloc+0xd2/0x180 > [<c0166078>] pipe_new+0x28/0xd0 > [<c0166153>] get_pipe_inode+0x23/0xb0 > [<c0166212>] do_pipe+0x32/0x1e0 > [<c0111ed3>] sys_pipe+0x13/0x60 > [<c010ad9b>] syscall_call+0x7/0xb
Don't know. If you're using anticipatory scheduler in 2.5.63-mmfoo this will happen. 64-mm1 is OK.
> Unable to handle kernel paging request at virtual address 2020202b > printing eip: > c010cbd7 > *pde = 5a5a5a5a > Oops: 0002 > CPU: 0 > EIP: 0060:[<c010cbd7>] Not tainted > EFLAGS: 00010283 > EIP is at show_interrupts+0x237/0x270 > eax: 20202020 ebx: e4f798a4 ecx: 00000000 edx: 0000000b > esi: c02ba31b edi: 00000020 ebp: 00000000 esp: e424df00 > ds: 007b es: 007b ss: 0068 > Process sadc (pid: 1250, threadinfo=e424c000 task=e43780e0) > Stack: 00000390 c03b40a0 000000e0 00000001 e4f799bc 00000001 e4f799bc c0178e68 > e4f799bc 00000001 e424df38 00000000 e424df48 00000001 00000000 00000000 > e41d1870 e457ae84 e4649ef0 e4649ee4 00000000 40014000 e3830b54 00000400 > Call Trace: > [<c0178e68>] seq_read+0x108/0x2c0 > [<c01590d8>] vfs_read+0xa8/0x160 > [<c01593ca>] sys_read+0x2a/0x40 > [<c010ad9b>] syscall_call+0x7/0xb > > Code: c6 04 02 0a ff 43 0c a1 60 6a 3b c0 50 68 21 a3 2b c0 53 e8 > > (gdb) list *show_interrupts+0x237 > 0xc010cbd7 is in show_interrupts (include/linux/seq_file.h:40). > 35 int seq_escape(struct seq_file *, const char *, const char *); > 36 > 37 static inline int seq_putc(struct seq_file *m, char c) > 38 { > 39 if (m->count < m->size) { > 40 m->buf[m->count++] = c; > 41 return 0; > 42 } > 43 return -1;
show_interrupts() is walking the per-irq action chain without locking it. Any concurrent add/remove activity will explode.
Do you want to hunt down all the show_interrupts() instances and pop a spin_lock_irq(desc->lock) around them?
- 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/
| ![\](/images/icornerr.gif) |