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

[James Bottomley <James.Bottomley@SteelEye.com>]

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.

James


-
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/