On Sun, 2010-12-19 at 20:19 +0100, Stefano Zacchiroli wrote:
> On Sun, Dec 19, 2010 at 07:30:58PM +0100, Julien BLACHE wrote:
> > I am hereby asking the tech-ctte to decide how the kernel ABI should
> > be managed.
>
> Hi Julien, from the bug log it's pretty clear that there was no
> possibilities of agreement between you and the kernel team, so thanks
> for bringing this issue to tech-ctte.
>
> I've a question for the kernel team, which might help some investigation
> of the tech-ctte. There seem to be two intertwined issue here:
>
> 1) the general policy of kernel ABI maintenance
> 2) the specific smp_ops issue
>
> You asked ruling about (1), on which there is a clear divergence of
> opinions between you (as bug reporter / user) and the kernel team (as
> package maintainers). Of course ruling about (1) will also address (2),
> one way or the other.
>
> Still, (2) is more urgent, as (I agree on that) it will impact upgrade
> experience of Debian users like Julien, who are forced to use VMWare. No
> matter who is at fault, the choice about (2) will have an impact on a
> specific class of users.
>
> My question to the kernel team is if, no matter (2), there are
> *technical* reasons for not reverting the removal of the "smp_send_stop"
> symbol. I understand there are "political" reasons for *not* reverting
> the change, like reinforcing the position that people should not rely on
> symbols not exported for out-of-tree modules. I believe it would help
> the discussion to know whether there are technical blockers to the
> revert.
[...]
smp_send_stop was never exported in its own right. The change to
smp_ops was made as part of this bug fix:
commit ae832c21a08514fd11d2d1d6e217c8a537764bb0
Author: Alok Kataria <akataria@vmware.com>
Date: Mon Oct 11 14:37:08 2010 -0700
x86, kexec: Make sure to stop all CPUs before exiting the kernel
commit 76fac077db6b34e2c6383a7b4f3f4f7b7d06d8ce upstream.
x86 smp_ops now has a new op, stop_other_cpus which takes a parameter
"wait" this allows the caller to specify if it wants to stop until all
the cpus have processed the stop IPI. This is required specifically
for the kexec case where we should wait for all the cpus to be stopped
before starting the new kernel. We now wait for the cpus to stop in
all cases except for panic/kdump where we expect things to be broken
and we are doing our best to make things work anyway.
This patch fixes a legitimate regression, which was introduced during
2.6.30, by commit id 4ef702c10b5df18ab04921fc252c26421d4d6c75.
Signed-off-by: Alok N Kataria <akataria@vmware.com>
LKML-Reference: <1286833028.1372.20.camel@ank32.eng.vmware.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Jeremy Fitzhardinge <jeremy@xensource.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
(ooh, irony).
Ben.
--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.
Attachment:
signature.asc
Description: This is a digitally signed message part