1. 02 Sep, 2015 1 commit
  2. 31 Aug, 2015 1 commit
  3. 22 Aug, 2015 4 commits
    • Thomas Gleixner's avatar
      x86/apic: Fix fallout from x2apic cleanup · a57e456a
      Thomas Gleixner authored
      In the recent x2apic cleanup I got two things really wrong:
      1) The safety check in __disable_x2apic which allows the function to
         be called unconditionally is backwards. The check is there to
         prevent access to the apic MSR in case that the machine has no
         apic. Though right now it returns if the machine has an apic and
         therefor the disabling of x2apic is never invoked.
      
      2) x2apic_disable() sets x2apic_mode to 0 after registering the local
         apic. That's wrong, because register_lapic_address() checks x2apic
         mode and therefor takes the wrong code path.
      
      This results in boot failures on machines with x2apic preenabled by
      BIOS and can also lead to an fatal MSR access on machines without
      apic.
      
      The solutions are simple:
      1) Correct the sanity check for apic availability
      2) Clear x2apic_mode _before_ calling register_lapic_address()
      
      Fixes: 659006bf 'x86/x2apic: Split enable and setup function'
      Reported-and-tested-by: default avatarJavier Monteagudo <javiermon@gmail.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Link: https://bugzilla.redhat.com/show_bug.cgi?id=1224764
      Cc: stable@vger.kernel.org # 4.0+
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Borislav Petkov <bp@alien8.de>
      a57e456a
    • Tim Chen's avatar
      x86/cpufeatures: Enable cpuid for Intel SHA extensions · 488ca7d7
      Tim Chen authored
      Add Intel CPUID for Intel Secure Hash Algorithm Extensions. This feature
      provides new instructions for accelerated computation of SHA-1 and SHA-256.
      This allows the feature to be shown in the /proc/cpuinfo for cpus that
      support it.
      
      Refer to SHA extension programming guide in chapter 8.2 of the Intel
      Architecture Instruction Set Extensions Programming reference
      for definition of this feature's cpuid: CPUID.(EAX=07H, ECX=0):EBX.SHA [bit 29] = 1
      https://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdfOriginally-by: default avatarChandramouli Narayanan <mouli_7982@yahoo.com>
      Signed-off-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Link: http://lkml.kernel.org/r/1440194206.3940.6.camel@schen9-mobl2Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      488ca7d7
    • Ingo Molnar's avatar
      x86/fpu/math-emu: Fix crash in fork() · 827409b2
      Ingo Molnar authored
      During later stages of math-emu bootup the following crash triggers:
      
      	 math_emulate: 0060:c100d0a8
      	 Kernel panic - not syncing: Math emulation needed in kernel
      	 CPU: 0 PID: 1511 Comm: login Not tainted 4.2.0-rc7+ #1012
      	 [...]
      	 Call Trace:
      	  [<c181d50d>] dump_stack+0x41/0x52
      	  [<c181c918>] panic+0x77/0x189
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c164c2d7>] math_emulate+0xba7/0xbd0
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c1109c3c>] ? __alloc_pages_nodemask+0x12c/0x870
      	  [<c136ac20>] ? proc_clear_tty+0x40/0x70
      	  [<c136ac6e>] ? session_clear_tty+0x1e/0x30
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c1003575>] do_device_not_available+0x45/0x70
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c18258e6>] error_code+0x5a/0x60
      	  [<c1003530>] ? math_error+0x140/0x140
      	  [<c100d0a8>] ? fpu__copy+0x138/0x1c0
      	  [<c100c205>] arch_dup_task_struct+0x25/0x30
      	  [<c1048cea>] copy_process.part.51+0xea/0x1480
      	  [<c115a8e5>] ? dput+0x175/0x200
      	  [<c136af70>] ? no_tty+0x30/0x30
      	  [<c1157242>] ? do_vfs_ioctl+0x322/0x540
      	  [<c104a21a>] _do_fork+0xca/0x340
      	  [<c1057b06>] ? SyS_rt_sigaction+0x66/0x90
      	  [<c104a557>] SyS_clone+0x27/0x30
      	  [<c1824a80>] sysenter_do_call+0x12/0x12
      
      The reason is the incorrect assumption in fpu_copy(), that FNSAVE
      can be executed from math-emu kernels as well.
      
      Don't try to copy the registers, the soft state will be copied
      by fork anyway, so the child task inherits the parent task's
      soft math state.
      
      With this fix applied math-emu kernels boot up fine on modern
      hardware and the 'no387 nofxsr' boot options.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Bobby Powers <bobbypowers@gmail.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      827409b2
    • Ingo Molnar's avatar
      x86/fpu/math-emu: Fix math-emu boot crash · 5fc96038
      Ingo Molnar authored
      On a math-emu bootup the following crash occurs:
      
      	Initializing CPU#0
      	------------[ cut here ]------------
      	kernel BUG at arch/x86/kernel/traps.c:779!
      	invalid opcode: 0000 [#1] SMP
      	[...]
      	EIP is at do_device_not_available+0xe/0x70
      	[...]
      	Call Trace:
      	 [<c18238e6>] error_code+0x5a/0x60
      	 [<c1002bd0>] ? math_error+0x140/0x140
      	 [<c100bbd9>] ? fpu__init_cpu+0x59/0xa0
      	 [<c1012322>] cpu_init+0x202/0x330
      	 [<c104509f>] ? __native_set_fixmap+0x1f/0x30
      	 [<c1b56ab0>] trap_init+0x305/0x346
      	 [<c1b548af>] start_kernel+0x1a5/0x35d
      	 [<c1b542b4>] i386_start_kernel+0x82/0x86
      
      The reason is that in the following commit:
      
        b1276c48 ("x86/fpu: Initialize fpregs in fpu__init_cpu_generic()")
      
      I failed to consider math-emu's limitation that it cannot execute the
      FNINIT instruction in kernel mode.
      
      The long term fix might be to allow math-emu to execute (certain) kernel
      mode FPU instructions, but for now apply the safe (albeit somewhat ugly)
      fix: initialize the emulation state explicitly without trapping out to
      the FPU emulator.
      
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5fc96038
  4. 20 Aug, 2015 3 commits
    • Jisheng Zhang's avatar
      x86/idle: Restore trace_cpu_idle to mwait_idle() calls · e43d0189
      Jisheng Zhang authored
      Commit b253149b ("sched/idle/x86: Restore mwait_idle() to fix boot
      hangs, to improve power savings and to improve performance") restores
      mwait_idle(), but the trace_cpu_idle related calls are missing. This
      causes powertop on my old desktop powered by Intel Core2 E6550 to
      report zero wakeups and zero events.
      
      Add them back to restore the proper behaviour.
      
      Fixes: b253149b ("sched/idle/x86: Restore mwait_idle() to ...")
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Cc: <len.brown@intel.com>
      Cc: stable@vger.kernel.org # 4.1
      Link: http://lkml.kernel.org/r/1440046479-4262-1-git-send-email-jszhang@marvell.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      e43d0189
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · 3243f50b
      Linus Torvalds authored
      Pull SCSI target fixes from Nicholas Bellinger:
       "This contains a v4.2-rc specific RCU module unload regression bug-fix,
        a long-standing iscsi-target bug-fix for duplicate target_xfer_tags
        during NOP processing from Alexei, and two more small REPORT_LUNs
        emulation related patches to make Solaris FC host LUN scanning happy
        from Roland.
      
        There is also one patch not included that allows target-core to limit
        the number of fabric driver SGLs per I/O request using residuals, that
        is currently required as a work-around for FC hosts which don't honor
        EVPD block-limits settings.  At this point, it will most likely become
        for-next material"
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
        target: Fix handling of small allocation lengths in REPORT LUNS
        target: REPORT LUNS should return LUN 0 even for dynamic ACLs
        target/iscsi: Fix double free of a TUR followed by a solicited NOPOUT
        target: Perform RCU callback barrier before backend/fabric unload
      3243f50b
    • Linus Torvalds's avatar
      Merge branch 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal · 3bd8f7d8
      Linus Torvalds authored
      Pull thermal fixes from Eduardo Valentin:
       "Last minute fixes on the thermal-soc tree.  There is a fix of a long
        lasting bug in cpu cooling device, thanks for RMK for being pushing
        this"
      
      * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal:
        thermal/cpu_cooling: update policy limits if clipped_freq < policy->max
        thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
        thermal/cpu_cooling: rename cpufreq_val as clipped_freq
        thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
        thermal/cpu_cooling: quit early after updating policy
        thermal/cpu_cooling: No need to initialize max_freq to 0
        thermal: cpu_cooling: fix lockdep problems in cpu_cooling
        thermal: power_allocator: do not use devm* interfaces
      3bd8f7d8
  5. 19 Aug, 2015 2 commits
  6. 18 Aug, 2015 4 commits
  7. 17 Aug, 2015 5 commits
  8. 16 Aug, 2015 8 commits
  9. 15 Aug, 2015 12 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · 1efdb5f0
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "This has two libfc fixes for bugs causing rare crashes, one iscsi fix
        for a potential hang on shutdown, and a fix for an I/O blocksize issue
        which caused a regression"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        sd: Fix maximum I/O size for BLOCK_PC requests
        libfc: Fix fc_fcp_cleanup_each_cmd()
        libfc: Fix fc_exch_recv_req() error path
        libiscsi: Fix host busy blocking during connection teardown
      1efdb5f0
    • Dave Airlie's avatar
      Merge tag 'topic/drm-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel into drm-next · 7945dc58
      Dave Airlie authored
      single MST fixes from Maarten.
      
      * tag 'topic/drm-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel:
        drm/dp/mst: Remove port after removing connector.
      7945dc58
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel into drm-next · 3acceca9
      Dave Airlie authored
      three display fixes for Intel.
      
      * tag 'drm-intel-fixes-2015-08-14' of git://anongit.freedesktop.org/drm-intel:
        drm/i915: Commit planes on each crtc separately.
        drm/i915: calculate primary visibility changes instead of calling from set_config
        drm/i915: Only dither on 6bpc panels
      3acceca9
    • Viresh Kumar's avatar
      thermal/cpu_cooling: update policy limits if clipped_freq < policy->max · 1afb9c53
      Viresh Kumar authored
      policy->max is the maximum allowed frequency defined by user and
      clipped_freq is the maximum that thermal constraints allow.
      
      If clipped_freq is lower than policy->max, then we need to readjust
      policy->max.
      
      But, if clipped_freq is greater than policy->max, we don't need to do
      anything. We used to call cpufreq_verify_within_limits() in this case,
      but it doesn't change anything in this case.
      
      Lets skip this unnecessary call and write a comment that explains this.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      1afb9c53
    • Viresh Kumar's avatar
      thermal/cpu_cooling: rename max_freq as clipped_freq in notifier · abcbcc25
      Viresh Kumar authored
      That's what it is for, lets name it properly.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      abcbcc25
    • Viresh Kumar's avatar
      thermal/cpu_cooling: rename cpufreq_val as clipped_freq · 59f0d218
      Viresh Kumar authored
      That's what it is for, lets name it properly.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      59f0d218
    • Viresh Kumar's avatar
      thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier · a24af233
      Viresh Kumar authored
      We just need to take care of single event here and there is no need to
      increase indentation level of most of the code (which causes lines
      longer that 80 columns to break).
      
      Kill the switch block.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      a24af233
    • Viresh Kumar's avatar
      thermal/cpu_cooling: quit early after updating policy · 166529c9
      Viresh Kumar authored
      If a valid cpufreq_dev is found for policy->cpu, we should update the
      policy and quit the for loop. There is no need to keep traversing the
      list of cpufreq_dev's.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarEduardo Valentin <edubezval@gmail.com>
      166529c9
    • 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
    • Linus Torvalds's avatar
      Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm · 45e38cff
      Linus Torvalds authored
      Pull KVM fixes from Paolo Bonzini:
       "Just two very small & simple patches"
      
      * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
        KVM: x86: Use adjustment in guest cycles when handling MSR_IA32_TSC_ADJUST
        KVM: x86: zero IDT limit on entry to SMM
      45e38cff
    • Linus Torvalds's avatar
      Merge branch 'akpm' (patches from Andrew) · 8394a1b7
      Linus Torvalds authored
      Merge fixes from Andrew Morton:
       "11 fixes"
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        Update maintainers for DRM STI driver
        mm: cma: mark cma_bitmap_maxno() inline in header
        zram: fix pool name truncation
        memory-hotplug: fix wrong edge when hot add a new node
        .mailmap: Andrey Ryabinin has moved
        ipc/sem.c: update/correct memory barriers
        mm/hwpoison: fix panic due to split huge zero page
        ipc,sem: remove uneeded sem_undo_list lock usage in exit_sem()
        ipc,sem: fix use after free on IPC_RMID after a task using same semaphore set exits
        mm/hwpoison: fix fail isolate hugetlbfs page w/ refcount held
        mm/hwpoison: fix page refcount of unknown non LRU page
      8394a1b7