1. 15 Aug, 2015 2 commits
    • Viresh Kumar's avatar
      thermal/cpu_cooling: No need to initialize max_freq to 0 · 76fd38ce
      Viresh Kumar authored
      Its always set before getting used, don't initialize it.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      76fd38ce
    • Russell King's avatar
      thermal: cpu_cooling: fix lockdep problems in cpu_cooling · 02373d7c
      Russell King authored
      A recent change to the cpu_cooling code introduced a AB-BA deadlock
      scenario between the cpufreq_policy_notifier_list rwsem and the
      cooling_cpufreq_lock.  This is caused by cooling_cpufreq_lock being held
      before the registration/removal of the notifier block (an operation
      which takes the rwsem), and the notifier code itself which takes the
      locks in the reverse order:
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.18.0+ #1453 Not tainted
      -------------------------------------------------------
      rc.local/770 is trying to acquire lock:
       (cooling_cpufreq_lock){+.+.+.}, at: [<c04abfc4>] cpufreq_thermal_notifier+0x34/0xfc
      
      but task is already holding lock:
       ((cpufreq_policy_notifier_list).rwsem){++++.+}, at: [<c0042f04>]  __blocking_notifier_call_chain+0x34/0x68
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 ((cpufreq_policy_notifier_list).rwsem){++++.+}:
             [<c06bc3b0>] down_write+0x44/0x9c
             [<c0043444>] blocking_notifier_chain_register+0x28/0xd8
             [<c04ad610>] cpufreq_register_notifier+0x68/0x90
             [<c04abe4c>] __cpufreq_cooling_register.part.1+0x120/0x180
             [<c04abf44>] __cpufreq_cooling_register+0x98/0xa4
             [<c04abf8c>] cpufreq_cooling_register+0x18/0x1c
             [<bf0046f8>] imx_thermal_probe+0x1c0/0x470 [imx_thermal]
             [<c037cef8>] platform_drv_probe+0x50/0xac
             [<c037b710>] driver_probe_device+0x114/0x234
             [<c037b8cc>] __driver_attach+0x9c/0xa0
             [<c0379d68>] bus_for_each_dev+0x5c/0x90
             [<c037b204>] driver_attach+0x24/0x28
             [<c037ae7c>] bus_add_driver+0xe0/0x1d8
             [<c037c0cc>] driver_register+0x80/0xfc
             [<c037cd80>] __platform_driver_register+0x50/0x64
             [<bf007018>] 0xbf007018
             [<c0008a5c>] do_one_initcall+0x88/0x1d8
             [<c0095da4>] load_module+0x1768/0x1ef8
             [<c0096614>] SyS_init_module+0xe0/0xf4
             [<c000ec00>] ret_fast_syscall+0x0/0x48
      
      -> #0 (cooling_cpufreq_lock){+.+.+.}:
             [<c00619f8>] lock_acquire+0xb0/0x124
             [<c06ba3b4>] mutex_lock_nested+0x5c/0x3d8
             [<c04abfc4>] cpufreq_thermal_notifier+0x34/0xfc
             [<c0042bf4>] notifier_call_chain+0x4c/0x8c
             [<c0042f20>] __blocking_notifier_call_chain+0x50/0x68
             [<c0042f58>] blocking_notifier_call_chain+0x20/0x28
             [<c04ae62c>] cpufreq_set_policy+0x7c/0x1d0
             [<c04af3cc>] store_scaling_governor+0x74/0x9c
             [<c04ad418>] store+0x90/0xc0
             [<c0175384>] sysfs_kf_write+0x54/0x58
             [<c01746b4>] kernfs_fop_write+0xdc/0x190
             [<c010dcc0>] vfs_write+0xac/0x1b4
             [<c010dfec>] SyS_write+0x44/0x90
             [<c000ec00>] ret_fast_syscall+0x0/0x48
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((cpufreq_policy_notifier_list).rwsem);
                                     lock(cooling_cpufreq_lock);
                                     lock((cpufreq_policy_notifier_list).rwsem);
        lock(cooling_cpufreq_lock);
      
       *** DEADLOCK ***
      
      7 locks held by rc.local/770:
       #0:  (sb_writers#6){.+.+.+}, at: [<c010dda0>] vfs_write+0x18c/0x1b4
       #1:  (&of->mutex){+.+.+.}, at: [<c0174678>] kernfs_fop_write+0xa0/0x190
       #2:  (s_active#52){.+.+.+}, at: [<c0174680>] kernfs_fop_write+0xa8/0x190
       #3:  (cpu_hotplug.lock){++++++}, at: [<c0026a60>] get_online_cpus+0x34/0x90
       #4:  (cpufreq_rwsem){.+.+.+}, at: [<c04ad3e0>] store+0x58/0xc0
       #5:  (&policy->rwsem){+.+.+.}, at: [<c04ad3f8>] store+0x70/0xc0
       #6:  ((cpufreq_policy_notifier_list).rwsem){++++.+}, at: [<c0042f04>] __blocking_notifier_call_chain+0x34/0x68
      
      stack backtrace:
      CPU: 0 PID: 770 Comm: rc.local Not tainted 3.18.0+ #1453
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Backtrace:
      [<c00121c8>] (dump_backtrace) from [<c0012360>] (show_stack+0x18/0x1c)
       r6:c0b85a80 r5:c0b75630 r4:00000000 r3:00000000
      [<c0012348>] (show_stack) from [<c06b6c48>] (dump_stack+0x7c/0x98)
      [<c06b6bcc>] (dump_stack) from [<c06b42a4>] (print_circular_bug+0x28c/0x2d8)
       r4:c0b85a80 r3:d0071d40
      [<c06b4018>] (print_circular_bug) from [<c00613b0>] (__lock_acquire+0x1acc/0x1bb0)
       r10:c0b50660 r8:c09e6d80 r7:d0071d40 r6:c11d0f0c r5:00000007 r4:d0072240
      [<c005f8e4>] (__lock_acquire) from [<c00619f8>] (lock_acquire+0xb0/0x124)
       r10:00000000 r9:c04abfc4 r8:00000000 r7:00000000 r6:00000000 r5:c0a06f0c
       r4:00000000
      [<c0061948>] (lock_acquire) from [<c06ba3b4>] (mutex_lock_nested+0x5c/0x3d8)
       r10:ec853800 r9:c0a06ed4 r8:d0071d40 r7:c0a06ed4 r6:c11d0f0c r5:00000000
       r4:c04abfc4
      [<c06ba358>] (mutex_lock_nested) from [<c04abfc4>] (cpufreq_thermal_notifier+0x34/0xfc)
       r10:ec853800 r9:ec85380c r8:d00d7d3c r7:c0a06ed4 r6:d00d7d3c r5:00000000
       r4:fffffffe
      [<c04abf90>] (cpufreq_thermal_notifier) from [<c0042bf4>] (notifier_call_chain+0x4c/0x8c)
       r7:00000000 r6:00000000 r5:00000000 r4:fffffffe
      [<c0042ba8>] (notifier_call_chain) from [<c0042f20>] (__blocking_notifier_call_chain+0x50/0x68)
       r8:c0a072a4 r7:00000000 r6:d00d7d3c r5:ffffffff r4:c0a06fc8 r3:ffffffff
      [<c0042ed0>] (__blocking_notifier_call_chain) from [<c0042f58>] (blocking_notifier_call_chain+0x20/0x28)
       r7:ec98b540 r6:c13ebc80 r5:ed76e600 r4:d00d7d3c
      [<c0042f38>] (blocking_notifier_call_chain) from [<c04ae62c>] (cpufreq_set_policy+0x7c/0x1d0)
      [<c04ae5b0>] (cpufreq_set_policy) from [<c04af3cc>] (store_scaling_governor+0x74/0x9c)
       r7:ec98b540 r6:0000000c r5:ec98b540 r4:ed76e600
      [<c04af358>] (store_scaling_governor) from [<c04ad418>] (store+0x90/0xc0)
       r6:0000000c r5:ed76e6d4 r4:ed76e600
      [<c04ad388>] (store) from [<c0175384>] (sysfs_kf_write+0x54/0x58)
       r8:0000000c r7:d00d7f78 r6:ec98b540 r5:0000000c r4:ec853800 r3:0000000c
      [<c0175330>] (sysfs_kf_write) from [<c01746b4>] (kernfs_fop_write+0xdc/0x190)
       r6:ec98b540 r5:00000000 r4:00000000 r3:c0175330
      [<c01745d8>] (kernfs_fop_write) from [<c010dcc0>] (vfs_write+0xac/0x1b4)
       r10:0162aa70 r9:d00d6000 r8:0000000c r7:d00d7f78 r6:0162aa70 r5:0000000c
       r4:eccde500
      [<c010dc14>] (vfs_write) from [<c010dfec>] (SyS_write+0x44/0x90)
       r10:0162aa70 r8:0000000c r7:eccde500 r6:eccde500 r5:00000000 r4:00000000
      [<c010dfa8>] (SyS_write) from [<c000ec00>] (ret_fast_syscall+0x0/0x48)
       r10:00000000 r8:c000edc4 r7:00000004 r6:000216cc r5:0000000c r4:0162aa70
      
      Solve this by moving to finer grained locking - use one mutex to protect
      the cpufreq_dev_list as a whole, and a separate lock to ensure correct
      ordering of cpufreq notifier registration and removal.
      
      cooling_list_lock is taken within cooling_cpufreq_lock on
      (un)registration to preserve the behavior of the code, i.e. to
      atomically add/remove to the list and (un)register the notifier.
      
      Fixes: 2dcd851f ("thermal: cpu_cooling: Update always cpufreq policy with
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      02373d7c
  2. 14 Aug, 2015 1 commit
  3. 13 Aug, 2015 9 commits
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm · 7ddab733
      Linus Torvalds authored
      Pull ARM fixes from Russell King:
       "Another few small ARM fixes, mostly addressing some VDSO issues"
      
      * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
        ARM: 8410/1: VDSO: fix coarse clock monotonicity regression
        ARM: 8409/1: Mark ret_fast_syscall as a function
        ARM: 8408/1: Fix the secondary_startup function in Big Endian case
        ARM: 8405/1: VDSO: fix regression with toolchains lacking ld.bfd executable
      7ddab733
    • Linus Torvalds's avatar
      x86: fix error handling for 32-bit compat out-of-range system call numbers · cd88ec23
      Linus Torvalds authored
      Commit 3f5159a9 ("x86/asm/entry/32: Update -ENOSYS handling to match
      the 64-bit logic") broke the ENOSYS handling for the 32-bit compat case.
      The proper error return value was never loaded into %rax, except if
      things just happened to go through the audit paths, which ended up
      reloading the return value.
      
      This moves the loading or %rax into the normal system call path, just to
      make sure the error case triggers it.  It's kind of sad, since it adds a
      useless instruction to reload the register to the fast path, but it's
      not like that single load from the stack is going to be noticeable.
      Reported-by: default avatarDavid Drysdale <drysdale@google.com>
      Tested-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      cd88ec23
    • Linus Torvalds's avatar
      Merge tag 'dm-4.2-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm · 5b3e2e14
      Linus Torvalds authored
      Pull device mapper fixes from Mike Snitzer:
      
       - two stable fixes for corruption seen in a snapshot of thinp metadata;
         metadata snapshots aren't widely used but help provide a consistent
         view of the metadata associated with an active thin-pool.
      
       - a dm-cache fix for the 4.2 "default" policy switch from "mq" to "smq"
      
      * tag 'dm-4.2-fixes-5' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
        dm cache policy smq: move 'dm-cache-default' module alias to SMQ
        dm btree: add ref counting ops for the leaves of top level btrees
        dm thin metadata: delete btrees when releasing metadata snapshot
      5b3e2e14
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · ebcbf166
      Linus Torvalds authored
      Pull xen block driver fixes from Jens Axboe:
       "A few small bug fixes for xen-blk{front,back} that have been sitting
        over my vacation"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        xen-blkback: replace work_pending with work_busy in purge_persistent_gnt()
        xen-blkfront: don't add indirect pages to list when !feature_persistent
        xen-blkfront: introduce blkfront_gather_backend_features()
      ebcbf166
    • Linus Torvalds's avatar
      Merge tag 'for-linus-4.2-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · 6b476e11
      Linus Torvalds authored
      Pull xen bug fixes from David Vrabel:
      
       - revert a fix from 4.2-rc5 that was causing lots of WARNING spam.
      
       - fix a memory leak affecting backends in HVM guests.
      
       - fix PV domU hang with certain configurations.
      
      * tag 'for-linus-4.2-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
        xen/xenbus: Don't leak memory when unmapping the ring on HVM backend
        Revert "xen/events/fifo: Handle linked events when closing a port"
        x86/xen: build "Xen PV" APIC driver for domU as well
      6b476e11
    • Linus Torvalds's avatar
      Revert x86 sigcontext cleanups · ed596cde
      Linus Torvalds authored
      This reverts commits 9a036b93 ("x86/signal/64: Remove 'fs' and 'gs'
      from sigcontext") and c6f20629 ("x86/signal/64: Fix SS handling for
      signals delivered to 64-bit programs").
      
      They were cleanups, but they break dosemu by changing the signal return
      behavior (and removing 'fs' and 'gs' from the sigcontext struct - while
      not actually changing any behavior - causes build problems).
      Reported-and-tested-by: default avatarStas Sergeev <stsp@list.ru>
      Acked-by: default avatarAndy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ed596cde
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 26b552e0
      Linus Torvalds authored
      Pull networking fixes from David Miller:
      
       1) Workaround hw bug when acquiring PCI bos ownership of iwlwifi
          devices, from Emmanuel Grumbach.
      
       2) Falling back to vmalloc in conntrack should not emit a warning, from
          Pablo Neira Ayuso.
      
       3) Fix NULL deref when rtlwifi driver is used as an AP, from Luis
          Felipe Dominguez Vega.
      
       4) Rocker doesn't free netdev on device removal, from Ido Schimmel.
      
       5) UDP multicast early sock demux has route handling races, from Eric
          Dumazet.
      
       6) Fix L4 checksum handling in openvswitch, from Glenn Griffin.
      
       7) Fix use-after-free in skb_set_peeked, from Herbert Xu.
      
       8) Don't advertize NETIF_F_FRAGLIST in virtio_net driver, this can lead
          to fraglists longer than the driver can support.  From Jason Wang.
      
       9) Fix mlx5 on non-4k-pagesize systems, from Carol L Soto.
      
      10) Fix interrupt storm in bna driver, from Ivan Vecera.
      
      11) Don't propagate -EBUSY from netlink_insert(), from Daniel Borkmann.
      
      12) Fix inet request sock leak, from Eric Dumazet.
      
      13) Fix TX interrupt masking and marking in TX descriptors of fs_enet
          driver, from LEROY Christophe.
      
      14) Get rid of rule optimizer in gianfar driver, it's buggy and unlikely
          to get fixed any time soon.  From Jakub Kicinski
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (61 commits)
        cosa: missing error code on failure in probe()
        gianfar: remove faulty filer optimizer
        gianfar: correct list membership accounting
        gianfar: correct filer table writing
        bonding: Gratuitous ARP gets dropped when first slave added
        net: dsa: Do not override PHY interface if already configured
        net: fs_enet: mask interrupts for TX partial frames.
        net: fs_enet: explicitly remove I flag on TX partial frames
        inet: fix possible request socket leak
        inet: fix races with reqsk timers
        mkiss: Fix error handling in mkiss_open()
        bnx2x: Free NVRAM lock at end of each page
        bnx2x: Prevent null pointer dereference on SKB release
        cxgb4: missing curly braces in t4_setup_debugfs()
        net-timestamp: Update skb_complete_tx_timestamp comment
        ipv6: don't reject link-local nexthop on other interface
        netlink: make sure -EBUSY won't escape from netlink_insert
        bna: fix interrupts storm caused by erroneous packets
        net: mvpp2: replace TX coalescing interrupts with hrtimer
        net: mvpp2: enable proper per-CPU TX buffers unmapping
        ...
      26b552e0
    • Linus Torvalds's avatar
      Merge tag 'edac_fix_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp · 2331d30d
      Linus Torvalds authored
      Pull EDAC fix from Borislav Petkov:
       "A ppc4xx_edac fix for accessing ->csrows properly.  This driver was
        missed during the conversion a couple of years ago"
      
      * tag 'edac_fix_for_4.2' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp:
        EDAC, ppc4xx: Access mci->csrows array elements properly
      2331d30d
    • Michael Walle's avatar
      EDAC, ppc4xx: Access mci->csrows array elements properly · 5c16179b
      Michael Walle authored
      The commit
      
        de3910eb ("edac: change the mem allocation scheme to
      		 make Documentation/kobject.txt happy")
      
      changed the memory allocation for the csrows member. But ppc4xx_edac was
      forgotten in the patch. Fix it.
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Cc: <stable@vger.kernel.org>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Link: http://lkml.kernel.org/r/1437469253-8611-1-git-send-email-michael@walle.ccSigned-off-by: default avatarBorislav Petkov <bp@suse.de>
      5c16179b
  4. 12 Aug, 2015 16 commits
  5. 11 Aug, 2015 12 commits