2008-12-17 00:05:00

by Greg KH

[permalink] [raw]
Subject: [patch 00/22] 2.6.27.10 stable review

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 [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 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(-)


2008-12-19 07:21:55

by Pavel Machek

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

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 <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-19 11:22:05

by Joerg Roedel

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

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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> 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

2008-12-19 16:17:31

by Greg KH

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

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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> 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

2008-12-20 11:32:27

by Pavel Machek

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

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 <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > 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

2008-12-20 21:49:04

by Joerg Roedel

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

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

2008-12-17 00:05:17

by Greg KH

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

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

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

From: Joerg Roedel <[email protected]>

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:05:59

by Greg KH

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

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

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

From: Jay Vosburgh <[email protected]>

commit fba4acda35f3119328bcba28aacefae14245d2bb upstream.

During the rework of the mii monitor for:

commit f0c76d61779b153dbfb955db3f144c62d02173c2
Author: Jay Vosburgh <[email protected]>
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 <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:06:42

by Greg KH

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

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

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

From: Manfred Spraul <[email protected]>

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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:06:22

by Greg KH

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

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

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

From: Linus Torvalds <[email protected]>

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 <[email protected]>
Requested-by: Rafael J. Wysocki <[email protected]>
Acked-by: Dave Kleikamp <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Ingo Molnar <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:07:00

by Greg KH

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

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

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

From: Jeff Kirsher <[email protected]>

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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:07:40

by Greg KH

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

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

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

From: Oliver Hartkopp <[email protected]>

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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:08:01

by Greg KH

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

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

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

From: Stephen Hemminger <[email protected]>

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 <[email protected]>
Cc: David Miller <[email protected]>
Cc: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:09:11

by Greg KH

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

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

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

From: Johannes Berg <[email protected]>

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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:10:21

by Greg KH

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

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

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

From: Stefan Richter <[email protected]>

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 <[email protected]>
Signed-off-by: Stefan Richter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:11:19

by Greg KH

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

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

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

From: Trond Myklebust <[email protected]>

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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:09:31

by Greg KH

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

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

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

From: Alexey Dobriyan <[email protected]>

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 <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Cc: Kadianakis George <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:12:45

by Greg KH

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

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

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

From: Finn Thain <[email protected]>

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 <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:09:50

by Greg KH

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

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

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

From: Stefan Richter <[email protected]>

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

/*

2008-12-17 00:13:01

by Greg KH

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

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

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

From: Mauro Carvalho Chehab <[email protected]>

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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:12:23

by Greg KH

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

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

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

From: Gerald Schaefer <[email protected]>

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 <[email protected]>
Acked-by: KAMEZAWA Hiroyuki <[email protected]>
Tested-by: Yasunori Goto <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
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 */

2008-12-17 00:08:48

by Greg KH

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

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

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

From: Ingo Brueckl <[email protected]>

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 <[email protected]>
Acked-by: H. Peter Anvin <[email protected]>
Cc: Egmont Koblinger <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:11:36

by Greg KH

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

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

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

From: Wilfried Klaebe <[email protected]>

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 <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: Karsten Keil <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:08:27

by Greg KH

[permalink] [raw]
Subject: [patch 12/22] unicode table for cp437

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

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

From: Ingo Brueckl <[email protected]>

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 <[email protected]>
Acked-by: H. Peter Anvin <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:14:11

by Greg KH

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

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

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

From: Zachary Amsden <[email protected]>

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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:10:56

by Greg KH

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

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

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

From: Tomas Winkler <[email protected]>

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 <[email protected]>
Signed-off-by: Zhu Yi <[email protected]>
Reported-by: Carlos R. Mafra <[email protected]>
Reported-by: Lukas Hejtmanek <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:13:48

by Greg KH

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

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

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

From: Tejun Heo <[email protected]>

commit d10d491f842243e2e3bf5a2714020f9d649e1e38 upstream.

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

Signed-off-by: Tejun Heo <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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

2008-12-17 00:13:31

by Greg KH

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

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

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

From: Oliver Hartkopp <[email protected]>

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 <[email protected]>
Acked-by: Kurt Van Dijck <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

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