[patch 00/47] 2.6.25-stable review
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]stable@kernel.org[/email]
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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 01/47] b43legacy: Do not return TX_BUSY from op_tx
2.6.25-stable review patch. If anyone has any objections, please let us know.
------------------
From: Michael Buesch <mb@bu3sch.de>
Never return TX_BUSY from op_tx. It doesn't make sense to return
TX_BUSY, if we can not transmit the packet.
Drop the packet and return TX_OK.
Upstream commit is
eb803e419ca6be06ece2e42027bb4ebd8ec09f91
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/b43legacy/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/wireless/b43legacy/main.c
+++ b/drivers/net/wireless/b43legacy/main.c
@@ -2350,8 +2350,10 @@ static int b43legacy_op_tx(struct ieee80
} else
err = b43legacy_dma_tx(dev, skb, ctl);
out:
- if (unlikely(err))
- return NETDEV_TX_BUSY;
+ if (unlikely(err)) {
+ /* Drop the packet. */
+ dev_kfree_skb_any(skb);
+ }
return NETDEV_TX_OK;
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 05/47] block: Fix the starving writes bug in the anticipatory IO scheduler
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Divyesh Shah <dpshah@google.com>
commit d585d0b9d73ed999cc7b8cf3cac4a5b01abb544e upstream
AS scheduler alternates between issuing read and write batches. It does
the batch switch only after all requests from the previous batch are
completed.
When switching to a write batch, if there is an on-going read request,
it waits for its completion and indicates its intention of switching by
setting ad->changed_batch and the new direction but does not update the
batch_expire_time for the new write batch which it does in the case of
no previous pending requests.
On completion of the read request, it sees that we were waiting for the
switch and schedules work for kblockd right away and resets the
ad->changed_data flag.
Now when kblockd enters dispatch_request where it is expected to pick
up a write request, it in turn ends the write batch because the
batch_expire_timer was not updated and shows the expire timestamp for
the previous batch.
This results in the write starvation for all the cases where there is
the intention for switching to a write batch, but there is a previous
in-flight read request and the batch gets reverted to a read_batch
right away.
This also holds true in the reverse case (switching from a write batch
to a read batch with an in-flight write request).
I've checked that this bug exists on 2.6.11, 2.6.18, 2.6.24 and
linux-2.6-block git HEAD. I've tested the fix on x86 platforms with
SCSI drives where the driver asks for the next request while a current
request is in-flight.
This patch is based off linux-2.6-block git HEAD.
Bug reproduction:
A simple scenario which reproduces this bug is:
- dd if=/dev/hda3 of=/dev/null &
- lilo
The lilo takes forever to complete.
This can also be reproduced fairly easily with the earlier dd and
another test
program doing msync().
The example test program below should print out a message after every
iteration
but it simply hangs forever. With this bugfix it makes forward progress.
====
Example test program using msync() (thanks to suleiman AT google DOT
com)
inline uint64_t
rdtsc(void)
{
int64_t tsc;
__asm __volatile("rdtsc" : "=A" (tsc));
return (tsc);
}
int
main(int argc, char **argv)
{
struct stat st;
uint64_t e, s, t;
char *p, q;
long i;
int fd;
if (argc < 2) {
printf("Usage: %s <file>\n", argv[0]);
return (1);
}
if ((fd = open(argv[1], O_RDWR | O_NOATIME)) < 0)
err(1, "open");
if (fstat(fd, &st) < 0)
err(1, "fstat");
p = mmap(NULL, st.st_size, PROT_READ | PROT_WRITE,
MAP_SHARED, fd, 0);
t = 0;
for (i = 0; i < 1000; i++) {
*p = 0;
msync(p, 4096, MS_SYNC);
s = rdtsc();
*p = 0;
__asm __volatile(""::: "memory");
e = rdtsc();
if (argc > 2)
printf("%d: %lld cycles %jd %jd\n",
i, e - s, (intmax_t)s, (intmax_t)e);
t += e - s;
}
printf("average time: %lld cycles\n", t / 1000);
return (0);
}
Acked-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
block/as-iosched.c | 2 ++
1 file changed, 2 insertions(+)
--- a/block/as-iosched.c
+++ b/block/as-iosched.c
@@ -831,6 +831,8 @@ static void as_completed_request(struct
}
if (ad->changed_batch && ad->nr_dispatched == 1) {
+ ad->current_batch_expires = jiffies +
+ ad->batch_expire[ad->batch_data_dir];
kblockd_schedule_work(&ad->antic_work);
ad->changed_batch = 0;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 24/47] can: add sanity checks
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Oliver Hartkopp <oliver@hartkopp.net>
commit 7f2d38eb7a42bea1c1df51bbdaa2ca0f0bdda07f upstream
Even though the CAN netlayer only deals with CAN netdevices, the
netlayer interface to the userspace and to the device layer should
perform some sanity checks.
This patch adds several sanity checks that mainly prevent userspace apps
to send broken content into the system that may be misinterpreted by
some other userspace application.
Signed-off-by: Oliver Hartkopp <oliver.hartkopp@volkswagen.de>
Signed-off-by: Urs Thuermann <urs.thuermann@volkswagen.de>
Acked-by: Andre Naujoks <nautsch@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/can/af_can.c | 10 ++++++++++
net/can/bcm.c | 23 +++++++++++++++++++----
net/can/raw.c | 3 +++
3 files changed, 32 insertions(+), 4 deletions(-)
--- a/net/can/af_can.c
+++ b/net/can/af_can.c
@@ -205,12 +205,19 @@ static int can_create(struct net *net, s
* -ENOBUFS on full driver queue (see net_xmit_errno())
* -ENOMEM when local loopback failed at calling skb_clone()
* -EPERM when trying to send on a non-CAN interface
+ * -EINVAL when the skb->data does not contain a valid CAN frame
*/
int can_send(struct sk_buff *skb, int loop)
{
struct sk_buff *newskb = NULL;
+ struct can_frame *cf = (struct can_frame *)skb->data;
int err;
+ if (skb->len != sizeof(struct can_frame) || cf->can_dlc > 8) {
+ kfree_skb(skb);
+ return -EINVAL;
+ }
+
if (skb->dev->type != ARPHRD_CAN) {
kfree_skb(skb);
return -EPERM;
@@ -605,6 +612,7 @@ static int can_rcv(struct sk_buff *skb,
struct packet_type *pt, struct net_device *orig_dev)
{
struct dev_rcv_lists *d;
+ struct can_frame *cf = (struct can_frame *)skb->data;
int matches;
if (dev->type != ARPHRD_CAN || dev->nd_net != &init_net) {
@@ -612,6 +620,8 @@ static int can_rcv(struct sk_buff *skb,
return 0;
}
+ BUG_ON(skb->len != sizeof(struct can_frame) || cf->can_dlc > 8);
+
/* update statistics */
can_stats.rx_frames++;
can_stats.rx_frames_delta++;
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -326,7 +326,7 @@ static void bcm_send_to_user(struct bcm_
if (head->nframes) {
/* can_frames starting here */
- firstframe = (struct can_frame *) skb_tail_pointer(skb);
+ firstframe = (struct can_frame *)skb_tail_pointer(skb);
memcpy(skb_put(skb, datalen), frames, datalen);
@@ -818,6 +818,10 @@ static int bcm_tx_setup(struct bcm_msg_h
for (i = 0; i < msg_head->nframes; i++) {
err = memcpy_fromiovec((u8 *)&op->frames[i],
msg->msg_iov, CFSIZ);
+
+ if (op->frames[i].can_dlc > 8)
+ err = -EINVAL;
+
if (err < 0)
return err;
@@ -850,6 +854,10 @@ static int bcm_tx_setup(struct bcm_msg_h
for (i = 0; i < msg_head->nframes; i++) {
err = memcpy_fromiovec((u8 *)&op->frames[i],
msg->msg_iov, CFSIZ);
+
+ if (op->frames[i].can_dlc > 8)
+ err = -EINVAL;
+
if (err < 0) {
if (op->frames != &op->sframe)
kfree(op->frames);
@@ -1161,9 +1169,12 @@ static int bcm_tx_send(struct msghdr *ms
skb->dev = dev;
skb->sk = sk;
- can_send(skb, 1); /* send with loopback */
+ err = can_send(skb, 1); /* send with loopback */
dev_put(dev);
+ if (err)
+ return err;
+
return CFSIZ + MHSIZ;
}
@@ -1182,6 +1193,10 @@ static int bcm_sendmsg(struct kiocb *ioc
if (!bo->bound)
return -ENOTCONN;
+ /* check for valid message length from userspace */
+ if (size < MHSIZ || (size - MHSIZ) % CFSIZ)
+ return -EINVAL;
+
/* check for alternative ifindex for this bcm_op */
if (!ifindex && msg->msg_name) {
@@ -1256,8 +1271,8 @@ static int bcm_sendmsg(struct kiocb *ioc
break;
case TX_SEND:
- /* we need at least one can_frame */
- if (msg_head.nframes < 1)
+ /* we need exactly one can_frame behind the msg head */
+ if ((msg_head.nframes != 1) || (size != CFSIZ + MHSIZ))
ret = -EINVAL;
else
ret = bcm_tx_send(msg, ifindex, sk);
--- a/net/can/raw.c
+++ b/net/can/raw.c
@@ -632,6 +632,9 @@ static int raw_sendmsg(struct kiocb *ioc
} else
ifindex = ro->ifindex;
+ if (size != sizeof(struct can_frame))
+ return -EINVAL;
+
dev = dev_get_by_index(&init_net, ifindex);
if (!dev)
return -ENXIO;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 07/47] md: Dont acknowlege that stripe-expand is complete until it really is.
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <neilb@notabene.brown>
commit efe311431869b40d67911820a309f9a1a41306f3 upstream
We shouldn't acknowledge that a stripe has been expanded (When
reshaping a raid5 by adding a device) until the moved data has
actually been written out. However we are currently
acknowledging (by calling md_done_sync) when the POST_XOR
is complete and before the write.
So track in s.locked whether there are pending writes, and don't
call md_done_sync yet if there are.
Note: we all set R5_LOCKED on devices which are are about to
read from. This probably isn't technically necessary, but is
usually done when writing a block, and justifies the use of
s.locked here.
This bug can lead to a crash if an array is stopped while an reshape
is in progress.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/md/raid5.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2861,6 +2861,8 @@ static void handle_stripe5(struct stripe
for (i = conf->raid_disks; i--; ) {
set_bit(R5_Wantwrite, &sh->dev[i].flags);
+ set_bit(R5_LOCKED, &dev->flags);
+ s.locked++;
if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))
sh->ops.count++;
}
@@ -2874,6 +2876,7 @@ static void handle_stripe5(struct stripe
conf->raid_disks);
s.locked += handle_write_operations5(sh, 1, 1);
} else if (s.expanded &&
+ s.locked == 0 &&
!test_bit(STRIPE_OP_POSTXOR, &sh->ops.pending)) {
clear_bit(STRIPE_EXPAND_READY, &sh->state);
atomic_dec(&conf->reshape_stripes);
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 28/47] netfilter: nf_conntrack_tcp: fixing to check the lower bound of valid ACK
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Upstream commit 84ebe1c:
Lost connections was reported by Thomas Bätzler (running 2.6.25 kernel) on
the netfilter mailing list (see the thread "Weird nat/conntrack Problem
with PASV FTP upload"). He provided tcpdump recordings which helped to
find a long lingering bug in conntrack.
In TCP connection tracking, checking the lower bound of valid ACK could
lead to mark valid packets as INVALID because:
- We have got a "higher or equal" inequality, but the test checked
the "higher" condition only; fixed.
- If the packet contains a SACK option, it could occur that the ACK
value was before the left edge of our (S)ACK "window": if a previous
packet from the other party intersected the right edge of the window
of the receiver, we could move forward the window parameters beyond
accepting a valid ack. Therefore in this patch we check the rightmost
SACK edge instead of the ACK value in the lower bound of valid (S)ACK
test.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/netfilter/nf_conntrack_proto_tcp.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/net/netfilter/nf_conntrack_proto_tcp.c
+++ b/net/netfilter/nf_conntrack_proto_tcp.c
@@ -332,12 +332,13 @@ static unsigned int get_conntrack_index(
I. Upper bound for valid data: seq <= sender.td_maxend
II. Lower bound for valid data: seq + len >= sender.td_end - receiver.td_maxwin
- III. Upper bound for valid ack: sack <= receiver.td_end
- IV. Lower bound for valid ack: ack >= receiver.td_end - MAXACKWINDOW
+ III. Upper bound for valid (s)ack: sack <= receiver.td_end
+ IV. Lower bound for valid (s)ack: sack >= receiver.td_end - MAXACKWINDOW
- where sack is the highest right edge of sack block found in the packet.
+ where sack is the highest right edge of sack block found in the packet
+ or ack in the case of packet without SACK option.
- The upper bound limit for a valid ack is not ignored -
+ The upper bound limit for a valid (s)ack is not ignored -
we doesn't have to deal with fragments.
*/
@@ -607,12 +608,12 @@ static int tcp_in_window(const struct nf
before(seq, sender->td_maxend + 1),
after(end, sender->td_end - receiver->td_maxwin - 1),
before(sack, receiver->td_end + 1),
- after(ack, receiver->td_end - MAXACKWINDOW(sender)));
+ after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1));
if (before(seq, sender->td_maxend + 1) &&
after(end, sender->td_end - receiver->td_maxwin - 1) &&
before(sack, receiver->td_end + 1) &&
- after(ack, receiver->td_end - MAXACKWINDOW(sender))) {
+ after(sack, receiver->td_end - MAXACKWINDOW(sender) - 1)) {
/*
* Take into account window scaling (RFC 1323).
*/
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 13/47] USB: fix interrupt disabling for HCDs with shared interrupt handlers
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Stefan Becker <Stefan.Becker@nokia.com>
commit de85422b94ddb23c021126815ea49414047c13dc upstream
As has been discussed several times on LKML, IRQF_SHARED | IRQF_DISABLED
doesn't work reliably, i.e. a shared interrupt handler CAN'T be certain to
be called with interrupts disabled. Most USB HCD handlers use IRQF_DISABLED
and therefore havoc can break out if they share their interrupt with a
handler that doesn't use it.
On my test machine the yenta_socket interrupt handler (no IRQF_DISABLED)
was registered before ehci_hcd and one uhci_hcd instance. Therefore all
usb_hcd_irq() invocations for ehci_hcd and for one uhci_hcd instance
happened with interrupts enabled. That led to random lockups as USB core
HCD functions that acquire the same spinlock could be called twice
from interrupt handlers.
This patch updates usb_hcd_irq() to always disable/restore interrupts.
usb_add_hcd() will silently remove any IRQF_DISABLED requested from HCD code.
Signed-off-by: Stefan Becker <stefan.becker@nokia.com>
Acked-by: David Brownell <david-b@pacbell.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/core/hcd.c | 42 ++++++++++++++++++++++++++++++------------
1 file changed, 30 insertions(+), 12 deletions(-)
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1685,19 +1685,30 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
irqreturn_t usb_hcd_irq (int irq, void *__hcd)
{
struct usb_hcd *hcd = __hcd;
- int start = hcd->state;
+ unsigned long flags;
+ irqreturn_t rc;
- if (unlikely(start == HC_STATE_HALT ||
- !test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags)))
- return IRQ_NONE;
- if (hcd->driver->irq (hcd) == IRQ_NONE)
- return IRQ_NONE;
-
- set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
-
- if (unlikely(hcd->state == HC_STATE_HALT))
- usb_hc_died (hcd);
- return IRQ_HANDLED;
+ /* IRQF_DISABLED doesn't work correctly with shared IRQs
+ * when the first handler doesn't use it. So let's just
+ * assume it's never used.
+ */
+ local_irq_save(flags);
+
+ if (unlikely(hcd->state == HC_STATE_HALT ||
+ !test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))) {
+ rc = IRQ_NONE;
+ } else if (hcd->driver->irq(hcd) == IRQ_NONE) {
+ rc = IRQ_NONE;
+ } else {
+ set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
+
+ if (unlikely(hcd->state == HC_STATE_HALT))
+ usb_hc_died(hcd);
+ rc = IRQ_HANDLED;
+ }
+
+ local_irq_restore(flags);
+ return rc;
}
/*-------------------------------------------------------------------------*/
@@ -1861,6 +1872,13 @@ int usb_add_hcd(struct usb_hcd *hcd,
/* enable irqs just before we start the controller */
if (hcd->driver->irq) {
+
+ /* IRQF_DISABLED doesn't work as advertised when used together
+ * with IRQF_SHARED. As usb_hcd_irq() will always disable
+ * interrupts we can remove it here.
+ */
+ irqflags &= ~IRQF_DISABLED;
+
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
if ((retval = request_irq(irqnum, &usb_hcd_irq, irqflags,
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 10/47] OHCI: Fix problem if SM501 and another platform driver is selected
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Ben Dooks <ben-linux@fluff.org>
commit 3ee38d8bf46b364b1ca364ddb7c379a4afcd8bbb upstream
If the SM501 and another platform driver, such as the SM501
then we end up defining PLATFORM_DRIVER twice. This patch
seperated the SM501 onto a seperate define of SM501_OHCI_DRIVER
so that it can be selected without overwriting the original
definition.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/ohci-hcd.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -1054,7 +1054,7 @@ MODULE_LICENSE ("GPL");
#ifdef CONFIG_MFD_SM501
#include "ohci-sm501.c"
-#define PLATFORM_DRIVER ohci_hcd_sm501_driver
+#define SM501_OHCI_DRIVER ohci_hcd_sm501_driver
#endif
#if !defined(PCI_DRIVER) && \
@@ -1062,6 +1062,7 @@ MODULE_LICENSE ("GPL");
!defined(OF_PLATFORM_DRIVER) && \
!defined(SA1111_DRIVER) && \
!defined(PS3_SYSTEM_BUS_DRIVER) && \
+ !defined(SM501_OHCI_DRIVER) && \
!defined(SSB_OHCI_DRIVER)
#error "missing bus glue for ohci-hcd"
#endif
@@ -1121,9 +1122,18 @@ static int __init ohci_hcd_mod_init(void
goto error_ssb;
#endif
+#ifdef SM501_OHCI_DRIVER
+ retval = platform_driver_register(&SM501_OHCI_DRIVER);
+ if (retval < 0)
+ goto error_sm501;
+#endif
+
return retval;
/* Error path */
+#ifdef SM501_OHCI_DRIVER
+ error_sm501:
+#endif
#ifdef SSB_OHCI_DRIVER
error_ssb:
#endif
@@ -1159,6 +1169,9 @@ module_init(ohci_hcd_mod_init);
static void __exit ohci_hcd_mod_exit(void)
{
+#ifdef SM501_OHCI_DRIVER
+ platform_driver_unregister(&SM501_OHCI_DRIVER);
+#endif
#ifdef SSB_OHCI_DRIVER
ssb_driver_unregister(&SSB_OHCI_DRIVER);
#endif
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 23/47] serial: fix serial_match_port() for dynamic major tty-device numbers
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
commit 7ca796f492a11f9408e661c8f22cd8c4f486b8e5 upstream
As reported by Vipul Gandhi, the current serial_match_port() doesn't work
for tty-devices using dynamic major number allocation. Fix it.
It oopses if you suspend a serial port with _dynamic_ major number. ATM,
I think, there's only the drivers/serial/jsm/jsm_driver.c driver, that
does it in-tree.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Tested-by: Vipul Gandhi <vcgandhi1@aol.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/serial/serial_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1950,7 +1950,9 @@ struct uart_match {
static int serial_match_port(struct device *dev, void *data)
{
struct uart_match *match = data;
- dev_t devt = MKDEV(match->driver->major, match->driver->minor) + match->port->line;
+ struct tty_driver *tty_drv = match->driver->tty_driver;
+ dev_t devt = MKDEV(tty_drv->major, tty_drv->minor_start) +
+ match->port->line;
return dev->devt == devt; /* Actually, only one tty per port */
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 26/47] md: ensure all blocks are uptodate or locked when syncing
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Dan Williams <dan.j.williams@intel.com>
commit 7a1fc53c5adb910751a9b212af90302eb4ffb527 upstream
Remove the dubious attempt to prefer 'compute' over 'read'. Not only is it
wrong given commit c337869d (md: do not compute parity unless it is on a failed
drive), but it can trigger a BUG_ON in handle_parity_checks5().
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/md/raid5.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -1999,12 +1999,7 @@ static int __handle_issuing_new_read_req
*/
s->uptodate++;
return 0; /* uptodate + compute == disks */
- } else if ((s->uptodate < disks - 1) &&
- test_bit(R5_Insync, &dev->flags)) {
- /* Note: we hold off compute operations while checks are
- * in flight, but we still prefer 'compute' over 'read'
- * hence we only read if (uptodate < * disks-1)
- */
+ } else if (test_bit(R5_Insync, &dev->flags)) {
set_bit(R5_LOCKED, &dev->flags);
set_bit(R5_Wantread, &dev->flags);
if (!test_and_set_bit(STRIPE_OP_IO, &sh->ops.pending))
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 15/47] b43legacy: Fix possible NULL pointer dereference in DMA code
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Michael Buesch <mb@bu3sch.de>
commit 2f9ec47d0954f9d2e5a00209c2689cbc477a8c89 upstream
This fixes a possible NULL pointer dereference in an error path of the
DMA allocation error checking code. This is also necessary for a future
DMA API change that is on its way into the mainline kernel that adds
an additional dev parameter to dma_mapping_error().
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/b43legacy/dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/wireless/b43legacy/dma.c
+++ b/drivers/net/wireless/b43legacy/dma.c
@@ -876,6 +876,7 @@ struct b43legacy_dmaring *b43legacy_setu
if (!ring)
goto out;
ring->type = type;
+ ring->dev = dev;
nr_slots = B43legacy_RXRING_SLOTS;
if (for_tx)
@@ -922,7 +923,6 @@ struct b43legacy_dmaring *b43legacy_setu
DMA_TO_DEVICE);
}
- ring->dev = dev;
ring->nr_slots = nr_slots;
ring->mmio_base = b43legacy_dmacontroller_base(type, controller_index);
ring->index = controller_index;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 06/47] md: Fix error paths if md_probe fails.
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <neilb@notabene.brown>
commit 9bbbca3a0ee09293108b67835c6bdf6196d7bcb3 upstream
md_probe can fail (e.g. alloc_disk could fail) without
returning an error (as it alway returns NULL).
So when we call mddev_find immediately afterwards, we need
to check that md_probe actually succeeded. This means checking
that mdev->gendisk is non-NULL.
Cc: Dave Jones <davej@redhat.com>
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/md/md.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -3804,8 +3804,10 @@ static void autorun_devices(int part)
md_probe(dev, NULL, NULL);
mddev = mddev_find(dev);
- if (!mddev) {
- printk(KERN_ERR
+ if (!mddev || !mddev->gendisk) {
+ if (mddev)
+ mddev_put(mddev);
+ printk(KERN_ERR
"md: cannot allocate memory for md drive.\n");
break;
}
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 21/47] reiserfs: discard prealloc in reiserfs_delete_inode
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Jeff Mahoney <jeffm@suse.com>
commit eb35c218d83ec0780d9db869310f2e333f628702 upstream
With the removal of struct file from the xattr code,
reiserfs_file_release() isn't used anymore, so the prealloc isn't
discarded. This causes hangs later down the line.
This patch adds it to reiserfs_delete_inode. In most cases it will be a
no-op due to it already having been called, but will avoid hangs with
xattrs.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/reiserfs/inode.c | 2 ++
1 file changed, 2 insertions(+)
--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -45,6 +45,8 @@ void reiserfs_delete_inode(struct inode
goto out;
reiserfs_update_inode_transaction(inode);
+ reiserfs_discard_prealloc(&th, inode);
+
err = reiserfs_delete_object(&th, inode);
/* Do quota update inside a transaction for journaled quotas. We must do that
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 30/47] exec: fix stack excutability without PT_GNU_STACK
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Hugh Dickins <hugh@veritas.com>
commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream
Kernel Bugzilla #11063 points out that on some architectures (e.g. x86_32)
exec'ing an ELF without a PT_GNU_STACK program header should default to an
executable stack; but this got broken by the unlimited argv feature because
stack vma is now created before the right personality has been established:
so breaking old binaries using nested function trampolines.
Therefore re-evaluate VM_STACK_FLAGS in setup_arg_pages, where stack
vm_flags used to be set, before the mprotect_fixup. Checking through
our existing VM_flags, none would have changed since insert_vm_struct:
so this seems safer than finding a way through the personality labyrinth.
Reported-by: [email]pageexec@freemail.hu[/email]
Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/exec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -605,7 +605,7 @@ int setup_arg_pages(struct linux_binprm
bprm->exec -= stack_shift;
down_write(&mm->mmap_sem);
- vm_flags = vma->vm_flags;
+ vm_flags = VM_STACK_FLAGS;
/*
* Adjust stack execute permissions; explicitly enable for
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 14/47] hdaps: add support for various newer Lenovo thinkpads
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: maximilian attems <max@stro.at>
commit 292d73551d0aa19526c3417e791c529b49ebadf3 upstream
Adds R61, T61p, X61s, X61, Z61m, Z61p models to whitelist.
Fixes this:
cullen@lenny:~$ sudo modprobe hdaps
FATAL: Error inserting hdaps (/lib/modules/2.6.22-10-generic/kernel/drivers/hwmon/hdaps.ko): No such device
[25192.888000] hdaps: supported laptop not found!
[25192.888000] hdaps: driver init failed (ret=-19)!
Originally based on an Ubuntu patch that got it wrong, the dmidecode
output of the corresponding laptops shows LENOVO as the manufacturer.
[url]https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/133636[/url]
tested on X61s:
[ 184.893588] hdaps: inverting axis readings.
[ 184.893588] hdaps: LENOVO ThinkPad X61s detected.
[ 184.893588] input: hdaps as /class/input/input12
[ 184.924326] hdaps: driver successfully loaded.
Cc: Klaus S. Madsen <ubuntu@hjernemadsen.org>
Cc: Chuck Short <zulcss@ubuntu.com>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: maximilian attems <max@stro.at>
Cc: Mark M. Hoffman <mhoffman@lightlink.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/hwmon/hdaps.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/hwmon/hdaps.c
+++ b/drivers/hwmon/hdaps.c
@@ -515,16 +515,24 @@ static struct dmi_system_id __initdata h
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R50"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R51"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad R52"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad R61i"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad R61"),
HDAPS_DMI_MATCH_INVERT("IBM", "ThinkPad T41p"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T41"),
HDAPS_DMI_MATCH_INVERT("IBM", "ThinkPad T42p"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T42"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad T43"),
HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T60"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T61p"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad T61"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad X40"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad X41"),
HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X60"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X61s"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad X61"),
HDAPS_DMI_MATCH_NORMAL("IBM", "ThinkPad Z60m"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad Z61m"),
+ HDAPS_DMI_MATCH_INVERT("LENOVO", "ThinkPad Z61p"),
{ .ident = NULL }
};
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 29/47] zd1211rw: add ID for AirTies WUS-201
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Firat Birlik <firat@airties.com>
Commit 9dfd55008e3863dcd93219c74bf05b09e5c549e2 upstream
I would like to inform you of our zd1211 based usb wifi adapter (AirTies
WUS-201), which works with the zd1211rw driver with the following device
id definition.
Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Peter Nixon <listuser@peternixon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -64,6 +64,7 @@ static struct usb_device_id usb_ids[] =
{ USB_DEVICE(0x079b, 0x0062), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x1582, 0x6003), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x050d, 0x705c), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x083a, 0xe506), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x083a, 0x4505), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0471, 0x1236), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x13b1, 0x0024), .driver_info = DEVICE_ZD1211B },
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 18/47] SCSI: esp: tidy up target reference counting
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: James Bottomley <James.Bottomley@HansenPartnership.com>
commit ec5e69f6d3f4350681d6f7eaae515cf014be9276 upstream
The esp driver currently does hand rolled reference counting of its
target. It's much easier to do what it needs to do if it's plugged into
the mid-layer callbacks (target_alloc and target_destroy) which were
designed for this case, so do it this way and get rid of the internal
target reference count.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/scsi/esp_scsi.c | 30 ++++++++++++++++++++----------
drivers/scsi/esp_scsi.h | 1 -
2 files changed, 20 insertions(+), 11 deletions(-)
--- a/drivers/scsi/esp_scsi.c
+++ b/drivers/scsi/esp_scsi.c
@@ -2352,6 +2352,24 @@ void scsi_esp_unregister(struct esp *esp
}
EXPORT_SYMBOL(scsi_esp_unregister);
+static int esp_target_alloc(struct scsi_target *starget)
+{
+ struct esp *esp = shost_priv(dev_to_shost(&starget->dev));
+ struct esp_target_data *tp = &esp->target[starget->id];
+
+ tp->starget = starget;
+
+ return 0;
+}
+
+static void esp_target_destroy(struct scsi_target *starget)
+{
+ struct esp *esp = shost_priv(dev_to_shost(&starget->dev));
+ struct esp_target_data *tp = &esp->target[starget->id];
+
+ tp->starget = NULL;
+}
+
static int esp_slave_alloc(struct scsi_device *dev)
{
struct esp *esp = shost_priv(dev->host);
@@ -2363,9 +2381,6 @@ static int esp_slave_alloc(struct scsi_d
return -ENOMEM;
dev->hostdata = lp;
- tp->starget = dev->sdev_target;
- tp->starget_ref++;
-
spi_min_period(tp->starget) = esp->min_period;
spi_max_offset(tp->starget) = 15;
@@ -2413,17 +2428,10 @@ static int esp_slave_configure(struct sc
static void esp_slave_destroy(struct scsi_device *dev)
{
- struct esp *esp = shost_priv(dev->host);
- struct esp_target_data *tp = &esp->target[dev->id];
struct esp_lun_data *lp = dev->hostdata;
kfree(lp);
dev->hostdata = NULL;
-
- BUG_ON(tp->starget_ref <= 0);
-
- if (!--tp->starget_ref)
- tp->starget = NULL;
}
static int esp_eh_abort_handler(struct scsi_cmnd *cmd)
@@ -2603,6 +2611,8 @@ struct scsi_host_template scsi_esp_templ
.name = "esp",
.info = esp_info,
.queuecommand = esp_queuecommand,
+ .target_alloc = esp_target_alloc,
+ .target_destroy = esp_target_destroy,
.slave_alloc = esp_slave_alloc,
.slave_configure = esp_slave_configure,
.slave_destroy = esp_slave_destroy,
--- a/drivers/scsi/esp_scsi.h
+++ b/drivers/scsi/esp_scsi.h
@@ -322,7 +322,6 @@ struct esp_target_data {
u8 nego_goal_tags;
struct scsi_target *starget;
- int starget_ref;
};
struct esp_event_ent {
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 22/47] cciss: read config to obtain max outstanding commands per controller
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Mike Miller <mike.miller@hp.com>
commit 491539982aa01fa71de93c2a06ac5d890d4cf1e2 upstream
This patch changes the way we determine the maximum number of outstanding
commands for each controller.
Most Smart Array controllers can support up to 1024 commands, the notable
exceptions are the E200 and E200i.
The next generation of controllers which were just added support a mode of
operation called Zero Memory Raid (ZMR). In this mode they only support
64 outstanding commands. In Full Function Raid (FFR) mode they support
1024.
We have been setting the queue depth by arbitrarily assigning some value
for each controller. We needed a better way to set the queue depth to
avoid lots of annoying "fifo full" messages. So we made the driver a
little smarter. We now read the config table and subtract 4 from the
returned value. The -4 is to allow some room for ioctl calls which are
not tracked the same way as io commands are tracked.
Please consider this for inclusion.
Signed-off-by: Mike Miller <mike.miller@hp.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/block/cciss.c | 66 ++++++++++++++++++++++++++++----------------------
1 file changed, 37 insertions(+), 29 deletions(-)
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -106,35 +106,34 @@ MODULE_DEVICE_TABLE(pci, cciss_pci_devic
/* board_id = Subsystem Device ID & Vendor ID
* product = Marketing Name for the board
* access = Address of the struct of function pointers
- * nr_cmds = Number of commands supported by controller
*/
static struct board_type products[] = {
- {0x40700E11, "Smart Array 5300", &SA5_access, 512},
- {0x40800E11, "Smart Array 5i", &SA5B_access, 512},
- {0x40820E11, "Smart Array 532", &SA5B_access, 512},
- {0x40830E11, "Smart Array 5312", &SA5B_access, 512},
- {0x409A0E11, "Smart Array 641", &SA5_access, 512},
- {0x409B0E11, "Smart Array 642", &SA5_access, 512},
- {0x409C0E11, "Smart Array 6400", &SA5_access, 512},
- {0x409D0E11, "Smart Array 6400 EM", &SA5_access, 512},
- {0x40910E11, "Smart Array 6i", &SA5_access, 512},
- {0x3225103C, "Smart Array P600", &SA5_access, 512},
- {0x3223103C, "Smart Array P800", &SA5_access, 512},
- {0x3234103C, "Smart Array P400", &SA5_access, 512},
- {0x3235103C, "Smart Array P400i", &SA5_access, 512},
- {0x3211103C, "Smart Array E200i", &SA5_access, 120},
- {0x3212103C, "Smart Array E200", &SA5_access, 120},
- {0x3213103C, "Smart Array E200i", &SA5_access, 120},
- {0x3214103C, "Smart Array E200i", &SA5_access, 120},
- {0x3215103C, "Smart Array E200i", &SA5_access, 120},
- {0x3237103C, "Smart Array E500", &SA5_access, 512},
- {0x323D103C, "Smart Array P700m", &SA5_access, 512},
- {0x3241103C, "Smart Array P212", &SA5_access, 384},
- {0x3243103C, "Smart Array P410", &SA5_access, 384},
- {0x3245103C, "Smart Array P410i", &SA5_access, 384},
- {0x3247103C, "Smart Array P411", &SA5_access, 384},
- {0x3249103C, "Smart Array P812", &SA5_access, 384},
- {0xFFFF103C, "Unknown Smart Array", &SA5_access, 120},
+ {0x40700E11, "Smart Array 5300", &SA5_access},
+ {0x40800E11, "Smart Array 5i", &SA5B_access},
+ {0x40820E11, "Smart Array 532", &SA5B_access},
+ {0x40830E11, "Smart Array 5312", &SA5B_access},
+ {0x409A0E11, "Smart Array 641", &SA5_access},
+ {0x409B0E11, "Smart Array 642", &SA5_access},
+ {0x409C0E11, "Smart Array 6400", &SA5_access},
+ {0x409D0E11, "Smart Array 6400 EM", &SA5_access},
+ {0x40910E11, "Smart Array 6i", &SA5_access},
+ {0x3225103C, "Smart Array P600", &SA5_access},
+ {0x3223103C, "Smart Array P800", &SA5_access},
+ {0x3234103C, "Smart Array P400", &SA5_access},
+ {0x3235103C, "Smart Array P400i", &SA5_access},
+ {0x3211103C, "Smart Array E200i", &SA5_access},
+ {0x3212103C, "Smart Array E200", &SA5_access},
+ {0x3213103C, "Smart Array E200i", &SA5_access},
+ {0x3214103C, "Smart Array E200i", &SA5_access},
+ {0x3215103C, "Smart Array E200i", &SA5_access},
+ {0x3237103C, "Smart Array E500", &SA5_access},
+ {0x323D103C, "Smart Array P700m", &SA5_access},
+ {0x3241103C, "Smart Array P212", &SA5_access},
+ {0x3243103C, "Smart Array P410", &SA5_access},
+ {0x3245103C, "Smart Array P410i", &SA5_access},
+ {0x3247103C, "Smart Array P411", &SA5_access},
+ {0x3249103C, "Smart Array P812", &SA5_access},
+ {0xFFFF103C, "Unknown Smart Array", &SA5_access},
};
/* How long to wait (in milliseconds) for board to go into simple mode */
@@ -3082,11 +3081,20 @@ static int __devinit cciss_pci_init(ctlr
print_cfg_table(c->cfgtable);
#endif /* CCISS_DEBUG */
+ /* Some controllers support Zero Memory Raid (ZMR).
+ * When configured in ZMR mode the number of supported
+ * commands drops to 64. So instead of just setting an
+ * arbitrary value we make the driver a little smarter.
+ * We read the config table to tell us how many commands
+ * are supported on the controller then subtract 4 to
+ * leave a little room for ioctl calls.
+ */
+ c->max_commands = readl(&(c->cfgtable->CmdsOutMax));
for (i = 0; i < ARRAY_SIZE(products); i++) {
if (board_id == products[i].board_id) {
c->product_name = products[i].product_name;
c->access = *(products[i].access);
- c->nr_cmds = products[i].nr_cmds;
+ c->nr_cmds = c->max_commands - 4;
break;
}
}
@@ -3106,7 +3114,7 @@ static int __devinit cciss_pci_init(ctlr
if (subsystem_vendor_id == PCI_VENDOR_ID_HP) {
c->product_name = products[i-1].product_name;
c->access = *(products[i-1].access);
- c->nr_cmds = products[i-1].nr_cmds;
+ c->nr_cmds = c->max_commands - 4;
printk(KERN_WARNING "cciss: This is an unknown "
"Smart Array controller.\n"
"cciss: Please update to the latest driver "
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 12/47] USB: ohci - record data toggle after unlink
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: David Brownell <dbrownell@users.sourceforge.net>
commit 29c8f6a727a683b5988877dd80dbdefd49e64a51 upstream
This patch fixes a problem with OHCI where canceling bulk or
interrupt URBs may lose track of the right data toggle. This
seems to be a longstanding bug, possibly dating back to the
Linux 2.4 kernel, which stayed hidden because
(a) about half the time the data toggle bit was correct;
(b) canceling such URBs is unusual; and
(c) the few drivers which cancel these URBs either
[1] do it only as part of shutting down, or
[2] have fault recovery logic, which recovers.
For those transfer types, the toggle is normally written back
into the ED when each TD is retired. But canceling bypasses
the mechanism used to retire TDs ... so on average, half the
time the toggle bit will be invalid after cancelation.
The fix is simple: the toggle state of any canceled TDs are
propagated back to the ED in the finish_unlinks function.
(Issue found by [email]leonidv11@gmail.com[/email] ...)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Leonid <leonidv11@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/usb/host/ohci-q.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -952,6 +952,7 @@ rescan_this:
struct urb *urb;
urb_priv_t *urb_priv;
__hc32 savebits;
+ u32 tdINFO;
td = list_entry (entry, struct td, td_list);
urb = td->urb;
@@ -966,6 +967,17 @@ rescan_this:
savebits = *prev & ~cpu_to_hc32 (ohci, TD_MASK);
*prev = td->hwNextTD | savebits;
+ /* If this was unlinked, the TD may not have been
+ * retired ... so manually save the data toggle.
+ * The controller ignores the value we save for
+ * control and ISO endpoints.
+ */
+ tdINFO = hc32_to_cpup(ohci, &td->hwINFO);
+ if ((tdINFO & TD_T) == TD_T_DATA0)
+ ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_C);
+ else if ((tdINFO & TD_T) == TD_T_DATA1)
+ ed->hwHeadP |= cpu_to_hc32(ohci, ED_C);
+
/* HC may have partly processed this TD */
td_done (ohci, urb, td);
urb_priv->td_cnt++;
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]
[patch 08/47] md: Ensure interrupted recovery completed properly (v1 metadata plus bitmap)
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Neil Brown <neilb@notabene.brown>
commit 8c2e870a625bd336b2e7a65a97c1836acef07322 upstream
If, while assembling an array, we find a device which is not fully
in-sync with the array, it is important to set the "fullsync" flags.
This is an exact analog to the setting of this flag in hot_add_disk
methods.
Currently, only v1.x metadata supports having devices in an array
which are not fully in-sync (it keep track of how in sync they are).
The 'fullsync' flag only makes a difference when a write-intent bitmap
is being used. In this case it tells recovery to ignore the bitmap
and recovery all blocks.
This fix is already in place for raid1, but not raid5/6 or raid10.
So without this fix, a raid1 ir raid4/5/6 array with version 1.x
metadata and a write intent bitmaps, that is stopped in the middle
of a recovery, will appear to complete the recovery instantly
after it is reassembled, but the recovery will not be correct.
If you might have an array like that, issueing
echo repair > /sys/block/mdXX/md/sync_action
will make sure recovery completes properly.
Signed-off-by: Neil Brown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
drivers/md/raid10.c | 2 ++
drivers/md/raid5.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2102,6 +2102,8 @@ static int run(mddev_t *mddev)
!test_bit(In_sync, &disk->rdev->flags)) {
disk->head_position = 0;
mddev->degraded++;
+ if (disk->rdev)
+ conf->fullsync = 1;
}
}
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -4166,7 +4166,9 @@ static int run(mddev_t *mddev)
" disk %d\n", bdevname(rdev->bdev,b),
raid_disk);
working_disks++;
- }
+ } else
+ /* Cannot rely on bitmap to complete recovery */
+ conf->fullsync = 1;
}
/*
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email]majordomo@vger.kernel.org[/email]
More majordomo info at [url]http://vger.kernel.org/majordomo-info.html[/url]
Please read the FAQ at [url]http://www.tux.org/lkml/[/url]