[patch 00/47] 2.6.25-stable review - Kernel

This is a discussion on [patch 00/47] 2.6.25-stable review - Kernel ; 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 ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 54

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

  1. [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 stable@kernel.org
    to add your name to the list. If you want to be off the reviewer list,
    also email us.

    Responses should be made by July 24, 22:00:00 UTC. Anything received
    after that time might be too late.

    The whole patch series can be found in one patch at:
    kernel.org/pub/linux/kernel/v2.6/stable-review/patch-2.6.25.12-rc1.gz
    and the diffstat can be found below.


    thanks,

    the -stable release team

    -----

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

  2. [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

    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
    Signed-off-by: Greg Kroah-Hartman


    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [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

    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 \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
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. [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

    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
    Signed-off-by: Urs Thuermann
    Acked-by: Andre Naujoks
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. [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

    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
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. [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

    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
    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

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

    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
    Acked-by: David Brownell
    Acked-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. [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

    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
    Acked-by: David Brownell
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. [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

    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
    Tested-by: Vipul Gandhi
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. [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

    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
    Signed-off-by: Neil Brown
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. [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

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

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. [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

    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
    Signed-off-by: Neil Brown
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. [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

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

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. [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

    commit 96a8e13ed44e380fc2bb6c711d74d5ba698c00b2 upstream

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

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

    Reported-by: pageexec@freemail.hu
    Signed-off-by: Hugh Dickins
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. [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

    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/+s...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
    Cc: Chuck Short
    Cc: Jean Delvare
    Cc: Tim Gardner
    Signed-off-by: maximilian attems
    Cc: Mark M. Hoffman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. [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

    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
    Signed-off-by: John W. Linville
    Cc: Peter Nixon
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. [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

    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
    Signed-off-by: James Bottomley
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. [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

    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
    Cc: Jens Axboe
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. [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

    commit 29c8f6a727a683b5988877dd80dbdefd49e64a51 upstream

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

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

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

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

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

    Signed-off-by: David Brownell
    Cc: Leonid
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. [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

    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
    Signed-off-by: Greg Kroah-Hartman

    ---
    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 majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast