Messages in this thread | | | Subject | Re: must-fix list for 2.6.0 | From | Andi Kleen <> | Date | 30 Apr 2003 03:36:18 +0200 |
| |
I found a new bad class of bugs (slowly working on fixing them, also present in 2.4)
Machine Check handlers use printk in an NMI like (ignoring cli) situation. This can deadlock on the console or low level character driver (serial, vga) locks. Not all MCEs are fatal (e.g. corrected ECC errors) and the kernel should be safely able to continue.
Need to buffer the printk in an atomic fashion (e.g. in a ring buffer managed with cmpxchg) and cause an self IPI that triggers an interrupt after the next sti. This is easy with x86/APIC mode, but difficult with PIC (the 8259 supports it in theory, but it's not clear that all clones in various chipsets do; also changing the programming may be risky). Fallback: pick it up with the next timer interrupt by adding a check there.
New entries for the x86-64 list (actually I'm not sure they are all x86-64 specific, just that the bug has been seen there)
- 32bit core dumps do not dump 32bit SSE data currently. they should - AT_GID/AT_UID ELF environment vector contains crap currently This breaks debugging of the shared linker for suid programs because ld.so always thinks it is suid/not called by root and ignores environment variables. - NIS/ypbind breaks with an abort() in glibc. Only happens on 2.5, 2.4 is fine. - need /proc/kcore access for kernel mappings that are outside vmalloc (in particular the kernel and the modules are special mappings on x86-64; other architectures have the same problem) Best would be to put them in the vmalloc mappings list, but that requires some more fixes in other code that uses it. Also /proc/kcore seems to have some 64bit signedness bugs (patch for 2.4 exists)
Generic item:
- need to share the ioctl 32bit emulation handlers between ports. Pavel has a patch, but he's running into difficulties with merging it.
-Andi - 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/
| |