08 Mar, 2011

40 commits

  • Greg Kroah-Hartman
     
  • commit d11327ad6695db8117c78d70611e71102ceec2ac upstream.

    NETDEV_NOTIFY_PEER is an explicit request by the driver to send a link
    notification while NETDEV_UP/NETDEV_CHANGEADDR generate link
    notifications as a sort of side effect.

    In the later cases the sysctl option is present because link
    notification events can have undesired effects e.g. if the link is
    flapping. I don't think this applies in the case of an explicit
    request from a driver.

    This patch makes NETDEV_NOTIFY_PEER unconditional, if preferred we
    could add a new sysctl for this case which defaults to on.

    This change causes Xen post-migration ARP notifications (which cause
    switches to relearn their MAC tables etc) to be sent by default.

    Signed-off-by: Ian Campbell
    Signed-off-by: David S. Miller
    [reported to solve hyperv live migration problem - gkh]
    Cc: Haiyang Zhang
    Cc: Mike Surcouf
    Cc: Hank Janssen
    Signed-off-by: Greg Kroah-Hartman

    Ian Campbell
     
  • commit 1362fa078dae16776cd439791c6605b224ea6171 upstream.

    When a DNS resolver key is instantiated with an error indication, attempts to
    read that key will result in an oops because user_read() is expecting there to
    be a payload - and there isn't one [CVE-2011-1076].

    Give the DNS resolver key its own read handler that returns the error cached in
    key->type_data.x[0] as an error rather than crashing.

    Also make the kenter() at the beginning of dns_resolver_instantiate() limit the
    amount of data it prints, since the data is not necessarily NUL-terminated.

    The buggy code was added in:

    commit 4a2d789267e00b5a1175ecd2ddefcc78b83fbf09
    Author: Wang Lei
    Date: Wed Aug 11 09:37:58 2010 +0100
    Subject: DNS: If the DNS server returns an error, allow that to be cached [ver #2]

    This can trivially be reproduced by any user with the following program
    compiled with -lkeyutils:

    #include
    #include
    #include
    static char payload[] = "#dnserror=6";
    int main()
    {
    key_serial_t key;
    key = add_key("dns_resolver", "a", payload, sizeof(payload),
    KEY_SPEC_SESSION_KEYRING);
    if (key == -1)
    err(1, "add_key");
    if (keyctl_read(key, NULL, 0) == -1)
    err(1, "read_key");
    return 0;
    }

    What should happen is that keyctl_read() reports error 6 (ENXIO) to the user:

    dns-break: read_key: No such device or address

    but instead the kernel oopses.

    This cannot be reproduced with the 'keyutils add' or 'keyutils padd' commands
    as both of those cut the data down below the NUL termination that must be
    included in the data. Without this dns_resolver_instantiate() will return
    -EINVAL and the key will not be instantiated such that it can be read.

    The oops looks like:

    BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    IP: [] user_read+0x4f/0x8f
    PGD 3bdf8067 PUD 385b9067 PMD 0
    Oops: 0000 [#1] SMP
    last sysfs file: /sys/devices/pci0000:00/0000:00:19.0/irq
    CPU 0
    Modules linked in:

    Pid: 2150, comm: dns-break Not tainted 2.6.38-rc7-cachefs+ #468 /DG965RY
    RIP: 0010:[] [] user_read+0x4f/0x8f
    RSP: 0018:ffff88003bf47f08 EFLAGS: 00010246
    RAX: 0000000000000001 RBX: ffff88003b5ea378 RCX: ffffffff81972368
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88003b5ea378
    RBP: ffff88003bf47f28 R08: ffff88003be56620 R09: 0000000000000000
    R10: 0000000000000395 R11: 0000000000000002 R12: 0000000000000000
    R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffffffffa1
    FS: 00007feab5751700(0000) GS:ffff88003e000000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000010 CR3: 000000003de40000 CR4: 00000000000006f0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    Process dns-break (pid: 2150, threadinfo ffff88003bf46000, task ffff88003be56090)
    Stack:
    ffff88003b5ea378 ffff88003b5ea3a0 0000000000000000 0000000000000000
    ffff88003bf47f68 ffffffff811b708e ffff88003c442bc8 0000000000000000
    00000000004005a0 00007fffba368060 0000000000000000 0000000000000000
    Call Trace:
    [] keyctl_read_key+0xac/0xcf
    [] sys_keyctl+0x75/0xb6
    [] system_call_fastpath+0x16/0x1b
    Code: 75 1f 48 83 7b 28 00 75 18 c6 05 58 2b fb 00 01 be bb 00 00 00 48 c7 c7 76 1c 75 81 e8 13 c2 e9 ff 4c 8b b3 e0 00 00 00 4d 85 ed 0f b7 5e 10 74 2d 4d 85 e4 74 28 e8 98 79 ee ff 49 39 dd 48
    RIP [] user_read+0x4f/0x8f
    RSP
    CR2: 0000000000000010

    Signed-off-by: David Howells
    Acked-by: Jeff Layton
    cc: Wang Lei
    Signed-off-by: James Morris
    Signed-off-by: Greg Kroah-Hartman

    David Howells
     
  • commit 4def99bbfd46e05c5e03b5b282cb4ee30e27ff19 upstream.

    When support for 82577/82578 was added[1] in 2.6.31, PHY wakeup was in-
    advertently enabled (even though it does not function properly) on ICH10
    LOMs. This patch makes it so that the ICH10 LOMs use MAC wakeup instead
    as was done with the initial support for those devices (i.e. 82567LM-3,
    82567LF-3 and 82567V-4).

    [1] commit a4f58f5455ba0efda36fb33c37074922d1527a10

    Reported-by: Aurelien Jarno
    Signed-off-by: Bruce Allan
    Signed-off-by: Jeff Kirsher
    Signed-off-by: Greg Kroah-Hartman

    Bruce Allan
     
  • commit 720dc34bbbe9493c7bd48b2243058b4e447a929d upstream.

    This fixes a bug in the order of dccp_rcv_state_process() that still permitted
    reception even after closing the socket. A Reset after close thus causes a NULL
    pointer dereference by not preventing operations on an already torn-down socket.

    dccp_v4_do_rcv()
    |
    | state other than OPEN
    v
    dccp_rcv_state_process()
    |
    | DCCP_PKT_RESET
    v
    dccp_rcv_reset()
    |
    v
    dccp_time_wait()

    WARNING: at net/ipv4/inet_timewait_sock.c:141 __inet_twsk_hashdance+0x48/0x128()
    Modules linked in: arc4 ecb carl9170 rt2870sta(C) mac80211 r8712u(C) crc_ccitt ah
    [] (unwind_backtrace+0x0/0xec) from [] (warn_slowpath_common)
    [] (warn_slowpath_common+0x4c/0x64) from [] (warn_slowpath_n)
    [] (warn_slowpath_null+0x1c/0x24) from [] (__inet_twsk_hashd)
    [] (__inet_twsk_hashdance+0x48/0x128) from [] (dccp_time_wai)
    [] (dccp_time_wait+0x40/0xc8) from [] (dccp_rcv_state_proces)
    [] (dccp_rcv_state_process+0x120/0x538) from [] (dccp_v4_do_)
    [] (dccp_v4_do_rcv+0x11c/0x14c) from [] (release_sock+0xac/0)
    [] (release_sock+0xac/0x110) from [] (dccp_close+0x28c/0x380)
    [] (dccp_close+0x28c/0x380) from [] (inet_release+0x64/0x70)

    The fix is by testing the socket state first. Receiving a packet in Closed state
    now also produces the required "No connection" Reset reply of RFC 4340, 8.3.1.

    Reported-and-tested-by: Johan Hovold
    Signed-off-by: Gerrit Renker
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Gerrit Renker
     
  • commit ba04c7c93bbcb48ce880cf75b6e9dffcd79d4c7b upstream.

    For some time is known that ASPM is causing troubles on r8169, i.e. make
    device randomly stop working without any errors in dmesg.

    Currently Tomi Leppikangas reports that system with r8169 device hangs
    with MCE errors when ASPM is enabled:
    https://bugzilla.redhat.com/show_bug.cgi?id=642861#c4

    Lets disable ASPM for r8169 devices at all, to avoid problems with
    r8169 PCIe devices at least for some users.

    Reported-by: Tomi Leppikangas
    Signed-off-by: Stanislaw Gruszka
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Stanislaw Gruszka
     
  • commit c86664e5a285af1afa06416e450e7c4af04daa7c upstream.

    "AirLive X.USB now works perfectly under a Linux
    environment!"

    Signed-off-by: Christian Lamparter
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Jan Puk
     
  • commit 72746ac643928f6c3113b5aa783d8ea1b13949d2 upstream.

    According to the report from Jiro SEKIBA titled "regression in
    2.6.37?" (Message-Id: ), on 2.6.37 and
    later kernels, lscp command no longer displays "i" flag on checkpoints
    that snapshot operations or garbage collection created.

    This is a regression of nilfs2 checkpointing function, and it's
    critical since it broke behavior of a part of nilfs2 applications.
    For instance, snapshot manager of TimeBrowse gets to create
    meaningless snapshots continuously; snapshot creation triggers another
    checkpoint, but applications cannot distinguish whether the new
    checkpoint contains meaningful changes or not without the i-flag.

    This patch fixes the regression and brings that application behavior
    back to normal.

    Reported-by: Jiro SEKIBA
    Signed-off-by: Ryusuke Konishi
    Tested-by: Ryusuke Konishi
    Tested-by: Jiro SEKIBA
    Signed-off-by: Greg Kroah-Hartman

    Ryusuke Konishi
     
  • commit 2b799a6b25bb9f9fbc478782cd9503e8066ab618 upstream.

    Reported-by: Mark Davis
    Signed-off-by: Christian Lamparter
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Christian Lamparter
     
  • commit 2c27392dc4d4f5ee8a3967a520b8f6cac0418031 upstream.

    The stream length/tag fields have to be in little endian
    format. Fixing this makes the driver work on big-endian
    platforms.

    Tested-by: raghunathan.kailasanathan@wipro.com
    Signed-off-by: Sujith Manoharan
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Sujith Manoharan
     
  • commit fd51469fb68b987032e46297e0a4fe9020063c20 upstream.

    Following steps lead to deadlock in kernel:

    dd if=/dev/zero of=img bs=512 count=1000
    losetup -f img
    mkfs.ext2 /dev/loop0
    mount -t ext2 -o loop /dev/loop0 mnt
    umount mnt/

    Stacktrace:
    [] irq_exit+0x36/0x59
    [] smp_apic_timer_interrupt+0x6b/0x75
    [] apic_timer_interrupt+0x31/0x38
    [] mutex_spin_on_owner+0x54/0x5b
    [] lo_release+0x12/0x67 [loop]
    [] __blkdev_put+0x7c/0x10c
    [] fput+0xd5/0x1aa
    [] loop_clr_fd+0x1a9/0x1b1 [loop]
    [] lo_release+0x39/0x67 [loop]
    [] __blkdev_put+0x7c/0x10c
    [] deactivate_locked_super+0x17/0x36
    [] sys_umount+0x27e/0x2a5
    [] sys_oldumount+0xb/0xe
    [] sysenter_do_call+0x12/0x26
    [] 0xffffffff

    Regression since 2a48fc0ab24241755dc9, which introduced the private
    loop_mutex as part of the BKL removal process.

    As per [1], the mutex can be safely removed.

    [1] http://www.gossamer-threads.com/lists/linux/kernel/1341930

    Addresses: https://bugzilla.novell.com/show_bug.cgi?id=669394
    Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=29172

    Signed-off-by: Petr Uzel
    Reviewed-by: Nikanth Karthikesan
    Acked-by: Arnd Bergmann
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Petr Uzel
     
  • commit 255bb490c8c27eed484d538efe6ef6a7473bd3f6 upstream.

    blk-flush decomposes a flush into sequence of multiple requests. On
    completion of a request, the next one is queued; however, block layer
    must not implicitly call into q->request_fn() directly from completion
    path. This makes the queue behave unexpectedly when seen from the
    drivers and violates the assumption that q->request_fn() is called
    with process context + queue_lock.

    This patch makes blk-flush the following two changes to make sure
    q->request_fn() is not called directly from request completion path.

    - blk_flush_complete_seq_end_io() now asks __blk_run_queue() to always
    use kblockd instead of calling directly into q->request_fn().

    - queue_next_fseq() uses ELEVATOR_INSERT_REQUEUE instead of
    ELEVATOR_INSERT_FRONT so that elv_insert() doesn't try to unplug the
    request queue directly.

    Reported by Jan in the following threads.

    http://thread.gmane.org/gmane.linux.ide/48778
    http://thread.gmane.org/gmane.linux.ide/48786

    stable: applicable to v2.6.37.

    Signed-off-by: Tejun Heo
    Reported-by: Jan Beulich
    Cc: "David S. Miller"
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • commit 1654e7411a1ad4999fe7890ef51d2a2bbb1fcf76 upstream.

    __blk_run_queue() automatically either calls q->request_fn() directly
    or schedules kblockd depending on whether the function is recursed.
    blk-flush implementation needs to be able to explicitly choose
    kblockd. Add @force_kblockd.

    All the current users are converted to specify %false for the
    parameter and this patch doesn't introduce any behavior change.

    stable: This is prerequisite for fixing ide oops caused by the new
    blk-flush implementation.

    Signed-off-by: Tejun Heo
    Cc: Jan Beulich
    Cc: James Bottomley
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Tejun Heo
     
  • commit 450adcbe518ab3a3953d8475309525d22de77cba upstream.

    o Dominik Klein reported a system hang issue while doing some blkio
    throttling testing.

    https://lkml.org/lkml/2011/2/24/173

    o Some tracing revealed that CFQ was not dispatching any more jobs as
    queue unplug was not happening. And queue unplug was not happening
    because unplug work was not being called as there was one throttling
    work on same cpu which as not finished yet. And throttling work had not
    finished as it was tyring to dispatch a bio to CFQ but all the request
    descriptors were consume to it was put to sleep.

    o So basically it is a cyclic dependecny between CFQ unplug work and
    throtl dispatch work. Tejun suggested that use separate workqueue for
    such cases.

    o This patch uses a separate workqueue for throttle related work and
    does not rely on kblockd workqueue anymore.

    Reported-by: Dominik Klein
    Signed-off-by: Vivek Goyal
    Acked-by: Tejun Heo
    Signed-off-by: Jens Axboe
    Signed-off-by: Greg Kroah-Hartman

    Vivek Goyal
     
  • commit 6927faf30920b8c03dfa007e732642a1f1f20089 upstream.

    On a Thinkpad x61s, I noticed some memory corruption when
    plugging/unplugging the external VGA connection. The symptoms are that
    4 bytes at the beginning of a page get overwritten by zeroes.
    The address of the corruption varies when rebooting the machine, but
    stays constant while it's running (so it's possible to repeatedly write
    some data and then corrupt it again by plugging the cable).

    Further investigation revealed that the corrupted address is
    (dev_priv->status_page_dmah->busaddr & 0xffffffff), ie. the beginning of
    the hardware status page of the i965 graphics card, cut to 32 bits.

    So it seems that for some memory access, the hardware uses only 32 bit
    addressing. If the hardware status page is located >4GB, this
    corrupts unrelated memory.

    Signed-off-by: Jan Niehusmann
    Acked-by: Daniel Vetter
    Signed-off-by: Chris Wilson
    Signed-off-by: Greg Kroah-Hartman

    Jan Niehusmann
     
  • commit ed199facd070f8e551dc16a2ae1baa01d8d28ed4 upstream.

    If management firmware is present and the device is down, the firmware
    will assume control of the phy. If a phy access were allowed from the
    host, it will collide with firmware phy accesses, resulting in
    unpredictable behavior. This patch fixes the problem by disallowing phy
    accesses during the problematic condition.

    Signed-off-by: Matt Carlson
    Reviewed-by: Michael Chan
    Signed-off-by: David S. Miller
    Signed-off-by: Greg Kroah-Hartman

    Matt Carlson
     
  • commit 4f919a3bc54da01db829c520ce4b1fabfde1c3f7 upstream.

    I previously managed to reproduce a hang while scanning wireless
    channels (reproducible with airodump-ng hopping channels); subsequent
    lockdep instrumentation revealed a lock ordering issue.

    Without knowing the design intent, it looks like the locks should be
    taken in reverse order; please comment.

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.38-rc5-341cd #4
    -------------------------------------------------------
    airodump-ng/15445 is trying to acquire lock:
    (&rdev->devlist_mtx){+.+.+.}, at: []
    cfg80211_wext_siwfreq+0xc6/0x100

    but task is already holding lock:
    (&wdev->mtx){+.+.+.}, at: [] cfg80211_wext_siwfreq+0xbc/0x100

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&wdev->mtx){+.+.+.}:
    [] lock_acquire+0xc6/0x280
    [] mutex_lock_nested+0x6e/0x4b0
    [] cfg80211_netdev_notifier_call+0x430/0x5f0
    [] notifier_call_chain+0x8b/0x100
    [] raw_notifier_call_chain+0x11/0x20
    [] call_netdevice_notifiers+0x32/0x60
    [] __dev_notify_flags+0x34/0x80
    [] dev_change_flags+0x40/0x70
    [] do_setlink+0x1fc/0x8d0
    [] rtnl_setlink+0xf2/0x140
    [] rtnetlink_rcv_msg+0x163/0x270
    [] netlink_rcv_skb+0xa1/0xd0
    [] rtnetlink_rcv+0x20/0x30
    [] netlink_unicast+0x2ba/0x300
    [] netlink_sendmsg+0x267/0x3e0
    [] sock_sendmsg+0xe4/0x110
    [] sys_sendmsg+0x253/0x3b0
    [] system_call_fastpath+0x16/0x1b

    -> #0 (&rdev->devlist_mtx){+.+.+.}:
    [] __lock_acquire+0x1622/0x1d10
    [] lock_acquire+0xc6/0x280
    [] mutex_lock_nested+0x6e/0x4b0
    [] cfg80211_wext_siwfreq+0xc6/0x100
    [] ioctl_standard_call+0x5d/0xd0
    [] T.808+0x163/0x170
    [] wext_handle_ioctl+0x3a/0x90
    [] dev_ioctl+0x6f2/0x830
    [] sock_ioctl+0xfd/0x290
    [] do_vfs_ioctl+0x9d/0x590
    [] sys_ioctl+0x4a/0x80
    [] system_call_fastpath+0x16/0x1b

    other info that might help us debug this:

    2 locks held by airodump-ng/15445:
    #0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
    #1: (&wdev->mtx){+.+.+.}, at: []
    cfg80211_wext_siwfreq+0xbc/0x100

    stack backtrace:
    Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
    Call Trace:
    [] ? print_circular_bug+0xfa/0x100
    [] ? __lock_acquire+0x1622/0x1d10
    [] ? trace_hardirqs_off_caller+0x29/0xc0
    [] ? lock_acquire+0xc6/0x280
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? mark_held_locks+0x67/0x90
    [] ? mutex_lock_nested+0x6e/0x4b0
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? mark_held_locks+0x67/0x90
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? cfg80211_wext_siwfreq+0xc6/0x100
    [] ? ioctl_standard_call+0x5d/0xd0
    [] ? __dev_get_by_name+0x9b/0xc0
    [] ? ioctl_standard_call+0x0/0xd0
    [] ? T.808+0x163/0x170
    [] ? might_fault+0x72/0xd0
    [] ? wext_handle_ioctl+0x3a/0x90
    [] ? might_fault+0xbb/0xd0
    [] ? dev_ioctl+0x6f2/0x830
    [] ? put_lock_stats+0xe/0x40
    [] ? lock_release_holdtime+0xac/0x150
    [] ? sock_ioctl+0xfd/0x290
    [] ? do_vfs_ioctl+0x9d/0x590
    [] ? fget_light+0x1df/0x3c0
    [] ? sys_ioctl+0x4a/0x80
    [] ? system_call_fastpath+0x16/0x1b

    Signed-off-by: Daniel J Blueman
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville
    Signed-off-by: Greg Kroah-Hartman

    Daniel J Blueman
     
  • commit 3c323c01b6bd5fd01be21a8f0cdc11e55997aa06 upstream.

    As mentioned by W. Trevor King on the devel@linuxdriverproject.org list
    on "Thu, 27 Jan 2011 18:52:15 -0500", "Message-ID:
    ", the ni_pcimio module
    is missing module metadata, including a license.

    This patch adds module metadata to all the NI comedi driver modules. It
    also removes a duplicate MODULE_LICENSE("GPL") line from the "mite"
    module.

    Signed-off-by: Ian Abbott
    Cc: W. Trevor King
    Signed-off-by: Greg Kroah-Hartman

    Ian Abbott
     
  • commit 664dc878ed6f0476b875547547a49e06f7a4e73b upstream.

    During init, reading the 2 PHY ID registers back-to-back in the default
    fast mode could return invalid data (all F's) and in slow mode could
    return data to the second read the data from the first read. To resolve
    the issue in fast mode, set to slow mode before any PHY accesses; to
    resolve the issue in slow mode, put in a delay for every 82579 PHY access.
    Since this PHY is currently only paired with the pch2lan MAC and the PHY
    type is not known before the first PHY access which can fail this way,
    check for this based on MAC-type.

    Signed-off-by: Bruce Allan
    Tested-by: Jeff Pieper
    Signed-off-by: Jeff Kirsher
    Acked-by: Brandon Philips
    Signed-off-by: Greg Kroah-Hartman

    Bruce Allan
     
  • commit b44129b30652c8771db2265939bb8b463724043d upstream.

    reduce_pgdat_percpu_threshold() and restore_pgdat_percpu_threshold() exist
    to adjust the per-cpu vmstat thresholds while kswapd is awake to avoid
    errors due to counter drift. The functions duplicate some code so this
    patch replaces them with a single set_pgdat_percpu_threshold() that takes
    a callback function to calculate the desired threshold as a parameter.

    [akpm@linux-foundation.org: readability tweak]
    [kosaki.motohiro@jp.fujitsu.com: set_pgdat_percpu_threshold(): don't use for_each_online_cpu]
    Signed-off-by: Mel Gorman
    Reviewed-by: Christoph Lameter
    Reviewed-by: KAMEZAWA Hiroyuki
    Signed-off-by: KOSAKI Motohiro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Mel Gorman
     
  • commit e8a80c6f769dd4622d8b211b398452158ee60c0b upstream.

    vfs_rename_other() does not lock renamed inode with i_mutex. Thus changing
    i_nlink in a non-atomic manner (which happens in ext2_rename()) can corrupt
    it as reported and analyzed by Josh.

    In fact, there is no good reason to mess with i_nlink of the moved file.
    We did it presumably to simulate linking into the new directory and unlinking
    from an old one. But the practical effect of this is disputable because fsck
    can possibly treat file as being properly linked into both directories without
    writing any error which is confusing. So we just stop increment-decrement
    games with i_nlink which also fixes the corruption.

    CC: Al Viro
    Signed-off-by: Josh Hunt
    Signed-off-by: Jan Kara
    Signed-off-by: Greg Kroah-Hartman

    Josh Hunt
     
  • commit 3a142a0672b48a853f00af61f184c7341ac9c99d upstream.

    When the per cpu timer is marked CLOCK_EVT_FEAT_C3STOP, then we only
    can switch into oneshot mode, when the backup broadcast device
    supports oneshot mode as well. Otherwise we would try to switch the
    broadcast device into an unsupported mode unconditionally. This went
    unnoticed so far as the current available broadcast devices support
    oneshot mode. Seth unearthed this problem while debugging and working
    around an hpet related BIOS wreckage.

    Add the necessary check to tick_is_oneshot_available().

    Reported-and-tested-by: Seth Forshee
    Signed-off-by: Thomas Gleixner
    LKML-Reference:
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     
  • commit 5a18ec176c934ca1bc9dc61580a5e0e90a9b5733 upstream.

    Single threaded NTFS-3G could get stuck if a delayed RELEASE reply
    triggered a DESTROY request via path_put().

    Fix this by

    a) making RELEASE requests synchronous, whenever possible, on fuseblk
    filesystems

    b) if not possible (triggered by an asynchronous read/write) then do
    the path_put() in a separate thread with schedule_work().

    Reported-by: Oliver Neukum
    Signed-off-by: Miklos Szeredi
    Signed-off-by: Greg Kroah-Hartman

    Miklos Szeredi
     
  • commit 4bfc4e2508234f9149fd33fae853e99fb9e4a75b upstream.

    Correct names for pxa AC97 DAI are pxa2xx-ac97 and pxa2xx-ac97-aux. Fix
    that for all PXA platforms.

    Signed-off-by: Dmitry Eremin-Solenikov
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Dmitry Eremin-Solenikov
     
  • commit 43c63188821dc21b2af23a40a18faea6e386e90a upstream.

    commit f0fba2ad1b6b53d5360125c41953b7afcd6deff0 included a mistake
    on the name of the platform in the snd_soc_dai_link structure.

    Signed-off-by: Eric Bénard
    Acked-by: Liam Girdwood
    Signed-off-by: Mark Brown
    Signed-off-by: Greg Kroah-Hartman

    Eric Bénard
     
  • commit e9036e336a8e5640871e0006ea4a89982b25046f upstream.

    Add the btusb.c blacklist [0489:e02c] for Atheros AR5BBU12 BT
    and add to ath3k.c supported this device.

    Signed-off-by: Yu-Chen Cho
    Signed-off-by: Gustavo F. Padovan
    Signed-off-by: Greg Kroah-Hartman

    Yu-Chen Cho
     
  • commit 8efdd0cdc54f3bb5db464b3baf88f7441f54da47 upstream.

    Quirky dongles sometimes do not use the iso interface which
    causes a crash with runtime PM

    Signed-off-by: Oliver Neukum
    Signed-off-by: Gustavo F. Padovan
    Signed-off-by: Greg Kroah-Hartman

    Oliver Neukum
     
  • commit 509e7861d8a5e26bb07b5a3a13e2b9e442283631 upstream.

    Add the btusb.c blacklist [03f0:311d] for Atheros AR9285 Malbec BT
    and add to ath3k.c ath3-1.fw (md5:1211fa34c09e10ba48381586b7c3883d)
    supported this device.

    Signed-off-by: Yu-Chen Cho
    Signed-off-by: Gustavo F. Padovan
    Signed-off-by: Greg Kroah-Hartman

    Yu-Chen Cho
     
  • commit 299c56966a72b9109d47c71a6db52097098703dd upstream.

    A customer of ours, complained that when setting the reset
    vector back to 0, it trashed other data and hung their box.
    They noticed when only 4 bytes were set to 0 instead of 8,
    everything worked correctly.

    Mathew pointed out:

    |
    | We're supposed to be resetting trampoline_phys_low and
    | trampoline_phys_high here, which are two 16-bit values.
    | Writing 64 bits is definitely going to overwrite space
    | that we're not supposed to be touching.
    |

    So limit the area modified to u32.

    Signed-off-by: Don Zickus
    Acked-by: Matthew Garrett
    LKML-Reference:
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Don Zickus
     
  • commit 9063f1f15eec35e5fd608879cef8be5728f2d12a upstream.

    Call input_set_abs_params instead of manually setting absbit only.
    This fixes this oops:

    Unable to handle kernel NULL pointer dereference at virtual address 00000024
    Internal error: Oops: 41b67017 [#1]
    CPU: 0 Not tainted (2.6.37 #4)
    pc : [] lr : [] psr: 20000093
    sp : c19e5f30 ip : c19e5e6c fp : c19e5f58
    r10: 00000000 r9 : c19e4000 r8 : 00000003
    r7 : 000001e4 r6 : 00000001 r5 : c1854400 r4 : 00000003
    r3 : 00000018 r2 : 00000018 r1 : 00000018 r0 : c185447c
    Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
    Control: c1b6717f Table: c1b6717f DAC: 00000017
    Stack: (0xc19e5f30 to 0xc19e6000)
    5f20: 00000003 00000003 c1854400 00000013
    5f40: 00000001 000001e4 000001c5 c19e5f80 c19e5f5c c016d5e8 c016cf5c 000001e4
    5f60: c1854400 c18b5860 00000000 00000171 000001e4 c19e5fc4 c19e5f84 c01559a4
    5f80: c016d584 c18b5868 00000000 c1bb5c40 c0035afc c18b5868 c18b5868 c1a55d54
    5fa0: c18b5860 c0155750 00000013 00000000 00000000 00000000 c19e5ff4 c19e5fc8
    5fc0: c0050174 c015575c 00000000 c18b5860 00000000 c19e5fd4 c19e5fd4 c1a55d54
    5fe0: c00500f0 c003b464 00000000 c19e5ff8 c003b464 c00500fc 04000400 04000400
    Backtrace:
    Function entered at [] from []
    Function entered at [] from []
    r8:000001e4 r7:00000171 r6:00000000 r5:c18b5860 r4:c1854400
    Function entered at [] from []
    Function entered at [] from []
    r6:c003b464 r5:c00500f0 r4:c1a55d54
    Code: e59520fc e1a03286 e0433186 e0822003 (e592000c)

    >>PC; c016d1fc
    Trace; c016d5e8
    Trace; c016d578
    Trace; c01559a4
    Trace; c0155750
    Trace; c0050174
    Trace; c00500f0
    Trace; c003b464

    Signed-off-by: Jochen Friedrich
    Signed-off-by: Samuel Ortiz
    Signed-off-by: Greg Kroah-Hartman

    Jochen Friedrich
     
  • commit 4b57018dcd6418e18c08088c89f123da8a7bfc45 upstream.

    tps6586 does not support burst writes. i2c writes have to be
    1 byte at a time.

    Signed-off-by: Varun Wadekar
    Signed-off-by: Samuel Ortiz
    Signed-off-by: Greg Kroah-Hartman

    vwadekar@nvidia.com
     
  • commit 2949ad50711cc161721cf788711722eeeca33764 upstream.

    File position is not controlled, it may lead to overwrites of arbitrary
    kernel memory. Also the code may kfree() the same pointer multiple
    times.

    One more flaw is still present: if multiple processes open the file then
    all 3 static variables are shared, leading to various race conditions.
    They should be moved to file->private_data.

    Signed-off-by: Vasiliy Kulikov
    Reviewed-by: WANG Cong
    Reviewed-by: Eugene Teo
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Greg Kroah-Hartman

    Vasiliy Kulikov
     
  • commit 1922756124ddd53846877416d92ba4a802bc658f upstream.

    This fixes CVE-2011-1013.

    Reported-by: Matthiew Herrb (OpenBSD X.org team)
    Signed-off-by: Dave Airlie
    Signed-off-by: Greg Kroah-Hartman

    Dave Airlie
     
  • commit acf3bb007e5636ef4c17505affb0974175108553 upstream.

    Current refcounttree codes actually didn't writeback the new pages out in
    write-back mode, due to a bug of always passing a ZERO number of clusters
    to 'ocfs2_cow_sync_writeback', the patch tries to pass a proper one in.

    Signed-off-by: Tristan Ye
    Signed-off-by: Joel Becker
    Signed-off-by: Greg Kroah-Hartman

    Tristan Ye
     
  • commit 52c303c56c3638944b5f733e3961dc58eb8c7270 upstream.

    Commit 2c442719e90a44a6982c033d69df4aae4b167cfa added some checks for proper
    heartbeat mode when the o2cb stack is running. Unfortunately, it didn't
    take into account that a userpsace stack could be running. Fix this by only
    doing the check if o2cb is in use. This patch allows userspace stacks to
    mount the fs again.

    Signed-off-by: Mark Fasheh
    Signed-off-by: Joel Becker
    Signed-off-by: Greg Kroah-Hartman

    Mark Fasheh
     
  • commit ebbd224c22a00dbbee95031a0d6d595460f6f2b3 upstream.

    These two Dell machines have been reported working well with
    the ideapad model.

    BugLink: http://bugs.launchpad.net/bugs/723676
    Tested-by: David Chen
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson
     
  • commit 306496761745942d8167e9193a738b559a7fb0b3 upstream.

    This typo caused some microphone inputs not to be correctly
    initialized on VIA codecs.

    Reported-By: Mark Goldstein
    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson
     
  • commit 382225e62bdb8059b7f915b133426425516dd300 upstream.

    When a USB audio device is disconnected, snd_usb_audio_disconnect()
    kills all audio URBs. At the same time, the application, after being
    notified of the disconnection, might close the device, in which case
    ALSA calls the .hw_free callback, which should free the URBs too.

    Commit de1b8b93a0ba "[ALSA] Fix hang-up at disconnection of usb-audio"
    prevented snd_usb_hw_free() from freeing the URBs to avoid a hang that
    resulted from this race, but this introduced another race because the
    URB callbacks could now be executed after snd_usb_hw_free() has
    returned, and try to access already freed data.

    Fix the first race by introducing a mutex to serialize the disconnect
    callback and all PCM callbacks that manage URBs (hw_free and hw_params).

    Reported-and-tested-by: Pierre-Louis Bossart
    [CL: also serialize hw_params callback]
    Signed-off-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 6da8b51657a9cd5a87b4e6e4c7bc76b598a95175 upstream.

    Conexant 506e/20590 has the same graph as the rest of the 5066 family.

    BugLink: http://bugs.launchpad.net/bugs/723672

    Signed-off-by: David Henningsson
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    David Henningsson
     
  • commit ec95d35a6bd0047f05fe8a21e6c52f8bb418da55 upstream.

    MUSB is a non-standard host implementation which
    can handle all speeds with the same core. We need
    to set has_tt flag after commit
    d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent
    buggy hubs from crashing the USB stack) in order for
    MUSB HCD to continue working.

    Signed-off-by: Felipe Balbi
    Cc: Alan Stern
    Tested-by: Michael Jones
    Tested-by: Alexander Holler
    Signed-off-by: Greg Kroah-Hartman

    Felipe Balbi