Commits on Mar 27, 2011
  1. @gregkh

    Linux 2.6.32.36

    gregkh committed Mar 27, 2011
  2. @gregkh

    dcdbas: force SMI to happen when expected

    commit dd65c73 upstream.
    
    The dcdbas driver can do an I/O write to cause a SMI to occur.  The SMI handler
    looks at certain registers and memory locations, so the SMI needs to happen
    immediately.  On some systems I/O writes are posted, though, causing the SMI to
    happen well after the "outb" occurred, which causes random failures.  Following
    the "outb" with an "inb" forces the write to go through even if it is posted.
    
    Signed-off-by: Stuart Hayes <stuart_hayes@yahoo.com>
    Acked-by: Doug Warzecha <douglas_warzecha@dell.com>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Stuart Hayes committed with gregkh Mar 2, 2011
  3. @gregkh

    fs: call security_d_instantiate in d_obtain_alias V2

    commit 24ff666 upstream.
    
    While trying to track down some NFS problems with BTRFS, I kept noticing I was
    getting -EACCESS for no apparent reason.  Eric Paris and printk() helped me
    figure out that it was SELinux that was giving me grief, with the following
    denial
    
    type=AVC msg=audit(1290013638.413:95): avc:  denied  { 0x800000 } for  pid=1772
    comm="nfsd" name="" dev=sda1 ino=256 scontext=system_u:system_r:kernel_t:s0
    tcontext=system_u:object_r:unlabeled_t:s0 tclass=file
    
    Turns out this is because in d_obtain_alias if we can't find an alias we create
    one and do all the normal instantiation stuff, but we don't do the
    security_d_instantiate.
    
    Usually we are protected from getting a hashed dentry that hasn't yet run
    security_d_instantiate() by the parent's i_mutex, but obviously this isn't an
    option there, so in order to deal with the case that a second thread comes in
    and finds our new dentry before we get to run security_d_instantiate(), we go
    ahead and call it if we find a dentry already.  Eric assures me that this is ok
    as the code checks to see if the dentry has been initialized already so calling
    security_d_instantiate() against the same dentry multiple times is ok.  With
    this patch I'm no longer getting errant -EACCESS values.
    
    Signed-off-by: Josef Bacik <josef@redhat.com>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Chuck Ebbert <cebbert@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Josef Bacik committed with gregkh Nov 18, 2010
  4. @gregkh

    SUNRPC: Never reuse the socket port after an xs_close()

    commit 246408d upstream.
    
    If we call xs_close(), we're in one of two situations:
     - Autoclose, which means we don't expect to resend a request
     - bind+connect failed, which probably means the port is in use
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Trond Myklebust committed with gregkh Mar 22, 2011
  5. @olafhering @gregkh

    Input: xen-kbdfront - advertise either absolute or relative coordinates

    commit 8c3c283 upstream.
    
    A virtualized display device is usually viewed with the vncviewer
    application, either by 'xm vnc domU' or with vncviewer localhost:port.
    vncviewer and the RFB protocol provides absolute coordinates to the
    virtual display. These coordinates are either passed through to a PV
    guest or converted to relative coordinates for a HVM guest.
    
    A PV guest receives these coordinates and passes them to the kernels
    evdev driver. There it can be picked up by applications such as the
    xorg-input drivers. Using absolute coordinates avoids issues such as
    guest mouse pointer not tracking host mouse pointer due to wrong mouse
    acceleration settings in the guests X display.
    
    Advertise either absolute or relative coordinates to the input system
    and the evdev driver, depending on what dom0 provides. The xorg-input
    driver prefers relative coordinates even if a devices provides both.
    
    Signed-off-by: Olaf Hering <olaf@aepfle.de>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    olafhering committed with gregkh Mar 16, 2011
  6. @jhovold @gregkh

    USB: cdc-acm: fix potential null-pointer dereference on disconnect

    commit 7e7797e upstream.
    
    Fix potential null-pointer exception on disconnect introduced by commit
    11ea859 (USB: additional power savings
    for cdc-acm devices that support remote wakeup).
    
    Only access acm->dev after making sure it is non-null in control urb
    completion handler.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jhovold committed with gregkh Mar 22, 2011
  7. @jhovold @gregkh

    USB: cdc-acm: fix potential null-pointer dereference

    commit 15e5bee upstream.
    
    Must check return value of tty_port_tty_get.
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jhovold committed with gregkh Mar 22, 2011
  8. @jhovold @gregkh

    USB: cdc-acm: fix memory corruption / panic

    commit 23b8055 upstream.
    
    Prevent read urbs from being resubmitted from tasklet after port close.
    
    The receive tasklet was not disabled on port close, which could lead to
    corruption of receive lists on consecutive port open. In particular,
    read urbs could be re-submitted before port open, added to free list in
    open, and then added a second time to the free list in the completion
    handler.
    
    cdc-acm.c: Entering acm_tty_open.
    cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
    cdc-acm.c: Entering acm_rx_tasklet
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
    cdc-acm.c: set line: 115200 0 0 8
    cdc-acm.c: acm_control_msg: rq: 0x20 val: 0x0 len: 0x7 result: 7
    cdc-acm.c: acm_tty_close
    cdc-acm.c: acm_port_down
    cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x0 len: 0x0 result: 0
    cdc-acm.c: acm_ctrl_irq - urb shutting down with status: -2
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
    cdc-acm.c: Entering acm_read_bulk with status -2
    cdc_acm 4-1:1.1: Aborting, acm not ready
    cdc-acm.c: Entering acm_read_bulk with status -2
    cdc_acm 4-1:1.1: Aborting, acm not ready
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da400, rcv 0xf57fbbe8, buf 0xf57fbd28
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da480, rcv 0xf57fbbd4, buf 0xf57fbd14
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da900, rcv 0xf57fbbc0, buf 0xf57fbd00
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da980, rcv 0xf57fbbac, buf 0xf57fbcec
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa00, rcv 0xf57fbb98, buf 0xf57fbcd8
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50daa80, rcv 0xf57fbb84, buf 0xf57fbcc4
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab00, rcv 0xf57fbb70, buf 0xf57fbcb0
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dab80, rcv 0xf57fbb5c, buf 0xf57fbc9c
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac00, rcv 0xf57fbb48, buf 0xf57fbc88
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dac80, rcv 0xf57fbb34, buf 0xf57fbc74
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad00, rcv 0xf57fbb20, buf 0xf57fbc60
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50dad80, rcv 0xf57fbb0c, buf 0xf57fbc4c
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da880, rcv 0xf57fbaf8, buf 0xf57fbc38
    cdc-acm.c: Entering acm_tty_open.
    cdc-acm.c: acm_control_msg: rq: 0x22 val: 0x3 len: 0x0 result: 0
    cdc-acm.c: Entering acm_rx_tasklet
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da280, rcv 0xf57fbc24, buf 0xf57fbd64
    cdc-acm.c: Entering acm_tty_write to write 3 bytes,
    cdc-acm.c: Get 3 bytes...
    cdc-acm.c: acm_write_start susp_count: 0
    cdc-acm.c: Entering acm_read_bulk with status 0
    ------------[ cut here ]------------
    WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
    Hardware name: Vostro 1520
    list_del corruption. next->prev should be f57fbc10, but was f57fbaf8
    Modules linked in: cdc_acm
    Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.37+ #39
    Call Trace:
     [<c103c7e2>] warn_slowpath_common+0x72/0xa0
     [<c11dd8ac>] ? list_del+0x10c/0x120
     [<c11dd8ac>] ? list_del+0x10c/0x120
     [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
     [<c11dd8ac>] list_del+0x10c/0x120
     [<f8051dbf>] acm_rx_tasklet+0xef/0x3e0 [cdc_acm]
     [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
     [<c1042bb6>] tasklet_action+0xe6/0x140
     [<c104342f>] __do_softirq+0xaf/0x210
     [<c1043380>] ? __do_softirq+0x0/0x210
     <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
     [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
     [<c105ac24>] ? kthread+0x74/0x80
     [<c105abb0>] ? kthread+0x0/0x80
     [<c100337a>] ? kernel_thread_helper+0x6/0x10
    ---[ end trace efd9a11434f0082e ]---
    ------------[ cut here ]------------
    WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:57 list_del+0x10c/0x120()
    Hardware name: Vostro 1520
    list_del corruption. next->prev should be f57fbd50, but was f57fbdb0
    Modules linked in: cdc_acm
    Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
    Call Trace:
     [<c103c7e2>] warn_slowpath_common+0x72/0xa0
     [<c11dd8ac>] ? list_del+0x10c/0x120
     [<c11dd8ac>] ? list_del+0x10c/0x120
     [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
     [<c11dd8ac>] list_del+0x10c/0x120
     [<f8051dd6>] acm_rx_tasklet+0x106/0x3e0 [cdc_acm]
     [<c135465d>] ? net_rps_action_and_irq_enable+0x6d/0x80
     [<c1042bb6>] tasklet_action+0xe6/0x140
     [<c104342f>] __do_softirq+0xaf/0x210
     [<c1043380>] ? __do_softirq+0x0/0x210
     <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
     [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
     [<c105ac24>] ? kthread+0x74/0x80
     [<c105abb0>] ? kthread+0x0/0x80
     [<c100337a>] ? kernel_thread_helper+0x6/0x10
    ---[ end trace efd9a11434f0082f ]---
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da300, rcv 0xf57fbc10, buf 0xf57fbd50
    cdc-acm.c: disconnected from network
    cdc-acm.c: acm_rx_tasklet: sending urb 0xf50da380, rcv 0xf57fbbfc, buf 0xf57fbd3c
    cdc-acm.c: Entering acm_rx_tasklet
    ------------[ cut here ]------------
    WARNING: at /home/johan/src/linux/linux-2.6/lib/list_debug.c:48 list_del+0xd5/0x120()
    Hardware name: Vostro 1520
    list_del corruption, next is LIST_POISON1 (00100100)
    Modules linked in: cdc_acm
    Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39
    Call Trace:
     [<c103c7e2>] warn_slowpath_common+0x72/0xa0
     [<c11dd875>] ? list_del+0xd5/0x120
     [<c11dd875>] ? list_del+0xd5/0x120
     [<c103c8b3>] warn_slowpath_fmt+0x33/0x40
     [<c11dd875>] list_del+0xd5/0x120
     [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
     [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
     [<c1042b30>] ? tasklet_action+0x60/0x140
     [<c1042bb6>] tasklet_action+0xe6/0x140
     [<c104342f>] __do_softirq+0xaf/0x210
     [<c1043380>] ? __do_softirq+0x0/0x210
     <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
     [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
     [<c105ac24>] ? kthread+0x74/0x80
     [<c105abb0>] ? kthread+0x0/0x80
     [<c100337a>] ? kernel_thread_helper+0x6/0x10
    ---[ end trace efd9a11434f00830 ]---
    BUG: unable to handle kernel paging request at 00200200
    IP: [<c11dd7bd>] list_del+0x1d/0x120
    *pde = 00000000
    Oops: 0000 [#1] PREEMPT SMP
    last sysfs file: /sys/devices/pci0000:00/0000:00:1a.1/usb4/4-1/4-1:1.0/tty/ttyACM0/uevent
    Modules linked in: cdc_acm
    Pid: 3, comm: ksoftirqd/0 Tainted: G        W   2.6.37+ #39 0T816J/Vostro 1520
    EIP: 0060:[<c11dd7bd>] EFLAGS: 00010046 CPU: 0
    EIP is at list_del+0x1d/0x120
    EAX: f57fbd3c EBX: f57fb800 ECX: ffff8000 EDX: 00200200
    ESI: f57fbe90 EDI: f57fbd3c EBP: f600bf54 ESP: f600bf3c
     DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
    Process ksoftirqd/0 (pid: 3, ti=f600a000 task=f60791c0 task.ti=f6082000)
    Stack:
     c1527e84 00000030 c1527e54 00100100 f57fb800 f57fbd3c f600bf98 f8051fac
     f8053104 f8052b94 f600bf6c c106dbab f600bf80 00000286 f60791c0 c1042b30
     f57fbda8 f57f5800 f57fbdb0 f57fbd80 f57fbe7c c1656b04 00000000 f600bfb0
    Call Trace:
     [<f8051fac>] ? acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
     [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
     [<c1042b30>] ? tasklet_action+0x60/0x140
     [<c1042bb6>] ? tasklet_action+0xe6/0x140
     [<c104342f>] ? __do_softirq+0xaf/0x210
     [<c1043380>] ? __do_softirq+0x0/0x210
     <IRQ>
     [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
     [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
     [<c105ac24>] ? kthread+0x74/0x80
     [<c105abb0>] ? kthread+0x0/0x80
     [<c100337a>] ? kernel_thread_helper+0x6/0x10
    Code: ff 48 14 e9 57 ff ff ff 90 90 90 90 90 90 55 89 e5 83 ec 18 81 38 00 01 10 00 0f 84 9c 00 00 00 8b 50 04 81 fa 00 02 20 00 74 33 <8b> 12 39 d0 75 5c 8b 10 8b 4a 04 39 c8 0f 85 b5 00 00 00 8b 48
    EIP: [<c11dd7bd>] list_del+0x1d/0x120 SS:ESP 0068:f600bf3c
    CR2: 0000000000200200
    ---[ end trace efd9a11434f00831 ]---
    Kernel panic - not syncing: Fatal exception in interrupt
    Pid: 3, comm: ksoftirqd/0 Tainted: G      D W   2.6.37+ #39
    Call Trace:
     [<c13fede1>] ? printk+0x1d/0x24
     [<c13fecce>] panic+0x66/0x15c
     [<c10067df>] oops_end+0x8f/0x90
     [<c1025476>] no_context+0xc6/0x160
     [<c10255a8>] __bad_area_nosemaphore+0x98/0x140
     [<c103cf68>] ? release_console_sem+0x1d8/0x210
     [<c1025667>] bad_area_nosemaphore+0x17/0x20
     [<c1025a49>] do_page_fault+0x279/0x420
     [<c1006a8f>] ? show_trace+0x1f/0x30
     [<c13fede1>] ? printk+0x1d/0x24
     [<c10257d0>] ? do_page_fault+0x0/0x420
     [<c140333b>] error_code+0x5f/0x64
     [<c103007b>] ? select_task_rq_fair+0x37b/0x6a0
     [<c10257d0>] ? do_page_fault+0x0/0x420
     [<c11dd7bd>] ? list_del+0x1d/0x120
     [<f8051fac>] acm_rx_tasklet+0x2dc/0x3e0 [cdc_acm]
     [<c106dbab>] ? trace_hardirqs_on+0xb/0x10
     [<c1042b30>] ? tasklet_action+0x60/0x140
     [<c1042bb6>] tasklet_action+0xe6/0x140
     [<c104342f>] __do_softirq+0xaf/0x210
     [<c1043380>] ? __do_softirq+0x0/0x210
     <IRQ>  [<c1042c9a>] ? run_ksoftirqd+0x8a/0x1c0
     [<c1042c10>] ? run_ksoftirqd+0x0/0x1c0
     [<c105ac24>] ? kthread+0x74/0x80
     [<c105abb0>] ? kthread+0x0/0x80
     [<c100337a>] ? kernel_thread_helper+0x6/0x10
    panic occurred, switching back to text console
    ------------[ cut here ]------------
    
    Signed-off-by: Johan Hovold <jhovold@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    jhovold committed with gregkh Mar 22, 2011
  9. @gregkh

    USB: uss720 fixup refcount position

    commit adaa3c6 upstream.
    
    My testprog do a lot of bitbang - after hours i got following warning and my machine lockups:
    WARNING: at /build/buildd/linux-2.6.38/lib/kref.c:34
    After debugging uss720 driver i discovered that the completion callback was called before
    usb_submit_urb returns. The callback frees the request structure that is krefed on return by
    usb_submit_urb.
    
    Signed-off-by: Peter Holik <peter@holik.at>
    Acked-by: Thomas Sailer <t.sailer@alumni.ethz.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Peter Holik committed with gregkh Mar 18, 2011
  10. @gregkh

    ehci-hcd: Bug fix: don't set a QH's Halt bit

    commit b5a3b3d upstream.
    
    This patch (as1453) fixes a long-standing bug in the ehci-hcd driver.
    
    There is no need to set the Halt bit in the overlay region for an
    unlinked or blocked QH.  Contrary to what the comment says, setting
    the Halt bit does not cause the QH to be patched later; that decision
    (made in qh_refresh()) depends only on whether the QH is currently
    pointing to a valid qTD.  Likewise, setting the Halt bit does not
    prevent completions from activating the QH while it is "stopped"; they
    are prevented by the fact that qh_completions() temporarily changes
    qh->qh_state to QH_STATE_COMPLETING.
    
    On the other hand, there are circumstances in which the QH will be
    reactivated _without_ being patched; this happens after an URB beyond
    the head of the queue is unlinked.  Setting the Halt bit will then
    cause the hardware to see the QH with both the Active and Halt bits
    set, an invalid combination that will prevent the queue from
    advancing and may even crash some controllers.
    
    Apparently the only reason this hasn't been reported before is that
    unlinking URBs from the middle of a running queue is quite uncommon.
    However Test 17, recently added to the usbtest driver, does exactly
    this, and it confirms the presence of the bug.
    
    In short, there is no reason to set the Halt bit for an unlinked or
    blocked QH, and there is a very good reason not to set it.  Therefore
    the code that sets it is removed.
    
    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Andiry Xu <andiry.xu@amd.com>
    CC: David Brownell <david-b@pacbell.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Alan Stern committed with gregkh Mar 16, 2011
  11. @gregkh

    uvcvideo: Fix uvc_fixup_video_ctrl() format search

    commit 38a6682 upstream.
    
    The scheme used to index format in uvc_fixup_video_ctrl() is not robust:
    format index is based on descriptor ordering, which does not necessarily
    match bFormatIndex ordering.  Searching for first matching format will
    prevent uvc_fixup_video_ctrl() from using the wrong format/frame to make
    adjustments.
    
    Signed-off-by: Stephan Lachowsky <stephan.lachowsky@maxim-ic.com>
    Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Stephan Lachowsky committed with gregkh Jan 27, 2011
  12. @gregkh

    nfsd: wrong index used in inner loop

    commit 5a02ab7 upstream.
    
    We must not use dummy for index.
    After the first index, READ32(dummy) will change dummy!!!!
    
    Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
    [bfields@redhat.com: Trond points out READ_BUF alone is sufficient.]
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Mi Jinlong committed with gregkh Mar 11, 2011
  13. @gregkh

    nfsd41: modify the members value of nfsd4_op_flags

    commit 5ece3ca upstream.
    
    The members of nfsd4_op_flags, (ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS)
    equals to  ALLOWED_AS_FIRST_OP, maybe that's not what we want.
    
    OP_PUTROOTFH with op_flags = ALLOWED_WITHOUT_FH | ALLOWED_ON_ABSENT_FS,
    can't appears as the first operation with out SEQUENCE ops.
    
    This patch modify the wrong value of ALLOWED_WITHOUT_FH etc which
    was introduced by f9bb94c.
    
    Reviewed-by: Benny Halevy <bhalevy@panasas.com>
    Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Mi Jinlong committed with gregkh Feb 18, 2011
  14. @gregkh

    fbcon: Bugfix soft cursor detection in Tile Blitting

    commit d6244bc upstream.
    
    Use mask 0x10 for "soft cursor" detection on in function tile_cursor.
    (Tile Blitting Operation in framebuffer console).
    
    The old mask 0x01 for vc_cursor_type detects CUR_NONE, CUR_LOWER_THIRD
    and every second mode value as "software cursor". This hides the cursor
    for these modes (cursor.mode = 0). But, only CUR_NONE or "software cursor"
    should hide the cursor.
    See also 0x10 in functions add_softcursor, bit_cursor and cw_cursor.
    
    Signed-off-by: Henry Nestler <henry.nestler@gmail.com>
    Signed-off-by: Paul Mundt <lethal@linux-sh.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Henry Nestler committed with gregkh Feb 20, 2011
  15. @gregkh

    proc: protect mm start_code/end_code in /proc/pid/stat

    commit 5883f57 upstream.
    
    While mm->start_stack was protected from cross-uid viewing (commit
    f83ce3e ("proc: avoid information leaks to non-privileged
    processes")), the start_code and end_code values were not.  This would
    allow the text location of a PIE binary to leak, defeating ASLR.
    
    Note that the value "1" is used instead of "0" for a protected value since
    "ps", "killall", and likely other readers of /proc/pid/stat, take
    start_code of "0" to mean a kernel thread and will misbehave.  Thanks to
    Brad Spengler for pointing this out.
    
    Addresses CVE-2011-0726
    
    Signed-off-by: Kees Cook <kees.cook@canonical.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Eugene Teo <eugeneteo@kernel.sg>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Brad Spengler <spender@grsecurity.net>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Kees Cook committed with gregkh Mar 23, 2011
  16. @aakoskin @gregkh

    procfs: fix /proc/<pid>/maps heap check

    commit 0db0c01 upstream.
    
    The current code fails to print the "[heap]" marking if the heap is split
    into multiple mappings.
    
    Fix the check so that the marking is displayed in all possible cases:
    	1. vma matches exactly the heap
    	2. the heap vma is merged e.g. with bss
    	3. the heap vma is splitted e.g. due to locked pages
    
    Test cases. In all cases, the process should have mapping(s) with
    [heap] marking:
    
    	(1) vma matches exactly the heap
    
    	#include <stdio.h>
    	#include <unistd.h>
    	#include <sys/types.h>
    
    	int main (void)
    	{
    		if (sbrk(4096) != (void *)-1) {
    			printf("check /proc/%d/maps\n", (int)getpid());
    			while (1)
    				sleep(1);
    		}
    		return 0;
    	}
    
    	# ./test1
    	check /proc/553/maps
    	[1] + Stopped                    ./test1
    	# cat /proc/553/maps | head -4
    	00008000-00009000 r-xp 00000000 01:00 3113640    /test1
    	00010000-00011000 rw-p 00000000 01:00 3113640    /test1
    	00011000-00012000 rw-p 00000000 00:00 0          [heap]
    	4006f000-40070000 rw-p 00000000 00:00 0
    
    	(2) the heap vma is merged
    
    	#include <stdio.h>
    	#include <unistd.h>
    	#include <sys/types.h>
    
    	char foo[4096] = "foo";
    	char bar[4096];
    
    	int main (void)
    	{
    		if (sbrk(4096) != (void *)-1) {
    			printf("check /proc/%d/maps\n", (int)getpid());
    			while (1)
    				sleep(1);
    		}
    		return 0;
    	}
    
    	# ./test2
    	check /proc/556/maps
    	[2] + Stopped                    ./test2
    	# cat /proc/556/maps | head -4
    	00008000-00009000 r-xp 00000000 01:00 3116312    /test2
    	00010000-00012000 rw-p 00000000 01:00 3116312    /test2
    	00012000-00014000 rw-p 00000000 00:00 0          [heap]
    	4004a000-4004b000 rw-p 00000000 00:00 0
    
    	(3) the heap vma is splitted (this fails without the patch)
    
    	#include <stdio.h>
    	#include <unistd.h>
    	#include <sys/mman.h>
    	#include <sys/types.h>
    
    	int main (void)
    	{
    		if ((sbrk(4096) != (void *)-1) && !mlockall(MCL_FUTURE) &&
    		    (sbrk(4096) != (void *)-1)) {
    			printf("check /proc/%d/maps\n", (int)getpid());
    			while (1)
    				sleep(1);
    		}
    		return 0;
    	}
    
    	# ./test3
    	check /proc/559/maps
    	[1] + Stopped                    ./test3
    	# cat /proc/559/maps|head -4
    	00008000-00009000 r-xp 00000000 01:00 3119108    /test3
    	00010000-00011000 rw-p 00000000 01:00 3119108    /test3
    	00011000-00012000 rw-p 00000000 00:00 0          [heap]
    	00012000-00013000 rw-p 00000000 00:00 0          [heap]
    
    It looks like the bug has been there forever, and since it only results in
    some information missing from a procfile, it does not fulfil the -stable
    "critical issue" criteria.
    
    Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
    Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.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>
    aakoskin committed with gregkh Mar 23, 2011
  17. @amir73il @gregkh

    ext3: skip orphan cleanup on rocompat fs

    commit ce654b3 upstream.
    
    Orphan cleanup is currently executed even if the file system has some
    number of unknown ROCOMPAT features, which deletes inodes and frees
    blocks, which could be very bad for some RO_COMPAT features.
    
    This patch skips the orphan cleanup if it contains readonly compatible
    features not known by this ext3 implementation, which would prevent
    the fs from being mounted (or remounted) readwrite.
    
    Signed-off-by: Amir Goldstein <amir73il@users.sf.net>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    amir73il committed with gregkh Feb 26, 2011
  18. @gregkh

    Prevent rt_sigqueueinfo and rt_tgsigqueueinfo from spoofing the signa…

    …l code
    
    commit da48524 upstream.
    
    Userland should be able to trust the pid and uid of the sender of a
    signal if the si_code is SI_TKILL.
    
    Unfortunately, the kernel has historically allowed sigqueueinfo() to
    send any si_code at all (as long as it was negative - to distinguish it
    from kernel-generated signals like SIGILL etc), so it could spoof a
    SI_TKILL with incorrect siginfo values.
    
    Happily, it looks like glibc has always set si_code to the appropriate
    SI_QUEUE, so there are probably no actual user code that ever uses
    anything but the appropriate SI_QUEUE flag.
    
    So just tighten the check for si_code (we used to allow any negative
    value), and add a (one-time) warning in case there are binaries out
    there that might depend on using other si_code values.
    
    Signed-off-by: Julien Tinnes <jln@google.com>
    Acked-by: Oleg Nesterov <oleg@redhat.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Julien Tinnes committed with gregkh Mar 18, 2011
  19. @michich @gregkh

    PCI: return correct value when writing to the "reset" attribute

    commit 447c5dd upstream.
    
    A successful write() to the "reset" sysfs attribute should return the
    number of bytes written, not 0. Otherwise userspace (bash) retries the
    write over and over again.
    
    Acked-by: Michael S. Tsirkin <mst@redhat.com>
    Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    michich committed with gregkh May 11, 2010
  20. @gregkh

    x86: Cleanup highmap after brk is concluded

    commit e5f15b4 upstream.
    
    Now cleanup_highmap actually is in two steps: one is early in head64.c
    and only clears above _end; a second one is in init_memory_mapping() and
    tries to clean from _brk_end to _end.
    It should check if those boundaries are PMD_SIZE aligned but currently
    does not.
    Also init_memory_mapping() is called several times for numa or memory
    hotplug, so we really should not handle initial kernel mappings there.
    
    This patch moves cleanup_highmap() down after _brk_end is settled so
    we can do everything in one step.
    Also we honor max_pfn_mapped in the implementation of cleanup_highmap.
    
    Signed-off-by: Yinghai Lu <yinghai@kernel.org>
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Yinghai Lu committed with gregkh Feb 18, 2011
  21. @gregkh

    xen: set max_pfn_mapped to the last pfn mapped

    commit 14988a4 upstream.
    
    Do not set max_pfn_mapped to the end of the initial memory mappings,
    that also contain pages that don't belong in pfn space (like the mfn
    list).
    
    Set max_pfn_mapped to the last real pfn mapped in the initial memory
    mappings that is the pfn backing _end.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    LKML-Reference: <alpine.DEB.2.00.1103171739050.3382@kaball-desktop>
    Signed-off-by: H. Peter Anvin <hpa@zytor.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Stefano Stabellini committed with gregkh Feb 18, 2011
  22. @gregkh

    PCI hotplug: acpiphp: set current_state to D0 in register_slot

    commit 47e9037 upstream.
    
    If a device doesn't support power management (pm_cap == 0) but it is
    acpi_pci_power_manageable() because there is a _PS0 method declared for
    it and _EJ0 is also declared for the slot then nobody is going to set
    current_state = PCI_D0 for this device.  This is what I think it is
    happening:
    
    pci_enable_device
        |
    __pci_enable_device_flags
    /* here we do not set current_state because !pm_cap */
        |
    do_pci_enable_device
        |
    pci_set_power_state
        |
    __pci_start_power_transition
        |
    pci_platform_power_transition
    /* platform_pci_power_manageable() calls acpi_pci_power_manageable that
     * returns true */
        |
    platform_pci_set_power_state
    /* acpi_pci_set_power_state gets called and does nothing because the
     * acpi device has _EJ0, see the comment "If the ACPI device has _EJ0,
     * ignore the device" */
    
    at this point if we refer to the commit message that introduced the
    comment above (10b3dca), it is up to
    the hotplug driver to set the state to D0.
    However AFAICT the pci hotplug driver never does, in fact
    drivers/pci/hotplug/acpiphp_glue.c:register_slot sets the slot flags to
    (SLOT_ENABLED | SLOT_POWEREDON) but it does not set the pci device
    current state to PCI_D0.
    
    So my proposed fix is also to set current_state = PCI_D0 in
    register_slot.
    Comments are very welcome.
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Stefano Stabellini committed with gregkh Feb 28, 2011
  23. @gregkh

    shmem: let shared anonymous be nonlinear again

    commit bee4c36 upstream.
    
    Up to 2.6.22, you could use remap_file_pages(2) on a tmpfs file or a
    shared mapping of /dev/zero or a shared anonymous mapping.  In 2.6.23 we
    disabled it by default, but set VM_CAN_NONLINEAR to enable it on safe
    mappings.  We made sure to set it in shmem_mmap() for tmpfs files, but
    missed it in shmem_zero_setup() for the others.  Fix that at last.
    
    Reported-by: Kenny Simpson <theonetruekenny@yahoo.com>
    Signed-off-by: Hugh Dickins <hughd@google.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>
    Hugh Dickins committed with gregkh Mar 22, 2011
  24. @rolandd @gregkh

    aio: wake all waiters when destroying ctx

    commit e91f90b upstream.
    
    The test program below will hang because io_getevents() uses
    add_wait_queue_exclusive(), which means the wake_up() in io_destroy() only
    wakes up one of the threads.  Fix this by using wake_up_all() in the aio
    code paths where we want to make sure no one gets stuck.
    
    	// t.c -- compile with gcc -lpthread -laio t.c
    
    	#include <libaio.h>
    	#include <pthread.h>
    	#include <stdio.h>
    	#include <unistd.h>
    
    	static const int nthr = 2;
    
    	void *getev(void *ctx)
    	{
    		struct io_event ev;
    		io_getevents(ctx, 1, 1, &ev, NULL);
    		printf("io_getevents returned\n");
    		return NULL;
    	}
    
    	int main(int argc, char *argv[])
    	{
    		io_context_t ctx = 0;
    		pthread_t thread[nthr];
    		int i;
    
    		io_setup(1024, &ctx);
    
    		for (i = 0; i < nthr; ++i)
    			pthread_create(&thread[i], NULL, getev, ctx);
    
    		sleep(1);
    
    		io_destroy(ctx);
    
    		for (i = 0; i < nthr; ++i)
    			pthread_join(thread[i], NULL);
    
    		return 0;
    	}
    
    Signed-off-by: Roland Dreier <roland@purestorage.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    rolandd committed with gregkh Mar 22, 2011
Commits on Mar 24, 2011
  1. @gregkh

    Linux 2.6.32.35

    gregkh committed Mar 24, 2011
  2. @gregkh

    Revert "perf: Handle stopped state with tracepoints"

    This reverts commit 6f197b7, which was
    originally commit a0f7d0f upstream.
    
    This breaks the build, thanks to Jiri Slaby for pointing this out.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    gregkh committed Mar 24, 2011
Commits on Mar 23, 2011
  1. @gregkh

    Linux 2.6.32.34

    gregkh committed Mar 23, 2011
  2. @vivien @gregkh

    hwmon: (sht15) Fix integer overflow in humidity calculation

    commit ccd32e7 upstream.
    
    An integer overflow occurs in the calculation of RHlinear when the
    relative humidity is greater than around 30%. The consequence is a subtle
    (but noticeable) error in the resulting humidity measurement.
    
    Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Cc: Jonathan Cameron <jic23@cam.ac.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    vivien committed with gregkh Mar 21, 2011
  3. @heukelum @gregkh

    x86, binutils, xen: Fix another wrong size directive

    commit 371c394 upstream.
    
    The latest binutils (2.21.0.20110302/Ubuntu) breaks the build
    yet another time, under CONFIG_XEN=y due to a .size directive that
    refers to a slightly differently named (hence, to the now very
    strict and unforgiving assembler, non-existent) symbol.
    
    [ mingo:
    
       This unnecessary build breakage caused by new binutils
       version 2.21 gets escallated back several kernel releases spanning
       several years of Linux history, affecting over 130,000 upstream
       kernel commits (!), on CONFIG_XEN=y 64-bit kernels (i.e. essentially
       affecting all major Linux distro kernel configs).
    
       Git annotate tells us that this slight debug symbol code mismatch
       bug has been introduced in 2008 in commit 3d75e1b:
    
         3d75e1b        (Jeremy Fitzhardinge    2008-07-08 15:06:49 -0700 1231) ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
    
       The 'bug' is just a slight assymetry in ENTRY()/END()
       debug-symbols sequences, with lots of assembly code between the
       ENTRY() and the END():
    
         ENTRY(xen_do_hypervisor_callback)   # do_hypervisor_callback(struct *pt_regs)
           ...
         END(do_hypervisor_callback)
    
       Human reviewers almost never catch such small mismatches, and binutils
       never even warned about it either.
    
       This new binutils version thus breaks the Xen build on all upstream kernels
       since v2.6.27, out of the blue.
    
       This makes a straightforward Git bisection of all 64-bit Xen-enabled kernels
       impossible on such binutils, for a bisection window of over hundred
       thousand historic commits. (!)
    
       This is a major fail on the side of binutils and binutils needs to turn
       this show-stopper build failure into a warning ASAP. ]
    
    Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
    Cc: Jeremy Fitzhardinge <jeremy@goop.org>
    Cc: Jan Beulich <jbeulich@novell.com>
    Cc: H.J. Lu <hjl.tools@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Kees Cook <kees.cook@canonical.com>
    LKML-Reference: <1299877178-26063-1-git-send-email-heukelum@fastmail.fm>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    heukelum committed with gregkh Mar 11, 2011
  4. @mdmillerii @gregkh

    powerpc: rtas_flash needs to use rtas_data_buf

    commit bd2b64a upstream.
    
    When trying to flash a machine via the update_flash command, Anton received the
    following error:
    
        Restarting system.
        FLASH: kernel bug...flash list header addr above 4GB
    
    The code in question has a comment that the flash list should be in
    the kernel data and therefore under 4GB:
    
            /* NOTE: the "first" block list is a global var with no data
             * blocks in the kernel data segment.  We do this because
             * we want to ensure this block_list addr is under 4GB.
             */
    
    Unfortunately the Kconfig option is marked tristate which means the variable
    may not be in the kernel data and could be above 4GB.
    
    Instead of relying on the data segment being below 4GB, use the static
    data buffer allocated by the kernel for use by rtas.  Since we don't
    use the header struct directly anymore, convert it to a simple pointer.
    
    Reported-By: Anton Blanchard <anton@samba.org>
    Signed-Off-By: Milton Miller <miltonm@bga.com>
    Tested-By: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    mdmillerii committed with gregkh Jun 12, 2010
  5. @mikey @gregkh

    powerpc/kdump: Fix race in kdump shutdown

    commit 60adec6 upstream.
    
    When we are crashing, the crashing/primary CPU IPIs the secondaries to
    turn off IRQs, go into real mode and wait in kexec_wait.  While this
    is happening, the primary tears down all the MMU maps.  Unfortunately
    the primary doesn't check to make sure the secondaries have entered
    real mode before doing this.
    
    On PHYP machines, the secondaries can take a long time shutting down
    the IRQ controller as RTAS calls are need.  These RTAS calls need to
    be serialised which resilts in the secondaries contending in
    lock_rtas() and hence taking a long time to shut down.
    
    We've hit this on large POWER7 machines, where some secondaries are
    still waiting in lock_rtas(), when the primary tears down the HPTEs.
    
    This patch makes sure all secondaries are in real mode before the
    primary tears down the MMU.  It uses the new kexec_state entry in the
    paca.  It times out if the secondaries don't reach real mode after
    10sec.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    cc: Anton Blanchard <anton@samba.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    mikey committed with gregkh May 13, 2010
  6. @mikey @gregkh

    powerpc/kexec: Fix race in kexec shutdown

    commit 1fc711f upstream.
    
    In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
    kexec_smp_down().  kexec_smp_down() calls kexec_smp_wait() which sets
    the hw_cpu_id() to -1.  The primary does this while leaving IRQs on
    which means the primary can take a timer interrupt which can lead to
    the IPIing one of the secondary CPUs (say, for a scheduler re-balance)
    but since the secondary CPU now has a hw_cpu_id = -1, we IPI CPU
    -1... Kaboom!
    
    We are hitting this case regularly on POWER7 machines.
    
    There is also a second race, where the primary will tear down the MMU
    mappings before knowing the secondaries have entered real mode.
    
    Also, the secondaries are clearing out any pending IPIs before
    guaranteeing that no more will be received.
    
    This changes kexec_prepare_cpus() so that we turn off IRQs in the
    primary CPU much earlier.  It adds a paca flag to say that the
    secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
    rather than overloading hw_cpu_id with -1.  This new paca flag is
    again used to in indicate when the secondaries has entered real mode.
    
    It also ensures that all CPUs have their IRQs off before we clear out
    any pending IPI requests (in kexec_cpu_down()) to ensure there are no
    trailing IPIs left unacknowledged.
    
    Signed-off-by: Michael Neuling <mikey@neuling.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
    cc: Anton Blanchard <anton@samba.org>
    Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    mikey committed with gregkh May 13, 2010
  7. @gregkh

    mmc: sdio: remember new card RCA when redetecting card

    commit 0aab399 upstream.
    
    During redetection of a SDIO card, a request for a new card RCA
    was submitted to the card, but was then overwritten by the old RCA.
    This caused the card to be deselected instead of selected when using
    the incorrect RCA.  This bug's been present since the "oldcard"
    handling was introduced in 2.6.32.
    
    Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
    Reviewed-by: Ulf Hansson <ulf.hansson@stericsson.com>
    Reviewed-by: Pawel Wieczorkiewicz <pawel.wieczorkiewicz@stericsson.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Chris Ball <cjb@laptop.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Stefan Nilsson XK committed with gregkh Mar 1, 2011
  8. @gregkh

    i2c: Fix typo in instantiating-devices document

    commit 6ced9e6 upstream.
    
    The struct i2c_board_info member holding the name is "type", not
    "name".
    
    Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
    Signed-off-by: Jean Delvare <khali@linux-fr.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Roman Fietze committed with gregkh Mar 20, 2011
  9. @gregkh

    fix per-cpu flag problem in the cpu affinity checkers

    commit 9804c9e upstream.
    
    The CHECK_IRQ_PER_CPU is wrong, it should be checking
    irq_to_desc(irq)->status not just irq.
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: James Bottomley <James.Bottomley@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
    Thomas Gleixner committed with gregkh Feb 7, 2011