Messages in this thread | | | Subject | Re: [Fastboot] [PATCH 1/3] stack overflow safe kdump (2.6.18-rc1-i386) - safe_smp_processor_id | From | Fernando Luis Vázquez Cao <> | Date | Tue, 11 Jul 2006 15:21:50 +0900 |
| |
Hi James,
Thank you for taking the time to review the code!
On Mon, 2006-07-10 at 15:58 -0500, James Bottomley wrote: > On Mon, 2006-07-10 at 12:20 -0600, Eric W. Biederman wrote: > > I agree that it shows the problem, and that voyager is different from the > > rest of the x86 implementations. > > As a non-apic based SMP implementation, I don't think there was ever any > dissent about the latter. > > > At least for things like the cpumask_t density of processor ids > > is still an interesting property. The basic issue is that apicids are > > not in general dense on x86. Not being able compile with support > > for only two cpus because your cpus happen to be apicid 0 and apicid > > 6 by default is an issue. > > Density or lack of it is pretty much irrelevant nowadays since the CPU > map iterators are sparse efficient. Whether x86 PC chooses to avail > itself of this or not is the business of the PC subarch maintainers. > The vast marjority of non-x86 SMP implementations still have sparse (or > at least physical only) CPU maps. > > > To some extent this also shows the mess that the x86 subarch code is > > because it is never clear if code is implemented in a subarchitecture > > or not. > > Erm, it does? How? My statement is that introducing subarch specific > #defines into subarch independent header files is a problem (which it > is). If you grep for subarch defines in the rest of the arch > independent headers, I don't believe you'll find any. This would rather > tend to show that for the last seven years, the subarch interface has > been remarkably effective .... > > > Fernando can you just put a trivial voyager specific definition of > > safe_smp_processor_id in mach-voyager/voyager_smp.c. It isn't a fast > > path so the little extra overhead of making two separate functions > > is not an issue and then the generic header doesn't have to have > > subarch breakage. Just a definition of safe_smp_processor_id(). > > Yes, that should work. Done. I hope I got it right this time. Anyway, if there is something incorrect in the new patches (1/4 and 2/4 in particular) let me know.
Regards,
Fernando
- 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/
| |