[patch 0/8] -stable review
Chris Wright
There are 8 patches in this series, all will be posted as a response to
this one. If anyone has any issues with these being applied, please let
us know. If anyone is a maintainer of the proper subsystem, and wants
to add a signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email sta...@kernel.org
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Sat, Aug 13, 22:00 UTC. Anything received
after that time, might be too late.
thanks,
the -stable release team
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Wright
Chris Wright
Chris Wright
Chris Wright
Andi Kleen
> {
> if (notscsync || !cpu_has_tsc)
> return;
> - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> - boot_cpu_id);
> - sync_tsc();
> + sync_tsc(boot_cpu_id);
I actually found a bug in this today. This should be sync_tsc(0), not sync_tsc(boot_cpu_id)
Can you just fix it in your tree or should I submit a new patch?
-Andi
Chris Wright
> > static void __cpuinit tsc_sync_wait(void)
> > {
> > if (notscsync || !cpu_has_tsc)
> > return;
> > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > - boot_cpu_id);
> > - sync_tsc();
> > + sync_tsc(boot_cpu_id);
>
> I actually found a bug in this today. This should be sync_tsc(0), not sync_tsc(boot_cpu_id)
> Can you just fix it in your tree or should I submit a new patch?
I'll fix it locally. Thanks for the heads-up.
-chris
Peter Osterlund
> -stable review patch. If anyone has any objections, please let us know.
> ------------------
>
> a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
Why does this 6 year old bug have to be fixed in the 2.6.12 stable
series? Doesn't the patch violate this stable series rule?
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing.)
Maybe the motivation was just missing from the patch description?
--
Peter Osterlund - pet...@telia.com
http://web.telia.com/~u89404340
Chris Wright
> Chris Wright <chr...@osdl.org> writes:
> > a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html
>
> Why does this 6 year old bug have to be fixed in the 2.6.12 stable
> series? Doesn't the patch violate this stable series rule?
>
> - It must fix a real bug that bothers people (not a, "This could be a
> problem..." type thing.)
>
> Maybe the motivation was just missing from the patch description?
These can manifest as possible overflow (1st one, given CAN-2005-2458),
or NULL deref (2nd one given CAN-2005-2459), which could have possible
security consequences.
thanks,
-chris
H. Peter Anvin
> -stable review patch. If anyone has any objections, please let us know.
Looks good to me. Feel free to add:
Signed-off-by: H. Peter Anvin <h...@zytor.com>
Chris Wright
> Chris Wright wrote:
> >-stable review patch. If anyone has any objections, please let us know.
>
> Looks good to me. Feel free to add:
>
> Signed-off-by: H. Peter Anvin <h...@zytor.com>
Will do, thanks.
-chris
Eric W. Biederman
> * Andi Kleen (a...@suse.de) wrote:
>> > static void __cpuinit tsc_sync_wait(void)
>> > {
>> > if (notscsync || !cpu_has_tsc)
>> > return;
>> > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
>> > - boot_cpu_id);
>> > - sync_tsc();
>> > + sync_tsc(boot_cpu_id);
>>
>> I actually found a bug in this today. This should be sync_tsc(0), not
> sync_tsc(boot_cpu_id)
>> Can you just fix it in your tree or should I submit a new patch?
>
> I'll fix it locally. Thanks for the heads-up.
Someone needs to send the patch to Linus for 2.6.13 as well. Is someone
else going to or should I. I knew I was confused about physical versus
logical apic ids when I generated the patch.
Eric
Eric W. Biederman
2.6.13. Linus please apply this micro patch.
> > static void __cpuinit tsc_sync_wait(void)
> > {
> > if (notscsync || !cpu_has_tsc)
> > return;
> > - printk(KERN_INFO "CPU %d: Syncing TSC to CPU %u.\n", smp_processor_id(),
> > - boot_cpu_id);
> > - sync_tsc();
> > + sync_tsc(boot_cpu_id);
>
> I actually found a bug in this today. This should be sync_tsc(0), not
> sync_tsc(boot_cpu_id)
> Can you just fix it in your tree or should I submit a new patch?
>
> -Andi
Oops. I knew I didn't have the physical versus logical cpu identifiers right
when I generated that patch. It's not nearly as bad as I feared at the time
though.
Signed-off-by: Eric W. Biederman <ebie...@xmission.com>
---
arch/x86_64/kernel/smpboot.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
5192895f71c7eff7e1335cd9d6a775dda2bb5d52
diff --git a/arch/x86_64/kernel/smpboot.c b/arch/x86_64/kernel/smpboot.c
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -334,7 +334,7 @@ static void __cpuinit tsc_sync_wait(void
{
if (notscsync || !cpu_has_tsc)
return;
- sync_tsc(boot_cpu_id);
+ sync_tsc(0);
}
static __init int notscsync_setup(char *s)
yhlu
Anyway sync_tsc(...) there is master and MASTER..., but value are all 0.
YH
Denis Vlasenko
> -stable review patch. If anyone has any objections, please let us know.
>
> The module code assumes noone will ever ask for a per-cpu area more than
> SMP_CACHE_BYTES aligned. However, as these cases show, gcc asks sometimes
> asks for 32-byte alignment for the per-cpu section on a module, and if
> CONFIG_X86_L1_CACHE_SHIFT is 4, we hit that BUG_ON(). This is obviously an
> unusual combination, as there have been few reports, but better to warn
> than die.
gcc gets increasingly sadistic about alignment:
"char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22158
Please, everybody who thinks that _32_ _byte_ alignment
is outright silly, add your comments to this bugzilla entry.
--
vda