[00/15] 2.6.25-stable review

[00/15] 2.6.25-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.25.8 release.
There are 15 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 stable@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 June 21, 20:00:00 UTC.  Anything received after
that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.8-rc1.gz
and the diffstat can be found below.


thanks,

the -stable release team


 Makefile                               |    2 +-
 arch/x86/kernel/process_32.c           |   23 +++++++++++++++++++++--
 arch/x86/kernel/process_64.c           |   24 +++++++++++++++++++++---
 arch/x86/lib/copy_user_64.S            |   25 +++++++++++--------------
 arch/x86/lib/copy_user_nocache_64.S    |   25 +++++++++++--------------
 drivers/acpi/tables/tbinstal.c         |   18 +++++++-----------
 drivers/ide/pci/opti621.c              |   23 ++++-------------------
 drivers/net/virtio_net.c               |    8 +++++---
 drivers/net/wireless/b43/b43.h         |    1 -
 drivers/net/wireless/b43/dma.c         |    2 +-
 drivers/net/wireless/b43/main.c        |   16 ++++++++++------
 drivers/scsi/hosts.c                   |    5 +++--
 drivers/scsi/sr.c                      |    3 +++
 drivers/serial/8250.c                  |    4 +++-
 net/netfilter/nf_conntrack_core.c      |    3 +--
 net/netfilter/nf_conntrack_h323_main.c |   22 +++++++++++++++-------
 16 files changed, 117 insertions(+), 87 deletions(-)

[patch 01/15] x86-64: Fix "bytes left to copy" return value for copy_from_user()

[Greg KH]

[-- Attachment #1: x86-64-fix-bytes-left-to-copy-return-value-for-copy_from_user.patch --]
[-- Type: text/plain, Size: 5223 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us know.

------------------


From: Linus Torvalds <torvalds@linux-foundation.org>

commit 42a886af728c089df8da1b0017b0e7e6c81b5335 upstream

Most users by far do not care about the exact return value (they only
really care about whether the copy succeeded in its entirety or not),
but a few special core routines actually care deeply about exactly how
many bytes were copied from user space.

And the unrolled versions of the x86-64 user copy routines would
sometimes report that it had copied more bytes than it actually had.

Very few uses actually have partial copies to begin with, but to make
this bug even harder to trigger, most x86 CPU's use the "rep string"
instructions for normal user copies, and that version didn't have this
issue.

To make it even harder to hit, the one user of this that really cared
about the return value (and used the uncached version of the copy that
doesn't use the "rep string" instructions) was the generic write
routine, which pre-populated its source, once more hiding the problem by
avoiding the exception case that triggers the bug.

In other words, very special thanks to Bron Gondwana who not only
triggered this, but created a test-program to show it, and bisected the
behavior down to commit 08291429cfa6258c4cd95d8833beb40f828b194e ("mm:
fix pagecache write deadlocks") which changed the access pattern just
enough that you can now trigger it with 'writev()' with multiple
iovec's.

That commit itself was not the cause of the bug, it just allowed all the
stars to align just right that you could trigger the problem.

[ Side note: this is just the minimal fix to make the copy routines
  (with __copy_from_user_inatomic_nocache as the particular version that
  was involved in showing this) have the right return values.

  We really should improve on the exceptional case further - to make the
  copy do a byte-accurate copy up to the exact page limit that causes it
  to fail.  As it is, the callers have to do extra work to handle the
  limit case gracefully. ]

Reported-by: Bron Gondwana <brong@fastmail.fm>
Cc: Nick Piggin <npiggin@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/lib/copy_user_64.S         |   25 +++++++++++--------------
 arch/x86/lib/copy_user_nocache_64.S |   25 +++++++++++--------------
 2 files changed, 22 insertions(+), 28 deletions(-)

--- a/arch/x86/lib/copy_user_64.S
+++ b/arch/x86/lib/copy_user_64.S
@@ -217,19 +217,19 @@ ENTRY(copy_user_generic_unrolled)
 	/* table sorted by exception address */
 	.section __ex_table,"a"
 	.align 8
-	.quad .Ls1,.Ls1e
-	.quad .Ls2,.Ls2e
-	.quad .Ls3,.Ls3e
-	.quad .Ls4,.Ls4e
-	.quad .Ld1,.Ls1e
+	.quad .Ls1,.Ls1e	/* Ls1-Ls4 have copied zero bytes */
+	.quad .Ls2,.Ls1e
+	.quad .Ls3,.Ls1e
+	.quad .Ls4,.Ls1e
+	.quad .Ld1,.Ls1e	/* Ld1-Ld4 have copied 0-24 bytes */
 	.quad .Ld2,.Ls2e
 	.quad .Ld3,.Ls3e
 	.quad .Ld4,.Ls4e
-	.quad .Ls5,.Ls5e
-	.quad .Ls6,.Ls6e
-	.quad .Ls7,.Ls7e
-	.quad .Ls8,.Ls8e
-	.quad .Ld5,.Ls5e
+	.quad .Ls5,.Ls5e	/* Ls5-Ls8 have copied 32 bytes */
+	.quad .Ls6,.Ls5e
+	.quad .Ls7,.Ls5e
+	.quad .Ls8,.Ls5e
+	.quad .Ld5,.Ls5e	/* Ld5-Ld8 have copied 32-56 bytes */
 	.quad .Ld6,.Ls6e
 	.quad .Ld7,.Ls7e
 	.quad .Ld8,.Ls8e
@@ -244,11 +244,8 @@ ENTRY(copy_user_generic_unrolled)
 	.quad .Le5,.Le_zero
 	.previous
 
-	/* compute 64-offset for main loop. 8 bytes accuracy with error on the
-	   pessimistic side. this is gross. it would be better to fix the
-	   interface. */
 	/* eax: zero, ebx: 64 */
-.Ls1e: 	addl $8,%eax
+.Ls1e: 	addl $8,%eax		/* eax is bytes left uncopied within the loop (Ls1e: 64 .. Ls8e: 8) */
 .Ls2e: 	addl $8,%eax
 .Ls3e: 	addl $8,%eax
 .Ls4e: 	addl $8,%eax
--- a/arch/x86/lib/copy_user_nocache_64.S
+++ b/arch/x86/lib/copy_user_nocache_64.S
@@ -145,19 +145,19 @@ ENTRY(__copy_user_nocache)
 	/* table sorted by exception address */
 	.section __ex_table,"a"
 	.align 8
-	.quad .Ls1,.Ls1e
-	.quad .Ls2,.Ls2e
-	.quad .Ls3,.Ls3e
-	.quad .Ls4,.Ls4e
-	.quad .Ld1,.Ls1e
+	.quad .Ls1,.Ls1e	/* .Ls[1-4] - 0 bytes copied */
+	.quad .Ls2,.Ls1e
+	.quad .Ls3,.Ls1e
+	.quad .Ls4,.Ls1e
+	.quad .Ld1,.Ls1e	/* .Ld[1-4] - 0..24 bytes coped */
 	.quad .Ld2,.Ls2e
 	.quad .Ld3,.Ls3e
 	.quad .Ld4,.Ls4e
-	.quad .Ls5,.Ls5e
-	.quad .Ls6,.Ls6e
-	.quad .Ls7,.Ls7e
-	.quad .Ls8,.Ls8e
-	.quad .Ld5,.Ls5e
+	.quad .Ls5,.Ls5e	/* .Ls[5-8] - 32 bytes copied */
+	.quad .Ls6,.Ls5e
+	.quad .Ls7,.Ls5e
+	.quad .Ls8,.Ls5e
+	.quad .Ld5,.Ls5e	/* .Ld[5-8] - 32..56 bytes copied */
 	.quad .Ld6,.Ls6e
 	.quad .Ld7,.Ls7e
 	.quad .Ld8,.Ls8e
@@ -172,11 +172,8 @@ ENTRY(__copy_user_nocache)
 	.quad .Le5,.Le_zero
 	.previous
 
-	/* compute 64-offset for main loop. 8 bytes accuracy with error on the
-	   pessimistic side. this is gross. it would be better to fix the
-	   interface. */
 	/* eax: zero, ebx: 64 */
-.Ls1e: 	addl $8,%eax
+.Ls1e: 	addl $8,%eax	/* eax: bytes left uncopied: Ls1e: 64 .. Ls8e: 8 */
 .Ls2e: 	addl $8,%eax
 .Ls3e: 	addl $8,%eax
 .Ls4e: 	addl $8,%eax

-- 

[patch 02/15] Fix tty speed handling on 8250

[Greg KH]

[-- Attachment #1: fix-tty-speed-handling-on-8250.patch --]
[-- Type: text/plain, Size: 1189 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Alan Cox <alan@lxorguk.ukuu.org.uk>

commit e991a2bd4fa0b2f475b67dfe8f33e8ecbdcbb40b upstream.

We try and write the correct speed back but the serial midlayer already
mangles the speed on us and that means if we request B0 we report back B9600
when we should not.  For now we'll hack around this in the drivers and serial
code, pending a better long term solution.

Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/serial/8250.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2174,7 +2174,9 @@ serial8250_set_termios(struct uart_port 
 	}
 	serial8250_set_mctrl(&up->port, up->port.mctrl);
 	spin_unlock_irqrestore(&up->port.lock, flags);
-	tty_termios_encode_baud_rate(termios, baud, baud);
+	/* Don't rewrite B0 */
+	if (tty_termios_baud_rate(termios))
+		tty_termios_encode_baud_rate(termios, baud, baud);
 }
 
 static void

-- 

[patch 03/15] opti621: disable read prefetch

[Greg KH]

[-- Attachment #1: opti621-disable-read-prefetch.patch --]
[-- Type: text/plain, Size: 1954 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

commit 62128b2ca812c1266f4ff7bac068bf0b626c6179 upstream

This fixes 2.6.25 regression (kernel.org bugzilla bug #10723) caused by:

commit 912fb29a36a7269ac1c4a4df45bc0ac1d2637972
Author: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date:   Fri Oct 19 00:30:11 2007 +0200

    opti621: always tune PIO
...

Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.

Bisected-by: Juergen Kosel <juergen.kosel@gmx.de>
Tested-by: Juergen Kosel <juergen.kosel@gmx.de>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ide/pci/opti621.c |   15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

--- a/drivers/ide/pci/opti621.c
+++ b/drivers/ide/pci/opti621.c
@@ -103,18 +103,6 @@
  *  address: 50 ns, data: 50 ns, recovery: 100 ns.
  */
 
-/* #define READ_PREFETCH 0 */
-/* Uncomment for disable read prefetch.
- * There is some readprefetch capatibility in hdparm,
- * but when I type hdparm -P 1 /dev/hda, I got errors
- * and till reset drive is inaccessible.
- * This (hw) read prefetch is safe on my drive.
- */
-
-#ifndef READ_PREFETCH
-#define READ_PREFETCH 0x40 /* read prefetch is enabled */
-#endif /* else read prefetch is disabled */
-
 #define READ_REG 0	/* index of Read cycle timing register */
 #define WRITE_REG 1	/* index of Write cycle timing register */
 #define CNTRL_REG 3	/* index of Control register */
@@ -260,7 +248,8 @@ static void opti621_set_pio_mode(ide_dri
 
 	cycle1 = ((first.data_time-1)<<4)  | (first.recovery_time-2);
 	cycle2 = ((second.data_time-1)<<4) | (second.recovery_time-2);
-	misc = READ_PREFETCH | ((ax-1)<<4) | ((drdy-2)<<1);
+
+	misc = ((ax - 1) << 4) | ((drdy - 2) << 1);
 
 #ifdef OPTI621_DEBUG
 	printk("%s: master: address: %d, data: %d, "

-- 

[patch 04/15] opti621: remove DMA support

[Greg KH]

[-- Attachment #1: opti621-remove-dma-support.patch --]
[-- Type: text/plain, Size: 1404 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

commit f361037631ba547ea88adf8d2359d810c1b2605a upstream

These controllers don't support DMA.

Based on a bugreport from Juergen Kosel & inspired by pata_opti.c code.

Tested-by: Juergen Kosel <juergen.kosel@gmx.de>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ide/pci/opti621.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

--- a/drivers/ide/pci/opti621.c
+++ b/drivers/ide/pci/opti621.c
@@ -324,20 +324,16 @@ static const struct ide_port_info opti62
 		.name		= "OPTI621",
 		.init_hwif	= init_hwif_opti621,
 		.enablebits	= {{0x45,0x80,0x00}, {0x40,0x08,0x00}},
-		.host_flags	= IDE_HFLAG_TRUST_BIOS_FOR_DMA |
+		.host_flags	= IDE_HFLAG_NO_DMA |
 				  IDE_HFLAG_BOOTABLE,
 		.pio_mask	= ATA_PIO3,
-		.swdma_mask	= ATA_SWDMA2,
-		.mwdma_mask	= ATA_MWDMA2,
 	},{	/* 1 */
 		.name		= "OPTI621X",
 		.init_hwif	= init_hwif_opti621,
 		.enablebits	= {{0x45,0x80,0x00}, {0x40,0x08,0x00}},
-		.host_flags	= IDE_HFLAG_TRUST_BIOS_FOR_DMA |
+		.host_flags	= IDE_HFLAG_NO_DMA |
 				  IDE_HFLAG_BOOTABLE,
 		.pio_mask	= ATA_PIO3,
-		.swdma_mask	= ATA_SWDMA2,
-		.mwdma_mask	= ATA_MWDMA2,
 	}
 };
 

-- 

[patch 05/15] virtio_net: Fix skb->csum_start computation

[Greg KH]

[-- Attachment #1: virtio_net-fix-skb-csum_start-computation.patch --]
[-- Type: text/plain, Size: 1800 bytes --]


2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Mark McLoughlin <markmc@redhat.com>

commit 23cde76d801246a702e7a84c3fe3d655b35c89a1 upstream.

hdr->csum_start is the offset from the start of the ethernet
header to the transport layer checksum field. skb->csum_start
is the offset from skb->head.

skb_partial_csum_set() assumes that skb->data points to the
ethernet header - i.e. it computes skb->csum_start by adding
the headroom to hdr->csum_start.

Since eth_type_trans() skb_pull()s the ethernet header,
skb_partial_csum_set() should be called before
eth_type_trans().

(Without this patch, GSO packets from a guest to the world outside the
host are corrupted).

Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/virtio_net.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -83,9 +83,7 @@ static void receive_skb(struct net_devic
 	BUG_ON(len > MAX_PACKET_LEN);
 
 	skb_trim(skb, len);
-	skb->protocol = eth_type_trans(skb, dev);
-	pr_debug("Receiving skb proto 0x%04x len %i type %i\n",
-		 ntohs(skb->protocol), skb->len, skb->pkt_type);
+
 	dev->stats.rx_bytes += skb->len;
 	dev->stats.rx_packets++;
 
@@ -95,6 +93,10 @@ static void receive_skb(struct net_devic
 			goto frame_err;
 	}
 
+	skb->protocol = eth_type_trans(skb, dev);
+	pr_debug("Receiving skb proto 0x%04x len %i type %i\n",
+		 ntohs(skb->protocol), skb->len, skb->pkt_type);
+
 	if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
 		pr_debug("GSO!\n");
 		switch (hdr->gso_type & ~VIRTIO_NET_HDR_GSO_ECN) {

-- 

[patch 06/15] b43: Fix noise calculation WARN_ON

[Greg KH]

[-- Attachment #1: b43-fix-noise-calculation-warn_on.patch --]
[-- Type: text/plain, Size: 2853 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Michael Buesch <mb@bu3sch.de>

commit 98a3b2fe435ae76170936c14f5c9e6a87548e3ef upstream.

This removes a WARN_ON that is responsible for the following koops:
http://www.kerneloops.org/searchweek.php?search=b43_generate_noise_sample

The comment in the patch describes why it's safe to simply remove
the check.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/net/wireless/b43/b43.h  |    1 -
 drivers/net/wireless/b43/main.c |   16 ++++++++++------
 2 files changed, 10 insertions(+), 7 deletions(-)

--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -596,7 +596,6 @@ struct b43_dma {
 
 /* Context information for a noise calculation (Link Quality). */
 struct b43_noise_calculation {
-	u8 channel_at_start;
 	bool calculation_running;
 	u8 nr_samples;
 	s8 samples[8][4];
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -1027,7 +1027,6 @@ static void b43_generate_noise_sample(st
 	b43_jssi_write(dev, 0x7F7F7F7F);
 	b43_write32(dev, B43_MMIO_MACCMD,
 		    b43_read32(dev, B43_MMIO_MACCMD) | B43_MACCMD_BGNOISE);
-	B43_WARN_ON(dev->noisecalc.channel_at_start != dev->phy.channel);
 }
 
 static void b43_calculate_link_quality(struct b43_wldev *dev)
@@ -1036,7 +1035,6 @@ static void b43_calculate_link_quality(s
 
 	if (dev->noisecalc.calculation_running)
 		return;
-	dev->noisecalc.channel_at_start = dev->phy.channel;
 	dev->noisecalc.calculation_running = 1;
 	dev->noisecalc.nr_samples = 0;
 
@@ -1053,9 +1051,16 @@ static void handle_irq_noise(struct b43_
 
 	/* Bottom half of Link Quality calculation. */
 
+	/* Possible race condition: It might be possible that the user
+	 * changed to a different channel in the meantime since we
+	 * started the calculation. We ignore that fact, since it's
+	 * not really that much of a problem. The background noise is
+	 * an estimation only anyway. Slightly wrong results will get damped
+	 * by the averaging of the 8 sample rounds. Additionally the
+	 * value is shortlived. So it will be replaced by the next noise
+	 * calculation round soon. */
+
 	B43_WARN_ON(!dev->noisecalc.calculation_running);
-	if (dev->noisecalc.channel_at_start != phy->channel)
-		goto drop_calculation;
 	*((__le32 *)noise) = cpu_to_le32(b43_jssi_read(dev));
 	if (noise[0] == 0x7F || noise[1] == 0x7F ||
 	    noise[2] == 0x7F || noise[3] == 0x7F)
@@ -1096,11 +1101,10 @@ static void handle_irq_noise(struct b43_
 			average -= 48;
 
 		dev->stats.link_noise = average;
-	      drop_calculation:
 		dev->noisecalc.calculation_running = 0;
 		return;
 	}
-      generate_new:
+generate_new:
 	b43_generate_noise_sample(dev);
 }
 

-- 

[patch 07/15] b43: Fix possible NULL pointer dereference in DMA code

[Greg KH]

[-- Attachment #1: b43-fix-possible-null-pointer-dereference-in-dma-code.patch --]
[-- Type: text/plain, Size: 1219 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Michael Buesch <mb@bu3sch.de>

a cut-down version of commit 028118a5f09a9c807e6b43e2231efdff9f224c74 upstream

This fixes a possible NULL pointer dereference in an error path of the
DMA allocation error checking code. In case the DMA allocation address is invalid,
the dev pointer is dereferenced for unmapping of the buffer.

Reported-by: Miles Lane <miles.lane@gmail.com>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/b43/dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -850,6 +850,7 @@ struct b43_dmaring *b43_setup_dmaring(st
 	if (!ring)
 		goto out;
 	ring->type = type;
+	ring->dev = dev;
 
 	nr_slots = B43_RXRING_SLOTS;
 	if (for_tx)
@@ -901,7 +902,6 @@ struct b43_dmaring *b43_setup_dmaring(st
 				 DMA_TO_DEVICE);
 	}
 
-	ring->dev = dev;
 	ring->nr_slots = nr_slots;
 	ring->mmio_base = b43_dmacontroller_base(type, controller_index);
 	ring->index = controller_index;

-- 

[patch 08/15] scsi_host regression: fix scsi host leak

[Greg KH]

[-- Attachment #1: scsi_host-regression-fix-scsi-host-leak.patch --]
[-- Type: text/plain, Size: 1816 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Mike Christie <michaelc@cs.wisc.edu>

The patch is upstream as commit 3ed7897242b7efe977f3a8d06d4e5a4ebe28b10e

A different backport is necessary because of the class_device to device
conversion post 2.6.25.


commit 9c7701088a61cc0cf8a6e1c68d1e74e3cc2ee0b7
Author: Dave Young <hidave.darkstar@gmail.com>
Date:   Tue Jan 22 14:01:34 2008 +0800

    scsi: use class iteration api

Isn't a correct replacement for the original hand rolled host
lookup. The problem is that class_find_child would get a reference to
the host's class device which is never released.  Since the host class
device holds a reference to the host gendev, the host can never be
freed.

In 2.6.25 we started using class_find_device, and this function also
gets a reference to the device, so we end up with an extra ref
and the host will not get released.

This patch adds a class_put_device to balance the class_find_device()
get. I kept the scsi_host_get in scsi_host_lookup, because the target
layer is using scsi_host_lookup and it looks like it needs the SHOST_DEL
check.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/scsi/hosts.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -455,9 +455,10 @@ struct Scsi_Host *scsi_host_lookup(unsig
 	struct Scsi_Host *shost = ERR_PTR(-ENXIO);
 
 	cdev = class_find_child(&shost_class, &hostnum, __scsi_host_match);
-	if (cdev)
+	if (cdev) {
 		shost = scsi_host_get(class_to_shost(cdev));
-
+		class_device_put(cdev);
+	}
 	return shost;
 }
 EXPORT_SYMBOL(scsi_host_lookup);

-- 

[patch 09/15] ACPICA: Ignore ACPI table signature for Load() operator

[Greg KH]

[-- Attachment #1: acpica-ignore-acpi-table-signature-for-load-operator.patch --]
[-- Type: text/plain, Size: 2124 bytes --]


2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Bob Moore <robert.moore@intel.com>

upstream bc45b1d39a925b56796bebf8a397a0491489d85c

Without this patch booting with acpi_osi="!Windows 2006" is required
for several machines to function properly with cpufreq
due to failure to load a Vista specific table with a bad signature.

Only "SSDT" is acceptable to the ACPI spec, but tables are
seen with OEMx and null sigs. Therefore, signature validation
is worthless.  Apparently MS ACPI accepts such signatures, ACPICA
must be compatible.

http://bugzilla.kernel.org/show_bug.cgi?id=9919
http://bugzilla.kernel.org/show_bug.cgi?id=10383
http://bugzilla.kernel.org/show_bug.cgi?id=10454
https://bugzilla.novell.com/show_bug.cgi?id=396311

Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/acpi/tables/tbinstal.c |   18 +++++++-----------
 1 file changed, 7 insertions(+), 11 deletions(-)

--- a/drivers/acpi/tables/tbinstal.c
+++ b/drivers/acpi/tables/tbinstal.c
@@ -123,17 +123,13 @@ acpi_tb_add_table(struct acpi_table_desc
 		}
 	}
 
-	/* The table must be either an SSDT or a PSDT or an OEMx */
-
-	if ((!ACPI_COMPARE_NAME(table_desc->pointer->signature, ACPI_SIG_PSDT))
-	    &&
-	    (!ACPI_COMPARE_NAME(table_desc->pointer->signature, ACPI_SIG_SSDT))
-	    && (strncmp(table_desc->pointer->signature, "OEM", 3))) {
-		ACPI_ERROR((AE_INFO,
-			    "Table has invalid signature [%4.4s], must be SSDT, PSDT or OEMx",
-			    table_desc->pointer->signature));
-		return_ACPI_STATUS(AE_BAD_SIGNATURE);
-	}
+	/*
+	 * Originally, we checked the table signature for "SSDT" or "PSDT" here.
+	 * Next, we added support for OEMx tables, signature "OEM".
+	 * Valid tables were encountered with a null signature, so we've just
+	 * given up on validating the signature, since it seems to be a waste
+	 * of code. The original code was removed (05/2008).
+	 */
 
 	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 

-- 

Re: [patch 09/15] ACPICA: Ignore ACPI table signature for Load() operator

[nokos]

Hi

the upstream commit bc45b1d39a925b56796bebf8a397a0491489d85c 
introduces a small problem in the /sys filesystem: (can completely confuse 
which do a simple recursion through /sys since the filename is empty)

computer /sys/firmware/acpi/tables> ls -l
ls: cannot access : No such file or directory
total 0
-????????? ? ?    ?    ?            ? 
-r--r--r-- 1 root root 0 Jun 26 01:48 APIC
-r--r--r-- 1 root root 0 Jun 26 01:48 BOOT
-r--r--r-- 1 root root 0 Jun 26 01:48 DSDT
-r--r--r-- 1 root root 0 Jun 26 01:48 FACP
-r--r--r-- 1 root root 0 Jun 26 01:48 FACS
-r--r--r-- 1 root root 0 Jun 26 01:48 HPET
-r--r--r-- 1 root root 0 Jun 26 01:48 MCFG
-r--r--r-- 1 root root 0 Jun 26 01:48 SLIC
-r--r--r-- 1 root root 0 Jun 26 01:48 SSDT1
-r--r--r-- 1 root root 0 Jun 26 01:48 SSDT2
-r--r--r-- 1 root root 0 Jun 26 01:48 SSDT3
-r--r--r-- 1 root root 0 Jun 26 01:48 SSDT4
-r--r--r-- 1 root root 0 Jun 26 01:48 SSDT5

two possible solutions: (any thoughts?)

--- a/drivers/acpi/system.c
+++ b/drivers/acpi/system.c
@@ -94,7 +94,11 @@ static void acpi_table_attr_init(struct acpi_table_attr *table_attr,
        struct acpi_table_header *header = NULL;
        struct acpi_table_attr *attr = NULL;
 
-       memcpy(table_attr->name, table_header->signature, ACPI_NAME_SIZE);
+        if (table_header->signature[0] == '\0') {
+                strncpy(table_attr->name, "NULL", ACPI_NAME_SIZE);
+        } else {
+               memcpy(table_attr->name, table_header->signature, ACPI_NAME_SIZE);
+        }
 
        list_for_each_entry(attr, &acpi_table_attr_list, node) {
                if (!memcmp(table_header->signature, attr->name,
@@ -108,7 +112,7 @@ static void acpi_table_attr_init(struct acpi_table_attr *table_attr,
                                         !acpi_get_table(table_header->
                                                         signature, 2,
                                                         &header)))
-               sprintf(table_attr->name + 4, "%d", table_attr->instance);
+               sprintf(table_attr->name + ACPI_NAME_SIZE, "%d", table_attr->instance);
 
        table_attr->attr.size = 0;
        table_attr->attr.read = acpi_table_show;

--- a/drivers/acpi/tables/tbinstal.c
+++ b/drivers/acpi/tables/tbinstal.c
@@ -130,6 +130,11 @@ acpi_tb_add_table(struct acpi_table_desc *table_desc,
         * given up on validating the signature, since it seems to be a waste
         * of code. The original code was removed (05/2008).
         */
+        if (!strict_signature_check && table_desc->pointer->signature[0] == '\0') {
+                ACPI_DEBUG_PRINT((ACPI_DB_TABLES,
+                        "Table has empty signature, correcting"));
+                strncpy(table_desc->pointer->signature, "SSDT", 4);
+        }
 
        (void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
 

Peter



Am Donnerstag, den 19.06.2008, 14:30 -0700 schrieb Greg KH:
> einfaches Textdokument-Anlage
> (acpica-ignore-acpi-table-signature-for-load-operator.patch)
> 2.6.25-stable review patch.  If anyone has any objections, please let us
> know.
> 
> ------------------
> From: Bob Moore <robert.moore@intel.com>
> 
> upstream bc45b1d39a925b56796bebf8a397a0491489d85c
> 
> Without this patch booting with acpi_osi="!Windows 2006" is required
> for several machines to function properly with cpufreq
> due to failure to load a Vista specific table with a bad signature.
> 
> Only "SSDT" is acceptable to the ACPI spec, but tables are
> seen with OEMx and null sigs. Therefore, signature validation
> is worthless.  Apparently MS ACPI accepts such signatures, ACPICA
> must be compatible.
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=9919
> http://bugzilla.kernel.org/show_bug.cgi?id=10383
> http://bugzilla.kernel.org/show_bug.cgi?id=10454
> https://bugzilla.novell.com/show_bug.cgi?id=396311
> 
> Signed-off-by: Bob Moore <robert.moore@intel.com>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> ---
>  drivers/acpi/tables/tbinstal.c |   18 +++++++-----------
>  1 file changed, 7 insertions(+), 11 deletions(-)
> 
> --- a/drivers/acpi/tables/tbinstal.c
> +++ b/drivers/acpi/tables/tbinstal.c
> @@ -123,17 +123,13 @@ acpi_tb_add_table(struct acpi_table_desc
>  		}
>  	}
>  
> -	/* The table must be either an SSDT or a PSDT or an OEMx */
> -
> -	if ((!ACPI_COMPARE_NAME(table_desc->pointer->signature, ACPI_SIG_PSDT))
> -	    &&
> -	    (!ACPI_COMPARE_NAME(table_desc->pointer->signature, ACPI_SIG_SSDT))
> -	    && (strncmp(table_desc->pointer->signature, "OEM", 3))) {
> -		ACPI_ERROR((AE_INFO,
> -			    "Table has invalid signature [%4.4s], must be SSDT, PSDT or OEMx",
> -			    table_desc->pointer->signature));
> -		return_ACPI_STATUS(AE_BAD_SIGNATURE);
> -	}
> +	/*
> +	 * Originally, we checked the table signature for "SSDT" or "PSDT" here.
> +	 * Next, we added support for OEMx tables, signature "OEM".
> +	 * Valid tables were encountered with a null signature, so we've just
> +	 * given up on validating the signature, since it seems to be a waste
> +	 * of code. The original code was removed (05/2008).
> +	 */
>  
>  	(void)acpi_ut_acquire_mutex(ACPI_MTX_TABLES);
>  
> 

[patch 10/15] SCSI: sr: fix corrupt CD data after media change and delay

[Greg KH]

[-- Attachment #1: scsi-sr-fix-corrupt-cd-data-after-media-change-and-delay.patch --]
[-- Type: text/plain, Size: 1434 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: James Bottomley <James.Bottomley@HansenPartnership.com>

commit: d1daeabf0da5bfa1943272ce508e2ba785730bf0 upstream

Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>

If you delay 30s or more before mounting a CD after inserting it then
the kernel has the wrong value for the CD size.

http://marc.info/?t=121276133000001

The problem is in sr_test_unit_ready(): the function eats unit
attentions without adjusting the sdev->changed status.  This means
that when the CD signals changed media via unit attention, we can
ignore it.  Fix by making sr_test_unit_ready() adjust the changed
status.

Reported-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Tested-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/sr.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -178,6 +178,9 @@ int sr_test_unit_ready(struct scsi_devic
 		the_result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL,
 					      0, sshdr, SR_TIMEOUT,
 					      retries--);
+		if (scsi_sense_valid(sshdr) &&
+		    sshdr->sense_key == UNIT_ATTENTION)
+			sdev->changed = 1;
 
 	} while (retries > 0 &&
 		 (!scsi_status_is_good(the_result) ||

-- 

[patch 11/15] nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()

[Greg KH]

[-- Attachment #1: nf_conntrack-fix-ctnetlink-related-crash-in-nf_nat_setup_info.patch --]
[-- Type: text/plain, Size: 2785 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Patrick McHardy <kaber@trash.net>

netfilter: nf_conntrack: fix ctnetlink related crash in nf_nat_setup_info()

Upstream commit ceeff7541e5a4ba8e8d97ffbae32b3f283cb7a3f

When creation of a new conntrack entry in ctnetlink fails after having
set up the NAT mappings, the conntrack has an extension area allocated
that is not getting properly destroyed when freeing the conntrack again.
This means the NAT extension is still in the bysource hash, causing a
crash when walking over the hash chain the next time:

BUG: unable to handle kernel paging request at 00120fbd
IP: [<c03d394b>] nf_nat_setup_info+0x221/0x58a
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP

Pid: 2795, comm: conntrackd Not tainted (2.6.26-rc5 #1)
EIP: 0060:[<c03d394b>] EFLAGS: 00010206 CPU: 1
EIP is at nf_nat_setup_info+0x221/0x58a
EAX: 00120fbd EBX: 00120fbd ECX: 00000001 EDX: 00000000
ESI: 0000019e EDI: e853bbb4 EBP: e853bbc8 ESP: e853bb78
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process conntrackd (pid: 2795, ti=e853a000 task=f7de10f0 task.ti=e853a000)
Stack: 00000000 e853bc2c e85672ec 00000008 c0561084 63c1db4a 00000000 00000000
       00000000 0002e109 61d2b1c3 00000000 00000000 00000000 01114e22 61d2b1c3
       00000000 00000000 f7444674 e853bc04 00000008 c038e728 0000000a f7444674
Call Trace:
 [<c038e728>] nla_parse+0x5c/0xb0
 [<c0397c1b>] ctnetlink_change_status+0x190/0x1c6
 [<c0397eec>] ctnetlink_new_conntrack+0x189/0x61f
 [<c0119aee>] update_curr+0x3d/0x52
 [<c03902d1>] nfnetlink_rcv_msg+0xc1/0xd8
 [<c0390228>] nfnetlink_rcv_msg+0x18/0xd8
 [<c0390210>] nfnetlink_rcv_msg+0x0/0xd8
 [<c038d2ce>] netlink_rcv_skb+0x2d/0x71
 [<c0390205>] nfnetlink_rcv+0x19/0x24
 [<c038d0f5>] netlink_unicast+0x1b3/0x216
 ...

Move invocation of the extension destructors to nf_conntrack_free()
to fix this problem.

Fixes http://bugzilla.kernel.org/show_bug.cgi?id=10875

Reported-and-Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/netfilter/nf_conntrack_core.c |    3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -199,8 +199,6 @@ destroy_conntrack(struct nf_conntrack *n
 	if (l4proto && l4proto->destroy)
 		l4proto->destroy(ct);
 
-	nf_ct_ext_destroy(ct);
-
 	rcu_read_unlock();
 
 	spin_lock_bh(&nf_conntrack_lock);
@@ -523,6 +521,7 @@ static void nf_conntrack_free_rcu(struct
 
 void nf_conntrack_free(struct nf_conn *ct)
 {
+	nf_ct_ext_destroy(ct);
 	call_rcu(&ct->rcu, nf_conntrack_free_rcu);
 }
 EXPORT_SYMBOL_GPL(nf_conntrack_free);

-- 

[patch 12/15] nf_conntrack_h323: fix module unload crash

[Greg KH]

[-- Attachment #1: nf_conntrack_h323-fix-module-unload-crash.patch --]
[-- Type: text/plain, Size: 4948 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Patrick McHardy <kaber@trash.net>

netfilter: nf_conntrack_h323: fix module unload crash

Upstream commit a56b8f81580761c65e4d8d0c04ac1cb7a788bdf1

The H.245 helper is not registered/unregistered, but assigned to
connections manually from the Q.931 helper. This means on unload
existing expectations and connections using the helper are not
cleaned up, leading to the following oops on module unload:

CPU 0 Unable to handle kernel paging request at virtual address c00a6828, epc == 802224dc, ra == 801d4e7c
Oops[#1]:
Cpu 0
$ 0   : 00000000 00000000 00000004 c00a67f0
$ 4   : 802a5ad0 81657e00 00000000 00000000
$ 8   : 00000008 801461c8 00000000 80570050
$12   : 819b0280 819b04b0 00000006 00000000
$16   : 802a5a60 80000000 80b46000 80321010
$20   : 00000000 00000004 802a5ad0 00000001
$24   : 00000000 802257a8
$28   : 802a4000 802a59e8 00000004 801d4e7c
Hi    : 0000000b
Lo    : 00506320
epc   : 802224dc ip_conntrack_help+0x38/0x74     Tainted: P
ra    : 801d4e7c nf_iterate+0xbc/0x130
Status: 1000f403    KERNEL EXL IE
Cause : 00800008
BadVA : c00a6828
PrId  : 00019374
Modules linked in: ip_nat_pptp ip_conntrack_pptp ath_pktlog wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_xauth ath_pci ath_dev ath_dfs ath_rate_atheros wlan ath_hal ip_nat_tftp ip_conntrack_tftp ip_nat_ftp ip_conntrack_ftp pppoe ppp_async ppp_deflate ppp_mppe pppox ppp_generic slhc
Process swapper (pid: 0, threadinfo=802a4000, task=802a6000)
Stack : 801e7d98 00000004 802a5a60 80000000 801d4e7c 801d4e7c 802a5ad0 00000004
        00000000 00000000 801e7d98 00000000 00000004 802a5ad0 00000000 00000010
        801e7d98 80b46000 802a5a60 80320000 80000000 801d4f8c 802a5b00 00000002
        80063834 00000000 80b46000 802a5a60 801e7d98 80000000 802ba854 00000000
        81a02180 80b7e260 81a021b0 819b0000 819b0000 80570056 00000000 00000001
        ...
Call Trace:
 [<801e7d98>] ip_finish_output+0x0/0x23c
 [<801d4e7c>] nf_iterate+0xbc/0x130
 [<801d4e7c>] nf_iterate+0xbc/0x130
 [<801e7d98>] ip_finish_output+0x0/0x23c
 [<801e7d98>] ip_finish_output+0x0/0x23c
 [<801d4f8c>] nf_hook_slow+0x9c/0x1a4

One way to fix this would be to split helper cleanup from the unregistration
function and invoke it for the H.245 helper, but since ctnetlink needs to be
able to find the helper for synchonization purposes, a better fix is to
register it normally and make sure its not assigned to connections during
helper lookup. The missing l3num initialization is enough for this, this
patch changes it to use AF_UNSPEC to make it more explicit though.

Reported-by: liannan <liannan@twsz.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 net/netfilter/nf_conntrack_h323_main.c |   21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -617,6 +617,7 @@ static struct nf_conntrack_helper nf_con
 	.me			= THIS_MODULE,
 	.max_expected		= H323_RTP_CHANNEL_MAX * 4 + 2 /* T.120 */,
 	.timeout		= 240,
+	.tuple.src.l3num	= AF_UNSPEC,
 	.tuple.dst.protonum	= IPPROTO_UDP,
 	.help			= h245_help
 };
@@ -1758,6 +1759,7 @@ static void __exit nf_conntrack_h323_fin
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_ras[0]);
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[1]);
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[0]);
+	nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
 	kfree(h323_buffer);
 	pr_debug("nf_ct_h323: fini\n");
 }
@@ -1770,27 +1772,32 @@ static int __init nf_conntrack_h323_init
 	h323_buffer = kmalloc(65536, GFP_KERNEL);
 	if (!h323_buffer)
 		return -ENOMEM;
-	ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[0]);
+	ret = nf_conntrack_helper_register(&nf_conntrack_helper_h245);
 	if (ret < 0)
 		goto err1;
-	ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[1]);
+	ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[0]);
 	if (ret < 0)
 		goto err2;
-	ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[0]);
+	ret = nf_conntrack_helper_register(&nf_conntrack_helper_q931[1]);
 	if (ret < 0)
 		goto err3;
-	ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[1]);
+	ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[0]);
 	if (ret < 0)
 		goto err4;
+	ret = nf_conntrack_helper_register(&nf_conntrack_helper_ras[1]);
+	if (ret < 0)
+		goto err5;
 	pr_debug("nf_ct_h323: init success\n");
 	return 0;
 
-err4:
+err5:
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_ras[0]);
-err3:
+err4:
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[1]);
-err2:
+err3:
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_q931[0]);
+err2:
+	nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
 err1:
 	return ret;
 }

-- 

[patch 13/15] nf_conntrack_h323: fix memory leak in module initialization error path

[Greg KH]

[-- Attachment #1: nf_conntrack_h323-fix-memory-leak-in-module-initialization-error-path.patch --]
[-- Type: text/plain, Size: 819 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Patrick McHardy <kaber@trash.net>

netfilter: nf_conntrack_h323: fix memory leak in module initialization error path

Upstream commit 8a548868db62422113104ebc658065e3fe976951

Properly free h323_buffer when helper registration fails.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/netfilter/nf_conntrack_h323_main.c |    1 +
 1 file changed, 1 insertion(+)

--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -1799,6 +1799,7 @@ err3:
 err2:
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
 err1:
+	kfree(h323_buffer);
 	return ret;
 }
 

-- 

[patch 14/15] x86: remove mwait capability C-state check

[Greg KH]

[-- Attachment #1: x86-remove-mwait-capability-c-state-check.patch --]
[-- Type: text/plain, Size: 2753 bytes --]

2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Ingo Molnar <mingo@elte.hu>

back-ported from upstream commit a738d897b7b03b83488ae74a9bc03d26a2875dc6 by Vegard Nossum

Vegard Nossum reports:

| powertop shows between 200-400 wakeups/second with the description
| "<kernel IPI>: Rescheduling interrupts" when all processors have load (e.g.
| I need to run two busy-loops on my 2-CPU system for this to show up).
|
| The bisect resulted in this commit:
|
| commit 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec
| Date:   Wed Jan 30 13:33:16 2008 +0100
|
|     x86: use the correct cpuid method to detect MWAIT support for C states

remove the functional effects of this patch and make mwait unconditional.

A future patch will turn off mwait on specific CPUs where that causes
power to be wasted.

Bisected-by: Vegard Nossum <vegard.nossum@gmail.com>
Tested-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/process_32.c |   10 +---------
 arch/x86/kernel/process_64.c |   11 +----------
 2 files changed, 2 insertions(+), 19 deletions(-)

--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -259,14 +259,6 @@ static void mwait_idle(void)
 	mwait_idle_with_hints(0, 0);
 }
 
-static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
-{
-	if (force_mwait)
-		return 1;
-	/* Any C1 states supported? */
-	return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0;
-}
-
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int selected;
@@ -279,7 +271,7 @@ void __cpuinit select_idle_routine(const
 			" performance may degrade.\n");
 	}
 #endif
-	if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
+	if (cpu_has(c, X86_FEATURE_MWAIT)) {
 		/*
 		 * Skip, if setup has overridden idle.
 		 * One CPU supports mwait => All CPUs supports mwait
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -254,15 +254,6 @@ static void mwait_idle(void)
 	}
 }
 
-
-static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
-{
-	if (force_mwait)
-		return 1;
-	/* Any C1 states supported? */
-	return c->cpuid_level >= 5 && ((cpuid_edx(5) >> 4) & 0xf) > 0;
-}
-
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int selected;
@@ -275,7 +266,7 @@ void __cpuinit select_idle_routine(const
 			" performance may degrade.\n");
 	}
 #endif
-	if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
+	if (cpu_has(c, X86_FEATURE_MWAIT)) {
 		/*
 		 * Skip, if setup has overridden idle.
 		 * One CPU supports mwait => All CPUs supports mwait

-- 

[patch 15/15] x86: disable mwait for AMD family 10H/11H CPUs

[Greg KH]

[-- Attachment #1: x86-disable-mwait-for-amd-family-10h-11h-cpus.patch --]
[-- Type: text/plain, Size: 3931 bytes --]


2.6.25-stable review patch.  If anyone has any objections, please let us
know.

------------------
From: Thomas Gleixner <tglx@linutronix.de>

back-ported from upstream commit e9623b35599fcdbc00c16535cbefbb4d5578f4ab by Vegard Nossum


The previous revert of 0c07ee38c9d4eb081758f5ad14bbffa7197e1aec left
out the mwait disable condition for AMD family 10H/11H CPUs.

Andreas Herrman said:

It depends on the CPU. For AMD CPUs that support MWAIT this is wrong.
Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings then
depend on a clock divisor and current Pstate of the core.

If all cores of a processor are in halt state (C1) the processor can
enter the C1E (C1 enhanced) state. If mwait is used this will never
happen.

Thus HLT saves more power than MWAIT here.

It might be best to switch off the mwait flag for these AMD CPU
families like it was introduced with commit
f039b754714a422959027cb18bb33760eb8153f0 (x86: Don't use MWAIT on AMD
Family 10)

Re-add the AMD families 10H/11H check and disable the mwait usage for
those.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/process_32.c |   29 ++++++++++++++++++++++++++++-
 arch/x86/kernel/process_64.c |   29 ++++++++++++++++++++++++++++-
 2 files changed, 56 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -259,6 +259,33 @@ static void mwait_idle(void)
 	mwait_idle_with_hints(0, 0);
 }
 
+/*
+ * mwait selection logic:
+ *
+ * It depends on the CPU. For AMD CPUs that support MWAIT this is
+ * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings
+ * then depend on a clock divisor and current Pstate of the core. If
+ * all cores of a processor are in halt state (C1) the processor can
+ * enter the C1E (C1 enhanced) state. If mwait is used this will never
+ * happen.
+ *
+ * idle=mwait overrides this decision and forces the usage of mwait.
+ */
+static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
+{
+	if (force_mwait)
+		return 1;
+
+	if (c->x86_vendor == X86_VENDOR_AMD) {
+		switch(c->x86) {
+		case 0x10:
+		case 0x11:
+			return 0;
+		}
+	}
+	return 1;
+}
+
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int selected;
@@ -271,7 +298,7 @@ void __cpuinit select_idle_routine(const
 			" performance may degrade.\n");
 	}
 #endif
-	if (cpu_has(c, X86_FEATURE_MWAIT)) {
+	if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
 		/*
 		 * Skip, if setup has overridden idle.
 		 * One CPU supports mwait => All CPUs supports mwait
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -254,6 +254,33 @@ static void mwait_idle(void)
 	}
 }
 
+/*
+ * mwait selection logic:
+ *
+ * It depends on the CPU. For AMD CPUs that support MWAIT this is
+ * wrong. Family 0x10 and 0x11 CPUs will enter C1 on HLT. Powersavings
+ * then depend on a clock divisor and current Pstate of the core. If
+ * all cores of a processor are in halt state (C1) the processor can
+ * enter the C1E (C1 enhanced) state. If mwait is used this will never
+ * happen.
+ *
+ * idle=mwait overrides this decision and forces the usage of mwait.
+ */
+static int __cpuinit mwait_usable(const struct cpuinfo_x86 *c)
+{
+	if (force_mwait)
+		return 1;
+
+	if (c->x86_vendor == X86_VENDOR_AMD) {
+		switch(c->x86) {
+		case 0x10:
+		case 0x11:
+			return 0;
+		}
+	}
+	return 1;
+}
+
 void __cpuinit select_idle_routine(const struct cpuinfo_x86 *c)
 {
 	static int selected;
@@ -266,7 +293,7 @@ void __cpuinit select_idle_routine(const
 			" performance may degrade.\n");
 	}
 #endif
-	if (cpu_has(c, X86_FEATURE_MWAIT)) {
+	if (cpu_has(c, X86_FEATURE_MWAIT) && mwait_usable(c)) {
 		/*
 		 * Skip, if setup has overridden idle.
 		 * One CPU supports mwait => All CPUs supports mwait

--