Re: [RFC][PATCH] timers fixes/improvements

[Andrew Morton]

Christoph Lameter <christoph@xxxxxxxxxxx> wrote:
>
> We have some strange race conditions as a result of the timer
> scalability fixes.
> 
> ptype_all is set to 0x10:0x10 on faster systems (Xeon 3.6Ghz).
> Slower systems do fine(Xeon 3.0Ghz) and do not corrupt ptype_all.
> 
> Its not clear to me how ptype_all could relate to timer operations

I'd do `nm -n vmlinux', see which data structures the linker placed nearby
to ptype_all and then go looking for overruns against them.

ptype_base is an array, but I cannot see any race around ptype_base.  So
look to see if ptype_base is corrupted as well, keep walking back through
memory, see where the scribble starts.

> but
> if I apply these timer patches I get ptype_all corruption.
> 
> timers-fixes-improvements.patch
> timers-fixes-improvements-smp_processor_id-fix.patch
> timers-fixes-improvements-fix.patch
> timer-deadlock-fix
> (It does not matter if the last three are applied)

2.6.12-rc3-mm3 has different patches:

timers-fixes-improvements.patch
timers-fixes-improvements-smp_processor_id-fix.patch
timers-fixes-improvements-fix.patch
timers-fix-__mod_timer-vs-__run_timers-deadlock.patch
timers-fix-__mod_timer-vs-__run_timers-deadlock-tidy.patch
timers-comments-update.patch
kernel-timerc-remove-a-goto-construct.patch

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/