[patch 00/47] 2.6.25-stable review

[patch 00/47] 2.6.25-stable review

[Greg KH]

This is the start of the stable review cycle for the 2.6.25.12 release.
There are 47 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 July 24, 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.25.12-rc1.gz
and the diffstat can be found below.


thanks,

the -stable release team

-----

 Makefile                                    |    2 
 arch/powerpc/kernel/of_platform.c           |    2 
 block/as-iosched.c                          |    2 
 crypto/chainiv.c                            |   10 +++-
 drivers/base/node.c                         |    4 -
 drivers/block/cciss.c                       |   66 +++++++++++++++-------------
 drivers/char/pcmcia/ipwireless/hardware.c   |    4 +
 drivers/char/rtc.c                          |    3 -
 drivers/char/tpm/tpm_tis.c                  |    1 
 drivers/hwmon/hdaps.c                       |    8 +++
 drivers/isdn/i4l/isdn_common.c              |    4 +
 drivers/md/md.c                             |    6 +-
 drivers/md/raid10.c                         |    2 
 drivers/md/raid5.c                          |   14 ++---
 drivers/media/dvb/dvb-usb/dib0700_devices.c |    7 ++
 drivers/media/dvb/dvb-usb/dvb-usb-ids.h     |    3 -
 drivers/media/video/ov7670.c                |    4 +
 drivers/message/fusion/mptspi.c             |    9 ++-
 drivers/mmc/host/pxamci.c                   |   13 +++++
 drivers/mmc/host/sdhci.c                    |    6 +-
 drivers/net/3c59x.c                         |    5 +-
 drivers/net/wireless/b43/leds.c             |    3 +
 drivers/net/wireless/b43/main.c             |    9 ++-
 drivers/net/wireless/b43legacy/dma.c        |    2 
 drivers/net/wireless/b43legacy/main.c       |    6 +-
 drivers/net/wireless/zd1211rw/zd_usb.c      |    1 
 drivers/rapidio/rio-driver.c                |    2 
 drivers/scsi/esp_scsi.c                     |   22 ++++++++-
 drivers/scsi/ses.c                          |    2 
 drivers/serial/8250.c                       |    3 +
 drivers/serial/serial_core.c                |    4 +
 drivers/usb/core/hcd.c                      |   38 +++++++++++-----
 drivers/usb/host/ehci.h                     |   19 ++++----
 drivers/usb/host/ohci-hcd.c                 |   15 +++++-
 drivers/usb/host/ohci-q.c                   |   12 +++++
 drivers/usb/misc/sisusbvga/sisusb.c         |    2 
 drivers/video/fb_defio.c                    |   20 ++++++++
 fs/buffer.c                                 |   13 +++--
 fs/cifs/cifsacl.c                           |   10 ++--
 fs/exec.c                                   |    2 
 fs/reiserfs/inode.c                         |    2 
 include/linux/fs.h                          |    1 
 kernel/hrtimer.c                            |    8 +++
 lib/ts_bm.c                                 |    2 
 mm/slub.c                                   |    4 +
 net/can/af_can.c                            |   10 ++++
 net/can/bcm.c                               |   23 ++++++++-
 net/can/raw.c                               |    3 +
 net/mac80211/tx.c                           |    9 +++
 net/netfilter/nf_conntrack_proto_tcp.c      |   13 ++---
 50 files changed, 323 insertions(+), 112 deletions(-)

[patch 01/47] b43legacy: Do not return TX_BUSY from op_tx

[Greg KH]

[-- Attachment #1: b43legacy-do-not-return-tx_busy-from-op_tx.patch --]
[-- Type: text/plain, Size: 915 bytes --]

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

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

Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.

Upstream commit is
eb803e419ca6be06ece2e42027bb4ebd8ec09f91

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/net/wireless/b43legacy/main.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/b43legacy/main.c
+++ b/drivers/net/wireless/b43legacy/main.c
@@ -2350,8 +2350,10 @@ static int b43legacy_op_tx(struct ieee80
 	} else
 		err = b43legacy_dma_tx(dev, skb, ctl);
 out:
-	if (unlikely(err))
-		return NETDEV_TX_BUSY;
+	if (unlikely(err)) {
+		/* Drop the packet. */
+		dev_kfree_skb_any(skb);
+	}
 	return NETDEV_TX_OK;
 }
 

-- 

[patch 02/47] b43: Do not return TX_BUSY from op_tx

[Greg KH]

[-- Attachment #1: b43-do-not-return-tx_busy-from-op_tx.patch --]
[-- Type: text/plain, Size: 1231 bytes --]

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

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

Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
This will fix the resume hang.

Upstream commit is
66193a7cef2239bfd1b9b96e304770facf7a49c7

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>


---
 drivers/net/wireless/b43/main.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -2607,7 +2607,7 @@ static int b43_op_tx(struct ieee80211_hw
 	int err;
 
 	if (unlikely(!dev))
-		return NETDEV_TX_BUSY;
+		goto drop_packet;
 
 	/* Transmissions on seperate queues can run concurrently. */
 	read_lock_irqsave(&wl->tx_lock, flags);
@@ -2619,7 +2619,12 @@ static int b43_op_tx(struct ieee80211_hw
 	read_unlock_irqrestore(&wl->tx_lock, flags);
 
 	if (unlikely(err))
-		return NETDEV_TX_BUSY;
+		goto drop_packet;
+	return NETDEV_TX_OK;
+
+drop_packet:
+	/* We can not transmit this packet. Drop it. */
+	dev_kfree_skb_any(skb);
 	return NETDEV_TX_OK;
 }
 

-- 

[patch 03/47] b43: Fix possible MMIO access while device is down

[Greg KH]

[-- Attachment #1: b43-fix-possible-mmio-access-while-device-is-down.patch --]
[-- Type: text/plain, Size: 999 bytes --]

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

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

This fixes a possible MMIO access while the device is still down
from a suspend cycle. MMIO accesses with the device powered down
may cause crashes on certain devices.

Upstream commit is
33598cf261e393f2b3349cb55509e358014bfd1f

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/b43/leds.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/net/wireless/b43/leds.c
+++ b/drivers/net/wireless/b43/leds.c
@@ -72,6 +72,9 @@ static void b43_led_brightness_set(struc
 	struct b43_wldev *dev = led->dev;
 	bool radio_enabled;
 
+	if (unlikely(b43_status(dev) < B43_STAT_INITIALIZED))
+		return;
+
 	/* Checking the radio-enabled status here is slightly racy,
 	 * but we want to avoid the locking overhead and we don't care
 	 * whether the LED has the wrong state for a second. */

-- 

[patch 04/47] mac80211: detect driver tx bugs

[Greg KH]

[-- Attachment #1: mac80211-detect-driver-tx-bugs.patch --]
[-- Type: text/plain, Size: 1503 bytes --]

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

------------------
From: Johannes Berg <johannes@sipsolutions.net>

When a driver rejects a frame in it's ->tx() callback, it must also
stop queues, otherwise mac80211 can go into a loop here. Detect this
situation and abort the loop after five retries, warning about the
driver bug.

This patch was added to mainline as
commit ef3a62d272f033989e83eb1f26505f93f93e3e69.

Thanks to Larry Finger <Larry.Finger@lwfinger.net> for doing the -stable
port.

Cc: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 net/mac80211/tx.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1090,7 +1090,7 @@ static int ieee80211_tx(struct net_devic
 	ieee80211_tx_handler *handler;
 	struct ieee80211_txrx_data tx;
 	ieee80211_txrx_result res = TXRX_DROP, res_prepare;
-	int ret, i;
+	int ret, i, retries = 0;
 
 	WARN_ON(__ieee80211_queue_pending(local, control->queue));
 
@@ -1181,6 +1181,13 @@ retry:
 		if (!__ieee80211_queue_stopped(local, control->queue)) {
 			clear_bit(IEEE80211_LINK_STATE_PENDING,
 				  &local->state[control->queue]);
+			retries++;
+			/*
+			 * Driver bug, it's rejecting packets but
+			 * not stopping queues.
+			 */
+			if (WARN_ON_ONCE(retries > 5))
+				goto drop;
 			goto retry;
 		}
 		memcpy(&store->control, control,

-- 

[patch 05/47] block: Fix the starving writes bug in the anticipatory IO scheduler

[Greg KH]

[-- Attachment #1: block-fix-the-starving-writes-bug-in-the-anticipatory-io-scheduler.patch --]
[-- Type: text/plain, Size: 3866 bytes --]

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

------------------
From: Divyesh Shah <dpshah@google.com>

commit d585d0b9d73ed999cc7b8cf3cac4a5b01abb544e upstream

AS scheduler alternates between issuing read and write batches. It does
the batch switch only after all requests from the previous batch are
completed.

When switching to a write batch, if there is an on-going read request,
it waits for its completion and indicates its intention of switching by
setting ad->changed_batch and the new direction but does not update the
batch_expire_time for the new write batch which it does in the case of
no previous pending requests.
On completion of the read request, it sees that we were waiting for the
switch and schedules work for kblockd right away and resets the
ad->changed_data flag.
Now when kblockd enters dispatch_request where it is expected to pick
up a write request, it in turn ends the write batch because the
batch_expire_timer was not updated and shows the expire timestamp for
the previous batch.

This results in the write starvation for all the cases where there is
the intention for switching to a write batch, but there is a previous
in-flight read request and the batch gets reverted to a read_batch
right away.

This also holds true in the reverse case (switching from a write batch
to a read batch with an in-flight write request).

I've checked that this bug exists on 2.6.11, 2.6.18, 2.6.24 and
linux-2.6-block git HEAD. I've tested the fix on x86 platforms with
SCSI drives where the driver asks for the next request while a current
request is in-flight.

This patch is based off linux-2.6-block git HEAD.

Bug reproduction:
A simple scenario which reproduces this bug is:
- dd if=/dev/hda3 of=/dev/null &
- lilo
   The lilo takes forever to complete.

This can also be reproduced fairly easily with the earlier dd and
another test
program doing msync().

The example test program below should print out a message after every
iteration
but it simply hangs forever. With this bugfix it makes forward progress.

====
Example test program using msync() (thanks to suleiman AT google DOT
com)

inline uint64_t
rdtsc(void)
{
         int64_t tsc;

         __asm __volatile("rdtsc" : "=A" (tsc));
         return (tsc);
}

int
main(int argc, char **argv)
{
         struct stat st;
         uint64_t e, s, t;
         char *p, q;
         long i;
         int fd;

         if (argc < 2) {
                 printf("Usage: %s <file>\n", argv[0]);
                 return (1);
         }

         if ((fd = open(argv[1], O_RDWR | O_NOATIME)) < 0)
                 err(1, "open");

         if (fstat(fd, &st) < 0)
                 err(1, "fstat");

         p = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);

         t = 0;
         for (i = 0; i < 1000; i++) {
                 *p = 0;
                 msync(p, 4096, MS_SYNC);
                 s = rdtsc();
                *p = 0;
                 __asm __volatile(""::: "memory");
                 e = rdtsc();
                 if (argc > 2)
                         printf("%d: %lld cycles %jd %jd\n",
                                i, e - s, (intmax_t)s, (intmax_t)e);
                 t += e - s;
         }
         printf("average time: %lld cycles\n", t / 1000);
         return (0);
}

Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 block/as-iosched.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/block/as-iosched.c
+++ b/block/as-iosched.c
@@ -831,6 +831,8 @@ static void as_completed_request(struct 
 	}
 
 	if (ad->changed_batch && ad->nr_dispatched == 1) {
+		ad->current_batch_expires = jiffies +
+					ad->batch_expire[ad->batch_data_dir];
 		kblockd_schedule_work(&ad->antic_work);
 		ad->changed_batch = 0;
 

-- 

[patch 06/47] md: Fix error paths if md_probe fails.

[Greg KH]

[-- Attachment #1: md-fix-error-paths-if-md_probe-fails.patch --]
[-- Type: text/plain, Size: 1039 bytes --]

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

------------------
From: Neil Brown <neilb@notabene.brown>

commit 9bbbca3a0ee09293108b67835c6bdf6196d7bcb3 upstream

md_probe can fail (e.g. alloc_disk could fail) without
returning an error (as it alway returns NULL).
So when we call mddev_find immediately afterwards, we need
to check that md_probe actually succeeded.  This means checking
that mdev->gendisk is non-NULL.

Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/md.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3804,8 +3804,10 @@ static void autorun_devices(int part)
 
 		md_probe(dev, NULL, NULL);
 		mddev = mddev_find(dev);
-		if (!mddev) {
-			printk(KERN_ERR 
+		if (!mddev || !mddev->gendisk) {
+			if (mddev)
+				mddev_put(mddev);
+			printk(KERN_ERR
 				"md: cannot allocate memory for md drive.\n");
 			break;
 		}

-- 

[patch 07/47] md: Dont acknowlege that stripe-expand is complete until it really is.

[Greg KH]

[-- Attachment #1: md-don-t-acknowlege-that-stripe-expand-is-complete-until-it-really-is.patch --]
[-- Type: text/plain, Size: 1690 bytes --]

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

------------------
From: Neil Brown <neilb@notabene.brown>

commit efe311431869b40d67911820a309f9a1a41306f3 upstream

We shouldn't acknowledge that a stripe has been expanded (When
reshaping a raid5 by adding a device) until the moved data has
actually been written out.  However we are currently
acknowledging (by calling md_done_sync) when the POST_XOR
is complete and before the write.

So track in s.locked whether there are pending writes, and don't
call md_done_sync yet if there are.

Note: we all set R5_LOCKED on devices which are are about to
read from.  This probably isn't technically necessary, but is
usually done when writing a block, and justifies the use of
s.locked here.

This bug can lead to a crash if an array is stopped while an reshape
is in progress.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/raid5.c |    3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2861,6 +2861,8 @@ static void handle_stripe5(struct stripe
 
 		for (i = conf->raid_disks; i--; ) {
 			set_bit(R5_Wantwrite, &sh->dev[i].flags);
+			set_bit(R5_LOCKED, &dev->flags);
+			s.locked++;
 			if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))
 				sh->ops.count++;
 		}
@@ -2874,6 +2876,7 @@ static void handle_stripe5(struct stripe
 			conf->raid_disks);
 		s.locked += handle_write_operations5(sh, 1, 1);
 	} else if (s.expanded &&
+		   s.locked == 0 &&
 		!test_bit(STRIPE_OP_POSTXOR, &sh->ops.pending)) {
 		clear_bit(STRIPE_EXPAND_READY, &sh->state);
 		atomic_dec(&conf->reshape_stripes);

-- 

[patch 08/47] md: Ensure interrupted recovery completed properly (v1 metadata plus bitmap)

[Greg KH]

[-- Attachment #1: md-ensure-interrupted-recovery-completed-properly.patch --]
[-- Type: text/plain, Size: 1945 bytes --]

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

------------------
From: Neil Brown <neilb@notabene.brown>

commit 8c2e870a625bd336b2e7a65a97c1836acef07322 upstream

If, while assembling an array, we find a device which is not fully
in-sync with the array, it is important to set the "fullsync" flags.
This is an exact analog to the setting of this flag in hot_add_disk
methods.

Currently, only v1.x metadata supports having devices in an array
which are not fully in-sync (it keep track of how in sync they are).
The 'fullsync' flag only makes a difference when a write-intent bitmap
is being used.  In this case it tells recovery to ignore the bitmap
and recovery all blocks.

This fix is already in place for raid1, but not raid5/6 or raid10.

So without this fix, a raid1 ir raid4/5/6 array with version 1.x
metadata and a write intent bitmaps, that is stopped in the middle
of a recovery, will appear to complete the recovery instantly
after it is reassembled, but the recovery will not be correct.

If you might have an array like that, issueing
   echo repair > /sys/block/mdXX/md/sync_action

will make sure recovery completes properly.

Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/raid10.c |    2 ++
 drivers/md/raid5.c  |    4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2102,6 +2102,8 @@ static int run(mddev_t *mddev)
 		    !test_bit(In_sync, &disk->rdev->flags)) {
 			disk->head_position = 0;
 			mddev->degraded++;
+			if (disk->rdev)
+				conf->fullsync = 1;
 		}
 	}
 
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4166,7 +4166,9 @@ static int run(mddev_t *mddev)
 				" disk %d\n", bdevname(rdev->bdev,b),
 				raid_disk);
 			working_disks++;
-		}
+		} else
+			/* Cannot rely on bitmap to complete recovery */
+			conf->fullsync = 1;
 	}
 
 	/*

-- 

[patch 09/47] block: Properly notify block layer of sync writes

[Greg KH]

[-- Attachment #1: block-properly-notify-block-layer-of-sync-writes.patch --]
[-- Type: text/plain, Size: 3958 bytes --]

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

------------------
From: Jens Axboe <jens.axboe@oracle.com>

commit 18ce3751ccd488c78d3827e9f6bf54e6322676fb upstream

fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
then immediately wait on them. Conceptually, that makes them sync writes
and we should treat them as such so that the IO schedulers can handle
them appropriately.

This patch fixes a write starvation issue that Lin Ming reported, where
xx is stuck for more than 2 minutes because of a large number of
synchronous IO in the system:

INFO: task kjournald:20558 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
kjournald     D ffff810010820978  6712 20558      2
ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
Call Trace:
[<ffffffff803ba6f2>] kobject_get+0x12/0x17
[<ffffffff80247537>] getnstimeofday+0x2f/0x83
[<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
[<ffffffff8066d195>] io_schedule+0x5d/0x9f
[<ffffffff8029c1e7>] sync_buffer+0x3b/0x3f
[<ffffffff8066d3f0>] __wait_on_bit+0x40/0x6f
[<ffffffff8029c1ac>] sync_buffer+0x0/0x3f
[<ffffffff8066d48b>] out_of_line_wait_on_bit+0x6c/0x78
[<ffffffff80243909>] wake_bit_function+0x0/0x23
[<ffffffff8029e3ad>] sync_dirty_buffer+0x98/0xcb
[<ffffffff8030056b>] journal_commit_transaction+0x97d/0xcb6
[<ffffffff8023a676>] lock_timer_base+0x26/0x4b
[<ffffffff8030300a>] kjournald+0xc1/0x1fb
[<ffffffff802438db>] autoremove_wake_function+0x0/0x2e
[<ffffffff80302f49>] kjournald+0x0/0x1fb
[<ffffffff802437bb>] kthread+0x47/0x74
[<ffffffff8022de51>] schedule_tail+0x28/0x5d
[<ffffffff8020cac8>] child_rip+0xa/0x12
[<ffffffff80243774>] kthread+0x0/0x74
[<ffffffff8020cabe>] child_rip+0x0/0x12

Lin Ming confirms that this patch fixes the issue. I've run tests with
it for the past week and no ill effects have been observed, so I'm
proposing it for inclusion into 2.6.26.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/buffer.c        |   13 ++++++++-----
 include/linux/fs.h |    1 +
 2 files changed, 9 insertions(+), 5 deletions(-)

--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -818,7 +818,7 @@ static int fsync_buffers_list(spinlock_t
 				 * contents - it is a noop if I/O is still in
 				 * flight on potentially older contents.
 				 */
-				ll_rw_block(SWRITE, 1, &bh);
+				ll_rw_block(SWRITE_SYNC, 1, &bh);
 				brelse(bh);
 				spin_lock(lock);
 			}
@@ -2952,16 +2952,19 @@ void ll_rw_block(int rw, int nr, struct 
 	for (i = 0; i < nr; i++) {
 		struct buffer_head *bh = bhs[i];
 
-		if (rw == SWRITE)
+		if (rw == SWRITE || rw == SWRITE_SYNC)
 			lock_buffer(bh);
 		else if (test_set_buffer_locked(bh))
 			continue;
 
-		if (rw == WRITE || rw == SWRITE) {
+		if (rw == WRITE || rw == SWRITE || rw == SWRITE_SYNC) {
 			if (test_clear_buffer_dirty(bh)) {
 				bh->b_end_io = end_buffer_write_sync;
 				get_bh(bh);
-				submit_bh(WRITE, bh);
+				if (rw == SWRITE_SYNC)
+					submit_bh(WRITE_SYNC, bh);
+				else
+					submit_bh(WRITE, bh);
 				continue;
 			}
 		} else {
@@ -2990,7 +2993,7 @@ int sync_dirty_buffer(struct buffer_head
 	if (test_clear_buffer_dirty(bh)) {
 		get_bh(bh);
 		bh->b_end_io = end_buffer_write_sync;
-		ret = submit_bh(WRITE, bh);
+		ret = submit_bh(WRITE_SYNC, bh);
 		wait_on_buffer(bh);
 		if (buffer_eopnotsupp(bh)) {
 			clear_buffer_eopnotsupp(bh);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -83,6 +83,7 @@ extern int dir_notify_enable;
 #define READ_SYNC	(READ | (1 << BIO_RW_SYNC))
 #define READ_META	(READ | (1 << BIO_RW_META))
 #define WRITE_SYNC	(WRITE | (1 << BIO_RW_SYNC))
+#define SWRITE_SYNC	(SWRITE | (1 << BIO_RW_SYNC))
 #define WRITE_BARRIER	((1 << BIO_RW) | (1 << BIO_RW_BARRIER))
 
 #define SEL_IN		1

-- 

[patch 10/47] OHCI: Fix problem if SM501 and another platform driver is selected

[Greg KH]

[-- Attachment #1: ohci-fix-problem-if-sm501-and-another-platform-driver-is-selected.patch --]
[-- Type: text/plain, Size: 1907 bytes --]

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

------------------
From: Ben Dooks <ben-linux@fluff.org>

commit 3ee38d8bf46b364b1ca364ddb7c379a4afcd8bbb upstream

If the SM501 and another platform driver, such as the SM501
then we end up defining PLATFORM_DRIVER twice. This patch
seperated the SM501 onto a seperate define of SM501_OHCI_DRIVER
so that it can be selected without overwriting the original
definition.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ohci-hcd.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1054,7 +1054,7 @@ MODULE_LICENSE ("GPL");
 
 #ifdef CONFIG_MFD_SM501
 #include "ohci-sm501.c"
-#define PLATFORM_DRIVER		ohci_hcd_sm501_driver
+#define SM501_OHCI_DRIVER	ohci_hcd_sm501_driver
 #endif
 
 #if	!defined(PCI_DRIVER) &&		\
@@ -1062,6 +1062,7 @@ MODULE_LICENSE ("GPL");
 	!defined(OF_PLATFORM_DRIVER) &&	\
 	!defined(SA1111_DRIVER) &&	\
 	!defined(PS3_SYSTEM_BUS_DRIVER) && \
+	!defined(SM501_OHCI_DRIVER) && \
 	!defined(SSB_OHCI_DRIVER)
 #error "missing bus glue for ohci-hcd"
 #endif
@@ -1121,9 +1122,18 @@ static int __init ohci_hcd_mod_init(void
 		goto error_ssb;
 #endif
 
+#ifdef SM501_OHCI_DRIVER
+	retval = platform_driver_register(&SM501_OHCI_DRIVER);
+	if (retval < 0)
+		goto error_sm501;
+#endif
+
 	return retval;
 
 	/* Error path */
+#ifdef SM501_OHCI_DRIVER
+ error_sm501:
+#endif
 #ifdef SSB_OHCI_DRIVER
  error_ssb:
 #endif
@@ -1159,6 +1169,9 @@ module_init(ohci_hcd_mod_init);
 
 static void __exit ohci_hcd_mod_exit(void)
 {
+#ifdef SM501_OHCI_DRIVER
+	platform_driver_unregister(&SM501_OHCI_DRIVER);
+#endif
 #ifdef SSB_OHCI_DRIVER
 	ssb_driver_unregister(&SSB_OHCI_DRIVER);
 #endif

-- 

[patch 11/47] USB: ehci - fix timer regression

[Greg KH]

[-- Attachment #1: usb-ehci-fix-timer-regression.patch --]
[-- Type: text/plain, Size: 2135 bytes --]

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

------------------
From: David Brownell <david-b@pacbell.net>

commit 056761e55c8687ddf3db14226213f2e8dc2689bc upstream

This patch fixes a regression in the EHCI driver's TIMER_IO_WATCHDOG
behavior.  The patch "USB: EHCI: add separate IAA watchdog timer" changed
how that timer is handled, so that short timeouts on the remaining
timer (unfortunately, overloaded) would never be used.

This takes a more direct approach, reorganizing the code slightly to
be explicit about only the I/O watchdog role now being overridable.
It also replaces a now-obsolete comment describing older timer behavior.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ehci.h |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -176,6 +176,15 @@ timer_action_done (struct ehci_hcd *ehci
 static inline void
 timer_action (struct ehci_hcd *ehci, enum ehci_timer_action action)
 {
+	/* Don't override timeouts which shrink or (later) disable
+	 * the async ring; just the I/O watchdog.  Note that if a
+	 * SHRINK were pending, OFF would never be requested.
+	 */
+	if (timer_pending(&ehci->watchdog)
+			&& ((BIT(TIMER_ASYNC_SHRINK) | BIT(TIMER_ASYNC_OFF))
+				& ehci->actions))
+		return;
+
 	if (!test_and_set_bit (action, &ehci->actions)) {
 		unsigned long t;
 
@@ -191,15 +200,7 @@ timer_action (struct ehci_hcd *ehci, enu
 			t = EHCI_SHRINK_JIFFIES;
 			break;
 		}
-		t += jiffies;
-		// all timings except IAA watchdog can be overridden.
-		// async queue SHRINK often precedes IAA.  while it's ready
-		// to go OFF neither can matter, and afterwards the IO
-		// watchdog stops unless there's still periodic traffic.
-		if (time_before_eq(t, ehci->watchdog.expires)
-				&& timer_pending (&ehci->watchdog))
-			return;
-		mod_timer (&ehci->watchdog, t);
+		mod_timer(&ehci->watchdog, t + jiffies);
 	}
 }
 

-- 

[patch 12/47] USB: ohci - record data toggle after unlink

[Greg KH]

[-- Attachment #1: usb-ohci-record-data-toggle-after-unlink.patch --]
[-- Type: text/plain, Size: 2242 bytes --]

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

------------------
From: David Brownell <dbrownell@users.sourceforge.net>

commit 29c8f6a727a683b5988877dd80dbdefd49e64a51 upstream

This patch fixes a problem with OHCI where canceling bulk or
interrupt URBs may lose track of the right data toggle.  This
seems to be a longstanding bug, possibly dating back to the
Linux 2.4 kernel, which stayed hidden because

 (a) about half the time the data toggle bit was correct;
 (b) canceling such URBs is unusual; and
 (c) the few drivers which cancel these URBs either
      [1] do it only as part of shutting down, or
      [2] have fault recovery logic, which recovers.

For those transfer types, the toggle is normally written back
into the ED when each TD is retired.  But canceling bypasses
the mechanism used to retire TDs ... so on average, half the
time the toggle bit will be invalid after cancelation.

The fix is simple:  the toggle state of any canceled TDs are
propagated back to the ED in the finish_unlinks function.

(Issue found by leonidv11@gmail.com ...)

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/host/ohci-q.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -952,6 +952,7 @@ rescan_this:
 			struct urb	*urb;
 			urb_priv_t	*urb_priv;
 			__hc32		savebits;
+			u32		tdINFO;
 
 			td = list_entry (entry, struct td, td_list);
 			urb = td->urb;
@@ -966,6 +967,17 @@ rescan_this:
 			savebits = *prev & ~cpu_to_hc32 (ohci, TD_MASK);
 			*prev = td->hwNextTD | savebits;
 
+			/* If this was unlinked, the TD may not have been
+			 * retired ... so manually save the data toggle.
+			 * The controller ignores the value we save for
+			 * control and ISO endpoints.
+			 */
+			tdINFO = hc32_to_cpup(ohci, &td->hwINFO);
+			if ((tdINFO & TD_T) == TD_T_DATA0)
+				ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_C);
+			else if ((tdINFO & TD_T) == TD_T_DATA1)
+				ed->hwHeadP |= cpu_to_hc32(ohci, ED_C);
+
 			/* HC may have partly processed this TD */
 			td_done (ohci, urb, td);
 			urb_priv->td_cnt++;

-- 

[patch 13/47] USB: fix interrupt disabling for HCDs with shared interrupt handlers

[Greg KH]

[-- Attachment #1: usb-fix-interrupt-disabling-for-hcds-with-shared-interrupt-handlers.patch --]
[-- Type: text/plain, Size: 3162 bytes --]

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

------------------
From: Stefan Becker <Stefan.Becker@nokia.com>

commit de85422b94ddb23c021126815ea49414047c13dc upstream

As has been discussed several times on LKML, IRQF_SHARED | IRQF_DISABLED
doesn't work reliably, i.e. a shared interrupt handler CAN'T be certain to
be called with interrupts disabled. Most USB HCD handlers use IRQF_DISABLED
and therefore havoc can break out if they share their interrupt with a
handler that doesn't use it.

On my test machine the yenta_socket interrupt handler (no IRQF_DISABLED)
was registered before ehci_hcd and one uhci_hcd instance. Therefore all
usb_hcd_irq() invocations for ehci_hcd and for one uhci_hcd instance
happened with interrupts enabled. That led to random lockups as USB core
HCD functions that acquire the same spinlock could be called twice
from interrupt handlers.

This patch updates usb_hcd_irq() to always disable/restore interrupts.
usb_add_hcd() will silently remove any IRQF_DISABLED requested from HCD code.

Signed-off-by: Stefan Becker <stefan.becker@nokia.com>
Acked-by: David Brownell <david-b@pacbell.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/core/hcd.c |   42 ++++++++++++++++++++++++++++++------------
 1 file changed, 30 insertions(+), 12 deletions(-)

--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1685,19 +1685,30 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 {
 	struct usb_hcd		*hcd = __hcd;
-	int			start = hcd->state;
+	unsigned long		flags;
+	irqreturn_t		rc;
 
-	if (unlikely(start == HC_STATE_HALT ||
-	    !test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags)))
-		return IRQ_NONE;
-	if (hcd->driver->irq (hcd) == IRQ_NONE)
-		return IRQ_NONE;
-
-	set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
-
-	if (unlikely(hcd->state == HC_STATE_HALT))
-		usb_hc_died (hcd);
-	return IRQ_HANDLED;
+	/* IRQF_DISABLED doesn't work correctly with shared IRQs
+	 * when the first handler doesn't use it.  So let's just
+	 * assume it's never used.
+	 */
+	local_irq_save(flags);
+
+	if (unlikely(hcd->state == HC_STATE_HALT ||
+		     !test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))) {
+		rc = IRQ_NONE;
+	} else if (hcd->driver->irq(hcd) == IRQ_NONE) {
+		rc = IRQ_NONE;
+	} else {
+		set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
+
+		if (unlikely(hcd->state == HC_STATE_HALT))
+			usb_hc_died(hcd);
+		rc = IRQ_HANDLED;
+	}
+
+	local_irq_restore(flags);
+	return rc;
 }
 
 /*-------------------------------------------------------------------------*/
@@ -1861,6 +1872,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
 
 	/* enable irqs just before we start the controller */
 	if (hcd->driver->irq) {
+
+		/* IRQF_DISABLED doesn't work as advertised when used together
+		 * with IRQF_SHARED. As usb_hcd_irq() will always disable
+		 * interrupts we can remove it here.
+		 */
+		irqflags &= ~IRQF_DISABLED;
+
 		snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
 				hcd->driver->description, hcd->self.busnum);
 		if ((retval = request_irq(irqnum, &usb_hcd_irq, irqflags,

-- 

[patch 14/47] hdaps: add support for various newer Lenovo thinkpads

[Greg KH]

[-- Attachment #1: hdaps-add-support-for-various-newer-lenovo-thinkpads.patch --]
[-- Type: text/plain, Size: 2671 bytes --]

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

------------------
From: maximilian attems <max@stro.at>

commit 292d73551d0aa19526c3417e791c529b49ebadf3 upstream

Adds R61, T61p, X61s, X61, Z61m, Z61p models to whitelist.

Fixes this:

cullen@lenny:~$ sudo modprobe hdaps
FATAL: Error inserting hdaps (/lib/modules/2.6.22-10-generic/kernel/drivers/hwmon/hdaps.ko): No such device

[25192.888000] hdaps: supported laptop not found!
[25192.888000] hdaps: driver init failed (ret=-19)!

Originally based on an Ubuntu patch that got it wrong, the dmidecode
output of the corresponding laptops shows LENOVO as the manufacturer.
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133636

tested on X61s:
[  184.893588] hdaps: inverting axis readings.
[  184.893588] hdaps: LENOVO ThinkPad X61s detected.
[  184.893588] input: hdaps as /class/input/input12
[  184.924326] hdaps: driver successfully loaded.

Cc: Klaus S. Madsen <ubuntu@hjernemadsen.org>
Cc: Chuck Short <zulcss@ubuntu.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: maximilian attems <max@stro.at>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/hwmon/hdaps.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/drivers/hwmon/hdaps.c
+++ b/drivers/hwmon/hdaps.c
@@ -515,16 +515,24 @@ static struct dmi_system_id __initdata h
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R50"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R51"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R52"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad R61i"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad R61"),
 	HDAPS_DMI_MATCH_INVERT("IBM", "ThinkPad T41p"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T41"),
 	HDAPS_DMI_MATCH_INVERT("IBM", "ThinkPad T42p"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T42"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T43"),
 	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T60"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T61p"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T61"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad X40"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad X41"),
 	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X60"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X61s"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X61"),
 	HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad Z60m"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad Z61m"),
+	HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad Z61p"),
 	{ .ident = NULL }
 };
 

-- 

[patch 15/47] b43legacy: Fix possible NULL pointer dereference in DMA code

[Greg KH]

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

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

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

commit 2f9ec47d0954f9d2e5a00209c2689cbc477a8c89 upstream

This fixes a possible NULL pointer dereference in an error path of the
DMA allocation error checking code. This is also necessary for a future
DMA API change that is on its way into the mainline kernel that adds
an additional dev parameter to dma_mapping_error().

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

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

--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -876,6 +876,7 @@ struct b43legacy_dmaring *b43legacy_setu
 	if (!ring)
 		goto out;
 	ring->type = type;
+	ring->dev = dev;
 
 	nr_slots = B43legacy_RXRING_SLOTS;
 	if (for_tx)
@@ -922,7 +923,6 @@ struct b43legacy_dmaring *b43legacy_setu
 				 DMA_TO_DEVICE);
 	}
 
-	ring->dev = dev;
 	ring->nr_slots = nr_slots;
 	ring->mmio_base = b43legacy_dmacontroller_base(type, controller_index);
 	ring->index = controller_index;

-- 

[patch 16/47] netdrvr: 3c59x: remove irqs_disabled warning from local_bh_enable

[Greg KH]

[-- Attachment #1: netdrvr-3c59x-remove-irqs_disabled-warning-from-local_bh_enable.patch --]
[-- Type: text/plain, Size: 4526 bytes --]

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

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

commit c5643cab7bf663ae049b11be43de8819683176dd upstream

Original Author: Michael Buesch <mb@bu3sch.de>

net, vortex: fix lockup

Ingo Molnar reported:

-tip testing found that Johannes Berg's "softirq: remove irqs_disabled
warning from local_bh_enable" enhancement to lockdep triggers a new
warning on an old testbox that uses 3c59x vortex and netlogging:

----->
    calling  vortex_init+0x0/0xb0
    PCI: Found IRQ 10 for device 0000:00:0b.0
    PCI: Sharing IRQ 10 with 0000:00:0a.0
    PCI: Sharing IRQ 10 with 0000:00:0b.1
    3c59x: Donald Becker and others.
    0000:00:0b.0: 3Com PCI 3c556 Laptop Tornado at e0800400.
    PCI: Enabling bus mastering for device 0000:00:0b.0
    initcall vortex_init+0x0/0xb0 returned 0 after 47 msecs
..
    calling  init_netconsole+0x0/0x1b0
    netconsole: local port 4444
    netconsole: local IP 10.0.1.9
    netconsole: interface eth0
    netconsole: remote port 4444
    netconsole: remote IP 10.0.1.16
    netconsole: remote ethernet address 00:19:xx:xx:xx:xx
    netconsole: device eth0 not up yet, forcing it
    eth0:  setting half-duplex.
    eth0:  setting full-duplex.
------------[ cut here ]------------
    WARNING: at kernel/softirq.c:137 local_bh_enable_ip+0xd1/0xe0()
    Pid: 1, comm: swapper Not tainted 2.6.26-rc6-tip #2091
     [<c0125ecf>] warn_on_slowpath+0x4f/0x70
     [<c0126834>] ? release_console_sem+0x1b4/0x1d0
     [<c0126d00>] ? vprintk+0x2a0/0x450
     [<c012fde5>] ? __mod_timer+0xa5/0xc0
     [<c046f7fd>] ? mdio_sync+0x3d/0x50
     [<c0160ef6>] ? marker_probe_cb+0x46/0xa0
     [<c0126ed7>] ? printk+0x27/0x50
     [<c046f4c3>] ? vortex_set_duplex+0x43/0xc0
     [<c046f521>] ? vortex_set_duplex+0xa1/0xc0
     [<c0471b92>] ? vortex_timer+0xe2/0x3e0
     [<c012b361>] local_bh_enable_ip+0xd1/0xe0
     [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40
     [<c0471b92>] vortex_timer+0xe2/0x3e0
     [<c014743b>] ? trace_hardirqs_on+0xb/0x10
     [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160
     [<c012f8b2>] run_timer_softirq+0x162/0x1c0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c012b361>] local_bh_enable_ip+0xd1/0xe0
     [<c08d9f9f>] _spin_unlock_bh+0x2f/0x40
     [<c0471b92>] vortex_timer+0xe2/0x3e0
     [<c014743b>] ? trace_hardirqs_on+0xb/0x10
     [<c0147358>] ? trace_hardirqs_on_caller+0x88/0x160
     [<c012f8b2>] run_timer_softirq+0x162/0x1c0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c0471ab0>] ? vortex_timer+0x0/0x3e0
     [<c012b60a>] __do_softirq+0x9a/0x160
     [<c012b570>] ? __do_softirq+0x0/0x160
     [<c0106775>] call_on_stack+0x15/0x30
     [<c012b4f5>] ? irq_exit+0x55/0x60
     [<c0106e85>] ? do_IRQ+0x85/0xd0
     [<c0147391>] ? trace_hardirqs_on_caller+0xc1/0x160
     [<c0104888>] ? common_interrupt+0x28/0x30
     [<c08d8ac8>] ? mutex_unlock+0x8/0x10
     [<c08d8180>] ? _cond_resched+0x10/0x30
     [<c07a3be7>] ? netpoll_setup+0x117/0x390
     [<c0cbfcfe>] ? init_netconsole+0x14e/0x1b0
     [<c013d539>] ? ktime_get+0x19/0x40
     [<c0c9bab2>] ? kernel_init+0x1b2/0x2c0
     [<c0cbfbb0>] ? init_netconsole+0x0/0x1b0
     [<c0396aa4>] ? trace_hardirqs_on_thunk+0xc/0x10
     [<c0103f12>] ? restore_nocheck_notrace+0x0/0xe
     [<c0c9b900>] ? kernel_init+0x0/0x2c0
     [<c0c9b900>] ? kernel_init+0x0/0x2c0
     [<c0104aa7>] ? kernel_thread_helper+0x7/0x10
     =======================
---[ end trace 37f9c502aff112e0 ]---
    console [netcon0] enabled
    netconsole: network logging started
    initcall init_netconsole+0x0/0x1b0 returned 0 after 2914 msecs

looking at the driver I think the bug is real and the fix actually
is trivial.

vp->lock is also taken in hardware IRQ context, so we _have_ to always
use irqsafe locking. As we run in a timer with IRQs disabled,
we can simply use spin_lock.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/net/3c59x.c
+++ b/drivers/net/3c59x.c
@@ -1769,9 +1769,10 @@ vortex_timer(unsigned long data)
 	case XCVR_MII: case XCVR_NWAY:
 		{
 			ok = 1;
-			spin_lock_bh(&vp->lock);
+			/* Interrupts are already disabled */
+			spin_lock(&vp->lock);
 			vortex_check_media(dev, 0);
-			spin_unlock_bh(&vp->lock);
+			spin_unlock(&vp->lock);
 		}
 		break;
 	  default:					/* Other media types handled by Tx timeouts. */

-- 

[patch 17/47] SCSI: esp: Fix OOPS in esp_reset_cleanup().

[Greg KH]

[-- Attachment #1: scsi-esp-fix-oops-in-esp_reset_cleanup.patch --]
[-- Type: text/plain, Size: 1961 bytes --]

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

------------------
From: David S. Miller <davem@davemloft.net>

commit eadc49b1a8d09480f14caea292142f103a89c77a upstream

OOPS reported by Friedrich Oslage <bluebird@porno-bullen.de>

The problem here is that tp->starget is set every time a lun
is allocated for a particular target so we can catch the
sdev_target parent value.

The reset handler uses the NULL'ness of this value to determine
which targets are active.

But esp_slave_destroy() does not NULL out this value when appropriate.

So for every target that doesn't respond, the SCSI bus scan causes
a stale pointer to be left here, with ensuing crashes like you're
seeing.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/esp_scsi.c |    8 ++++++++
 drivers/scsi/esp_scsi.h |    1 +
 2 files changed, 9 insertions(+)

--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2364,6 +2364,7 @@ static int esp_slave_alloc(struct scsi_d
 	dev->hostdata = lp;
 
 	tp->starget = dev->sdev_target;
+	tp->starget_ref++;
 
 	spi_min_period(tp->starget) = esp->min_period;
 	spi_max_offset(tp->starget) = 15;
@@ -2412,10 +2413,17 @@ static int esp_slave_configure(struct sc
 
 static void esp_slave_destroy(struct scsi_device *dev)
 {
+	struct esp *esp = shost_priv(dev->host);
+	struct esp_target_data *tp = &esp->target[dev->id];
 	struct esp_lun_data *lp = dev->hostdata;
 
 	kfree(lp);
 	dev->hostdata = NULL;
+
+	BUG_ON(tp->starget_ref <= 0);
+
+	if (!--tp->starget_ref)
+		tp->starget = NULL;
 }
 
 static int esp_eh_abort_handler(struct scsi_cmnd *cmd)
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -322,6 +322,7 @@ struct esp_target_data {
 	u8			nego_goal_tags;
 
 	struct scsi_target	*starget;
+	int			starget_ref;
 };
 
 struct esp_event_ent {

-- 

[patch 18/47] SCSI: esp: tidy up target reference counting

[Greg KH]

[-- Attachment #1: scsi-esp-tidy-up-target-reference-counting.patch --]
[-- Type: text/plain, Size: 2806 bytes --]

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

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

commit ec5e69f6d3f4350681d6f7eaae515cf014be9276 upstream

The esp driver currently does hand rolled reference counting of its
target.  It's much easier to do what it needs to do if it's plugged into
the mid-layer callbacks (target_alloc and target_destroy) which were
designed for this case, so do it this way and get rid of the internal
target reference count.

Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/scsi/esp_scsi.c |   30 ++++++++++++++++++++----------
 drivers/scsi/esp_scsi.h |    1 -
 2 files changed, 20 insertions(+), 11 deletions(-)

--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2352,6 +2352,24 @@ void scsi_esp_unregister(struct esp *esp
 }
 EXPORT_SYMBOL(scsi_esp_unregister);
 
+static int esp_target_alloc(struct scsi_target *starget)
+{
+	struct esp *esp = shost_priv(dev_to_shost(&starget->dev));
+	struct esp_target_data *tp = &esp->target[starget->id];
+
+	tp->starget = starget;
+
+	return 0;
+}
+
+static void esp_target_destroy(struct scsi_target *starget)
+{
+	struct esp *esp = shost_priv(dev_to_shost(&starget->dev));
+	struct esp_target_data *tp = &esp->target[starget->id];
+
+	tp->starget = NULL;
+}
+
 static int esp_slave_alloc(struct scsi_device *dev)
 {
 	struct esp *esp = shost_priv(dev->host);
@@ -2363,9 +2381,6 @@ static int esp_slave_alloc(struct scsi_d
 		return -ENOMEM;
 	dev->hostdata = lp;
 
-	tp->starget = dev->sdev_target;
-	tp->starget_ref++;
-
 	spi_min_period(tp->starget) = esp->min_period;
 	spi_max_offset(tp->starget) = 15;
 
@@ -2413,17 +2428,10 @@ static int esp_slave_configure(struct sc
 
 static void esp_slave_destroy(struct scsi_device *dev)
 {
-	struct esp *esp = shost_priv(dev->host);
-	struct esp_target_data *tp = &esp->target[dev->id];
 	struct esp_lun_data *lp = dev->hostdata;
 
 	kfree(lp);
 	dev->hostdata = NULL;
-
-	BUG_ON(tp->starget_ref <= 0);
-
-	if (!--tp->starget_ref)
-		tp->starget = NULL;
 }
 
 static int esp_eh_abort_handler(struct scsi_cmnd *cmd)
@@ -2603,6 +2611,8 @@ struct scsi_host_template scsi_esp_templ
 	.name			= "esp",
 	.info			= esp_info,
 	.queuecommand		= esp_queuecommand,
+	.target_alloc		= esp_target_alloc,
+	.target_destroy		= esp_target_destroy,
 	.slave_alloc		= esp_slave_alloc,
 	.slave_configure	= esp_slave_configure,
 	.slave_destroy		= esp_slave_destroy,
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -322,7 +322,6 @@ struct esp_target_data {
 	u8			nego_goal_tags;
 
 	struct scsi_target	*starget;
-	int			starget_ref;
 };
 
 struct esp_event_ent {

-- 

[patch 19/47] SCSI: ses: Fix timeout

[Greg KH]

[-- Attachment #1: scsi-ses-fix-timeout.patch --]
[-- Type: text/plain, Size: 786 bytes --]

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

------------------
From: Matthew Wilcox <matthew@wil.cx>

commit c95e62ce8905aab62fed224eaaa9b8558a0ef652 upstream

Timeouts are measured in jiffies, not in seconds.

Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/scsi/ses.c
+++ b/drivers/scsi/ses.c
@@ -61,7 +61,7 @@ static int ses_probe(struct device *dev)
 	return err;
 }
 
-#define SES_TIMEOUT 30
+#define SES_TIMEOUT (30 * HZ)
 #define SES_RETRIES 3
 
 static int ses_recv_diag(struct scsi_device *sdev, int page_code,

-- 

[patch 20/47] mm: switch node meminfo Active & Inactive pages to Kbytes

[Greg KH]

[-- Attachment #1: mm-switch-node-meminfo-active-inactive-pages-to-kbytes.patch --]
[-- Type: text/plain, Size: 1207 bytes --]

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

------------------
From: John Blackwood <john.blackwood@ccur.com>

commit 2d5c1be8870383622809c25935fff00d2630c7a5 upstream

There is a bug in the output of /sys/devices/system/node/node[n]/meminfo
where the Active and Inactive values are in pages instead of Kbytes.

Looks like this occurred back in 2.6.20 when the code was changed
over to use node_page_state().

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

---
 drivers/base/node.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -70,8 +70,8 @@ static ssize_t node_read_meminfo(struct 
 		       nid, K(i.totalram),
 		       nid, K(i.freeram),
 		       nid, K(i.totalram - i.freeram),
-		       nid, node_page_state(nid, NR_ACTIVE),
-		       nid, node_page_state(nid, NR_INACTIVE),
+		       nid, K(node_page_state(nid, NR_ACTIVE)),
+		       nid, K(node_page_state(nid, NR_INACTIVE)),
 #ifdef CONFIG_HIGHMEM
 		       nid, K(i.totalhigh),
 		       nid, K(i.freehigh),

-- 

[patch 21/47] reiserfs: discard prealloc in reiserfs_delete_inode

[Greg KH]

[-- Attachment #1: reiserfs-discard-prealloc-in-reiserfs_delete_inode.patch --]
[-- Type: text/plain, Size: 1094 bytes --]

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

------------------
From: Jeff Mahoney <jeffm@suse.com>

commit eb35c218d83ec0780d9db869310f2e333f628702 upstream

With the removal of struct file from the xattr code,
reiserfs_file_release() isn't used anymore, so the prealloc isn't
discarded.  This causes hangs later down the line.

This patch adds it to reiserfs_delete_inode.  In most cases it will be a
no-op due to it already having been called, but will avoid hangs with
xattrs.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/reiserfs/inode.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -45,6 +45,8 @@ void reiserfs_delete_inode(struct inode 
 			goto out;
 		reiserfs_update_inode_transaction(inode);
 
+		reiserfs_discard_prealloc(&th, inode);
+
 		err = reiserfs_delete_object(&th, inode);
 
 		/* Do quota update inside a transaction for journaled quotas. We must do that

-- 

[patch 22/47] cciss: read config to obtain max outstanding commands per controller

[Greg KH]

[-- Attachment #1: cciss-read-config-to-obtain-max-outstanding-commands-per-controller.patch --]
[-- Type: text/plain, Size: 5898 bytes --]

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

------------------
From: Mike Miller <mike.miller@hp.com>

commit 491539982aa01fa71de93c2a06ac5d890d4cf1e2 upstream

This patch changes the way we determine the maximum number of outstanding
commands for each controller.

Most Smart Array controllers can support up to 1024 commands, the notable
exceptions are the E200 and E200i.

The next generation of controllers which were just added support a mode of
operation called Zero Memory Raid (ZMR).  In this mode they only support
64 outstanding commands.  In Full Function Raid (FFR) mode they support
1024.

We have been setting the queue depth by arbitrarily assigning some value
for each controller.  We needed a better way to set the queue depth to
avoid lots of annoying "fifo full" messages.  So we made the driver a
little smarter.  We now read the config table and subtract 4 from the
returned value.  The -4 is to allow some room for ioctl calls which are
not tracked the same way as io commands are tracked.

Please consider this for inclusion.

Signed-off-by: Mike Miller <mike.miller@hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/block/cciss.c |   66 ++++++++++++++++++++++++++++----------------------
 1 file changed, 37 insertions(+), 29 deletions(-)

--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -106,35 +106,34 @@ MODULE_DEVICE_TABLE(pci, cciss_pci_devic
 /*  board_id = Subsystem Device ID & Vendor ID
  *  product = Marketing Name for the board
  *  access = Address of the struct of function pointers
- *  nr_cmds = Number of commands supported by controller
  */
 static struct board_type products[] = {
-	{0x40700E11, "Smart Array 5300", &SA5_access, 512},
-	{0x40800E11, "Smart Array 5i", &SA5B_access, 512},
-	{0x40820E11, "Smart Array 532", &SA5B_access, 512},
-	{0x40830E11, "Smart Array 5312", &SA5B_access, 512},
-	{0x409A0E11, "Smart Array 641", &SA5_access, 512},
-	{0x409B0E11, "Smart Array 642", &SA5_access, 512},
-	{0x409C0E11, "Smart Array 6400", &SA5_access, 512},
-	{0x409D0E11, "Smart Array 6400 EM", &SA5_access, 512},
-	{0x40910E11, "Smart Array 6i", &SA5_access, 512},
-	{0x3225103C, "Smart Array P600", &SA5_access, 512},
-	{0x3223103C, "Smart Array P800", &SA5_access, 512},
-	{0x3234103C, "Smart Array P400", &SA5_access, 512},
-	{0x3235103C, "Smart Array P400i", &SA5_access, 512},
-	{0x3211103C, "Smart Array E200i", &SA5_access, 120},
-	{0x3212103C, "Smart Array E200", &SA5_access, 120},
-	{0x3213103C, "Smart Array E200i", &SA5_access, 120},
-	{0x3214103C, "Smart Array E200i", &SA5_access, 120},
-	{0x3215103C, "Smart Array E200i", &SA5_access, 120},
-	{0x3237103C, "Smart Array E500", &SA5_access, 512},
-	{0x323D103C, "Smart Array P700m", &SA5_access, 512},
-	{0x3241103C, "Smart Array P212", &SA5_access, 384},
-	{0x3243103C, "Smart Array P410", &SA5_access, 384},
-	{0x3245103C, "Smart Array P410i", &SA5_access, 384},
-	{0x3247103C, "Smart Array P411", &SA5_access, 384},
-	{0x3249103C, "Smart Array P812", &SA5_access, 384},
-	{0xFFFF103C, "Unknown Smart Array", &SA5_access, 120},
+	{0x40700E11, "Smart Array 5300", &SA5_access},
+	{0x40800E11, "Smart Array 5i", &SA5B_access},
+	{0x40820E11, "Smart Array 532", &SA5B_access},
+	{0x40830E11, "Smart Array 5312", &SA5B_access},
+	{0x409A0E11, "Smart Array 641", &SA5_access},
+	{0x409B0E11, "Smart Array 642", &SA5_access},
+	{0x409C0E11, "Smart Array 6400", &SA5_access},
+	{0x409D0E11, "Smart Array 6400 EM", &SA5_access},
+	{0x40910E11, "Smart Array 6i", &SA5_access},
+	{0x3225103C, "Smart Array P600", &SA5_access},
+	{0x3223103C, "Smart Array P800", &SA5_access},
+	{0x3234103C, "Smart Array P400", &SA5_access},
+	{0x3235103C, "Smart Array P400i", &SA5_access},
+	{0x3211103C, "Smart Array E200i", &SA5_access},
+	{0x3212103C, "Smart Array E200", &SA5_access},
+	{0x3213103C, "Smart Array E200i", &SA5_access},
+	{0x3214103C, "Smart Array E200i", &SA5_access},
+	{0x3215103C, "Smart Array E200i", &SA5_access},
+	{0x3237103C, "Smart Array E500", &SA5_access},
+	{0x323D103C, "Smart Array P700m", &SA5_access},
+	{0x3241103C, "Smart Array P212", &SA5_access},
+	{0x3243103C, "Smart Array P410", &SA5_access},
+	{0x3245103C, "Smart Array P410i", &SA5_access},
+	{0x3247103C, "Smart Array P411", &SA5_access},
+	{0x3249103C, "Smart Array P812", &SA5_access},
+	{0xFFFF103C, "Unknown Smart Array", &SA5_access},
 };
 
 /* How long to wait (in milliseconds) for board to go into simple mode */
@@ -3082,11 +3081,20 @@ static int __devinit cciss_pci_init(ctlr
 	print_cfg_table(c->cfgtable);
 #endif				/* CCISS_DEBUG */
 
+	/* Some controllers support Zero Memory Raid (ZMR).
+	 * When configured in ZMR mode the number of supported
+	 * commands drops to 64. So instead of just setting an
+	 * arbitrary value we make the driver a little smarter.
+	 * We read the config table to tell us how many commands
+	 * are supported on the controller then subtract 4 to
+	 * leave a little room for ioctl calls.
+	 */
+	c->max_commands = readl(&(c->cfgtable->CmdsOutMax));
 	for (i = 0; i < ARRAY_SIZE(products); i++) {
 		if (board_id == products[i].board_id) {
 			c->product_name = products[i].product_name;
 			c->access = *(products[i].access);
-			c->nr_cmds = products[i].nr_cmds;
+			c->nr_cmds = c->max_commands - 4;
 			break;
 		}
 	}
@@ -3106,7 +3114,7 @@ static int __devinit cciss_pci_init(ctlr
 		if (subsystem_vendor_id == PCI_VENDOR_ID_HP) {
 			c->product_name = products[i-1].product_name;
 			c->access = *(products[i-1].access);
-			c->nr_cmds = products[i-1].nr_cmds;
+			c->nr_cmds = c->max_commands - 4;
 			printk(KERN_WARNING "cciss: This is an unknown "
 				"Smart Array controller.\n"
 				"cciss: Please update to the latest driver "

-- 

[patch 23/47] serial: fix serial_match_port() for dynamic major tty-device numbers

[Greg KH]

[-- Attachment #1: serial-fix-serial_match_port-for-dynamic-major-tty-device-numbers.patch --]
[-- Type: text/plain, Size: 1438 bytes --]

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

------------------
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>

commit 7ca796f492a11f9408e661c8f22cd8c4f486b8e5 upstream

As reported by Vipul Gandhi, the current serial_match_port() doesn't work
for tty-devices using dynamic major number allocation.  Fix it.

It oopses if you suspend a serial port with _dynamic_ major number.  ATM,
I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that
does it in-tree.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Vipul Gandhi <vcgandhi1@aol.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

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

--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1950,7 +1950,9 @@ struct uart_match {
 static int serial_match_port(struct device *dev, void *data)
 {
 	struct uart_match *match = data;
-	dev_t devt = MKDEV(match->driver->major, match->driver->minor) + match->port->line;
+	struct tty_driver *tty_drv = match->driver->tty_driver;
+	dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
+		match->port->line;
 
 	return dev->devt == devt; /* Actually, only one tty per port */
 }

-- 

[patch 24/47] can: add sanity checks

[Greg KH]

[-- Attachment #1: can-add-sanity-checks.patch --]
[-- Type: text/plain, Size: 4352 bytes --]

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

------------------
From: Oliver Hartkopp <oliver@hartkopp.net>

commit 7f2d38eb7a42bea1c1df51bbdaa2ca0f0bdda07f upstream

Even though the CAN netlayer only deals with CAN netdevices, the
netlayer interface to the userspace and to the device layer should
perform some sanity checks.

This patch adds several sanity checks that mainly prevent userspace apps
to send broken content into the system that may be misinterpreted by
some other userspace application.

Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
Acked-by: Andre Naujoks <nautsch@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 net/can/af_can.c |   10 ++++++++++
 net/can/bcm.c    |   23 +++++++++++++++++++----
 net/can/raw.c    |    3 +++
 3 files changed, 32 insertions(+), 4 deletions(-)

--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -205,12 +205,19 @@ static int can_create(struct net *net, s
  *  -ENOBUFS on full driver queue (see net_xmit_errno())
  *  -ENOMEM when local loopback failed at calling skb_clone()
  *  -EPERM when trying to send on a non-CAN interface
+ *  -EINVAL when the skb->data does not contain a valid CAN frame
  */
 int can_send(struct sk_buff *skb, int loop)
 {
 	struct sk_buff *newskb = NULL;
+	struct can_frame *cf = (struct can_frame *)skb->data;
 	int err;
 
+	if (skb->len != sizeof(struct can_frame) || cf->can_dlc > 8) {
+		kfree_skb(skb);
+		return -EINVAL;
+	}
+
 	if (skb->dev->type != ARPHRD_CAN) {
 		kfree_skb(skb);
 		return -EPERM;
@@ -605,6 +612,7 @@ static int can_rcv(struct sk_buff *skb, 
 		   struct packet_type *pt, struct net_device *orig_dev)
 {
 	struct dev_rcv_lists *d;
+	struct can_frame *cf = (struct can_frame *)skb->data;
 	int matches;
 
 	if (dev->type != ARPHRD_CAN || dev->nd_net != &init_net) {
@@ -612,6 +620,8 @@ static int can_rcv(struct sk_buff *skb, 
 		return 0;
 	}
 
+	BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
+
 	/* update statistics */
 	can_stats.rx_frames++;
 	can_stats.rx_frames_delta++;
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -326,7 +326,7 @@ static void bcm_send_to_user(struct bcm_
 
 	if (head->nframes) {
 		/* can_frames starting here */
-		firstframe = (struct can_frame *) skb_tail_pointer(skb);
+		firstframe = (struct can_frame *)skb_tail_pointer(skb);
 
 		memcpy(skb_put(skb, datalen), frames, datalen);
 
@@ -818,6 +818,10 @@ static int bcm_tx_setup(struct bcm_msg_h
 		for (i = 0; i < msg_head->nframes; i++) {
 			err = memcpy_fromiovec((u8 *)&op->frames[i],
 					       msg->msg_iov, CFSIZ);
+
+			if (op->frames[i].can_dlc > 8)
+				err = -EINVAL;
+
 			if (err < 0)
 				return err;
 
@@ -850,6 +854,10 @@ static int bcm_tx_setup(struct bcm_msg_h
 		for (i = 0; i < msg_head->nframes; i++) {
 			err = memcpy_fromiovec((u8 *)&op->frames[i],
 					       msg->msg_iov, CFSIZ);
+
+			if (op->frames[i].can_dlc > 8)
+				err = -EINVAL;
+
 			if (err < 0) {
 				if (op->frames != &op->sframe)
 					kfree(op->frames);
@@ -1161,9 +1169,12 @@ static int bcm_tx_send(struct msghdr *ms
 
 	skb->dev = dev;
 	skb->sk  = sk;
-	can_send(skb, 1); /* send with loopback */
+	err = can_send(skb, 1); /* send with loopback */
 	dev_put(dev);
 
+	if (err)
+		return err;
+
 	return CFSIZ + MHSIZ;
 }
 
@@ -1182,6 +1193,10 @@ static int bcm_sendmsg(struct kiocb *ioc
 	if (!bo->bound)
 		return -ENOTCONN;
 
+	/* check for valid message length from userspace */
+	if (size < MHSIZ || (size - MHSIZ) % CFSIZ)
+		return -EINVAL;
+
 	/* check for alternative ifindex for this bcm_op */
 
 	if (!ifindex && msg->msg_name) {
@@ -1256,8 +1271,8 @@ static int bcm_sendmsg(struct kiocb *ioc
 		break;
 
 	case TX_SEND:
-		/* we need at least one can_frame */
-		if (msg_head.nframes < 1)
+		/* we need exactly one can_frame behind the msg head */
+		if ((msg_head.nframes != 1) || (size != CFSIZ + MHSIZ))
 			ret = -EINVAL;
 		else
 			ret = bcm_tx_send(msg, ifindex, sk);
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -632,6 +632,9 @@ static int raw_sendmsg(struct kiocb *ioc
 	} else
 		ifindex = ro->ifindex;
 
+	if (size != sizeof(struct can_frame))
+		return -EINVAL;
+
 	dev = dev_get_by_index(&init_net, ifindex);
 	if (!dev)
 		return -ENXIO;

-- 

[patch 25/47] sisusbvga: Fix oops on disconnect.

[Greg KH]

[-- Attachment #1: sisusbvga-fix-oops-on-disconnect.patch --]
[-- Type: text/plain, Size: 1046 bytes --]

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

------------------
From: Will Newton <will.newton@gmail.com>

commit f15e39739a1d7dfaa2173a91707a74c11a246648 upstream

Remove dev_info call on disconnect. The sisusb_dev pointer may have been
set to zero by sisusb_delete at this point causing an oops.

The message does not provide any extra information over the standard USB
subsystem output so removing it does not affect functionality.

Signed-off-by: Will Newton <will.newton@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/usb/misc/sisusbvga/sisusb.c |    2 --
 1 file changed, 2 deletions(-)

--- a/drivers/usb/misc/sisusbvga/sisusb.c
+++ b/drivers/usb/misc/sisusbvga/sisusb.c
@@ -3264,8 +3264,6 @@ static void sisusb_disconnect(struct usb
 
 	/* decrement our usage count */
 	kref_put(&sisusb->kref, sisusb_delete);
-
-	dev_info(&sisusb->sisusb_dev->dev, "Disconnected\n");
 }
 
 static struct usb_device_id sisusb_table [] = {

-- 

[patch 26/47] md: ensure all blocks are uptodate or locked when syncing

[Greg KH]

[-- Attachment #1: md-ensure-all-blocks-are-uptodate-or-locked-when-syncing.patch --]
[-- Type: text/plain, Size: 1305 bytes --]

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

------------------
From: Dan Williams <dan.j.williams@intel.com>

commit 7a1fc53c5adb910751a9b212af90302eb4ffb527 upstream

Remove the dubious attempt to prefer 'compute' over 'read'.  Not only is it
wrong given commit c337869d (md: do not compute parity unless it is on a failed
drive), but it can trigger a BUG_ON in handle_parity_checks5().

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/md/raid5.c |    7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1999,12 +1999,7 @@ static int __handle_issuing_new_read_req
 			 */
 			s->uptodate++;
 			return 0; /* uptodate + compute == disks */
-		} else if ((s->uptodate < disks - 1) &&
-			test_bit(R5_Insync, &dev->flags)) {
-			/* Note: we hold off compute operations while checks are
-			 * in flight, but we still prefer 'compute' over 'read'
-			 * hence we only read if (uptodate < * disks-1)
-			 */
+		} else if (test_bit(R5_Insync, &dev->flags)) {
 			set_bit(R5_LOCKED, &dev->flags);
 			set_bit(R5_Wantread, &dev->flags);
 			if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))

-- 

[patch 27/47] textsearch: fix Boyer-Moore text search bug

[Greg KH]

[-- Attachment #1: textsearch-fix-boyer-moore-text-search-bug.patch --]
[-- Type: text/plain, Size: 1050 bytes --]

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

------------------
From: Joonwoo Park <joonwpark81@gmail.com>

Upstream commit aebb6a849cfe7d89bcacaaecc20a480dfc1180e7

The current logic has a bug which cannot find matching pattern, if the
pattern is matched from the first character of target string.
for example:
	pattern=abc, string=abcdefg
	pattern=a,   string=abcdefg
Searching algorithm should return 0 for those things.

Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 lib/ts_bm.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/lib/ts_bm.c
+++ b/lib/ts_bm.c
@@ -63,7 +63,7 @@ static unsigned int bm_find(struct ts_co
 	struct ts_bm *bm = ts_config_priv(conf);
 	unsigned int i, text_len, consumed = state->offset;
 	const u8 *text;
-	int shift = bm->patlen, bs;
+	int shift = bm->patlen - 1, bs;
 
 	for (;;) {
 		text_len = conf->get_next_block(consumed, &text, conf, state);

-- 

[patch 28/47] netfilter: nf_conntrack_tcp: fixing to check the lower bound of valid ACK

[Greg KH]

[-- Attachment #1: netfilter-nf_conntrack_tcp-fixing-to-check-the-lower-bound-of-valid-ack.patch --]
[-- Type: text/plain, Size: 3010 bytes --]

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

------------------
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

Upstream commit 84ebe1c:

Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on
the netfilter mailing list (see the thread "Weird nat/conntrack Problem
with PASV FTP upload"). He provided tcpdump recordings which helped to
find a long lingering bug in conntrack.

In TCP connection tracking, checking the lower bound of valid ACK could
lead to mark valid packets as INVALID because:

 - We have got a "higher or equal" inequality, but the test checked
   the "higher" condition only; fixed.
 - If the packet contains a SACK option, it could occur that the ACK
   value was before the left edge of our (S)ACK "window": if a previous
   packet from the other party intersected the right edge of the window
   of the receiver, we could move forward the window parameters beyond
   accepting a valid ack. Therefore in this patch we check the rightmost
   SACK edge instead of the ACK value in the lower bound of valid (S)ACK
   test.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

---
 net/netfilter/nf_conntrack_proto_tcp.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -332,12 +332,13 @@ static unsigned int get_conntrack_index(
 
    I.   Upper bound for valid data:	seq <= sender.td_maxend
    II.  Lower bound for valid data:	seq + len >= sender.td_end - receiver.td_maxwin
-   III.	Upper bound for valid ack:      sack <= receiver.td_end
-   IV.	Lower bound for valid ack:	ack >= receiver.td_end - MAXACKWINDOW
+   III.	Upper bound for valid (s)ack:   sack <= receiver.td_end
+   IV.	Lower bound for valid (s)ack:	sack >= receiver.td_end - MAXACKWINDOW
 
-   where sack is the highest right edge of sack block found in the packet.
+   where sack is the highest right edge of sack block found in the packet
+   or ack in the case of packet without SACK option.
 
-   The upper bound limit for a valid ack is not ignored -
+   The upper bound limit for a valid (s)ack is not ignored -
    we doesn't have to deal with fragments.
 */
 
@@ -607,12 +608,12 @@ static int tcp_in_window(const struct nf
 		 before(seq, sender->td_maxend + 1),
 		 after(end, sender->td_end - receiver->td_maxwin - 1),
 		 before(sack, receiver->td_end + 1),
-		 after(ack, receiver->td_end - MAXACKWINDOW(sender)));
+		 after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1));
 
 	if (before(seq, sender->td_maxend + 1) &&
 	    after(end, sender->td_end - receiver->td_maxwin - 1) &&
 	    before(sack, receiver->td_end + 1) &&
-	    after(ack, receiver->td_end - MAXACKWINDOW(sender))) {
+	    after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1)) {
 		/*
 		 * Take into account window scaling (RFC 1323).
 		 */

-- 

[patch 29/47] zd1211rw: add ID for AirTies WUS-201

[Greg KH]

[-- Attachment #1: zd1211rw-add-id-for-airties-wus-201.patch --]
[-- Type: text/plain, Size: 1250 bytes --]

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

------------------
From: Firat Birlik <firat@airties.com>

Commit 9dfd55008e3863dcd93219c74bf05b09e5c549e2 upstream

I would like to inform you of our zd1211 based usb wifi adapter (AirTies
WUS-201), which works with the zd1211rw driver with the following device
id definition.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Peter Nixon <listuser@peternixon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/net/wireless/zd1211rw/zd_usb.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -64,6 +64,7 @@ static struct usb_device_id usb_ids[] = 
 	{ USB_DEVICE(0x079b, 0x0062), .driver_info = DEVICE_ZD1211B },
 	{ USB_DEVICE(0x1582, 0x6003), .driver_info = DEVICE_ZD1211B },
 	{ USB_DEVICE(0x050d, 0x705c), .driver_info = DEVICE_ZD1211B },
+	{ USB_DEVICE(0x083a, 0xe506), .driver_info = DEVICE_ZD1211B },
 	{ USB_DEVICE(0x083a, 0x4505), .driver_info = DEVICE_ZD1211B },
 	{ USB_DEVICE(0x0471, 0x1236), .driver_info = DEVICE_ZD1211B },
 	{ USB_DEVICE(0x13b1, 0x0024), .driver_info = DEVICE_ZD1211B },

-- 

[patch 30/47] exec: fix stack excutability without PT_GNU_STACK

[Greg KH]

[-- Attachment #1: exec-fix-stack-excutability-without-pt_gnu_stack.patch --]
[-- Type: text/plain, Size: 1395 bytes --]

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

------------------
From: Hugh Dickins <hugh@veritas.com>

commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream

Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.

Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup.  Checking through
our existing VM_flags, none would have changed since insert_vm_struct:
so this seems safer than finding a way through the personality labyrinth.

Reported-by: pageexec@freemail.hu
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 fs/exec.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/exec.c
+++ b/fs/exec.c
@@ -605,7 +605,7 @@ int setup_arg_pages(struct linux_binprm 
 	bprm->exec -= stack_shift;
 
 	down_write(&mm->mmap_sem);
-	vm_flags = vma->vm_flags;
+	vm_flags = VM_STACK_FLAGS;
 
 	/*
 	 * Adjust stack execute permissions; explicitly enable for

-- 

[patch 31/47] slub: Fix use-after-preempt of per-CPU data structure

[Greg KH]

[-- Attachment #1: slub-fix-use-after-preempt-of-per-cpu-data-structure.patch --]
[-- Type: text/plain, Size: 2881 bytes --]

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

------------------
From: Dmitry Adamushko <dmitry.adamushko@gmail.com>

commit bdb21928512a860a60e6a24a849dc5b63cbaf96a upstream

Vegard Nossum reported a crash in kmem_cache_alloc():

	BUG: unable to handle kernel paging request at da87d000
	IP: [<c01991c7>] kmem_cache_alloc+0xc7/0xe0
	*pde = 28180163 *pte = 1a87d160
	Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
	Pid: 3850, comm: grep Not tainted (2.6.26-rc9-00059-gb190333 #5)
	EIP: 0060:[<c01991c7>] EFLAGS: 00210203 CPU: 0
	EIP is at kmem_cache_alloc+0xc7/0xe0
	EAX: 00000000 EBX: da87c100 ECX: 1adad71a EDX: 6b6b6b6b
	ESI: 00200282 EDI: da87d000 EBP: f60bfe74 ESP: f60bfe54
	DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

and analyzed it:

  "The register %ecx looks innocent but is very important here. The disassembly:

       mov    %edx,%ecx
       shr    $0x2,%ecx
       rep stos %eax,%es:(%edi) <-- the fault

   So %ecx has been loaded from %edx... which is 0x6b6b6b6b/POISON_FREE.
   (0x6b6b6b6b >> 2 == 0x1adadada.)

   %ecx is the counter for the memset, from here:

       memset(object, 0, c->objsize);

  i.e. %ecx was loaded from c->objsize, so "c" must have been freed.
  Where did "c" come from? Uh-oh...

       c = get_cpu_slab(s, smp_processor_id());

  This looks like it has very much to do with CPU hotplug/unplug. Is
  there a race between SLUB/hotplug since the CPU slab is used after it
  has been freed?"

Good analysis.

Yeah, it's possible that a caller of kmem_cache_alloc() -> slab_alloc()
can be migrated on another CPU right after local_irq_restore() and
before memset().  The inital cpu can become offline in the mean time (or
a migration is a consequence of the CPU going offline) so its
'kmem_cache_cpu' structure gets freed ( slab_cpuup_callback).

At some point of time the caller continues on another CPU having an
obsolete pointer...

Signed-off-by: Dmitry Adamushko <dmitry.adamushko@gmail.com>
Reported-by: Vegard Nossum <vegard.nossum@gmail.com>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 mm/slub.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1575,9 +1575,11 @@ static __always_inline void *slab_alloc(
 	void **object;
 	struct kmem_cache_cpu *c;
 	unsigned long flags;
+	unsigned int objsize;
 
 	local_irq_save(flags);
 	c = get_cpu_slab(s, smp_processor_id());
+	objsize = c->objsize;
 	if (unlikely(!c->freelist || !node_match(c, node)))
 
 		object = __slab_alloc(s, gfpflags, node, addr, c);
@@ -1590,7 +1592,7 @@ static __always_inline void *slab_alloc(
 	local_irq_restore(flags);
 
 	if (unlikely((gfpflags & __GFP_ZERO) && object))
-		memset(object, 0, c->objsize);
+		memset(object, 0, objsize);
 
 	return object;
 }

-- 

[patch 32/47] rtc: fix reported IRQ rate for when HPET is enabled

[Greg KH]

[-- Attachment #1: rtc-fix-reported-irq-rate-for-when-hpet-is-enabled.patch --]
[-- Type: text/plain, Size: 1397 bytes --]

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

------------------
From: Paul Gortmaker <paul.gortmaker@windriver.com>

commit 61ca9daa2ca3022dc9cb22bd98e69c1b61e412ad upstream

The IRQ rate reported back by the RTC is incorrect when HPET is enabled.

Newer hardware that has HPET to emulate the legacy RTC device gets this value
wrong since after it sets the rate, it returns before setting the variable
used to report the IRQ rate back to users of the device -- so the set rate and
the reported rate get out of sync.

Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: David Brownell <david-b@pacbell.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/rtc.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/char/rtc.c
+++ b/drivers/char/rtc.c
@@ -677,12 +677,13 @@ static int rtc_do_ioctl(unsigned int cmd
 		if (arg != (1<<tmp))
 			return -EINVAL;
 
+		rtc_freq = arg;
+
 		spin_lock_irqsave(&rtc_lock, flags);
 		if (hpet_set_periodic_freq(arg)) {
 			spin_unlock_irqrestore(&rtc_lock, flags);
 			return 0;
 		}
-		rtc_freq = arg;
 
 		val = CMOS_READ(RTC_FREQ_SELECT) & 0xf0;
 		val |= (16 - tmp);

-- 

[patch 33/47] rapidio: fix device reference counting

[Greg KH]

[-- Attachment #1: rapidio-fix-device-reference-counting.patch --]
[-- Type: text/plain, Size: 855 bytes --]

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

------------------
From: Eugene Surovegin <ebs@ebshome.net>

commit a7de3902edce099e4102c1272ec0ab569c1791f7 upstream

Fix RapidIO device reference counting.

Signed-of-by: Eugene Surovegin <ebs@ebshome.net>
Cc: Matt Porter <mporter@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/rapidio/rio-driver.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/rapidio/rio-driver.c
+++ b/drivers/rapidio/rio-driver.c
@@ -101,8 +101,8 @@ static int rio_device_probe(struct devic
 		if (error >= 0) {
 			rdev->driver = rdrv;
 			error = 0;
+		} else
 			rio_dev_put(rdev);
-		}
 	}
 	return error;
 }

-- 

[patch 34/47] tpm: add Intel TPM TIS device HID

[Greg KH]

[-- Attachment #1: tpm-add-intel-tpm-tis-device-hid.patch --]
[-- Type: text/plain, Size: 1021 bytes --]

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

------------------
From: Marcin Obara <marcin_obara@users.sourceforge.net>

commit fb0e7e11d017beb5f0b1fa25bc51e49e65c46d67 upstream

This patch adds Intel TPM TIS device HID:  ICO0102

Signed-off-by: Marcin Obara <marcin_obara@users.sourceforge.net>
Acked-by: Marcel Selhorst <tpm@selhorst.net>
Acked-by: Rajiv Andrade <srajiv@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/tpm/tpm_tis.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -623,6 +623,7 @@ static struct pnp_device_id tpm_pnp_tbl[
 	{"IFX0102", 0},		/* Infineon */
 	{"BCM0101", 0},		/* Broadcom */
 	{"NSC1200", 0},		/* National */
+	{"ICO0102", 0},		/* Intel */
 	/* Add new here */
 	{"", 0},		/* User Specified */
 	{"", 0}			/* Terminator */

-- 

[patch 35/47] cifs: fix wksidarr declaration to be big-endian friendly

[Greg KH]

[-- Attachment #1: cifs-fix-wksidarr-declaration-to-be-big-endian-friendly.patch --]
[-- Type: text/plain, Size: 2126 bytes --]

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

------------------
From: Jeff Layton <jlayton@redhat.com>

commit 536abdb0802f3fac1b217530741853843d63c281 upstream

The current definition of wksidarr works fine on little endian arches
(since cpu_to_le32 is a no-op there), but on big-endian arches, it fails
to compile with this error:

error: braced-group within expression allowed only inside a function

The problem is that this static declaration has cpu_to_le32 embedded
within it, and that expands into a function macro.  We need to use
__constant_cpu_to_le32() instead.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Steven French <sfrench@us.ibm.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>

---
 fs/cifs/cifsacl.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/fs/cifs/cifsacl.c
+++ b/fs/cifs/cifsacl.c
@@ -34,11 +34,11 @@
 static struct cifs_wksid wksidarr[NUM_WK_SIDS] = {
 	{{1, 0, {0, 0, 0, 0, 0, 0}, {0, 0, 0, 0, 0} }, "null user"},
 	{{1, 1, {0, 0, 0, 0, 0, 1}, {0, 0, 0, 0, 0} }, "nobody"},
-	{{1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(11), 0, 0, 0, 0} }, "net-users"},
-	{{1, 1, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(18), 0, 0, 0, 0} }, "sys"},
-	{{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(544), 0, 0, 0} }, "root"},
-	{{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(545), 0, 0, 0} }, "users"},
-	{{1, 2, {0, 0, 0, 0, 0, 5}, {cpu_to_le32(32), cpu_to_le32(546), 0, 0, 0} }, "guest"} }
+	{{1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(11), 0, 0, 0, 0} }, "net-users"},
+	{{1, 1, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(18), 0, 0, 0, 0} }, "sys"},
+	{{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(544), 0, 0, 0} }, "root"},
+	{{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(545), 0, 0, 0} }, "users"},
+	{{1, 2, {0, 0, 0, 0, 0, 5}, {__constant_cpu_to_le32(32), __constant_cpu_to_le32(546), 0, 0, 0} }, "guest"} }
 ;
 
 

-- 

[patch 36/47] ov7670: clean up ov7670_read semantics

[Greg KH]

[-- Attachment #1: ov7670-clean-up-ov7670_read-semantics.patch --]
[-- Type: text/plain, Size: 1448 bytes --]

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

------------------
From: Andres Salomon <dilinger@queued.net>

commit bca5c2c550f16d2dc2d21ffb7b4712bd0a7d32a9 upstream

Cortland Setlow pointed out a bug in ov7670.c where the result from
ov7670_read() was just being checked for !0, rather than <0.  This made me
realize that ov7670_read's semantics were rather confusing; it both fills
in 'value' with the result, and returns it.  This is goes against general
kernel convention; so rather than fixing callers, let's fix the function.

This makes ov7670_read return <0 in the case of an error, and 0 upon
success. Thus, code like:

res = ov7670_read(...);
if (!res)
	goto error;

.will work properly.

Signed-off-by: Cortland Setlow <csetlow@tower-research.com>
Signed-off-by: Andres Salomon <dilinger@debian.org>
Acked-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/video/ov7670.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -406,8 +406,10 @@ static int ov7670_read(struct i2c_client
 	int ret;
 
 	ret = i2c_smbus_read_byte_data(c, reg);
-	if (ret >= 0)
+	if (ret >= 0) {
 		*value = (unsigned char) ret;
+		ret = 0;
+	}
 	return ret;
 }
 

-- 

[patch 37/47] serial8250: sanity check nr_uarts on all paths.

[Greg KH]

[-- Attachment #1: serial8250-sanity-check-nr_uarts-on-all-paths.patch --]
[-- Type: text/plain, Size: 1157 bytes --]

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

------------------
From: Eric W. Biederman <ebiederm@xmission.com>

commit 05d81d2222beec7b63ac8c1c8cdb5bb4f82c2bad upstream

I had 8250.nr_uarts=16 in the boot line of a test kernel and I had a weird
mysterious crash in sysfs.  After taking an in-depth look I realized that
CONFIG_SERIAL_8250_NR_UARTS was set to 4 and I was walking off the end of
the serial8250_ports array.

Ouch!!!

Don't let this happen to someone else.

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

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

--- a/drivers/serial/8250.c
+++ b/drivers/serial/8250.c
@@ -2564,6 +2564,9 @@ static struct console serial8250_console
 
 static int __init serial8250_console_init(void)
 {
+	if (nr_uarts > UART_NR)
+		nr_uarts = UART_NR;
+
 	serial8250_isa_init_ports();
 	register_console(&serial8250_console);
 	return 0;

-- 

[patch 38/47] fbdev: bugfix for multiprocess defio

[Greg KH]

[-- Attachment #1: fbdev-bugfix-for-multiprocess-defio.patch --]
[-- Type: text/plain, Size: 2441 bytes --]

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

------------------
From: Jaya Kumar <jayakumar.lkml@gmail.com>

commit f31ad92f34913043cf008d6e479e92dfbaf02df1 upstream

This patch is a bugfix for how defio handles multiple processes manipulating
the same framebuffer.

Thanks to Bernard Blackham for identifying this bug.

It occurs when two applications mmap the same framebuffer and concurrently
write to the same page.  Normally, this doesn't occur since only a single
process mmaps the framebuffer.  The symptom of the bug is that the mapping
applications will hang.  The cause is that defio incorrectly tries to add the
same page twice to the pagelist.  The solution I have is to walk the pagelist
and check for a duplicate before adding.  Since I needed to walk the pagelist,
I now also keep the pagelist in sorted order.

Signed-off-by: Jaya Kumar <jayakumar.lkml@gmail.com>
Cc: Bernard Blackham <bernard@largestprime.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/video/fb_defio.c |   20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

--- a/drivers/video/fb_defio.c
+++ b/drivers/video/fb_defio.c
@@ -74,6 +74,7 @@ static int fb_deferred_io_mkwrite(struct
 {
 	struct fb_info *info = vma->vm_private_data;
 	struct fb_deferred_io *fbdefio = info->fbdefio;
+	struct page *cur;
 
 	/* this is a callback we get when userspace first tries to
 	write to the page. we schedule a workqueue. that workqueue
@@ -83,7 +84,24 @@ static int fb_deferred_io_mkwrite(struct
 
 	/* protect against the workqueue changing the page list */
 	mutex_lock(&fbdefio->lock);
-	list_add(&page->lru, &fbdefio->pagelist);
+
+	/* we loop through the pagelist before adding in order
+	to keep the pagelist sorted */
+	list_for_each_entry(cur, &fbdefio->pagelist, lru) {
+		/* this check is to catch the case where a new
+		process could start writing to the same page
+		through a new pte. this new access can cause the
+		mkwrite even when the original ps's pte is marked
+		writable */
+		if (unlikely(cur == page))
+			goto page_already_added;
+		else if (cur->index > page->index)
+			break;
+	}
+
+	list_add_tail(&page->lru, &cur->lru);
+
+page_already_added:
 	mutex_unlock(&fbdefio->lock);
 
 	/* come back after delay to process the deferred IO */

-- 

[patch 39/47] drivers/isdn/i4l/isdn_common.c fix small resource leak

[Greg KH]

[-- Attachment #1: drivers-isdn-i4l-isdn_common.c-fix-small-resource-leak.patch --]
[-- Type: text/plain, Size: 1423 bytes --]

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

------------------
From: Darren Jenkins <darrenrjenkins@gmail.com>

commit 4fc89e3911aa5357b55b85b60c4beaeb8a48a290 upstream

Coverity CID: 1356 RESOURCE_LEAK

I found a very old patch for this that was Acked but did not get applied
https://lists.linux-foundation.org/pipermail/kernel-janitors/2006-September/016362.html

There looks to be a small leak in isdn_writebuf_stub() in isdn_common.c, when
copy_from_user() returns an un-copied data length (length != 0).  The below
patch should be a minimally invasive fix.

Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Acked-by: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/isdn/i4l/isdn_common.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1977,8 +1977,10 @@ isdn_writebuf_stub(int drvidx, int chan,
 	if (!skb)
 		return -ENOMEM;
 	skb_reserve(skb, hl);
-	if (copy_from_user(skb_put(skb, len), buf, len))
+	if (copy_from_user(skb_put(skb, len), buf, len)) {
+		dev_kfree_skb(skb);
 		return -EFAULT;
+	}
 	ret = dev->drv[drvidx]->interface->writebuf_skb(drvidx, chan, 1, skb);
 	if (ret <= 0)
 		dev_kfree_skb(skb);

-- 

[patch 40/47] drivers/char/pcmcia/ipwireless/hardware.c fix resource leak

[Greg KH]

[-- Attachment #1: drivers-char-pcmcia-ipwireless-hardware.c-fix-resource-leak.patch --]
[-- Type: text/plain, Size: 1248 bytes --]

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

------------------
From: Darren Jenkins <darrenrjenkins@gmail.com>

commit 43f77e91eadbc290eb76a08110a039c809dde6c9 upstream

Coverity CID: 2172 RESOURCE_LEAK

When pool_allocate() tries to enlarge a packet, if it can not allocate enough
memory, it returns NULL without first freeing the old packet.

This patch just frees the packet first.

Signed-off-by: Darren Jenkins <darrenrjenkins@gmail.com>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/char/pcmcia/ipwireless/hardware.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

--- a/drivers/char/pcmcia/ipwireless/hardware.c
+++ b/drivers/char/pcmcia/ipwireless/hardware.c
@@ -616,8 +616,10 @@ static struct ipw_rx_packet *pool_alloca
 		packet = kmalloc(sizeof(struct ipw_rx_packet) +
 				old_packet->length + minimum_free_space,
 				GFP_ATOMIC);
-		if (!packet)
+		if (!packet) {
+			kfree(old_packet);
 			return NULL;
+		}
 		memcpy(packet, old_packet,
 				sizeof(struct ipw_rx_packet)
 					+ old_packet->length);

-- 

[patch 41/47] SCSI: mptspi: fix oops in mptspi_dv_renegotiate_work()

[Greg KH]

[-- Attachment #1: scsi-mptspi-fix-oops-in-mptspi_dv_renegotiate_work.patch --]
[-- Type: text/plain, Size: 1451 bytes --]

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

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

commit 081a5bcb39b455405d58f79bb3c9398a9d4477ed upstream

The problem here is that if the ioc faults too early in the bring up
sequence (as it usually does for an irq routing problem), ioc_reset gets
called before the scsi host is even allocated.  This causes an oops when
it later schedules a renegotiation.  Fix this by checking ioc->sh before
trying to renegotiate.

Cc: Eric Moore <Eric.Moore@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/message/fusion/mptspi.c |    9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/message/fusion/mptspi.c
+++ b/drivers/message/fusion/mptspi.c
@@ -1266,13 +1266,18 @@ mptspi_dv_renegotiate(struct _MPT_SCSI_H
 static int
 mptspi_ioc_reset(MPT_ADAPTER *ioc, int reset_phase)
 {
-	struct _MPT_SCSI_HOST *hd = shost_priv(ioc->sh);
 	int rc;
 
 	rc = mptscsih_ioc_reset(ioc, reset_phase);
 
-	if (reset_phase == MPT_IOC_POST_RESET)
+	/* only try to do a renegotiation if we're properly set up
+	 * if we get an ioc fault on bringup, ioc->sh will be NULL */
+	if (reset_phase == MPT_IOC_POST_RESET &&
+	    ioc->sh) {
+		struct _MPT_SCSI_HOST *hd = shost_priv(ioc->sh);
+
 		mptspi_dv_renegotiate(hd);
+	}
 
 	return rc;
 }

-- 

[patch 42/47] crypto: chainiv - Invoke completion function

[Greg KH]

[-- Attachment #1: crypto-chainiv-invoke-completion-function.patch --]
[-- Type: text/plain, Size: 1688 bytes --]

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

------------------
From: Herbert Xu <herbert@gondor.apana.org.au>

Upstream commit: 872ac8743cb400192a9fce4ba2d3ffd7bb309685

When chainiv postpones requests it never calls their completion functions.
This causes symptoms such as memory leaks when IPsec is in use.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 crypto/chainiv.c |   10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

--- a/crypto/chainiv.c
+++ b/crypto/chainiv.c
@@ -117,6 +117,7 @@ static int chainiv_init(struct crypto_tf
 static int async_chainiv_schedule_work(struct async_chainiv_ctx *ctx)
 {
 	int queued;
+	int err = ctx->err;
 
 	if (!ctx->queue.qlen) {
 		smp_mb__before_clear_bit();
@@ -131,7 +132,7 @@ static int async_chainiv_schedule_work(s
 	BUG_ON(!queued);
 
 out:
-	return ctx->err;
+	return err;
 }
 
 static int async_chainiv_postpone_request(struct skcipher_givcrypt_request *req)
@@ -227,6 +228,7 @@ static void async_chainiv_do_postponed(s
 						     postponed);
 	struct skcipher_givcrypt_request *req;
 	struct ablkcipher_request *subreq;
+	int err;
 
 	/* Only handle one request at a time to avoid hogging keventd. */
 	spin_lock_bh(&ctx->lock);
@@ -241,7 +243,11 @@ static void async_chainiv_do_postponed(s
 	subreq = skcipher_givcrypt_reqctx(req);
 	subreq->base.flags |= CRYPTO_TFM_REQ_MAY_SLEEP;
 
-	async_chainiv_givencrypt_tail(req);
+	err = async_chainiv_givencrypt_tail(req);
+
+	local_bh_disable();
+	skcipher_givcrypt_complete(req, err);
+	local_bh_enable();
 }
 
 static int async_chainiv_init(struct crypto_tfm *tfm)

-- 

[patch 43/47] powerpc: Add missing reference to coherent_dma_mask

[Greg KH]

[-- Attachment #1: powerpc-add-missing-reference-to-coherent_dma_mask.patch --]
[-- Type: text/plain, Size: 1064 bytes --]

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

------------------
From: Vitaly Bordug <vitb@kernel.crashing.org>

commit ba0fc709e197415aadd46b9ec208dc4abaa21edd upstream

There is dma_mask in of_device upon of_platform_device_create()
but we don't actually set coherent_dma_mask. This may cause weird
behavior of USB subsystem using of_device USB host drivers.

Signed-off-by: Vitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 arch/powerpc/kernel/of_platform.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -76,6 +76,8 @@ struct of_device* of_platform_device_cre
 		return NULL;
 
 	dev->dma_mask = 0xffffffffUL;
+	dev->dev.coherent_dma_mask = DMA_32BIT_MASK;
+
 	dev->dev.bus = &of_platform_bus_type;
 
 	/* We do not fill the DMA ops for platform devices by default.

-- 

[patch 44/47] pxamci: fix byte aligned DMA transfers

[Greg KH]

[-- Attachment #1: pxamci-fix-byte-aligned-dma-transfers.patch --]
[-- Type: text/plain, Size: 2125 bytes --]

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

------------------
From: Philipp Zabel <philipp.zabel@gmail.com>

commit 97f8571e663c808ad2d01a396627235167291556 upstream

The pxa27x DMA controller defaults to 64-bit alignment. This caused
the SCR reads to fail (and, depending on card type, error out) when
card->raw_scr was not aligned on a 8-byte boundary.

For performance reasons all scatter-gather addresses passed to
pxamci_request should be aligned on 8-byte boundaries, but if
this can't be guaranteed, byte aligned DMA transfers in the
have to be enabled in the controller to get correct behaviour.

Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/mmc/host/pxamci.c |   13 +++++++++++++
 1 file changed, 13 insertions(+)

--- a/drivers/mmc/host/pxamci.c
+++ b/drivers/mmc/host/pxamci.c
@@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxa
 	unsigned int nob = data->blocks;
 	unsigned long long clks;
 	unsigned int timeout;
+	bool dalgn = 0;
 	u32 dcmd;
 	int i;
 
@@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxa
 		host->sg_cpu[i].dcmd = dcmd | length;
 		if (length & 31 && !(data->flags & MMC_DATA_READ))
 			host->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;
+		/* Not aligned to 8-byte boundary? */
+		if (sg_dma_address(&data->sg[i]) & 0x7)
+			dalgn = 1;
 		if (data->flags & MMC_DATA_READ) {
 			host->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;
 			host->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);
@@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxa
 	host->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;
 	wmb();
 
+	/*
+	 * The PXA27x DMA controller encounters overhead when working with
+	 * unaligned (to 8-byte boundaries) data, so switch on byte alignment
+	 * mode only if we have unaligned data.
+	 */
+	if (dalgn)
+		DALGN |= (1 << host->dma);
+	else
+		DALGN &= (1 << host->dma);
 	DDADR(host->dma) = host->sg_dma;
 	DCSR(host->dma) = DCSR_RUN;
 }

-- 

Re: [patch 44/47] pxamci: fix byte aligned DMA transfers

[pHilipp Zabel]

Hi,

On Wed, Jul 23, 2008 at 1:17 AM, Greg KH <gregkh@suse.de> wrote:
> 2.6.25-stable review patch.  If anyone has any objections, please let us
> know.

There is an ugly typo in the patch below that was fixed by Karl Beldan:
http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commit;h=28bbe535df5c461c25eb57affb30e007072429c3

Not sure how you handle this, maybe this patch should only go in
together with the other.

> ------------------
> From: Philipp Zabel <philipp.zabel@gmail.com>
>
> commit 97f8571e663c808ad2d01a396627235167291556 upstream
>
> The pxa27x DMA controller defaults to 64-bit alignment. This caused
> the SCR reads to fail (and, depending on card type, error out) when
> card->raw_scr was not aligned on a 8-byte boundary.
>
> For performance reasons all scatter-gather addresses passed to
> pxamci_request should be aligned on 8-byte boundaries, but if
> this can't be guaranteed, byte aligned DMA transfers in the
> have to be enabled in the controller to get correct behaviour.
>
> Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
> Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
>
> ---
>  drivers/mmc/host/pxamci.c |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> --- a/drivers/mmc/host/pxamci.c
> +++ b/drivers/mmc/host/pxamci.c
> @@ -114,6 +114,7 @@ static void pxamci_setup_data(struct pxa
>        unsigned int nob = data->blocks;
>        unsigned long long clks;
>        unsigned int timeout;
> +       bool dalgn = 0;
>        u32 dcmd;
>        int i;
>
> @@ -152,6 +153,9 @@ static void pxamci_setup_data(struct pxa
>                host->sg_cpu[i].dcmd = dcmd | length;
>                if (length & 31 && !(data->flags & MMC_DATA_READ))
>                        host->sg_cpu[i].dcmd |= DCMD_ENDIRQEN;
> +               /* Not aligned to 8-byte boundary? */
> +               if (sg_dma_address(&data->sg[i]) & 0x7)
> +                       dalgn = 1;
>                if (data->flags & MMC_DATA_READ) {
>                        host->sg_cpu[i].dsadr = host->res->start + MMC_RXFIFO;
>                        host->sg_cpu[i].dtadr = sg_dma_address(&data->sg[i]);
> @@ -165,6 +169,15 @@ static void pxamci_setup_data(struct pxa
>        host->sg_cpu[host->dma_len - 1].ddadr = DDADR_STOP;
>        wmb();
>
> +       /*
> +        * The PXA27x DMA controller encounters overhead when working with
> +        * unaligned (to 8-byte boundaries) data, so switch on byte alignment
> +        * mode only if we have unaligned data.
> +        */
> +       if (dalgn)
> +               DALGN |= (1 << host->dma);
> +       else
> +               DALGN &= (1 << host->dma);
                         ^^^^^ here

>        DDADR(host->dma) = host->sg_dma;
>        DCSR(host->dma) = DCSR_RUN;
>  }
>
> --
>

regards
Philipp

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Greg KH]

On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
> Hi,
> 
> On Wed, Jul 23, 2008 at 1:17 AM, Greg KH <gregkh@suse.de> wrote:
> > 2.6.25-stable review patch.  If anyone has any objections, please let us
> > know.
> 
> There is an ugly typo in the patch below that was fixed by Karl Beldan:
> http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commit;h=28bbe535df5c461c25eb57affb30e007072429c3
> 
> Not sure how you handle this, maybe this patch should only go in
> together with the other.

As the above mentioned patch isn't in Linus's tree yet, I can't take it.

Care to send it to stable@kernel.org when it does go in?  Or is this
current patch just broken without it and not worth adding at all?

thanks,

greg k-h

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Linus Torvalds]

On Wed, 23 Jul 2008, Greg KH wrote:

> On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
> > 
> > There is an ugly typo in the patch below that was fixed by Karl Beldan:
> > http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commit;h=28bbe535df5c461c25eb57affb30e007072429c3
> > 
> > Not sure how you handle this, maybe this patch should only go in
> > together with the other.
> 
> As the above mentioned patch isn't in Linus's tree yet, I can't take it.
> 
> Care to send it to stable@kernel.org when it does go in?  Or is this
> current patch just broken without it and not worth adding at all?

Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c 
upstream. I don't know why it has a different SHA1 in the mmc tree, but I 
assume that it's because the MMC tree has rebased at some point. Ugh.

		Linus

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Greg KH]

On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
> 
> 
> On Wed, 23 Jul 2008, Greg KH wrote:
> 
> > On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
> > > 
> > > There is an ugly typo in the patch below that was fixed by Karl Beldan:
> > > http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commit;h=28bbe535df5c461c25eb57affb30e007072429c3
> > > 
> > > Not sure how you handle this, maybe this patch should only go in
> > > together with the other.
> > 
> > As the above mentioned patch isn't in Linus's tree yet, I can't take it.
> > 
> > Care to send it to stable@kernel.org when it does go in?  Or is this
> > current patch just broken without it and not worth adding at all?
> 
> Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c 
> upstream. I don't know why it has a different SHA1 in the mmc tree, but I 
> assume that it's because the MMC tree has rebased at some point. Ugh.

Ah, thanks, I missed that.

Hm, that is added post 2.6.26, so I'll add this fixup patch to the
.25-stable tree, and also add this one to the .26-stable queue.

Philipp, is that correct, or does this original one also need to get
added to the .26-stable queue as well?

thanks,

greg k-h

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[pHilipp Zabel]

On Wed, Jul 23, 2008 at 10:32 PM, Greg KH <greg@kroah.com> wrote:
> On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
>>
>>
>> On Wed, 23 Jul 2008, Greg KH wrote:
>>
>> > On Wed, Jul 23, 2008 at 09:01:34AM +0200, pHilipp Zabel wrote:
>> > >
>> > > There is an ugly typo in the patch below that was fixed by Karl Beldan:
>> > > http://git.kernel.org/?p=linux/kernel/git/drzeus/mmc.git;a=commit;h=28bbe535df5c461c25eb57affb30e007072429c3
>> > >
>> > > Not sure how you handle this, maybe this patch should only go in
>> > > together with the other.
>> >
>> > As the above mentioned patch isn't in Linus's tree yet, I can't take it.
>> >
>> > Care to send it to stable@kernel.org when it does go in?  Or is this
>> > current patch just broken without it and not worth adding at all?
>>
>> Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
>> upstream. I don't know why it has a different SHA1 in the mmc tree, but I
>> assume that it's because the MMC tree has rebased at some point. Ugh.

Thank you, I think when I wrote my mail it wasn't pulled yet.

> Ah, thanks, I missed that.
>
> Hm, that is added post 2.6.26, so I'll add this fixup patch to the
> .25-stable tree, and also add this one to the .26-stable queue.

Ok, thank you.

> Philipp, is that correct, or does this original one also need to get
> added to the .26-stable queue as well?

AFAICT, the original one (97f8571e663c808ad2d01a396627235167291556) is
post-26, too.

Both should be applied together. Although it is unlikely that with the
broken patch MMC accesses will accidentally clear the DALGN bits of
other running (unaligned) DMA chains (I'm not aware of any drivers
using unaligned DMA), the PXA27x developer manual says that this "must
not" be done. If it would result in memory corruption or lockups, I
don't know.

regards
Philipp

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Greg KH]

On Thu, Jul 24, 2008 at 12:33:34PM +0200, pHilipp Zabel wrote:
> Both should be applied together. Although it is unlikely that with the
> broken patch MMC accesses will accidentally clear the DALGN bits of
> other running (unaligned) DMA chains (I'm not aware of any drivers
> using unaligned DMA), the PXA27x developer manual says that this "must
> not" be done. If it would result in memory corruption or lockups, I
> don't know.

Ok, I'll add them both to the .26 queue as well.

thanks for the information,

greg k-h

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Linus Torvalds]

On Thu, 24 Jul 2008, pHilipp Zabel wrote:
> > On Wed, Jul 23, 2008 at 01:24:12PM -0700, Linus Torvalds wrote:
> >>
> >> Hmm. I think it's commit 4fe16897c59882420d66f2d503106653d026ed6c
> >> upstream. I don't know why it has a different SHA1 in the mmc tree, but I
> >> assume that it's because the MMC tree has rebased at some point. Ugh.
> 
> Thank you, I think when I wrote my mail it wasn't pulled yet.

Pulling doesn't change the SHA1 ID of a commit, so _if_ it had been stable 
in the -mmc tree, it would have had the same commit in the kernel too. 
That's very much a design issue in git: the same commit always has the 
same ID. _ALWAYS_.

So the fact that the ID changed implies that something odd happened in the 
-mmc tree. Most likely a rebase. And again, this implies that somebody 
rebased already-public commits, since otherwise nobody would have ever 
even seen the original SHA1 ID. 

Which is not good behaviour, _exactly_ because it makes it much harder for 
people to work together - suddenly a commit that got reported (for 
whatever reason: bug-report or 'please backport', it's all the same issue 
in the end) no longer exists.

		Linus

Re: [stable] [patch 44/47] pxamci: fix byte aligned DMA transfers

[Pierre Ossman]

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

On Thu, 24 Jul 2008 12:22:56 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> 
> Pulling doesn't change the SHA1 ID of a commit, so _if_ it had been stable 
> in the -mmc tree, it would have had the same commit in the kernel too. 
> That's very much a design issue in git: the same commit always has the 
> same ID. _ALWAYS_.
> 
> So the fact that the ID changed implies that something odd happened in the 
> -mmc tree. Most likely a rebase. And again, this implies that somebody 
> rebased already-public commits, since otherwise nobody would have ever 
> even seen the original SHA1 ID. 

Indeed I did. Things got shuffled around a bit when I updated the
patch queue with more stuff and the old attempt hadn't gotten merged
yet.

> 
> Which is not good behaviour, _exactly_ because it makes it much harder for 
> people to work together - suddenly a commit that got reported (for 
> whatever reason: bug-report or 'please backport', it's all the same issue 
> in the end) no longer exists.

I've always considered my "for-linus" branch to be primarily that, but I
guess I can be more careful so that other people can use it as well.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[patch 45/47] mmc: dont use DMA on newer ENE controllers

[Greg KH]

[-- Attachment #1: mmc-don-t-use-dma-on-newer-ene-controllers.patch --]
[-- Type: text/plain, Size: 1418 bytes --]

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

------------------
From: Pierre Ossman <drzeus@drzeus.cx>

commit bf5b1935d8e42b36a34645788eb261461fe07f2e upstream.

Even the newer ENE controllers have bugs in their DMA engine that make
it too dangerous to use. Disable it until someone has figured out under
which conditions it corrupts data.

This has caused problems at least once, and can be found as bug report
10925 in the kernel bugzilla.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/mmc/host/sdhci.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -109,7 +109,8 @@ static const struct pci_device_id pci_id
 		.subvendor      = PCI_ANY_ID,
 		.subdevice      = PCI_ANY_ID,
 		.driver_data    = SDHCI_QUIRK_SINGLE_POWER_WRITE |
-				  SDHCI_QUIRK_RESET_CMD_DATA_ON_IOS,
+				  SDHCI_QUIRK_RESET_CMD_DATA_ON_IOS |
+				  SDHCI_QUIRK_BROKEN_DMA,
 	},
 
 	{
@@ -118,7 +119,8 @@ static const struct pci_device_id pci_id
 		.subvendor      = PCI_ANY_ID,
 		.subdevice      = PCI_ANY_ID,
 		.driver_data    = SDHCI_QUIRK_SINGLE_POWER_WRITE |
-				  SDHCI_QUIRK_RESET_CMD_DATA_ON_IOS,
+				  SDHCI_QUIRK_RESET_CMD_DATA_ON_IOS |
+				  SDHCI_QUIRK_BROKEN_DMA,
 	},
 
 	{

-- 

[patch 46/47] hrtimer: prevent migration for raising softirq

[Greg KH]

[-- Attachment #1: hrtimer-prevent-migration-for-raising-softirq.patch --]
[-- Type: text/plain, Size: 1462 bytes --]

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

------------------
From: Steven Rostedt <rostedt@goodmis.org>

commit ee3ece830f6db9837f7ac67008f532a8c1e755f4 upstream.

Due to a possible deadlock, the waking of the softirq was pushed outside
of the hrtimer base locks. See commit 0c96c5979a522c3323c30a078a70120e29b5bdbc

Unfortunately this allows the task to migrate after setting up the softirq
and raising it. Since softirqs run a queue that is per-cpu we may raise the
softirq on the wrong CPU and this will keep the queued softirq task from
running.

To solve this issue, this patch disables preemption around the releasing
of the hrtimer lock and raising of the softirq.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 kernel/hrtimer.c |    8 ++++++++
 1 file changed, 8 insertions(+)

--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -896,10 +896,18 @@ hrtimer_start(struct hrtimer *timer, kti
 	 */
 	raise = timer->state == HRTIMER_STATE_PENDING;
 
+	/*
+	 * We use preempt_disable to prevent this task from migrating after
+	 * setting up the softirq and raising it. Otherwise, if me migrate
+	 * we will raise the softirq on the wrong CPU.
+	 */
+	preempt_disable();
+
 	unlock_hrtimer_base(timer, &flags);
 
 	if (raise)
 		hrtimer_raise_softirq();
+	preempt_enable();
 
 	return ret;
 }

-- 

[patch 47/47] V4L/DVB (7475): Added support for Terratec Cinergy T USB XXS

[Greg KH]

[-- Attachment #1: v4l-dvb-added-support-for-terratec-cinergy-t-usb-xxs.patch --]
[-- Type: text/plain, Size: 2441 bytes --]

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

------------------
From: Alexander Simon <alexander.simon@informatik.tu-muenchen.de>

commit dc88807ed61ed0fc0d57bd80a92508b9de638f5d upstream.


Alexander Simon found out that the Terratec Cinergy T USB XXS is just a
clone of another DiB7070P-based device.

Signed-off-by: Patrick Boettcher <pb@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Cc: Ludwig Nussel <lnussel@novell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

---
 drivers/media/dvb/dvb-usb/dib0700_devices.c |    7 ++++++-
 drivers/media/dvb/dvb-usb/dvb-usb-ids.h     |    3 ++-
 2 files changed, 8 insertions(+), 2 deletions(-)

--- a/drivers/media/dvb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_devices.c
@@ -1062,6 +1062,7 @@ struct usb_device_id dib0700_usb_id_tabl
 /* 30 */{ USB_DEVICE(USB_VID_PINNACLE,	USB_PID_PINNACLE_PCTV73E) },
 	{ USB_DEVICE(USB_VID_YUAN,	USB_PID_YUAN_EC372S) },
 	{ USB_DEVICE(USB_VID_TERRATEC,	USB_PID_TERRATEC_CINERGY_HT_EXPRESS) },
+	{ USB_DEVICE(USB_VID_TERRATEC,	USB_PID_TERRATEC_CINERGY_T_XXS) },
 	{ 0 }		/* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, dib0700_usb_id_table);
@@ -1251,7 +1252,7 @@ struct dvb_usb_device_properties dib0700
 			},
 		},
 
-		.num_device_descs = 8,
+		.num_device_descs = 9,
 		.devices = {
 			{   "DiBcom STK7070P reference design",
 				{ &dib0700_usb_id_table[15], NULL },
@@ -1285,6 +1286,10 @@ struct dvb_usb_device_properties dib0700
 				{ &dib0700_usb_id_table[30], NULL },
 				{ NULL },
 			},
+			{   "Terratec Cinergy T USB XXS",
+				{ &dib0700_usb_id_table[33], NULL },
+				{ NULL },
+			},
 		},
 
 		.rc_interval      = DEFAULT_RC_INTERVAL,
--- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
@@ -137,6 +137,7 @@
 #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY	0x005a
 #define USB_PID_TERRATEC_CINERGY_HT_USB_XE		0x0058
 #define USB_PID_TERRATEC_CINERGY_HT_EXPRESS		0x0060
+#define USB_PID_TERRATEC_CINERGY_T_XXS			0x0078
 #define USB_PID_PINNACLE_EXPRESSCARD_320CX		0x022e
 #define USB_PID_PINNACLE_PCTV2000E			0x022c
 #define USB_PID_PINNACLE_PCTV_DVB_T_FLASH		0x0228
@@ -191,6 +192,6 @@
 #define USB_PID_GIGABYTE_U7000				0x7001
 #define USB_PID_ASUS_U3000				0x171f
 #define USB_PID_ASUS_U3100				0x173f
-#define  USB_PID_YUAN_EC372S				0x1edc
+#define USB_PID_YUAN_EC372S				0x1edc
 
 #endif

-- 

Re: [patch 00/47] 2.6.25-stable review

[Michael Krufky]

Greg KH wrote:
> This is the start of the stable review cycle for the 2.6.25.12 release.
> There are 47 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 July 24, 22:00:00 UTC.  Anything received
> after that time might be too late.
>   
Greg,

Would it be possible to add the seven patches that I sent two days ago? 
It is very important that patch #1 gets into the first dot release, to
avoid confusion with cx18 firmware revisions.  Thanks.

These were sent to stable at kernel dot org:

[2.6.26.y PATCH 1/7] V4L: cx18: Upgrade to newer firmware & update
documentation
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007427.html

[2.6.26.y PATCH 2/7] DVB: dib0700: add support for Hauppauge Nova-TD
Stick 52009
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007429.html

[2.6.26.y PATCH 3/7] V4L: uvcvideo: Fix a buffer overflow in format
descriptor parsing
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007428.html

[2.6.26.y PATCH 4/7] V4L: uvcvideo: Use GFP_NOIO when allocating memory
during resume
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007430.html

[2.6.26.y PATCH 5/7] V4L: uvcvideo: Don't free URB buffers on suspend
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007431.html

[2.6.26.y PATCH 6/7] V4L: uvcvideo: Make input device support optional 
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007432.html

[2.6.26.y PATCH 7/7] V4L: uvcvideo: Add support for Medion Akoya Mini
E1210 integrated webcam
http://linuxtv.org/pipermail/v4l-dvb-maintainer/2008-July/007433.html

Regards,

Mike Krufky

Re: [patch 00/47] 2.6.25-stable review

[Michael Krufky]

Michael Krufky wrote:
> Greg KH wrote:
>   
>> This is the start of the stable review cycle for the 2.6.25.12 release.
> Would it be possible to add the seven patches that I sent two days ago? 
> It is very important that patch #1 gets into the first dot release, to
> avoid confusion with cx18 firmware revisions.  Thanks.

Please disregard that email -- I mistakenly thought this was a 2.6.26.1
review cycle -- my mistake!

I'm sorry for the noise.

-Mike