On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote: > > > /* XXX This clear should ultimately be part of > > local_flush_tlb_mm */ > > > - __clear_bit(id, stale_map[cpu]); > > > + for (cpu = cpu_first_thread_in_core(cpu); > > > + cpu <= cpu_last_thread_in_core(cpu); cpu++) > > > + __clear_bit(id, stale_map[cpu]); > > > } > > > > This looks a bit dodgy. using 'cpu' as both the loop variable and > > what you are computing to determine loop start/end.. > > > Hrm... I would have thought that it was still correct... do you see any > reason why the above code is wrong ? because if not we may be hitting a > gcc issue... > > IE. At loop init, cpu gets clamped down to the first thread in the core, > which should be fine. Then, we compare CPU to the last thread in core > for the current CPU which should always return the same value. > > So I'm very interested to know what is actually wrong, ie, either I'm > just missing something obvious, or you are just pushing a bug under the > carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu <= cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu <= cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu <= 1
cpu++ (1)
cpu <= 1
cpu++ (2)
cpu <= 3
...
:)
cheers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
