Re: [Fastboot] [PATCH 1/3] stack overflow safe kdump(2.6.18-rc1-i386) - safe_smp_processor_id

[Fernando Luis Vázquez Cao]

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/