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 Jul 11 2006 - 02:20:09 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/