[patch 00/22] 2.6.27.10 stable review

[patch 00/22] 2.6.27.10 stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.27.10 release.
There are 22 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 Thursday, December 18, 22: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.27.10-rc1.gz
and the diffstat can be found below.


thanks,

greg k-h


 Documentation/kernel-parameters.txt     |    2 
 Makefile                                |    2 
 arch/x86/kernel/amd_iommu_init.c        |    2 
 arch/x86/kernel/setup.c                 |   12 ++---
 arch/x86/kernel/smpboot.c               |    2 
 arch/x86/kernel/vmi_32.c                |   16 ++++--
 drivers/ata/libata-core.c               |   65 +++++++++++++++++++++++++---
 drivers/char/cp437.uni                  |   12 ++---
 drivers/char/vt.c                       |    2 
 drivers/firewire/fw-ohci.c              |   11 +++-
 drivers/firewire/fw-transaction.c       |    3 +
 drivers/firewire/fw-transaction.h       |    2 
 drivers/ieee1394/nodemgr.c              |    6 ++
 drivers/isdn/hardware/avm/b1isa.c       |    6 --
 drivers/media/video/tvaudio.c           |   30 +++++++++++-
 drivers/net/bonding/bond_main.c         |    3 +
 drivers/net/e1000e/ich8lan.c            |    9 +++
 drivers/net/wireless/iwlwifi/iwl-agn.c  |    6 +-
 drivers/net/wireless/iwlwifi/iwl-core.c |    3 +
 drivers/net/wireless/iwlwifi/iwl-dev.h  |    3 -
 drivers/net/wireless/iwlwifi/iwl-rx.c   |   26 +++++++----
 drivers/net/wireless/iwlwifi/iwl-sta.c  |   24 +++++++++-
 drivers/video/macfb.c                   |   74 +++++++++++++++-----------------
 include/asm-x86/vmi.h                   |    8 +++
 include/linux/can/core.h                |    2 
 kernel/sched_clock.c                    |    6 +-
 lib/idr.c                               |    8 +++
 mm/page_alloc.c                         |    4 -
 net/can/af_can.c                        |   68 ++++++++++++++++++++++-------
 net/can/bcm.c                           |    7 +--
 net/core/dev.c                          |    2 
 net/key/af_key.c                        |    1 
 net/sunrpc/auth_generic.c               |   20 +++++++-
 33 files changed, 318 insertions(+), 129 deletions(-)

[patch 01/22] AMD IOMMU: enable device isolation per default

[Greg KH]

[-- Attachment #1: amd-iommu-enable-device-isolation-per-default.patch --]
[-- Type: text/plain, Size: 1772 bytes --]

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

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

From: Joerg Roedel <joerg.roedel@amd.com>

commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream.

Impact: makes device isolation the default for AMD IOMMU

Some device drivers showed double-free bugs of DMA memory while testing
them with AMD IOMMU. If all devices share the same protection domain
this can lead to data corruption and data loss. Prevent this by putting
each device into its own protection domain per default.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 Documentation/kernel-parameters.txt |    2 +-
 arch/x86/kernel/amd_iommu_init.c    |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/arch/x86/kernel/amd_iommu_init.c
+++ b/arch/x86/kernel/amd_iommu_init.c
@@ -120,7 +120,7 @@ u16 amd_iommu_last_bdf;			/* largest PCI
 LIST_HEAD(amd_iommu_unity_map);		/* a list of required unity mappings
 					   we find in ACPI */
 unsigned amd_iommu_aperture_order = 26; /* size of aperture in power of 2 */
-int amd_iommu_isolate;			/* if 1, device isolation is enabled */
+int amd_iommu_isolate = 1;		/* if 1, device isolation is enabled */
 
 LIST_HEAD(amd_iommu_list);		/* list of all AMD IOMMUs in the
 					   system */
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -283,7 +283,7 @@ and is between 256 and 4096 characters. 
 			Possible values are:
 			isolate - enable device isolation (each device, as far
 			          as possible, will get its own protection
-			          domain)
+			          domain) [default]
 	amd_iommu_size= [HW,X86-64]
 			Define the size of the aperture for the AMD IOMMU
 			driver. Possible values are:

Re: [patch 01/22] AMD IOMMU: enable device isolation per default

[Pavel Machek]

On Tue 2008-12-16 16:03:53, Greg KH wrote:
> 2.6.27-stable review patch.  If anyone has any objections, please let us know.
> 
> ------------------
> 
> From: Joerg Roedel <joerg.roedel@amd.com>
> 
> commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream.
> 
> Impact: makes device isolation the default for AMD IOMMU
> 
> Some device drivers showed double-free bugs of DMA memory while testing
> them with AMD IOMMU. If all devices share the same protection domain
> this can lead to data corruption and data loss. Prevent this by putting
> each device into its own protection domain per default.
> 
> Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

This does not look like 'fix for a serious bug' to
me. stable_kernel_rules.txt says '...not a "this could be a problem"
type thing'.

Yes, maybe iommu is mature enough that we want it enabled, but...

(Or maybe Documentation/stable_kernel_rules.txt needs updating. The
patch for penguin dirty feet already got in.....)
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch 01/22] AMD IOMMU: enable device isolation per default

[Joerg Roedel]

On Thu, Dec 18, 2008 at 02:00:15PM +0100, Pavel Machek wrote:
> On Tue 2008-12-16 16:03:53, Greg KH wrote:
> > 2.6.27-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Joerg Roedel <joerg.roedel@amd.com>
> > 
> > commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream.
> > 
> > Impact: makes device isolation the default for AMD IOMMU
> > 
> > Some device drivers showed double-free bugs of DMA memory while testing
> > them with AMD IOMMU. If all devices share the same protection domain
> > this can lead to data corruption and data loss. Prevent this by putting
> > each device into its own protection domain per default.
> > 
> > Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> This does not look like 'fix for a serious bug' to
> me. stable_kernel_rules.txt says '...not a "this could be a problem"
> type thing'.

So you don't consider lost data because your filesystem is corrupted
as a problem? This is exactly what can happen (and I suffered from it
one time) if you use IOMMU with a buggy driver (typically a network card
driver).

Joerg

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy

Re: [patch 01/22] AMD IOMMU: enable device isolation per default

[Pavel Machek]

On Fri 2008-12-19 12:21:37, Joerg Roedel wrote:
> On Thu, Dec 18, 2008 at 02:00:15PM +0100, Pavel Machek wrote:
> > On Tue 2008-12-16 16:03:53, Greg KH wrote:
> > > 2.6.27-stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > ------------------
> > > 
> > > From: Joerg Roedel <joerg.roedel@amd.com>
> > > 
> > > commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream.
> > > 
> > > Impact: makes device isolation the default for AMD IOMMU
> > > 
> > > Some device drivers showed double-free bugs of DMA memory while testing
> > > them with AMD IOMMU. If all devices share the same protection domain
> > > this can lead to data corruption and data loss. Prevent this by putting
> > > each device into its own protection domain per default.
> > > 
> > > Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> > 
> > This does not look like 'fix for a serious bug' to
> > me. stable_kernel_rules.txt says '...not a "this could be a problem"
> > type thing'.
> 
> So you don't consider lost data because your filesystem is corrupted
> as a problem? This is exactly what can happen (and I suffered from it
> one time) if you use IOMMU with a buggy driver (typically a network card
> driver).

If you have buggy driver, _you have to fix the driver_, not work
around it by iommu magic that only few machines can do.

So this fixes nothing. (But it helps mask bugs in other pieces of
code/hw. Good. But for stable?)

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [patch 01/22] AMD IOMMU: enable device isolation per default

[Joerg Roedel]

On Sat, Dec 20, 2008 at 12:26:14PM +0100, Pavel Machek wrote:
> On Fri 2008-12-19 12:21:37, Joerg Roedel wrote:
> > So you don't consider lost data because your filesystem is corrupted
> > as a problem? This is exactly what can happen (and I suffered from it
> > one time) if you use IOMMU with a buggy driver (typically a network card
> > driver).
> 
> If you have buggy driver, _you have to fix the driver_, not work
> around it by iommu magic that only few machines can do.

If you can test and fix all possible drivers before maintenance of
2.6.27 ends this would be great. But I don't think this is realistic.
Before we can fix drivers the developers need ways to find those kind of
bugs (which have little or no impact if you use the nommu dma_ops driver).
Exactly for this reason I wrote the DMA API debugging patchset. With it
driver developers will be able to find most of those bugs. But fixing
them is surely not a thing which could be done in one kernel version
(All three network card drivers I tested with DMA API debugging code
 triggered errors).
So as long as not all drivers work correctly we have at least limit the
impact of driver bugs to the driver itself. This is done by making
device isolation the default.

> So this fixes nothing. (But it helps mask bugs in other pieces of
> code/hw. Good. But for stable?)

It does not mask the bugs, just limit the impact. The user will still
see the a WARN when a driver frees am address which is already free and
the user still get a message in dmesg when a device triggers an IO page
fault.

Joerg

Re: [patch 01/22] AMD IOMMU: enable device isolation per default

[Greg KH]

On Thu, Dec 18, 2008 at 02:00:15PM +0100, Pavel Machek wrote:
> On Tue 2008-12-16 16:03:53, Greg KH wrote:
> > 2.6.27-stable review patch.  If anyone has any objections, please let us know.
> > 
> > ------------------
> > 
> > From: Joerg Roedel <joerg.roedel@amd.com>
> > 
> > commit 3ce1f93c6d53c3f91c3846cf66b018276c8ac2e7 upstream.
> > 
> > Impact: makes device isolation the default for AMD IOMMU
> > 
> > Some device drivers showed double-free bugs of DMA memory while testing
> > them with AMD IOMMU. If all devices share the same protection domain
> > this can lead to data corruption and data loss. Prevent this by putting
> > each device into its own protection domain per default.
> > 
> > Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> 
> This does not look like 'fix for a serious bug' to
> me. stable_kernel_rules.txt says '...not a "this could be a problem"
> type thing'.

This is a serious bug, loosing data and crashing drivers seems serious
to me.  There was at least one bug report about this problem, and the
change is upstream and simple and obvious.

thanks,

greg k-h

[patch 02/22] bonding: fix miimon failure counter

[Greg KH]

[-- Attachment #1: bonding-fix-miimon-failure-counter.patch --]
[-- Type: text/plain, Size: 1082 bytes --]

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

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

From: Jay Vosburgh <fubar@us.ibm.com>

commit fba4acda35f3119328bcba28aacefae14245d2bb upstream.

During the rework of the mii monitor for:

  commit f0c76d61779b153dbfb955db3f144c62d02173c2
  Author: Jay Vosburgh <fubar@us.ibm.com>
  Date:   Wed Jul 2 18:21:58 2008 -0700

    bonding: refactor mii monitor

I left out the increment of the link failure counter.  This
patch corrects that omission.

Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/bonding/bond_main.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2370,6 +2370,9 @@ static void bond_miimon_commit(struct bo
 			continue;
 
 		case BOND_LINK_DOWN:
+			if (slave->link_failure_count < UINT_MAX)
+				slave->link_failure_count++;
+
 			slave->link = BOND_LINK_DOWN;
 
 			if (bond->params.mode == BOND_MODE_ACTIVEBACKUP ||

[patch 03/22] Revert "sched_clock: prevent scd->clock from moving backwards"

[Greg KH]

[-- Attachment #1: revert-sched_clock-prevent-scd-clock-from-moving-backwards.patch --]
[-- Type: text/plain, Size: 1552 bytes --]

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

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

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

commit ca7e716c7833aeaeb8fedd6d004c5f5d5e14d325 upstream.

This reverts commit 5b7dba4ff834259a5623e03a565748704a8fe449, which
caused a regression in hibernate, reported by and bisected by Fabio
Comolli.

This revert fixes

 http://bugzilla.kernel.org/show_bug.cgi?id=12155
 http://bugzilla.kernel.org/show_bug.cgi?id=12149

Bisected-by: Fabio Comolli <fabio.comolli@gmail.com>
Requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/sched_clock.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/kernel/sched_clock.c
+++ b/kernel/sched_clock.c
@@ -118,13 +118,13 @@ static u64 __update_sched_clock(struct s
 
 	/*
 	 * scd->clock = clamp(scd->tick_gtod + delta,
-	 *		      max(scd->tick_gtod, scd->clock),
-	 *		      max(scd->clock, scd->tick_gtod + TICK_NSEC));
+	 * 		      max(scd->tick_gtod, scd->clock),
+	 * 		      scd->tick_gtod + TICK_NSEC);
 	 */
 
 	clock = scd->tick_gtod + delta;
 	min_clock = wrap_max(scd->tick_gtod, scd->clock);
-	max_clock = wrap_max(scd->clock, scd->tick_gtod + TICK_NSEC);
+	max_clock = scd->tick_gtod + TICK_NSEC;
 
 	clock = wrap_max(clock, min_clock);
 	clock = wrap_min(clock, max_clock);

[patch 04/22] x86 Fix VMI crash on boot in 2.6.28-rc8

[Greg KH]

[-- Attachment #1: x86-fix-vmi-crash-on-boot-in-2.6.28-rc8.patch --]
[-- Type: text/plain, Size: 3271 bytes --]

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

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

From: Zachary Amsden <zach@vmware.com>

commit ae8d04e2ecbb233926860e9ce145eac19c7835dc upstream.

VMI initialiation can relocate the fixmap, causing early_ioremap to
malfunction if it is initialized before the relocation.  To fix this,
VMI activation is split into two phases; the detection, which must
happen before setting up ioremap, and the activation, which must happen
after parsing early boot parameters.

This fixes a crash on boot when VMI is enabled under VMware.

Signed-off-by: Zachary Amsden <zach@vmware.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/x86/kernel/setup.c   |   12 +++++-------
 arch/x86/kernel/smpboot.c |    2 --
 arch/x86/kernel/vmi_32.c  |   16 +++++++++++-----
 include/asm-x86/vmi.h     |    8 +++++++-
 4 files changed, 23 insertions(+), 15 deletions(-)

--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -634,6 +634,9 @@ void __init setup_arch(char **cmdline_p)
 	printk(KERN_INFO "Command line: %s\n", boot_command_line);
 #endif
 
+	/* VMI may relocate the fixmap; do this before touching ioremap area */
+	vmi_init();
+
 	early_cpu_init();
 	early_ioremap_init();
 
@@ -707,13 +710,8 @@ void __init setup_arch(char **cmdline_p)
 	check_efer();
 #endif
 
-#if defined(CONFIG_VMI) && defined(CONFIG_X86_32)
-	/*
-	 * Must be before kernel pagetables are setup
-	 * or fixmap area is touched.
-	 */
-	vmi_init();
-#endif
+	/* Must be before kernel pagetables are setup */
+	vmi_activate();
 
 	/* after early param, so could get panic from serial */
 	reserve_early_setup_data();
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -289,9 +289,7 @@ static void __cpuinit start_secondary(vo
 	 * fragile that we want to limit the things done here to the
 	 * most necessary things.
 	 */
-#ifdef CONFIG_VMI
 	vmi_bringup();
-#endif
 	cpu_init();
 	preempt_disable();
 	smp_callin();
--- a/arch/x86/kernel/vmi_32.c
+++ b/arch/x86/kernel/vmi_32.c
@@ -960,8 +960,6 @@ static inline int __init activate_vmi(vo
 
 void __init vmi_init(void)
 {
-	unsigned long flags;
-
 	if (!vmi_rom)
 		probe_vmi_rom();
 	else
@@ -973,13 +971,21 @@ void __init vmi_init(void)
 
 	reserve_top_address(-vmi_rom->virtual_top);
 
-	local_irq_save(flags);
-	activate_vmi();
-
 #ifdef CONFIG_X86_IO_APIC
 	/* This is virtual hardware; timer routing is wired correctly */
 	no_timer_check = 1;
 #endif
+}
+
+void vmi_activate(void)
+{
+	unsigned long flags;
+
+	if (!vmi_rom)
+		return;
+
+	local_irq_save(flags);
+	activate_vmi();
 	local_irq_restore(flags & X86_EFLAGS_IF);
 }
 
--- a/include/asm-x86/vmi.h
+++ b/include/asm-x86/vmi.h
@@ -223,9 +223,15 @@ struct pci_header {
 } __attribute__((packed));
 
 /* Function prototypes for bootstrapping */
+#ifdef CONFIG_VMI
 extern void vmi_init(void);
+extern void vmi_activate(void);
 extern void vmi_bringup(void);
-extern void vmi_apply_boot_page_allocations(void);
+#else
+static inline void vmi_init(void) {}
+static inline void vmi_activate(void) {}
+static inline void vmi_bringup(void) {}
+#endif
 
 /* State needed to start an application processor in an SMP system. */
 struct vmi_ap_state {

[patch 05/22] lib/idr.c: Fix bug introduced by RCU fix

[Greg KH]

[-- Attachment #1: lib-idr.c-fix-bug-introduced-by-rcu-fix.patch --]
[-- Type: text/plain, Size: 1350 bytes --]

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

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

From: Manfred Spraul <manfred@colorfullife.com>

commit 711a49a07f84f914aac26a52143f6e7526571143 upstream.

The last patch to lib/idr.c caused a bug if idr_get_new_above() was
called on an empty idr.

Usually, nodes stay on the same layer.  New layers are added to the top
of the tree.

The exception is idr_get_new_above() on an empty tree: In this case, the
new root node is first added on layer 0, then moved upwards.  p->layer
was not updated.

As usual: You shall never rely on the source code comments, they will
only mislead you.

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 lib/idr.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

--- a/lib/idr.c
+++ b/lib/idr.c
@@ -220,8 +220,14 @@ build_up:
 	 */
 	while ((layers < (MAX_LEVEL - 1)) && (id >= (1 << (layers*IDR_BITS)))) {
 		layers++;
-		if (!p->count)
+		if (!p->count) {
+			/* special case: if the tree is currently empty,
+			 * then we grow the tree by moving the top node
+			 * upwards.
+			 */
+			p->layer++;
 			continue;
+		}
 		if (!(new = get_from_free_list(idp))) {
 			/*
 			 * The allocation failed.  If we built part of

[patch 06/22] libata: fix Seagate NCQ+FLUSH blacklist

[Greg KH]

[-- Attachment #1: libata-fix-seagate-ncq-flush-blacklist.patch --]
[-- Type: text/plain, Size: 3678 bytes --]

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

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

From: Tejun Heo <tj@kernel.org>

commit d10d491f842243e2e3bf5a2714020f9d649e1e38 upstream.

Due to miscommunication, P/N was mistaken as firmware revision
strings.  Update it.

Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ata/libata-core.c |   65 +++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 59 insertions(+), 6 deletions(-)

--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -3979,17 +3979,70 @@ static const struct ata_blacklist_entry 
 	{ "ST3160023AS",	"3.42",		ATA_HORKAGE_NONCQ },
 
 	/* Seagate NCQ + FLUSH CACHE firmware bug */
-	{ "ST31500341AS",	"9JU138",	ATA_HORKAGE_NONCQ |
+	{ "ST31500341AS",	"SD15",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
-	{ "ST31000333AS",	"9FZ136",	ATA_HORKAGE_NONCQ |
+	{ "ST31500341AS",	"SD16",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
-	{ "ST3640623AS",	"9FZ164",	ATA_HORKAGE_NONCQ |
+	{ "ST31500341AS",	"SD17",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
-	{ "ST3640323AS",	"9FZ134",	ATA_HORKAGE_NONCQ |
+	{ "ST31500341AS",	"SD18",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
-	{ "ST3320813AS",	"9FZ182",	ATA_HORKAGE_NONCQ |
+	{ "ST31500341AS",	"SD19",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
-	{ "ST3320613AS",	"9FZ162",	ATA_HORKAGE_NONCQ |
+
+	{ "ST31000333AS",	"SD15",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST31000333AS",	"SD16",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST31000333AS",	"SD17",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST31000333AS",	"SD18",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST31000333AS",	"SD19",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+
+	{ "ST3640623AS",	"SD15",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640623AS",	"SD16",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640623AS",	"SD17",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640623AS",	"SD18",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640623AS",	"SD19",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+
+	{ "ST3640323AS",	"SD15",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640323AS",	"SD16",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640323AS",	"SD17",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640323AS",	"SD18",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3640323AS",	"SD19",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+
+	{ "ST3320813AS",	"SD15",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320813AS",	"SD16",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320813AS",	"SD17",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320813AS",	"SD18",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320813AS",	"SD19",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+
+	{ "ST3320613AS",	"SD15",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320613AS",	"SD16",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320613AS",	"SD17",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320613AS",	"SD18",		ATA_HORKAGE_NONCQ |
+						ATA_HORKAGE_FIRMWARE_WARN },
+	{ "ST3320613AS",	"SD19",		ATA_HORKAGE_NONCQ |
 						ATA_HORKAGE_FIRMWARE_WARN },
 
 	/* Blacklist entries taken from Silicon Image 3124/3132

[patch 07/22] e1000e: fix double release of mutex

[Greg KH]

[-- Attachment #1: e1000e-fix-double-release-of-mutex.patch --]
[-- Type: text/plain, Size: 1577 bytes --]

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

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

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

commit 30bb0e0dce78427f3e5cb728d6b5ea73acbefffa upstream.

During a reset, releasing the swflag after it failed to be acquired would
cause a double unlock of the mutex.  Instead, test whether acquisition of
the swflag was successful and if not, do not release the swflag.  The reset
must still be done to bring the device to a quiescent state.

This resolves [BUG 12200] BUG: bad unlock balance detected! e1000e
http://bugzilla.kernel.org/show_bug.cgi?id=12200

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/e1000e/ich8lan.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/net/e1000e/ich8lan.c
+++ b/drivers/net/e1000e/ich8lan.c
@@ -1791,12 +1791,17 @@ static s32 e1000_reset_hw_ich8lan(struct
 		ctrl |= E1000_CTRL_PHY_RST;
 	}
 	ret_val = e1000_acquire_swflag_ich8lan(hw);
+	/* Whether or not the swflag was acquired, we need to reset the part */
 	hw_dbg(hw, "Issuing a global reset to ich8lan");
 	ew32(CTRL, (ctrl | E1000_CTRL_RST));
 	msleep(20);
 
-	/* release the swflag because it is not reset by hardware reset */
-	e1000_release_swflag_ich8lan(hw);
+	if (!ret_val) {
+		/* release the swflag because it is not reset by
+		 * hardware reset
+		 */
+		e1000_release_swflag_ich8lan(hw);
+	}
 
 	ret_val = e1000e_get_auto_rd_done(hw);
 	if (ret_val) {

[patch 08/22] can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter

[Greg KH]

[-- Attachment #1: can-fix-can__flag-handling-in-can_filter.patch --]
[-- Type: text/plain, Size: 5397 bytes --]

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

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

From: Oliver Hartkopp <oliver@hartkopp.net>

commit d253eee20195b25e298bf162a6e72f14bf4803e5 upstream.

Due to a wrong safety check in af_can.c it was not possible to filter
for SFF frames with a specific CAN identifier without getting the
same selected CAN identifier from a received EFF frame also.

This fix has a minimum (but user visible) impact on the CAN filter
API and therefore the CAN version is set to a new date.

Indeed the 'old' API is still working as-is. But when now setting
CAN_(EFF|RTR)_FLAG in can_filter.can_mask you might get less traffic
than before - but still the stuff that you expected to get for your
defined filter ...

Thanks to Kurt Van Dijck for pointing at this issue and for the review.

Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Acked-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 include/linux/can/core.h |    2 -
 net/can/af_can.c         |   63 +++++++++++++++++++++++++++++++++++------------
 net/can/bcm.c            |    7 ++---
 3 files changed, 53 insertions(+), 19 deletions(-)

--- a/include/linux/can/core.h
+++ b/include/linux/can/core.h
@@ -19,7 +19,7 @@
 #include <linux/skbuff.h>
 #include <linux/netdevice.h>
 
-#define CAN_VERSION "20071116"
+#define CAN_VERSION "20081130"
 
 /* increment this number each time you change some user-space interface */
 #define CAN_ABI_VERSION "8"
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -319,23 +319,52 @@ static struct dev_rcv_lists *find_dev_rc
 	return n ? d : NULL;
 }
 
+/**
+ * find_rcv_list - determine optimal filterlist inside device filter struct
+ * @can_id: pointer to CAN identifier of a given can_filter
+ * @mask: pointer to CAN mask of a given can_filter
+ * @d: pointer to the device filter struct
+ *
+ * Description:
+ *  Returns the optimal filterlist to reduce the filter handling in the
+ *  receive path. This function is called by service functions that need
+ *  to register or unregister a can_filter in the filter lists.
+ *
+ *  A filter matches in general, when
+ *
+ *          <received_can_id> & mask == can_id & mask
+ *
+ *  so every bit set in the mask (even CAN_EFF_FLAG, CAN_RTR_FLAG) describe
+ *  relevant bits for the filter.
+ *
+ *  The filter can be inverted (CAN_INV_FILTER bit set in can_id) or it can
+ *  filter for error frames (CAN_ERR_FLAG bit set in mask). For error frames
+ *  there is a special filterlist and a special rx path filter handling.
+ *
+ * Return:
+ *  Pointer to optimal filterlist for the given can_id/mask pair.
+ *  Constistency checked mask.
+ *  Reduced can_id to have a preprocessed filter compare value.
+ */
 static struct hlist_head *find_rcv_list(canid_t *can_id, canid_t *mask,
 					struct dev_rcv_lists *d)
 {
 	canid_t inv = *can_id & CAN_INV_FILTER; /* save flag before masking */
 
-	/* filter error frames */
+	/* filter for error frames in extra filterlist */
 	if (*mask & CAN_ERR_FLAG) {
-		/* clear CAN_ERR_FLAG in list entry */
+		/* clear CAN_ERR_FLAG in filter entry */
 		*mask &= CAN_ERR_MASK;
 		return &d->rx[RX_ERR];
 	}
 
-	/* ensure valid values in can_mask */
-	if (*mask & CAN_EFF_FLAG)
-		*mask &= (CAN_EFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG);
-	else
-		*mask &= (CAN_SFF_MASK | CAN_RTR_FLAG);
+	/* with cleared CAN_ERR_FLAG we have a simple mask/value filterpair */
+
+#define CAN_EFF_RTR_FLAGS (CAN_EFF_FLAG | CAN_RTR_FLAG)
+
+	/* ensure valid values in can_mask for 'SFF only' frame filtering */
+	if ((*mask & CAN_EFF_FLAG) && !(*can_id & CAN_EFF_FLAG))
+		*mask &= (CAN_SFF_MASK | CAN_EFF_RTR_FLAGS);
 
 	/* reduce condition testing at receive time */
 	*can_id &= *mask;
@@ -348,15 +377,19 @@ static struct hlist_head *find_rcv_list(
 	if (!(*mask))
 		return &d->rx[RX_ALL];
 
-	/* use extra filterset for the subscription of exactly *ONE* can_id */
-	if (*can_id & CAN_EFF_FLAG) {
-		if (*mask == (CAN_EFF_MASK | CAN_EFF_FLAG)) {
-			/* RFC: a use-case for hash-tables in the future? */
-			return &d->rx[RX_EFF];
+	/* extra filterlists for the subscription of a single non-RTR can_id */
+	if (((*mask & CAN_EFF_RTR_FLAGS) == CAN_EFF_RTR_FLAGS)
+	    && !(*can_id & CAN_RTR_FLAG)) {
+
+		if (*can_id & CAN_EFF_FLAG) {
+			if (*mask == (CAN_EFF_MASK | CAN_EFF_RTR_FLAGS)) {
+				/* RFC: a future use-case for hash-tables? */
+				return &d->rx[RX_EFF];
+			}
+		} else {
+			if (*mask == (CAN_SFF_MASK | CAN_EFF_RTR_FLAGS))
+				return &d->rx_sff[*can_id];
 		}
-	} else {
-		if (*mask == CAN_SFF_MASK)
-			return &d->rx_sff[*can_id];
 	}
 
 	/* default: filter via can_id/can_mask */
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -64,10 +64,11 @@
 #define BCM_CAN_DLC_MASK 0x0F /* clean private flags in can_dlc by masking */
 
 /* get best masking value for can_rx_register() for a given single can_id */
-#define REGMASK(id) ((id & CAN_RTR_FLAG) | ((id & CAN_EFF_FLAG) ? \
-			(CAN_EFF_MASK | CAN_EFF_FLAG) : CAN_SFF_MASK))
+#define REGMASK(id) ((id & CAN_EFF_FLAG) ? \
+		     (CAN_EFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG) : \
+		     (CAN_SFF_MASK | CAN_EFF_FLAG | CAN_RTR_FLAG))
 
-#define CAN_BCM_VERSION "20080415"
+#define CAN_BCM_VERSION CAN_VERSION
 static __initdata const char banner[] = KERN_INFO
 	"can: broadcast manager protocol (rev " CAN_BCM_VERSION ")\n";
 

[patch 09/22] can: omit received RTR frames for single ID filter lists

[Greg KH]

[-- Attachment #1: can-omit-received-rtr-frames-for-single-id-filter-lists.patch --]
[-- Type: text/plain, Size: 1036 bytes --]

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

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

From: Oliver Hartkopp <oliver@hartkopp.net>

commit f706644d55f90e8306d87060168fef33804d6dd9 upstream.

Since commit d253eee20195b25e298bf162a6e72f14bf4803e5 the single CAN
identifier filter lists handle only non-RTR CAN frames.

So we need to omit the check of these filter lists when receiving RTR
CAN frames.

Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/can/af_can.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -622,7 +622,10 @@ static int can_rcv_filter(struct dev_rcv
 		}
 	}
 
-	/* check CAN_ID specific entries */
+	/* check filterlists for single non-RTR can_ids */
+	if (can_id & CAN_RTR_FLAG)
+		return matches;
+
 	if (can_id & CAN_EFF_FLAG) {
 		hlist_for_each_entry_rcu(r, n, &d->rx[RX_EFF], list) {
 			if (r->can_id == can_id) {

[patch 10/22] iwlwifi: clean key table in iwl_clear_stations_table function

[Greg KH]

[-- Attachment #1: iwlwifi-clean-key-table-in-iwl_clear_stations_table-function.patch --]
[-- Type: text/plain, Size: 4432 bytes --]

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

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

From: Tomas Winkler <tomas.winkler@intel.com>

commit 40a9a8299116297429298e8fcee08235134883f7 upstream.

This patch cleans uCode key table bit map iwl_clear_stations_table
since all stations are cleared also the key table must be.

Since the keys are not removed properly on suspend by mac80211
this may result in exhausting key table on resume leading
to memory corruption during removal

This patch also fixes a memory corruption problem reported in
http://marc.info/?l=linux-wireless&m=122641417231586&w=2 and tracked in
http://bugzilla.kernel.org/show_bug.cgi?id=12040.

When the key is removed a second time the offset is set to 255 - this
index is not valid for the ucode_key_table and corrupts the eeprom pointer
(which is 255 bits from ucode_key_table).

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Reported-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/iwlwifi/iwl-core.c |    3 +++
 drivers/net/wireless/iwlwifi/iwl-sta.c  |   24 +++++++++++++++++++++---
 2 files changed, 24 insertions(+), 3 deletions(-)

--- a/drivers/net/wireless/iwlwifi/iwl-core.c
+++ b/drivers/net/wireless/iwlwifi/iwl-core.c
@@ -290,6 +290,9 @@ void iwl_clear_stations_table(struct iwl
 	priv->num_stations = 0;
 	memset(priv->stations, 0, sizeof(priv->stations));
 
+	/* clean ucode key table bit map */
+	priv->ucode_key_table = 0;
+
 	spin_unlock_irqrestore(&priv->sta_lock, flags);
 }
 EXPORT_SYMBOL(iwl_clear_stations_table);
--- a/drivers/net/wireless/iwlwifi/iwl-sta.c
+++ b/drivers/net/wireless/iwlwifi/iwl-sta.c
@@ -475,7 +475,7 @@ static int iwl_get_free_ucode_key_index(
 		if (!test_and_set_bit(i, &priv->ucode_key_table))
 			return i;
 
-	return -1;
+	return WEP_INVALID_OFFSET;
 }
 
 int iwl_send_static_wepkey_cmd(struct iwl_priv *priv, u8 send_if_empty)
@@ -620,6 +620,9 @@ static int iwl_set_wep_dynamic_key_info(
 	/* else, we are overriding an existing key => no need to allocated room
 	 * in uCode. */
 
+	WARN(priv->stations[sta_id].sta.key.key_offset == WEP_INVALID_OFFSET,
+		"no space for new kew");
+
 	priv->stations[sta_id].sta.key.key_flags = key_flags;
 	priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
 	priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
@@ -637,6 +640,7 @@ static int iwl_set_ccmp_dynamic_key_info
 {
 	unsigned long flags;
 	__le16 key_flags = 0;
+	int ret;
 
 	key_flags |= (STA_KEY_FLG_CCMP | STA_KEY_FLG_MAP_KEY_MSK);
 	key_flags |= cpu_to_le16(keyconf->keyidx << STA_KEY_FLG_KEYID_POS);
@@ -664,14 +668,18 @@ static int iwl_set_ccmp_dynamic_key_info
 	/* else, we are overriding an existing key => no need to allocated room
 	 * in uCode. */
 
+	WARN(priv->stations[sta_id].sta.key.key_offset == WEP_INVALID_OFFSET,
+		"no space for new kew");
+
 	priv->stations[sta_id].sta.key.key_flags = key_flags;
 	priv->stations[sta_id].sta.sta.modify_mask = STA_MODIFY_KEY_MASK;
 	priv->stations[sta_id].sta.mode = STA_CONTROL_MODIFY_MSK;
 
+	ret = iwl_send_add_sta(priv, &priv->stations[sta_id].sta, CMD_ASYNC);
+
 	spin_unlock_irqrestore(&priv->sta_lock, flags);
 
-	IWL_DEBUG_INFO("hwcrypto: modify ucode station key info\n");
-	return iwl_send_add_sta(priv, &priv->stations[sta_id].sta, CMD_ASYNC);
+	return ret;
 }
 
 static int iwl_set_tkip_dynamic_key_info(struct iwl_priv *priv,
@@ -696,6 +704,9 @@ static int iwl_set_tkip_dynamic_key_info
 	/* else, we are overriding an existing key => no need to allocated room
 	 * in uCode. */
 
+	WARN(priv->stations[sta_id].sta.key.key_offset == WEP_INVALID_OFFSET,
+		"no space for new kew");
+
 	/* This copy is acutally not needed: we get the key with each TX */
 	memcpy(priv->stations[sta_id].keyinfo.key, keyconf->key, 16);
 
@@ -734,6 +745,13 @@ int iwl_remove_dynamic_key(struct iwl_pr
 		return 0;
 	}
 
+	if (priv->stations[sta_id].sta.key.key_offset == WEP_INVALID_OFFSET) {
+		IWL_WARNING("Removing wrong key %d 0x%x\n",
+			    keyconf->keyidx, key_flags);
+		spin_unlock_irqrestore(&priv->sta_lock, flags);
+		return 0;
+	}
+
 	if (!test_and_clear_bit(priv->stations[sta_id].sta.key.key_offset,
 		&priv->ucode_key_table))
 		IWL_ERROR("index %d not used in uCode key table.\n",

[patch 11/22] net: eliminate warning from NETIF_F_UFO on bridge

[Greg KH]

[-- Attachment #1: net-eliminate-warning-from-netif_f_ufo-on-bridge.patch --]
[-- Type: text/plain, Size: 1329 bytes --]

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

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

From: Stephen Hemminger <shemminger@vyatta.com>

Based on commit b63365a2d60268a3988285d6c3c6003d7066f93a upstream, but
drastically cut down for 2.6.27.y

The bridge device always causes a warning because when it is first created
it has the no checksum flag set along with all the segmentation/fragmentation
offload bits.  The code in register_netdevice incorrectly checks for only
hardware checksum bit and ignores no checksum bit.

Similar code is already in 2.6.28:
   commit b63365a2d60268a3988285d6c3c6003d7066f93a
   net: Fix disjunct computation of netdev features

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Cc: David Miller <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/core/dev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3990,7 +3990,7 @@ int register_netdevice(struct net_device
 		dev->features &= ~NETIF_F_TSO;
 	}
 	if (dev->features & NETIF_F_UFO) {
-		if (!(dev->features & NETIF_F_HW_CSUM)) {
+		if (!(dev->features & NETIF_F_GEN_CSUM)) {
 			printk(KERN_ERR "%s: Dropping NETIF_F_UFO since no "
 					"NETIF_F_HW_CSUM feature.\n",
 							dev->name);

[patch 12/22] unicode table for cp437

[Greg KH]

[-- Attachment #1: unicode-table-for-cp437.patch --]
[-- Type: text/plain, Size: 2104 bytes --]

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

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

From: Ingo Brueckl <ib@wupperonline.de>

commit f75bc06e5d00a827d3ec5d57bbb5b73a4adec855 upstream.

There is a major bug in the cp437 to unicode translation table.  Char
0x7c is mapped to U+00a5 which is the Yen sign and wrong.  The right
mapping is U+00a6 (broken bar).

Furthermore, a mapping for U+00b4 (a widely used character) is missing
even though easily possible.

The patch fixes these, as well as it provides a few other useful
mappings.

The changes are as follows:

  0x0f (enhancement) enables a sort of currency symbol
  0x27 (bug) enables a sort of acute accent which is a widely used character
  0x44 (enhancement) enables a sort of icelandic capital letter eth
  0x7c (major bug) corrects mapping
  0xeb (enhancement) enables a sort of icelandic small letter eth
  0xee (enhancement) enables a sort of math 'element of'

Signed-off-by: Ingo Brueckl <ib@wupperonline.de>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/cp437.uni |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/char/cp437.uni
+++ b/drivers/char/cp437.uni
@@ -27,7 +27,7 @@
 0x0c	U+2640
 0x0d	U+266a
 0x0e	U+266b
-0x0f	U+263c
+0x0f	U+263c U+00a4
 0x10	U+25b6 U+25ba
 0x11	U+25c0 U+25c4
 0x12	U+2195
@@ -55,7 +55,7 @@
 0x24	U+0024
 0x25	U+0025
 0x26	U+0026
-0x27	U+0027
+0x27	U+0027 U+00b4
 0x28	U+0028
 0x29	U+0029
 0x2a	U+002a
@@ -84,7 +84,7 @@
 0x41	U+0041 U+00c0 U+00c1 U+00c2 U+00c3
 0x42	U+0042
 0x43	U+0043 U+00a9
-0x44	U+0044
+0x44	U+0044 U+00d0
 0x45	U+0045 U+00c8 U+00ca U+00cb
 0x46	U+0046
 0x47	U+0047
@@ -140,7 +140,7 @@
 0x79	U+0079 U+00fd
 0x7a	U+007a
 0x7b	U+007b
-0x7c	U+007c U+00a5
+0x7c	U+007c U+00a6
 0x7d	U+007d
 0x7e	U+007e
 #
@@ -263,10 +263,10 @@
 0xe8	U+03a6 U+00d8
 0xe9	U+0398
 0xea	U+03a9 U+2126
-0xeb	U+03b4
+0xeb	U+03b4 U+00f0
 0xec	U+221e
 0xed	U+03c6 U+00f8
-0xee	U+03b5
+0xee	U+03b5 U+2208
 0xef	U+2229
 0xf0	U+2261
 0xf1	U+00b1

[patch 13/22] console ASCII glyph 1:1 mapping

[Greg KH]

[-- Attachment #1: console-ascii-glyph-1-1-mapping.patch --]
[-- Type: text/plain, Size: 1767 bytes --]

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

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

From: Ingo Brueckl <ib@wupperonline.de>

commit 1c55f18717304100a5f624c923f7cb6511b4116d upstream.

For the console, there is a 1:1 mapping of glyphs which cannot be found
in the current font.  This seems to be meant as a kind of 'emergency
fallback' for fonts without unicode mapping which otherwise would
display nothing readable on the screen.

At the moment it affects all chars for which no substitution character
is defined.  In particular this means that for all chars (>= 128) where
there is no iso88591-1/unicode character (e.g.  control character area)
you'll get the very strange 1:1 mapping of the (cp437) graphics card
glyphs.

I'm pretty sure that the 1:1 mapping should only affect strict ASCII
code characters, i.e.  chars < 128.

The patch limits the mapping as it probably was meant anyway.

Signed-off-by: Ingo Brueckl <ib@wupperonline.de>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Egmont Koblinger <egmont@uhulinux.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/vt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/vt.c
+++ b/drivers/char/vt.c
@@ -2287,7 +2287,7 @@ rescan_last_byte:
 				    continue; /* nothing to display */
 				}
 				/* Glyph not found */
-				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) || c < 128) && !(c & ~charmask)) {
+				if ((!(vc->vc_utf && !vc->vc_disp_ctrl) && c < 128) && !(c & ~charmask)) {
 				    /* In legacy mode use the glyph we get by a 1:1 mapping.
 				       This would make absolutely no sense with Unicode in mind,
 				       but do this for ASCII characters since a font may lack

[patch 14/22] iwlagn: fix RX skb alignment

[Greg KH]

[-- Attachment #1: iwlagn-fix-rx-skb-alignment.patch --]
[-- Type: text/plain, Size: 5919 bytes --]

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

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

From: Johannes Berg <johannes@sipsolutions.net>

commit 4018517a1a69a85c3d61b20fa02f187b80773137 upstream.

So I dug deeper into the DMA problems I had with iwlagn and a kind soul
helped me in that he said something about pci-e alignment and mentioned
the iwl_rx_allocate function to check for crossing 4KB boundaries. Since
there's 8KB A-MPDU support, crossing 4k boundaries didn't seem like
something the device would fail with, but when I looked into the
function for a minute anyway I stumbled over this little gem:

	BUG_ON(rxb->dma_addr & (~DMA_BIT_MASK(36) & 0xff));

Clearly, that is a totally bogus check, one would hope the compiler
removes it entirely. (Think about it)

After fixing it, I obviously ran into it, nothing guarantees the
alignment the way you want it,  because of the way skbs and their
headroom are allocated. I won't explain that here nor double-check that
I'm right, that goes beyond what most of the CC'ed people care about.

So then I came up with the patch below, and so far my system has
survived minutes with 64K pages, when it would previously fail in
seconds. And I haven't seen a single instance of the TX bug either. But
when you see the patch it'll be pretty obvious to you why.

This should fix the following reported kernel bugs:

http://bugzilla.kernel.org/show_bug.cgi?id=11596
http://bugzilla.kernel.org/show_bug.cgi?id=11393
http://bugzilla.kernel.org/show_bug.cgi?id=11983

I haven't checked if there are any elsewhere, but I suppose RHBZ will
have a few instances too...

I'd like to ask anyone who is CC'ed (those are people I know ran into
the bug) to try this patch.

I am convinced that this patch is correct in spirit, but I haven't
understood why, for example, there are so many unmap calls. I'm not
entirely convinced that this is the only bug leading to the TX reply
errors.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/iwlwifi/iwl-agn.c |    6 +++---
 drivers/net/wireless/iwlwifi/iwl-dev.h |    3 ++-
 drivers/net/wireless/iwlwifi/iwl-rx.c  |   26 +++++++++++++++++---------
 3 files changed, 22 insertions(+), 13 deletions(-)

--- a/drivers/net/wireless/iwlwifi/iwl-agn.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn.c
@@ -1384,7 +1384,7 @@ void iwl_rx_handle(struct iwl_priv *priv
 
 		rxq->queue[i] = NULL;
 
-		pci_dma_sync_single_for_cpu(priv->pci_dev, rxb->dma_addr,
+		pci_dma_sync_single_for_cpu(priv->pci_dev, rxb->aligned_dma_addr,
 					    priv->hw_params.rx_buf_size,
 					    PCI_DMA_FROMDEVICE);
 		pkt = (struct iwl_rx_packet *)rxb->skb->data;
@@ -1436,8 +1436,8 @@ void iwl_rx_handle(struct iwl_priv *priv
 			rxb->skb = NULL;
 		}
 
-		pci_unmap_single(priv->pci_dev, rxb->dma_addr,
-				 priv->hw_params.rx_buf_size,
+		pci_unmap_single(priv->pci_dev, rxb->real_dma_addr,
+				 priv->hw_params.rx_buf_size + 256,
 				 PCI_DMA_FROMDEVICE);
 		spin_lock_irqsave(&rxq->lock, flags);
 		list_add_tail(&rxb->list, &priv->rxq.rx_used);
--- a/drivers/net/wireless/iwlwifi/iwl-dev.h
+++ b/drivers/net/wireless/iwlwifi/iwl-dev.h
@@ -89,7 +89,8 @@ extern struct iwl_cfg iwl5100_abg_cfg;
 #define	DEFAULT_LONG_RETRY_LIMIT  4U
 
 struct iwl_rx_mem_buffer {
-	dma_addr_t dma_addr;
+	dma_addr_t real_dma_addr;
+	dma_addr_t aligned_dma_addr;
 	struct sk_buff *skb;
 	struct list_head list;
 };
--- a/drivers/net/wireless/iwlwifi/iwl-rx.c
+++ b/drivers/net/wireless/iwlwifi/iwl-rx.c
@@ -204,7 +204,7 @@ int iwl_rx_queue_restock(struct iwl_priv
 		list_del(element);
 
 		/* Point to Rx buffer via next RBD in circular buffer */
-		rxq->bd[rxq->write] = iwl_dma_addr2rbd_ptr(priv, rxb->dma_addr);
+		rxq->bd[rxq->write] = iwl_dma_addr2rbd_ptr(priv, rxb->aligned_dma_addr);
 		rxq->queue[rxq->write] = rxb;
 		rxq->write = (rxq->write + 1) & RX_QUEUE_MASK;
 		rxq->free_count--;
@@ -251,7 +251,7 @@ void iwl_rx_allocate(struct iwl_priv *pr
 		rxb = list_entry(element, struct iwl_rx_mem_buffer, list);
 
 		/* Alloc a new receive buffer */
-		rxb->skb = alloc_skb(priv->hw_params.rx_buf_size,
+		rxb->skb = alloc_skb(priv->hw_params.rx_buf_size + 256,
 				__GFP_NOWARN | GFP_ATOMIC);
 		if (!rxb->skb) {
 			if (net_ratelimit())
@@ -266,9 +266,17 @@ void iwl_rx_allocate(struct iwl_priv *pr
 		list_del(element);
 
 		/* Get physical address of RB/SKB */
-		rxb->dma_addr =
-		    pci_map_single(priv->pci_dev, rxb->skb->data,
-			   priv->hw_params.rx_buf_size, PCI_DMA_FROMDEVICE);
+		rxb->real_dma_addr = pci_map_single(
+					priv->pci_dev,
+					rxb->skb->data,
+					priv->hw_params.rx_buf_size + 256,
+					PCI_DMA_FROMDEVICE);
+		/* dma address must be no more than 36 bits */
+		BUG_ON(rxb->real_dma_addr & ~DMA_BIT_MASK(36));
+		/* and also 256 byte aligned! */
+		rxb->aligned_dma_addr = ALIGN(rxb->real_dma_addr, 256);
+		skb_reserve(rxb->skb, rxb->aligned_dma_addr - rxb->real_dma_addr);
+
 		list_add_tail(&rxb->list, &rxq->rx_free);
 		rxq->free_count++;
 	}
@@ -300,8 +308,8 @@ void iwl_rx_queue_free(struct iwl_priv *
 	for (i = 0; i < RX_QUEUE_SIZE + RX_FREE_BUFFERS; i++) {
 		if (rxq->pool[i].skb != NULL) {
 			pci_unmap_single(priv->pci_dev,
-					 rxq->pool[i].dma_addr,
-					 priv->hw_params.rx_buf_size,
+					 rxq->pool[i].real_dma_addr,
+					 priv->hw_params.rx_buf_size + 256,
 					 PCI_DMA_FROMDEVICE);
 			dev_kfree_skb(rxq->pool[i].skb);
 		}
@@ -354,8 +362,8 @@ void iwl_rx_queue_reset(struct iwl_priv 
 		 * to an SKB, so we need to unmap and free potential storage */
 		if (rxq->pool[i].skb != NULL) {
 			pci_unmap_single(priv->pci_dev,
-					 rxq->pool[i].dma_addr,
-					 priv->hw_params.rx_buf_size,
+					 rxq->pool[i].real_dma_addr,
+					 priv->hw_params.rx_buf_size + 256,
 					 PCI_DMA_FROMDEVICE);
 			priv->alloc_rxb_skb--;
 			dev_kfree_skb(rxq->pool[i].skb);

[patch 15/22] key: fix setkey(8) policy set breakage

[Greg KH]

[-- Attachment #1: key-fix-setkey-policy-set-breakage.patch --]
[-- Type: text/plain, Size: 1362 bytes --]

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

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

From: Alexey Dobriyan <adobriyan@gmail.com>

commit 920da6923cf03c8a78fbaffa408f8ab37f6abfc1 upstream.

Steps to reproduce:

	#/usr/sbin/setkey -f
	flush;
	spdflush;

	add 192.168.0.42 192.168.0.1 ah 24500 -A hmac-md5 "1234567890123456";
	add 192.168.0.42 192.168.0.1 esp 24501 -E 3des-cbc "123456789012123456789012";

	spdadd 192.168.0.42 192.168.0.1 any -P out ipsec
		esp/transport//require
		ah/transport//require;

setkey: invalid keymsg length

Policy dump will bail out with the same message after that.

-recv(4, "\2\16\0\0\32\0\3\0\0\0\0\0\37\r\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208
+recv(4, "\2\16\0\0\36\0\3\0\0\0\0\0H\t\0\0\3\0\5\0\377 \0\0\2\0\0\0\300\250\0*\0"..., 32768, 0) = 208

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Kadianakis George <desnacked@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/key/af_key.c |    1 -
 1 file changed, 1 deletion(-)

--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2051,7 +2051,6 @@ static int pfkey_xfrm_policy2msg(struct 
 			req_size += socklen * 2;
 		} else {
 			size -= 2*socklen;
-			socklen = 0;
 		}
 		rq = (void*)skb_put(skb, req_size);
 		pol->sadb_x_policy_len += req_size/8;

[patch 16/22] firewire: fw-ohci: fix IOMMU resource exhaustion

[Greg KH]

[-- Attachment #1: firewire-fw-ohci-fix-iommu-resource-exhaustion.patch --]
[-- Type: text/plain, Size: 3169 bytes --]

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

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

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

commit 1d1dc5e83f3299c108a4e44d58cc4bfef48c876a upstream.

There is a DMA map/ unmap imbalance whenever a block write request
packet is sent and then dequeued with ohci_cancel_packet.  The latter
may happen frequently if the AR resp tasklet is executed before the AT
req tasklet for the same transaction.

Add the missing dma_unmap_single.  This fixes
https://bugzilla.redhat.com/show_bug.cgi?id=475156

Reported-by: Emmanuel Kowalski
Tested-by: Emmanuel Kowalski
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/firewire/fw-ohci.c        |   11 +++++++----
 drivers/firewire/fw-transaction.c |    3 +++
 drivers/firewire/fw-transaction.h |    2 ++
 3 files changed, 12 insertions(+), 4 deletions(-)

--- a/drivers/firewire/fw-ohci.c
+++ b/drivers/firewire/fw-ohci.c
@@ -958,6 +958,7 @@ at_context_queue_packet(struct context *
 			packet->ack = RCODE_SEND_ERROR;
 			return -1;
 		}
+		packet->payload_bus = payload_bus;
 
 		d[2].req_count    = cpu_to_le16(packet->payload_length);
 		d[2].data_address = cpu_to_le32(payload_bus);
@@ -1009,7 +1010,6 @@ static int handle_at_packet(struct conte
 	struct driver_data *driver_data;
 	struct fw_packet *packet;
 	struct fw_ohci *ohci = context->ohci;
-	dma_addr_t payload_bus;
 	int evt;
 
 	if (last->transfer_status == 0)
@@ -1022,9 +1022,8 @@ static int handle_at_packet(struct conte
 		/* This packet was cancelled, just continue. */
 		return 1;
 
-	payload_bus = le32_to_cpu(last->data_address);
-	if (payload_bus != 0)
-		dma_unmap_single(ohci->card.device, payload_bus,
+	if (packet->payload_bus)
+		dma_unmap_single(ohci->card.device, packet->payload_bus,
 				 packet->payload_length, DMA_TO_DEVICE);
 
 	evt = le16_to_cpu(last->transfer_status) & 0x1f;
@@ -1681,6 +1680,10 @@ static int ohci_cancel_packet(struct fw_
 	if (packet->ack != 0)
 		goto out;
 
+	if (packet->payload_bus)
+		dma_unmap_single(ohci->card.device, packet->payload_bus,
+				 packet->payload_length, DMA_TO_DEVICE);
+
 	log_ar_at_event('T', packet->speed, packet->header, 0x20);
 	driver_data->packet = NULL;
 	packet->ack = RCODE_CANCELLED;
--- a/drivers/firewire/fw-transaction.c
+++ b/drivers/firewire/fw-transaction.c
@@ -207,6 +207,7 @@ fw_fill_request(struct fw_packet *packet
 	packet->speed = speed;
 	packet->generation = generation;
 	packet->ack = 0;
+	packet->payload_bus = 0;
 }
 
 /**
@@ -541,6 +542,8 @@ fw_fill_response(struct fw_packet *respo
 		BUG();
 		return;
 	}
+
+	response->payload_bus = 0;
 }
 EXPORT_SYMBOL(fw_fill_response);
 
--- a/drivers/firewire/fw-transaction.h
+++ b/drivers/firewire/fw-transaction.h
@@ -27,6 +27,7 @@
 #include <linux/list.h>
 #include <linux/spinlock_types.h>
 #include <linux/timer.h>
+#include <linux/types.h>
 #include <linux/workqueue.h>
 
 #define TCODE_IS_READ_REQUEST(tcode)	(((tcode) & ~1) == 4)
@@ -153,6 +154,7 @@ struct fw_packet {
 	size_t header_length;
 	void *payload;
 	size_t payload_length;
+	dma_addr_t payload_bus;
 	u32 timestamp;
 
 	/*

[patch 17/22] ieee1394: add quirk fix for Freecom HDD

[Greg KH]

[-- Attachment #1: ieee1394-add-quirk-fix-for-freecom-hdd.patch --]
[-- Type: text/plain, Size: 1162 bytes --]

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

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

From: Stefan Richter <stefanr@s5r6.in-berlin.de>

commit 25a41b280083259d05d68f61633194344a1f8a9f upstream.

According to http://bugzilla.kernel.org/show_bug.cgi?id=12206, Freecom
FireWire Hard Drive 1TB reports max_rom=2 but returns garbage if block
read requests are used to read the config ROM.  Force max_rom=0 to limit
them to quadlet read requests.

Reported-by: Christian Mueller <cm1@mumac.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/ieee1394/nodemgr.c |    6 ++++++
 1 file changed, 6 insertions(+)

--- a/drivers/ieee1394/nodemgr.c
+++ b/drivers/ieee1394/nodemgr.c
@@ -115,8 +115,14 @@ static int nodemgr_bus_read(struct csr12
 	return error;
 }
 
+#define OUI_FREECOM_TECHNOLOGIES_GMBH 0x0001db
+
 static int nodemgr_get_max_rom(quadlet_t *bus_info_data, void *__ci)
 {
+	/* Freecom FireWire Hard Drive firmware bug */
+	if (be32_to_cpu(bus_info_data[3]) >> 8 == OUI_FREECOM_TECHNOLOGIES_GMBH)
+		return 0;
+
 	return (be32_to_cpu(bus_info_data[2]) >> 8) & 0x3;
 }
 

[patch 18/22] SUNRPC: Fix a performance regression in the RPC authentication code

[Greg KH]

[-- Attachment #1: sunrpc-fix-a-performance-regression-in-the-rpc-authentication-code.patch --]
[-- Type: text/plain, Size: 2034 bytes --]

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

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

From: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 23918b03060f6e572168fdde1798a905679d2e06 upstream.

Fix a regression reported by Max Kellermann whereby kernel profiling
showed that his clients were spending 45% of their time in
rpcauth_lookup_credcache.

It turns out that although his processes had identical uid/gid/groups,
generic_match() was failing to detect this, because the task->group_info
pointers were not shared. This again lead to the creation of a huge number
of identical credentials at the RPC layer.

The regression is fixed by comparing the contents of task->group_info
if the actual pointers are not identical.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/sunrpc/auth_generic.c |   20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

--- a/net/sunrpc/auth_generic.c
+++ b/net/sunrpc/auth_generic.c
@@ -133,13 +133,29 @@ static int
 generic_match(struct auth_cred *acred, struct rpc_cred *cred, int flags)
 {
 	struct generic_cred *gcred = container_of(cred, struct generic_cred, gc_base);
+	int i;
 
 	if (gcred->acred.uid != acred->uid ||
 	    gcred->acred.gid != acred->gid ||
-	    gcred->acred.group_info != acred->group_info ||
 	    gcred->acred.machine_cred != acred->machine_cred)
-		return 0;
+		goto out_nomatch;
+
+	/* Optimisation in the case where pointers are identical... */
+	if (gcred->acred.group_info == acred->group_info)
+		goto out_match;
+
+	/* Slow path... */
+	if (gcred->acred.group_info->ngroups != acred->group_info->ngroups)
+		goto out_nomatch;
+	for (i = 0; i < gcred->acred.group_info->ngroups; i++) {
+		if (GROUP_AT(gcred->acred.group_info, i) !=
+				GROUP_AT(acred->group_info, i))
+			goto out_nomatch;
+	}
+out_match:
 	return 1;
+out_nomatch:
+	return 0;
 }
 
 void __init rpc_init_generic_auth(void)

[patch 19/22] b1isa: fix b1isa_exit() to really remove registered capi controllers

[Greg KH]

[-- Attachment #1: b1isa-fix-b1isa_exit-to-really-remove-registered-capi-controllers.patch --]
[-- Type: text/plain, Size: 4913 bytes --]

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

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

From: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>

commit 1c594c05a75770ab53a329fc4eb99c797a4bc7d7 upstream.

On "/etc/init.d/capiutils stop", this oops happened.

The oops happens on reading /proc/capi/controllers because
capi_ctrl->procinfo is called for the wrongly not unregistered
controller, which points to b1isa_procinfo(), which was removed on
module unload.

b1isa_exit() did not call b1isa_remove() for its controllers because
io[0] == 0 on module unload despite having been 0x340 on module load.

Besides, just removing the controllers that where added on module
load time and not those that were added later via b1isa_add_card() is
wrong too - the place where all added cards are found is isa_dev[].

relevant dmesg lines:

[    0.000000] Linux version 2.6.27.4 (w@shubashi) (gcc version 4.3.2 (Debian 4.3.2-1) ) #3 Thu Oct 30 16:49:03 CET 2008

[   67.403555] CAPI Subsystem Rev 1.1.2.8
[   68.529154] capifs: Rev 1.1.2.3
[   68.563292] capi20: Rev 1.1.2.7: started up with major 68 (middleware+capifs)
[   77.026936] b1: revision 1.1.2.2
[   77.049992] b1isa: revision 1.1.2.3
[   77.722655] kcapi: Controller [001]: b1isa-340 attached
[   77.722671] b1isa: AVM B1 ISA at i/o 0x340, irq 5, revision 255
[   81.272669] b1isa-340: card 1 "B1" ready.
[   81.272683] b1isa-340: card 1 Protocol: DSS1
[   81.272689] b1isa-340: card 1 Linetype: point to multipoint
[   81.272695] b1isa-340: B1-card (3.11-03) now active
[   81.272702] kcapi: card [001] "b1isa-340" ready.

[  153.721281] kcapi: card [001] down.
[  154.151889] BUG: unable to handle kernel paging request at e87af000
[  154.152081] IP: [<e87af000>]
[  154.153292] *pde = 2655b067 *pte = 00000000
[  154.153307] Oops: 0000 [#1]
[  154.153360] Modules linked in: rfcomm l2cap ppdev lp ipt_MASQUERADE tun capi capifs kernelcapi ac battery nfsd exportfs nfs lockd nfs_acl sunrpc sit tunnel4 bridge stp llc ipt_REJECT ipt_LOG xt_tcpudp xt_state iptable_filter iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables nls_utf8 isofs nls_base zlib_inflate loop ipv6 netconsole snd_via82xx dvb_usb_dib0700 gameport dib7000p dib7000m dvb_usb snd_ac97_codec ac97_bus dvb_core mt2266 snd_pcm tuner_xc2028 dib3000mc dibx000_common mt2060 dib0070 snd_page_alloc snd_mpu401_uart snd_seq_midi snd_seq_midi_event btusb snd_rawmidi bluetooth snd_seq snd_timer snd_seq_device snd via686a i2c_viapro soundcore i2c_core parport_pc parport button dm_mirror dm_log dm_snapshot floppy sg ohci1394 uhci_hcd ehci_hcd 8139too mii ieee1394 usbcore sr_mod cdrom sd_mod thermal processor fan [last unloaded: b1]
[  154.153360]
[  154.153360] Pid: 4132, comm: capiinit Not tainted (2.6.27.4 #3)
[  154.153360] EIP: 0060:[<e87af000>] EFLAGS: 00010286 CPU: 0
[  154.153360] EIP is at 0xe87af000
[  154.153360] EAX: e6b9ccc8 EBX: e6b9ccc8 ECX: e87a0c67 EDX: e87af000
[  154.153360] ESI: e142bbc0 EDI: e87a56e0 EBP: e0505f0c ESP: e0505ee4
[  154.153360]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[  154.153360] Process capiinit (pid: 4132, ti=e0504000 task=d1196cf0 task.ti=e0504000)
[  154.153360] Stack: e879f650 00000246 e0505ef4 c01472eb e0505f0c 00000246 e7001780 fffffff4
[  154.153360]        fffffff4 e142bbc0 e0505f48 c01a56c6 00000400 b805e000 d102dc80 e142bbe0
[  154.153360]        00000000 e87a56e0 00000246 e12617ac 00000000 00000000 e1261760 fffffffb
[  154.153360] Call Trace:
[  154.153360]  [<e879f650>] ? controller_show+0x20/0x90 [kernelcapi]
[  154.153360]  [<c01472eb>] ? trace_hardirqs_on+0xb/0x10
[  154.153360]  [<c01a56c6>] ? seq_read+0x126/0x2f0
[  154.153360]  [<c01a55a0>] ? seq_read+0x0/0x2f0
[  154.153360]  [<c01c033c>] ? proc_reg_read+0x5c/0x90
[  154.153360]  [<c0189919>] ? vfs_read+0x99/0x140
[  154.153360]  [<c01c02e0>] ? proc_reg_read+0x0/0x90
[  154.153360]  [<c0189a7d>] ? sys_read+0x3d/0x70
[  154.153360]  [<c0103c3d>] ? sysenter_do_call+0x12/0x35
[  154.153360]  =======================
[  154.153360] Code:  Bad EIP value.
[  154.153360] EIP: [<e87af000>] 0xe87af000 SS:ESP 0068:e0505ee4
[  154.153360] ---[ end trace 23750b6c2862de94 ]---

Signed-off-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/isdn/hardware/avm/b1isa.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

--- a/drivers/isdn/hardware/avm/b1isa.c
+++ b/drivers/isdn/hardware/avm/b1isa.c
@@ -233,10 +233,8 @@ static void __exit b1isa_exit(void)
 	int i;
 
 	for (i = 0; i < MAX_CARDS; i++) {
-		if (!io[i])
-			break;
-
-		b1isa_remove(&isa_dev[i]);
+		if (isa_dev[i].resource[0].start)
+			b1isa_remove(&isa_dev[i]);
 	}
 	unregister_capi_driver(&capi_driver_b1isa);
 }

[patch 20/22] macfb: Do not overflow fb_fix_screeninfo.id

[Greg KH]

[-- Attachment #1: macfb-do-not-overflow-fb_fix_screeninfo.id.patch --]
[-- Type: text/plain, Size: 7392 bytes --]

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

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

From: Finn Thain <fthain@telegraphics.com.au>

commit 89c223a616cddd9eab792b860f61f99cec53c4e8 upstream.

Don't overflow the 16-character fb_fix_screeninfo id string (fixes some
console erasing and blanking artifacts). Have the ID default to "Unknown"
on machines with no built-in video and no nubus devices. Check for
fb_alloc_cmap failure.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/macfb.c |   74 +++++++++++++++++++++++---------------------------
 1 file changed, 35 insertions(+), 39 deletions(-)

--- a/drivers/video/macfb.c
+++ b/drivers/video/macfb.c
@@ -164,7 +164,6 @@ static struct fb_var_screeninfo macfb_de
 };
 
 static struct fb_fix_screeninfo macfb_fix = {
-	.id	= "Macintosh ",
 	.type	= FB_TYPE_PACKED_PIXELS,
 	.accel	= FB_ACCEL_NONE,
 };
@@ -760,22 +759,22 @@ static int __init macfb_init(void)
 
 		switch(ndev->dr_hw) {
 		case NUBUS_DRHW_APPLE_MDC:
-			strcat( macfb_fix.id, "Display Card" );
+			strcpy(macfb_fix.id, "Mac Disp. Card");
 			macfb_setpalette = mdc_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			break;
 		case NUBUS_DRHW_APPLE_TFB:
-			strcat( macfb_fix.id, "Toby" );
+			strcpy(macfb_fix.id, "Toby");
 			macfb_setpalette = toby_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			break;
 		case NUBUS_DRHW_APPLE_JET:
-			strcat( macfb_fix.id, "Jet");
+			strcpy(macfb_fix.id, "Jet");
 			macfb_setpalette = jet_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			break;			
 		default:
-			strcat( macfb_fix.id, "Generic NuBus" );
+			strcpy(macfb_fix.id, "Generic NuBus");
 			break;
 		}
 	}
@@ -786,21 +785,11 @@ static int __init macfb_init(void)
 	if (!video_is_nubus)
 		switch( mac_bi_data.id )
 		{
-			/* These don't have onboard video.  Eventually, we may
-			   be able to write separate framebuffer drivers for
-			   them (tobyfb.c, hiresfb.c, etc, etc) */
-		case MAC_MODEL_II:
-		case MAC_MODEL_IIX:
-		case MAC_MODEL_IICX:
-		case MAC_MODEL_IIFX:
-			strcat( macfb_fix.id, "Generic NuBus" );
-			break;
-
 			/* Valkyrie Quadras */
 		case MAC_MODEL_Q630:
 			/* I'm not sure about this one */
 		case MAC_MODEL_P588:
-			strcat( macfb_fix.id, "Valkyrie built-in" );
+			strcpy(macfb_fix.id, "Valkyrie");
 			macfb_setpalette = valkyrie_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			valkyrie_cmap_regs = ioremap(DAC_BASE, 0x1000);
@@ -823,7 +812,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_Q700:
 		case MAC_MODEL_Q900:
 		case MAC_MODEL_Q950:
-			strcat( macfb_fix.id, "DAFB built-in" );
+			strcpy(macfb_fix.id, "DAFB");
 			macfb_setpalette = dafb_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			dafb_cmap_regs = ioremap(DAFB_BASE, 0x1000);
@@ -831,7 +820,7 @@ static int __init macfb_init(void)
 
 			/* LC II uses the V8 framebuffer */
 		case MAC_MODEL_LCII:
-			strcat( macfb_fix.id, "V8 built-in" );
+			strcpy(macfb_fix.id, "V8");
 			macfb_setpalette = v8_brazil_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000);
@@ -843,7 +832,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_IIVI:
 		case MAC_MODEL_IIVX:
 		case MAC_MODEL_P600:
-			strcat( macfb_fix.id, "Brazil built-in" );
+			strcpy(macfb_fix.id, "Brazil");
 			macfb_setpalette = v8_brazil_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
 			v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000);
@@ -860,7 +849,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_P460:
 			macfb_setpalette = v8_brazil_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
-			strcat( macfb_fix.id, "Sonora built-in" );
+			strcpy(macfb_fix.id, "Sonora");
 			v8_brazil_cmap_regs = ioremap(DAC_BASE, 0x1000);
 			break;
 
@@ -871,7 +860,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_IISI:
 			macfb_setpalette = rbv_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
-			strcat( macfb_fix.id, "RBV built-in" );
+			strcpy(macfb_fix.id, "RBV");
 			rbv_cmap_regs = ioremap(DAC_BASE, 0x1000);
 			break;
 
@@ -880,7 +869,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_C660:
 			macfb_setpalette = civic_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
-			strcat( macfb_fix.id, "Civic built-in" );
+			strcpy(macfb_fix.id, "Civic");
 			civic_cmap_regs = ioremap(CIVIC_BASE, 0x1000);
 			break;
 
@@ -901,7 +890,7 @@ static int __init macfb_init(void)
 				v8_brazil_cmap_regs =
 					ioremap(DAC_BASE, 0x1000);
 			}
-			strcat( macfb_fix.id, "LC built-in" );
+			strcpy(macfb_fix.id, "LC");
 			break;
 			/* We think this may be like the LC II */
 		case MAC_MODEL_CCL:
@@ -911,18 +900,18 @@ static int __init macfb_init(void)
 				v8_brazil_cmap_regs =
 					ioremap(DAC_BASE, 0x1000);
 			}
-			strcat( macfb_fix.id, "Color Classic built-in" );
+			strcpy(macfb_fix.id, "Color Classic");
 			break;
 
 			/* And we *do* mean "weirdos" */
 		case MAC_MODEL_TV:
-			strcat( macfb_fix.id, "Mac TV built-in" );
+			strcpy(macfb_fix.id, "Mac TV");
 			break;
 
 			/* These don't have colour, so no need to worry */
 		case MAC_MODEL_SE30:
 		case MAC_MODEL_CLII:
-			strcat( macfb_fix.id, "Monochrome built-in" );
+			strcpy(macfb_fix.id, "Monochrome");
 			break;
 
 			/* Powerbooks are particularly difficult.  Many of
@@ -935,7 +924,7 @@ static int __init macfb_init(void)
 		case MAC_MODEL_PB140:
 		case MAC_MODEL_PB145:
 		case MAC_MODEL_PB170:
-			strcat( macfb_fix.id, "DDC built-in" );
+			strcpy(macfb_fix.id, "DDC");
 			break;
 
 			/* Internal is GSC, External (if present) is ViSC */
@@ -945,13 +934,13 @@ static int __init macfb_init(void)
 		case MAC_MODEL_PB180:
 		case MAC_MODEL_PB210:
 		case MAC_MODEL_PB230:
-			strcat( macfb_fix.id, "GSC built-in" );
+			strcpy(macfb_fix.id, "GSC");
 			break;
 
 			/* Internal is TIM, External is ViSC */
 		case MAC_MODEL_PB165C:
 		case MAC_MODEL_PB180C:
-			strcat( macfb_fix.id, "TIM built-in" );
+			strcpy(macfb_fix.id, "TIM");
 			break;
 
 			/* Internal is CSC, External is Keystone+Ariel. */
@@ -963,12 +952,12 @@ static int __init macfb_init(void)
 		case MAC_MODEL_PB280C:
 			macfb_setpalette = csc_setpalette;
 			macfb_defined.activate = FB_ACTIVATE_NOW;
-			strcat( macfb_fix.id, "CSC built-in" );
+			strcpy(macfb_fix.id, "CSC");
 			csc_cmap_regs = ioremap(CSC_BASE, 0x1000);
 			break;
 		
 		default:
-			strcat( macfb_fix.id, "Unknown/Unsupported built-in" );
+			strcpy(macfb_fix.id, "Unknown");
 			break;
 		}
 
@@ -978,16 +967,23 @@ static int __init macfb_init(void)
 	fb_info.pseudo_palette	= pseudo_palette;
 	fb_info.flags		= FBINFO_DEFAULT;
 
-	fb_alloc_cmap(&fb_info.cmap, video_cmap_len, 0);
+	err = fb_alloc_cmap(&fb_info.cmap, video_cmap_len, 0);
+	if (err)
+		goto fail_unmap;
 	
 	err = register_framebuffer(&fb_info);
-	if (!err)
-		printk("fb%d: %s frame buffer device\n",
-		       fb_info.node, fb_info.fix.id);
-	else {
-		iounmap(fb_info.screen_base);
-		iounmap_macfb();
-	}
+	if (err)
+		goto fail_dealloc;
+
+	printk("fb%d: %s frame buffer device\n",
+	       fb_info.node, fb_info.fix.id);
+	return 0;
+
+fail_dealloc:
+	fb_dealloc_cmap(&fb_info.cmap);
+fail_unmap:
+	iounmap(fb_info.screen_base);
+	iounmap_macfb();
 	return err;
 }
 

[patch 21/22] V4L/DVB (9621): Avoid writing outside shadow.bytes[] array

[Greg KH]

[-- Attachment #1: v4l-dvb-avoid-writing-outside-shadow.bytes-array.patch --]
[-- Type: text/plain, Size: 2549 bytes --]

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

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

From: Mauro Carvalho Chehab <mchehab@redhat.com>

commit 494264379d186bf806613d27aafb7d88d42f4212 upstream.

There were no check about the limits of shadow.bytes array. This offers
a risk of writing values outside the limits, overriding other data
areas.

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/tvaudio.c |   30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

--- a/drivers/media/video/tvaudio.c
+++ b/drivers/media/video/tvaudio.c
@@ -152,7 +152,7 @@ static int chip_write(struct CHIPSTATE *
 {
 	unsigned char buffer[2];
 
-	if (-1 == subaddr) {
+	if (subaddr < 0) {
 		v4l_dbg(1, debug, chip->c, "%s: chip_write: 0x%x\n",
 			chip->c->name, val);
 		chip->shadow.bytes[1] = val;
@@ -163,6 +163,13 @@ static int chip_write(struct CHIPSTATE *
 			return -1;
 		}
 	} else {
+		if (subaddr + 1 >= ARRAY_SIZE(chip->shadow.bytes)) {
+			v4l_info(chip->c,
+				"Tried to access a non-existent register: %d\n",
+				subaddr);
+			return -EINVAL;
+		}
+
 		v4l_dbg(1, debug, chip->c, "%s: chip_write: reg%d=0x%x\n",
 			chip->c->name, subaddr, val);
 		chip->shadow.bytes[subaddr+1] = val;
@@ -177,12 +184,20 @@ static int chip_write(struct CHIPSTATE *
 	return 0;
 }
 
-static int chip_write_masked(struct CHIPSTATE *chip, int subaddr, int val, int mask)
+static int chip_write_masked(struct CHIPSTATE *chip,
+			     int subaddr, int val, int mask)
 {
 	if (mask != 0) {
-		if (-1 == subaddr) {
+		if (subaddr < 0) {
 			val = (chip->shadow.bytes[1] & ~mask) | (val & mask);
 		} else {
+			if (subaddr + 1 >= ARRAY_SIZE(chip->shadow.bytes)) {
+				v4l_info(chip->c,
+					"Tried to access a non-existent register: %d\n",
+					subaddr);
+				return -EINVAL;
+			}
+
 			val = (chip->shadow.bytes[subaddr+1] & ~mask) | (val & mask);
 		}
 	}
@@ -228,6 +243,15 @@ static int chip_cmd(struct CHIPSTATE *ch
 	if (0 == cmd->count)
 		return 0;
 
+	if (cmd->count + cmd->bytes[0] - 1 >= ARRAY_SIZE(chip->shadow.bytes)) {
+		v4l_info(chip->c,
+			 "Tried to access a non-existent register range: %d to %d\n",
+			 cmd->bytes[0] + 1, cmd->bytes[0] + cmd->count - 1);
+		return -EINVAL;
+	}
+
+	/* FIXME: it seems that the shadow bytes are wrong bellow !*/
+
 	/* update our shadow register set; print bytes if (debug > 0) */
 	v4l_dbg(1, debug, chip->c, "%s: chip_cmd(%s): reg=%d, data:",
 		chip->c->name, name,cmd->bytes[0]);

[patch 22/22] setup_per_zone_pages_min(): take zone->lock instead of zone->lru_lock

[Greg KH]

[-- Attachment #1: setup_per_zone_pages_min-take-zone-lock-instead-of-zone-lru_lock.patch --]
[-- Type: text/plain, Size: 1562 bytes --]

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

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

From: Gerald Schaefer <gerald.schaefer@de.ibm.com>

commit 1125b4e3949949b44a7c80b619507c6f61d62911 upstream.

This replaces zone->lru_lock in setup_per_zone_pages_min() with zone->lock.
There seems to be no need for the lru_lock anymore, but there is a need for
zone->lock instead, because that function may call move_freepages() via
setup_zone_migrate_reserve().

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Tested-by: Yasunori Goto <y-goto@jp.fujitsu.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>

---
 mm/page_alloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4224,7 +4224,7 @@ void setup_per_zone_pages_min(void)
 	for_each_zone(zone) {
 		u64 tmp;
 
-		spin_lock_irqsave(&zone->lru_lock, flags);
+		spin_lock_irqsave(&zone->lock, flags);
 		tmp = (u64)pages_min * zone->present_pages;
 		do_div(tmp, lowmem_pages);
 		if (is_highmem(zone)) {
@@ -4256,7 +4256,7 @@ void setup_per_zone_pages_min(void)
 		zone->pages_low   = zone->pages_min + (tmp >> 2);
 		zone->pages_high  = zone->pages_min + (tmp >> 1);
 		setup_zone_migrate_reserve(zone);
-		spin_unlock_irqrestore(&zone->lru_lock, flags);
+		spin_unlock_irqrestore(&zone->lock, flags);
 	}
 
 	/* update totalreserve_pages */