2.6.25-stable review

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 [email protected] 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(-)

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

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

From: Linus Torvalds <[email protected]>

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. ]

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

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

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

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

------------------
From: Alan Cox <[email protected]>

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.

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

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

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

------------------
From: Bartlomiej Zolnierkiewicz <[email protected]>

commit 62128b2ca812c1266f4ff7bac068bf0b626c6179 upstream

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

commit 912fb29a36a7269ac1c4a4df45bc0ac1d2637972

Author: Bartlomiej Zolnierkiewicz <[email protected]>
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.

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

@@ -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, "

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

------------------
From: Bartlomiej Zolnierkiewicz <[email protected]>

commit f361037631ba547ea88adf8d2359d810c1b2605a upstream

These controllers don't support DMA.

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

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

@@ -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,
 	}
 };
 

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

------------------
From: Mark McLoughlin <[email protected]>

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).

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

@@ -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) {

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

------------------
From: Mark McLoughlin <[email protected]>

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).

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

@@ -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) {

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

------------------
From: Michael Buesch <[email protected]>

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.

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

@@ -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];

@@ -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);
 }
 

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

------------------
From: Michael Buesch <[email protected]>

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.

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

@@ -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;

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

------------------
From: Mike Christie <[email protected]>

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 <[email protected]>
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.

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

@@ -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);

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

------------------
From: Bob Moore <[email protected]>

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

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

@@ -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);
 

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?)

@@ -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;

@@ -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:

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

------------------
From: James Bottomley <[email protected]>

commit: d1daeabf0da5bfa1943272ce508e2ba785730bf0 upstream

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.

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

@@ -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) ||

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

------------------
From: Patrick McHardy <[email protected]>

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

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

@@ -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);

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

------------------
From: Patrick McHardy <[email protected]>

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.

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

@@ -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;
 }

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

------------------
From: Patrick McHardy <[email protected]>

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

Upstream commit 8a548868db62422113104ebc658065e3fe976951

Properly free h323_buffer when helper registration fails.

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

@@ -1799,6 +1799,7 @@ err3:
 err2:
 	nf_conntrack_helper_unregister(&nf_conntrack_helper_h245);
 err1:
+	kfree(h323_buffer);
 	return ret;
 }
 

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

------------------
From: Ingo Molnar <[email protected]>

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.

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

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

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

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

------------------
From: Thomas Gleixner <[email protected]>

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.

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

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

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