Permalink
Commits on Jan 12, 2013
  1. Merge branch 'distro-3.7' into pf-3.7

    Oleksandr Natalenko committed Jan 12, 2013
  2. distro-3.7: remove git dep from build-pf.sh

    Oleksandr Natalenko committed Jan 12, 2013
  3. distro-3.7: bump Arch Linux PKGBUILD to v3.7.2-pf

    Oleksandr Natalenko committed Jan 12, 2013
  4. Merge branch 'configs-3.7' into pf-3.7

    Oleksandr Natalenko committed Jan 12, 2013
  5. configs-3.7: add SCSI CD-ROM support for dell-vostro-3360.config

    Oleksandr Natalenko committed Jan 12, 2013
  6. Merge branch 'version-3.7' into pf-3.7

    Oleksandr Natalenko committed Jan 12, 2013
  7. version-3.7: bump to v3.7.2-pf

    Oleksandr Natalenko committed Jan 12, 2013
  8. fix merge conflict

    Oleksandr Natalenko committed Jan 12, 2013
Commits on Jan 11, 2013
  1. Linux 3.7.2

    gregkh committed Jan 11, 2013
  2. cifs: don't compare uniqueids in cifs_prime_dcache unless server inod…

    jtlayton committed with gregkh Dec 18, 2012
    …e numbers are in use
    
    commit 2f2591a upstream.
    
    Oliver reported that commit cd60042 caused his cifs mounts to
    continually thrash through new inodes on readdir. His servers are not
    sending inode numbers (or he's not using them), and the new test in
    that function doesn't account for that sort of setup correctly.
    
    If we're not using server inode numbers, then assume that the inode
    attached to the dentry hasn't changed. Go ahead and update the
    attributes in place, but keep the same inode number.
    
    Reported-and-Tested-by: Oliver Mössinger <Oliver.Moessinger@ichaus.de>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <sfrench@us.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. cifs: rename cifs_readdir_lookup to cifs_prime_dcache and make it voi…

    jtlayton committed with gregkh Dec 3, 2012
    …d return
    
    commit eb1b3fa upstream.
    
    The caller doesn't do anything with the dentry, so there's no point in
    holding a reference to it on return. Also cifs_prime_dcache better
    describes the actual purpose of the function.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. can: Do not call dev_put if restart timer is running upon close

    Alexander Stein committed with gregkh Nov 27, 2012
    commit ab48b03 upstream.
    
    If the restart timer is running due to BUS-OFF and the device is
    disconnected an dev_put will decrease the usage counter to -1 thus
    blocking the interface removal, resulting in the following dmesg
    lines repeating every 10s:
    can: notifier: receive list not found for dev can0
    can: notifier: receive list not found for dev can0
    can: notifier: receive list not found for dev can0
    unregister_netdevice: waiting for can0 to become free. Usage count = -1
    
    Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
    Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. HID: Add Apple wireless keyboard 2011 ANSI to special driver list

    bwhacks committed with gregkh Dec 2, 2012
    commit f9af7b9 upstream.
    
    Commit 0a97e1e ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID')
    did not update the special driver list in hid-core.c, so hid-generic may
    still bind to this device.
    
    Reported-by: Ari Pollak <ari@scvngr.com>
    References: http://bugs.debian.org/694546
    Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
    Signed-off-by: Jiri Kosina <jkosina@suse.cz>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. linux/kernel.h: fix DIV_ROUND_CLOSEST with unsigned divisors

    groeck committed with gregkh Dec 20, 2012
    commit c4e1849 upstream.
    
    Commit 263a523 ("linux/kernel.h: Fix warning seen with W=1 due to
    change in DIV_ROUND_CLOSEST") fixes a warning seen with W=1 due to
    change in DIV_ROUND_CLOSEST.
    
    Unfortunately, the C compiler converts divide operations with unsigned
    divisors to unsigned, even if the dividend is signed and negative (for
    example, -10 / 5U = 858993457).  The C standard says "If one operand has
    unsigned int type, the other operand is converted to unsigned int", so
    the compiler is not to blame.  As a result, DIV_ROUND_CLOSEST(0, 2U) and
    similar operations now return bad values, since the automatic conversion
    of expressions such as "0 - 2U/2" to unsigned was not taken into
    account.
    
    Fix by checking for the divisor variable type when deciding which
    operation to perform.  This fixes DIV_ROUND_CLOSEST(0, 2U), but still
    returns bad values for negative dividends divided by unsigned divisors.
    Mark the latter case as unsupported.
    
    One observed effect of this problem is that the s2c_hwmon driver reports
    a value of 4198403 instead of 0 if the ADC reads 0.
    
    Other impact is unpredictable.  Problem is seen if the divisor is an
    unsigned variable or constant and the dividend is less than (divisor/2).
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reported-by: Juergen Beisert <jbe@pengutronix.de>
    Tested-by: Juergen Beisert <jbe@pengutronix.de>
    Cc: Jean Delvare <khali@linux-fr.org>
    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@linuxfoundation.org>
  7. mm: limit mmu_gather batching to fix soft lockups on !CONFIG_PREEMPT

    Michal Hocko committed with gregkh Jan 4, 2013
    commit 53a59fc upstream.
    
    Since commit e303297 ("mm: extended batches for generic
    mmu_gather") we are batching pages to be freed until either
    tlb_next_batch cannot allocate a new batch or we are done.
    
    This works just fine most of the time but we can get in troubles with
    non-preemptible kernel (CONFIG_PREEMPT_NONE or CONFIG_PREEMPT_VOLUNTARY)
    on large machines where too aggressive batching might lead to soft
    lockups during process exit path (exit_mmap) because there are no
    scheduling points down the free_pages_and_swap_cache path and so the
    freeing can take long enough to trigger the soft lockup.
    
    The lockup is harmless except when the system is setup to panic on
    softlockup which is not that unusual.
    
    The simplest way to work around this issue is to limit the maximum
    number of batches in a single mmu_gather.  10k of collected pages should
    be safe to prevent from soft lockups (we would have 2ms for one) even if
    they are all freed without an explicit scheduling point.
    
    This patch doesn't add any new explicit scheduling points because it
    relies on zap_pmd_range during page tables zapping which calls
    cond_resched per PMD.
    
    The following lockup has been reported for 3.0 kernel with a huge
    process (in order of hundreds gigs but I do know any more details).
    
      BUG: soft lockup - CPU#56 stuck for 22s! [kernel:31053]
      Modules linked in: af_packet nfs lockd fscache auth_rpcgss nfs_acl sunrpc mptctl mptbase autofs4 binfmt_misc dm_round_robin dm_multipath bonding cpufreq_conservative cpufreq_userspace cpufreq_powersave pcc_cpufreq mperf microcode fuse loop osst sg sd_mod crc_t10dif st qla2xxx scsi_transport_fc scsi_tgt netxen_nic i7core_edac iTCO_wdt joydev e1000e serio_raw pcspkr edac_core iTCO_vendor_support acpi_power_meter rtc_cmos hpwdt hpilo button container usbhid hid dm_mirror dm_region_hash dm_log linear uhci_hcd ehci_hcd usbcore usb_common scsi_dh_emc scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh dm_snapshot pcnet32 mii edd dm_mod raid1 ext3 mbcache jbd fan thermal processor thermal_sys hwmon cciss scsi_mod
      Supported: Yes
      CPU 56
      Pid: 31053, comm: kernel Not tainted 3.0.31-0.9-default #1 HP ProLiant DL580 G7
      RIP: 0010:  _raw_spin_unlock_irqrestore+0x8/0x10
      RSP: 0018:ffff883ec1037af0  EFLAGS: 00000206
      RAX: 0000000000000e00 RBX: ffffea01a0817e28 RCX: ffff88803ffd9e80
      RDX: 0000000000000200 RSI: 0000000000000206 RDI: 0000000000000206
      RBP: 0000000000000002 R08: 0000000000000001 R09: ffff887ec724a400
      R10: 0000000000000000 R11: dead000000200200 R12: ffffffff8144c26e
      R13: 0000000000000030 R14: 0000000000000297 R15: 000000000000000e
      FS:  00007ed834282700(0000) GS:ffff88c03f200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 000000000068b240 CR3: 0000003ec13c5000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process kernel (pid: 31053, threadinfo ffff883ec1036000, task ffff883ebd5d4100)
      Call Trace:
        release_pages+0xc5/0x260
        free_pages_and_swap_cache+0x9d/0xc0
        tlb_flush_mmu+0x5c/0x80
        tlb_finish_mmu+0xe/0x50
        exit_mmap+0xbd/0x120
        mmput+0x49/0x120
        exit_mm+0x122/0x160
        do_exit+0x17a/0x430
        do_group_exit+0x3d/0xb0
        get_signal_to_deliver+0x247/0x480
        do_signal+0x71/0x1b0
        do_notify_resume+0x98/0xb0
        int_signal+0x12/0x17
      DWARF2 unwinder stuck at int_signal+0x12/0x17
    
    Signed-off-by: Michal Hocko <mhocko@suse.cz>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    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@linuxfoundation.org>
  8. drivers/rtc/rtc-vt8500.c: fix handling of data passed in struct rtc_time

    tonyprisk committed with gregkh Jan 4, 2013
    commit 2f90b68 upstream.
    
    tm_mon is 0..11, whereas vt8500 expects 1..12 for the month field,
    causing invalid date errors for January, and causing the day field to
    roll over incorrectly.
    
    The century flag is only handled in vt8500_rtc_read_time, but not set in
    vt8500_rtc_set_time.  This patch corrects the behaviour of the century
    flag.
    
    Signed-off-by: Edgar Toernig <froese@gmx.de>
    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    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@linuxfoundation.org>
  9. drivers/rtc/rtc-vt8500.c: correct handling of CR_24H bitfield

    tonyprisk committed with gregkh Jan 4, 2013
    commit 532db57 upstream.
    
    Control register bitfield for 12H/24H mode is handled incorrectly.
    Setting CR_24H actually enables 12H mode.  This patch renames the define
    and changes the initialization code to correctly set 24H mode.
    
    Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
    Cc: Edgar Toernig <froese@gmx.de>
    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@linuxfoundation.org>
  10. revert "rtc: recycle id when unloading a rtc driver"

    akpm00 committed with gregkh Dec 20, 2012
    commit 5abe257 upstream.
    
    Revert commit 2830a6d.
    
    We already perform the ida_simple_remove() in rtc_device_release(),
    which is an appropriate place.  Commit 2830a6d ("rtc: recycle id when
    unloading a rtc driver") caused the kernel to emit
    
    	ida_remove called for id=0 which is not allocated.
    
    warnings when rtc_device_release() tries to release an alread-released
    ID.
    
    Let's restore things to their previous state and then work out why
    Vincent's kernel wasn't calling rtc_device_release() - presumably a bug
    in a specific sub-driver.
    
    Reported-by: Lothar Waßmann <LW@KARO-electronics.de>
    Acked-by: Alexander Holler <holler@ahsoftware.de>
    Cc: Vincent Palatin <vpalatin@chromium.org>
    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@linuxfoundation.org>
  11. CRIS: fix I/O macros

    cminyard committed with gregkh Dec 18, 2012
    commit c24bf9b upstream.
    
    The inb/outb macros for CRIS are broken from a number of points of view,
    missing () around parameters and they have an unprotected if statement
    in them.  This was breaking the compile of IPMI on CRIS and thus I was
    being annoyed by build regressions, so I fixed them.
    
    Plus I don't think they would have worked at all, since the data values
    were missing "&" and the outsl had a "3" instead of a "4" for the size.
    From what I can tell, this stuff is not used at all, so this can't be
    any more broken than it was before, anyway.
    
    Signed-off-by: Corey Minyard <cminyard@mvista.com>
    Cc: Jesper Nilsson <jesper.nilsson@axis.com>
    Cc: Mikael Starvik <starvik@axis.com>
    Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
    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@linuxfoundation.org>
  12. proc: pid/status: show all supplementary groups

    dedekind committed with gregkh Dec 18, 2012
    commit 8d23802 upstream.
    
    We display a list of supplementary group for each process in
    /proc/<pid>/status.  However, we show only the first 32 groups, not all of
    them.
    
    Although this is rare, but sometimes processes do have more than 32
    supplementary groups, and this kernel limitation breaks user-space apps
    that rely on the group list in /proc/<pid>/status.
    
    Number 32 comes from the internal NGROUPS_SMALL macro which defines the
    length for the internal kernel "small" groups buffer.  There is no
    apparent reason to limit to this value.
    
    This patch removes the 32 groups printing limit.
    
    The Linux kernel limits the amount of supplementary groups by NGROUPS_MAX,
    which is currently set to 65536.  And this is the maximum count of groups
    we may possibly print.
    
    Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
    Acked-by: Serge E. Hallyn <serge.hallyn@ubuntu.com>
    Acked-by: Kees Cook <keescook@chromium.org>
    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@linuxfoundation.org>
  13. lib: atomic64: Initialize locks statically to fix early users

    bebarino committed with gregkh Dec 20, 2012
    commit fcc1688 upstream.
    
    The atomic64 library uses a handful of static spin locks to implement
    atomic 64-bit operations on architectures without support for atomic
    64-bit instructions.
    
    Unfortunately, the spinlocks are initialized in a pure initcall and that
    is too late for the vfs namespace code which wants to use atomic64
    operations before the initcall is run.
    
    This became a problem as of commit 8823c07: "vfs: Add setns support
    for the mount namespace".
    
    This leads to BUG messages such as:
    
      BUG: spinlock bad magic on CPU#0, swapper/0/0
       lock: atomic64_lock+0x240/0x400, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
        do_raw_spin_lock+0x158/0x198
        _raw_spin_lock_irqsave+0x4c/0x58
        atomic64_add_return+0x30/0x5c
        alloc_mnt_ns.clone.14+0x44/0xac
        create_mnt_ns+0xc/0x54
        mnt_init+0x120/0x1d4
        vfs_caches_init+0xe0/0x10c
        start_kernel+0x29c/0x300
    
    coming out early on during boot when spinlock debugging is enabled.
    
    Fix this by initializing the spinlocks statically at compile time.
    
    Reported-and-tested-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
    Tested-by: Tony Lindgren <tony@atomide.com>
    Cc: Eric W. Biederman <ebiederm@xmission.com>
    Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  14. Revert "Bluetooth: Fix possible deadlock in SCO code"

    Gustavo Padovan committed with gregkh Dec 3, 2012
    commit 0b27a4b upstream.
    
    This reverts commit 269c484.
    
    The commit was causing dead locks and NULL dereferences in the sco code:
    
     [28084.104013] BUG: soft lockup - CPU#0 stuck for 22s! [kworker/u:0H:7]
     [28084.104021] Modules linked in: btusb bluetooth <snip [last unloaded:
    bluetooth]
    ...
     [28084.104021]  [<c160246d>] _raw_spin_lock+0xd/0x10
     [28084.104021]  [<f920e708>] sco_conn_del+0x58/0x1b0 [bluetooth]
     [28084.104021]  [<f920f1a9>] sco_connect_cfm+0xb9/0x2b0 [bluetooth]
     [28084.104021]  [<f91ef289>]
    hci_sync_conn_complete_evt.isra.94+0x1c9/0x260 [bluetooth]
     [28084.104021]  [<f91f1a8d>] hci_event_packet+0x74d/0x2b40 [bluetooth]
     [28084.104021]  [<c1501abd>] ? __kfree_skb+0x3d/0x90
     [28084.104021]  [<c1501b46>] ? kfree_skb+0x36/0x90
     [28084.104021]  [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
     [28084.104021]  [<f91fcb4e>] ? hci_send_to_monitor+0x10e/0x190 [bluetooth]
    
    Reported-by: Chan-yeol Park <chanyeol.park@gmail.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  15. Bluetooth: cancel power_on work when unregistering the device

    Gustavo Padovan committed with gregkh Nov 21, 2012
    commit b9b5ef1 upstream.
    
    We need to cancel the hci_power_on work in order to avoid it run when we
    try to free the hdev.
    
    [ 1434.201149] ------------[ cut here ]------------
    [ 1434.204998] WARNING: at lib/debugobjects.c:261 debug_print_object+0x8e/0xb0()
    [ 1434.208324] ODEBUG: free active (active state 0) object type: work_struct hint: hci
    _power_on+0x0/0x90
    [ 1434.210386] Pid: 8564, comm: trinity-child25 Tainted: G        W    3.7.0-rc5-next-
    20121112-sasha-00018-g2f4ce0e #127
    [ 1434.210760] Call Trace:
    [ 1434.210760]  [<ffffffff819f3d6e>] ? debug_print_object+0x8e/0xb0
    [ 1434.210760]  [<ffffffff8110b887>] warn_slowpath_common+0x87/0xb0
    [ 1434.210760]  [<ffffffff8110b911>] warn_slowpath_fmt+0x41/0x50
    [ 1434.210760]  [<ffffffff819f3d6e>] debug_print_object+0x8e/0xb0
    [ 1434.210760]  [<ffffffff8376b750>] ? hci_dev_open+0x310/0x310
    [ 1434.210760]  [<ffffffff83bf94e5>] ? _raw_spin_unlock_irqrestore+0x55/0xa0
    [ 1434.210760]  [<ffffffff819f3ee5>] __debug_check_no_obj_freed+0xa5/0x230
    [ 1434.210760]  [<ffffffff83785db0>] ? bt_host_release+0x10/0x20
    [ 1434.210760]  [<ffffffff819f4d15>] debug_check_no_obj_freed+0x15/0x20
    [ 1434.210760]  [<ffffffff8125eee7>] kfree+0x227/0x330
    [ 1434.210760]  [<ffffffff83785db0>] bt_host_release+0x10/0x20
    [ 1434.210760]  [<ffffffff81e539e5>] device_release+0x65/0xc0
    [ 1434.210760]  [<ffffffff819d3975>] kobject_cleanup+0x145/0x190
    [ 1434.210760]  [<ffffffff819d39cd>] kobject_release+0xd/0x10
    [ 1434.210760]  [<ffffffff819d33cc>] kobject_put+0x4c/0x60
    [ 1434.210760]  [<ffffffff81e548b2>] put_device+0x12/0x20
    [ 1434.210760]  [<ffffffff8376a334>] hci_free_dev+0x24/0x30
    [ 1434.210760]  [<ffffffff82fd8fe1>] vhci_release+0x31/0x60
    [ 1434.210760]  [<ffffffff8127be12>] __fput+0x122/0x250
    [ 1434.210760]  [<ffffffff811cab0d>] ? rcu_user_exit+0x9d/0xd0
    [ 1434.210760]  [<ffffffff8127bf49>] ____fput+0x9/0x10
    [ 1434.210760]  [<ffffffff81133402>] task_work_run+0xb2/0xf0
    [ 1434.210760]  [<ffffffff8106cfa7>] do_notify_resume+0x77/0xa0
    [ 1434.210760]  [<ffffffff83bfb0ea>] int_signal+0x12/0x17
    [ 1434.210760] ---[ end trace a6d57fefbc8a8cc7 ]---
    
    Reported-by: Sasha Levin <sasha.levin@oracle.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. Bluetooth: Add missing lock nesting notation

    Gustavo Padovan committed with gregkh Nov 21, 2012
    commit dc2a0e2 upstream.
    
    This patch fixes the following report, it happens when accepting rfcomm
    connections:
    
    [  228.165378] =============================================
    [  228.165378] [ INFO: possible recursive locking detected ]
    [  228.165378] 3.7.0-rc1-00536-gc1d5dc4 #120 Tainted: G        W
    [  228.165378] ---------------------------------------------
    [  228.165378] bluetoothd/1341 is trying to acquire lock:
    [  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
    [<ffffffffa0000aa0>] bt_accept_dequeue+0xa0/0x180 [bluetooth]
    [  228.165378]
    [  228.165378] but task is already holding lock:
    [  228.165378]  (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+...}, at:
    [<ffffffffa0205118>] rfcomm_sock_accept+0x58/0x2d0 [rfcomm]
    [  228.165378]
    [  228.165378] other info that might help us debug this:
    [  228.165378]  Possible unsafe locking scenario:
    [  228.165378]
    [  228.165378]        CPU0
    [  228.165378]        ----
    [  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
    [  228.165378]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM);
    [  228.165378]
    [  228.165378]  *** DEADLOCK ***
    [  228.165378]
    [  228.165378]  May be due to missing lock nesting notation
    
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  17. Bluetooth: Add support for BCM20702A0 [0b05, 17b5]

    sjuxax committed with gregkh Nov 9, 2012
    commit 1ee3ff6 upstream.
    
    Vendor-specific ID for BCM20702A0.
    Support for bluetooth over Asus Wi-Fi GO!, included with Asus P8Z77-V
    Deluxe.
    
    T:  Bus=07 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0b05 ProdID=17b5 Rev=01.12
    S:  Manufacturer=Broadcom Corp
    S:  Product=BCM20702A0
    S:  SerialNumber=94DBC98AC113
    C:  #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
    I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
    I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
    
    Signed-off-by: Jeff Cook <jeff@deserettechnology.com>
    Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  18. PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)

    Myron Stowe committed with gregkh Dec 26, 2012
    commit 1278998 upstream.
    
    Commit 284f5f9 was intended to disable the "only_one_child()" optimization
    on Stratus ftServer systems, but its DMI check is wrong.  It looks for
    DMI_SYS_VENDOR that contains "ftServer", when it should look for
    DMI_SYS_VENDOR containing "Stratus" and DMI_PRODUCT_NAME containing
    "ftServer".
    
    Tested on Stratus ftServer 6400.
    
    Reported-by: Fadeeva Marina <astarta@rat.ru>
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=51331
    Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  19. PCI/PM: Do not suspend port if any subordinate device needs PME polling

    Huang Ying committed with gregkh Dec 26, 2012
    commit c733b77 upstream.
    
    Ulrich reported that his USB3 cardreader does not work reliably when
    connected to the USB3 port.  It turns out that USB3 controller failed to
    awaken when plugging in the USB3 cardreader.  Further experiments found
    that the USB3 host controller can only be awakened via polling, not via PME
    interrupt.  But if the PCIe port to which the USB3 host controller is
    connected is suspended, we cannot poll the controller because its config
    space is not accessible when the PCIe port is in a low power state.
    
    To solve the issue, the PCIe port will not be suspended if any subordinate
    device needs PME polling.
    
    [bhelgaas: use bool consistently rather than mixing int/bool]
    Reference: http://lkml.kernel.org/r/50841CCC.9030809@uli-eckhardt.de
    Reported-by: Ulrich Eckhardt <usb@uli-eckhardt.de>
    Tested-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  20. PCI: Reduce Ricoh 0xe822 SD card reader base clock frequency to 50MHz

    amluto committed with gregkh Dec 1, 2012
    commit 812089e upstream.
    
    Otherwise it fails like this on cards like the Transcend 16GB SDHC card:
    
        mmc0: new SDHC card at address b368
        mmcblk0: mmc0:b368 SDC   15.0 GiB
        mmcblk0: error -110 sending status command, retrying
        mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb0
    
    Tested on my Lenovo x200 laptop.
    
    [bhelgaas: changelog]
    Signed-off-by: Andy Lutomirski <luto@amacapital.net>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Chris Ball <cjb@laptop.org>
    CC: Manoj Iyer <manoj.iyer@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  21. PCI/PM: Keep runtime PM enabled for unbound PCI devices

    Huang Ying committed with gregkh Nov 20, 2012
    commit 967577b upstream.
    
    For unbound PCI devices, what we need is:
    
     - Always in D0 state, because some devices do not work again after
       being put into D3 by the PCI bus.
    
     - In SUSPENDED state if allowed, so that the parent devices can still
       be put into low power state.
    
    To satisfy these requirements, the runtime PM for the unbound PCI
    devices are disabled and set to SUSPENDED state.  One issue of this
    solution is that the PCI devices will be put into SUSPENDED state even
    if the SUSPENDED state is forbidden via the sysfs interface
    (.../power/control) of the device.  This is not an issue for most
    devices, because most PCI devices are not used at all if unbound.
    But there are exceptions.  For example, unbound VGA card can be used
    for display, but suspending its parents makes it stop working.
    
    To fix the issue, we keep the runtime PM enabled when the PCI devices
    are unbound.  But the runtime PM callbacks will do nothing if the PCI
    devices are unbound.  This way, we can put the PCI devices into
    SUSPENDED state without putting the PCI devices into D3 state.
    
    Reference: https://bugzilla.kernel.org/show_bug.cgi?id=48201
    Signed-off-by: Huang Ying <ying.huang@intel.com>
    Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  22. solos-pci: fix double-free of TX skb in DMA mode

    dwmw2 committed with gregkh Dec 11, 2012
    commit cae49ed upstream.
    
    We weren't clearing card->tx_skb[port] when processing the TX done interrupt.
    If there wasn't another skb ready to transmit immediately, this led to a
    double-free because we'd free it *again* next time we did have a packet to
    send.
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  23. cifs: adjust sequence number downward after signing NT_CANCEL request

    jtlayton committed with gregkh Dec 27, 2012
    commit 31efee6 upstream.
    
    When a call goes out, the signing code adjusts the sequence number
    upward by two to account for the request and the response. An NT_CANCEL
    however doesn't get a response of its own, it just hurries the server
    along to get it to respond to the original request more quickly.
    Therefore, we must adjust the sequence number back down by one after
    signing a NT_CANCEL request.
    
    Reported-by: Tim Perry <tdparmor-sambabugs@yahoo.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  24. cifs: move check for NULL socket into smb_send_rqst

    jtlayton committed with gregkh Dec 27, 2012
    commit ea702b8 upstream.
    
    Cai reported this oops:
    
    [90701.616664] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
    [90701.625438] IP: [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
    [90701.632167] PGD fea319067 PUD 103fda4067 PMD 0
    [90701.637255] Oops: 0000 [#1] SMP
    [90701.640878] Modules linked in: des_generic md4 nls_utf8 cifs dns_resolver binfmt_misc tun sg igb iTCO_wdt iTCO_vendor_support lpc_ich pcspkr i2c_i801 i2c_core i7core_edac edac_core ioatdma dca mfd_core coretemp kvm_intel kvm crc32c_intel microcode sr_mod cdrom ata_generic sd_mod pata_acpi crc_t10dif ata_piix libata megaraid_sas dm_mirror dm_region_hash dm_log dm_mod
    [90701.677655] CPU 10
    [90701.679808] Pid: 9627, comm: ls Tainted: G        W    3.7.1+ #10 QCI QSSC-S4R/QSSC-S4R
    [90701.688950] RIP: 0010:[<ffffffff814a343e>]  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
    [90701.698383] RSP: 0018:ffff88177b431bb8  EFLAGS: 00010206
    [90701.704309] RAX: ffff88177b431fd8 RBX: 00007ffffffff000 RCX: ffff88177b431bec
    [90701.712271] RDX: 0000000000000003 RSI: 0000000000000006 RDI: 0000000000000000
    [90701.720223] RBP: ffff88177b431bc8 R08: 0000000000000004 R09: 0000000000000000
    [90701.728185] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000001
    [90701.736147] R13: ffff88184ef92000 R14: 0000000000000023 R15: ffff88177b431c88
    [90701.744109] FS:  00007fd56a1a47c0(0000) GS:ffff88105fc40000(0000) knlGS:0000000000000000
    [90701.753137] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    [90701.759550] CR2: 0000000000000028 CR3: 000000104f15f000 CR4: 00000000000007e0
    [90701.767512] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [90701.775465] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    [90701.783428] Process ls (pid: 9627, threadinfo ffff88177b430000, task ffff88185ca4cb60)
    [90701.792261] Stack:
    [90701.794505]  0000000000000023 ffff88177b431c50 ffff88177b431c38 ffffffffa014fcb1
    [90701.802809]  ffff88184ef921bc 0000000000000000 00000001ffffffff ffff88184ef921c0
    [90701.811123]  ffff88177b431c08 ffffffff815ca3d9 ffff88177b431c18 ffff880857758000
    [90701.819433] Call Trace:
    [90701.822183]  [<ffffffffa014fcb1>] smb_send_rqst+0x71/0x1f0 [cifs]
    [90701.828991]  [<ffffffff815ca3d9>] ? schedule+0x29/0x70
    [90701.834736]  [<ffffffffa014fe6d>] smb_sendv+0x3d/0x40 [cifs]
    [90701.841062]  [<ffffffffa014fe96>] smb_send+0x26/0x30 [cifs]
    [90701.847291]  [<ffffffffa015801f>] send_nt_cancel+0x6f/0xd0 [cifs]
    [90701.854102]  [<ffffffffa015075e>] SendReceive+0x18e/0x360 [cifs]
    [90701.860814]  [<ffffffffa0134a78>] CIFSFindFirst+0x1a8/0x3f0 [cifs]
    [90701.867724]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
    [90701.875601]  [<ffffffffa013f731>] ? build_path_from_dentry+0xf1/0x260 [cifs]
    [90701.883477]  [<ffffffffa01578e6>] cifs_query_dir_first+0x26/0x30 [cifs]
    [90701.890869]  [<ffffffffa015480d>] initiate_cifs_search+0xed/0x250 [cifs]
    [90701.898354]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
    [90701.904486]  [<ffffffffa01554cb>] cifs_readdir+0x45b/0x8f0 [cifs]
    [90701.911288]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
    [90701.917410]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
    [90701.923533]  [<ffffffff81195970>] ? fillonedir+0x100/0x100
    [90701.929657]  [<ffffffff81195848>] vfs_readdir+0xb8/0xe0
    [90701.935490]  [<ffffffff81195b9f>] sys_getdents+0x8f/0x110
    [90701.941521]  [<ffffffff815d3b99>] system_call_fastpath+0x16/0x1b
    [90701.948222] Code: 66 90 55 65 48 8b 04 25 f0 c6 00 00 48 89 e5 53 48 83 ec 08 83 fe 01 48 8b 98 48 e0 ff ff 48 c7 80 48 e0 ff ff ff ff ff ff 74 22 <48> 8b 47 28 ff 50 68 65 48 8b 14 25 f0 c6 00 00 48 89 9a 48 e0
    [90701.970313] RIP  [<ffffffff814a343e>] kernel_setsockopt+0x2e/0x60
    [90701.977125]  RSP <ffff88177b431bb8>
    [90701.981018] CR2: 0000000000000028
    [90701.984809] ---[ end trace 24bd602971110a43 ]---
    
    This is likely due to a race vs. a reconnection event.
    
    The current code checks for a NULL socket in smb_send_kvec, but that's
    too late. By the time that check is done, the socket will already have
    been passed to kernel_setsockopt. Move the check into smb_send_rqst, so
    that it's checked earlier.
    
    In truth, this is a bit of a half-assed fix. The -ENOTSOCK error
    return here looks like it could bubble back up to userspace. The locking
    rules around the ssocket pointer are really unclear as well. There are
    cases where the ssocket pointer is changed without holding the srv_mutex,
    but I'm not clear whether there's a potential race here yet or not.
    
    This code seems like it could benefit from some fundamental re-think of
    how the socket handling should behave. Until then though, this patch
    should at least fix the above oops in most cases.
    
    Reported-and-Tested-by: CAI Qian <caiqian@redhat.com>
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve French <smfrench@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  25. fs: Fix imbalance in freeze protection in mark_files_ro()

    jankara committed with gregkh Dec 5, 2012
    commit 72651ca upstream.
    
    File descriptors (even those for writing) do not hold freeze protection.
    Thus mark_files_ro() must call __mnt_drop_write() to only drop protection
    against remount read-only. Calling mnt_drop_write_file() as we do now
    results in:
    
    [ BUG: bad unlock balance detected! ]
    3.7.0-rc6-00028-g88e75b6 #101 Not tainted
    -------------------------------------
    kworker/1:2/79 is trying to release lock (sb_writers) at:
    [<ffffffff811b33b4>] mnt_drop_write+0x24/0x30
    but there are no more locks to release!
    
    Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
    Signed-off-by: Jan Kara <jack@suse.cz>
    Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
  26. ARM: 7606/1: cache: flush to LoUU instead of LoUIS on uniprocessor CPUs

    wildea01 committed with gregkh Dec 19, 2012
    commit d056a69 upstream.
    
    flush_cache_louis flushes the D-side caches to the point of unification
    inner-shareable. On uniprocessor CPUs, this is defined as zero and
    therefore no flushing will take place. Rather than invent a new interface
    for UP systems, instead use our SMP_ON_UP patching code to read the
    LoUU from the CLIDR instead.
    
    Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
    Tested-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>