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 [email protected]
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by 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(-)
2.6.25-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Buesch <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Buesch <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Buesch <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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. */
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Johannes Berg <[email protected]>
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 <[email protected]> for doing the -stable
port.
Cc: Larry Finger <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
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,
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Divyesh Shah <[email protected]>
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 <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <[email protected]>
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 <[email protected]>
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
/*
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <[email protected]>
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 <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Leonid <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
}
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jens Axboe <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Ben Dooks <[email protected]>
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 <[email protected]>
Acked-by: David Brownell <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <[email protected]>
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 [email protected] ...)
Signed-off-by: David Brownell <[email protected]>
Cc: Leonid <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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++;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Stefan Becker <[email protected]>
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 <[email protected]>
Acked-by: David Brownell <[email protected]>
Acked-by: Alan Stern <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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,
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: maximilian attems <[email protected]>
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 <[email protected]>
Cc: Chuck Short <[email protected]>
Cc: Jean Delvare <[email protected]>
Cc: Tim Gardner <[email protected]>
Signed-off-by: maximilian attems <[email protected]>
Cc: Mark M. Hoffman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 }
};
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Buesch <[email protected]>
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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David S. Miller <[email protected]>
commit eadc49b1a8d09480f14caea292142f103a89c77a upstream
OOPS reported by Friedrich Oslage <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 {
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Ingo Molnar <[email protected]>
commit c5643cab7bf663ae049b11be43de8819683176dd upstream
Original Author: Michael Buesch <[email protected]>
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 <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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. */
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: James Bottomley <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 {
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: John Blackwood <[email protected]>
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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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),
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Matthew Wilcox <[email protected]>
commit c95e62ce8905aab62fed224eaaa9b8558a0ef652 upstream
Timeouts are measured in jiffies, not in seconds.
Signed-off-by: Matthew Wilcox <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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,
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jeff Mahoney <[email protected]>
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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Mike Miller <[email protected]>
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 <[email protected]>
Cc: Jens Axboe <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 "
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Guennadi Liakhovetski <[email protected]>
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 <[email protected]>
Tested-by: Vipul Gandhi <[email protected]>
Cc: Alan Cox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Oliver Hartkopp <[email protected]>
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 <[email protected]>
Signed-off-by: Urs Thuermann <[email protected]>
Acked-by: Andre Naujoks <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Will Newton <[email protected]>
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 <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 [] = {
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Joonwoo Park <[email protected]>
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 <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
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);
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Dan Williams <[email protected]>
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 <[email protected]>
Signed-off-by: Neil Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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))
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Firat Birlik <[email protected]>
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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Cc: Peter Nixon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 },
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Dmitry Adamushko <[email protected]>
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 <[email protected]>
Reported-by: Vegard Nossum <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Hugh Dickins <[email protected]>
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: [email protected]
Signed-off-by: Hugh Dickins <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jozsef Kadlecsik <[email protected]>
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 <[email protected]>
Signed-off-by: Patrick McHardy <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
---
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).
*/
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Paul Gortmaker <[email protected]>
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 <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: David Brownell <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Marcin Obara <[email protected]>
commit fb0e7e11d017beb5f0b1fa25bc51e49e65c46d67 upstream
This patch adds Intel TPM TIS device HID: ICO0102
Signed-off-by: Marcin Obara <[email protected]>
Acked-by: Marcel Selhorst <[email protected]>
Acked-by: Rajiv Andrade <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Eugene Surovegin <[email protected]>
commit a7de3902edce099e4102c1272ec0ab569c1791f7 upstream
Fix RapidIO device reference counting.
Signed-of-by: Eugene Surovegin <[email protected]>
Cc: Matt Porter <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jeff Layton <[email protected]>
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 <[email protected]>
Cc: Steven French <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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"} }
;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Andres Salomon <[email protected]>
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 <[email protected]>
Signed-off-by: Andres Salomon <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Eric W. Biederman <[email protected]>
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 <[email protected]>
Acked-by: Alan Cox <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jaya Kumar <[email protected]>
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 <[email protected]>
Cc: Bernard Blackham <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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 */
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Darren Jenkins <[email protected]>
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 <[email protected]>
Acked-by: Karsten Keil <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Darren Jenkins <[email protected]>
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 <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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);
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: James Bottomley <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Herbert Xu <[email protected]>
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 <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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)
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Vitaly Bordug <[email protected]>
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 <[email protected]>
Signed-off-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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.
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Philipp Zabel <[email protected]>
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 <[email protected]>
Signed-off-by: Pierre Ossman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Pierre Ossman <[email protected]>
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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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,
},
{
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Steven Rostedt <[email protected]>
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 <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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;
}
--
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Alexander Simon <[email protected]>
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 <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Cc: Ludwig Nussel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
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
--
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 [email protected]
> to add your name to the list. If you want to be off the reviewer list,
> also email us.
>
> Responses should be made by 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
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
Hi,
On Wed, Jul 23, 2008 at 1:17 AM, Greg KH <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Pierre Ossman <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> 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
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 <[email protected]> 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 [email protected] when it does go in? Or is this
current patch just broken without it and not worth adding at all?
thanks,
greg k-h
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 [email protected] 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
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 [email protected] 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
On Wed, Jul 23, 2008 at 10:32 PM, Greg KH <[email protected]> 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 [email protected] 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
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
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
On Thu, 24 Jul 2008 12:22:56 -0700 (PDT)
Linus Torvalds <[email protected]> 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.