1. 05 Sep, 2018 1 commit
  2. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  3. 01 Nov, 2017 2 commits
    • Don Zickus's avatar
      watchdog/hardlockup/perf: Use atomics to track in-use cpu counter · 42f930da
      Don Zickus authored
      Guenter reported:
        There is still a problem. When running 
          echo 6 > /proc/sys/kernel/watchdog_thresh
          echo 5 > /proc/sys/kernel/watchdog_thresh
        repeatedly, the message
       
         NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
       
        stops after a while (after ~10-30 iterations, with fluctuations).
        Maybe watchdog_cpus needs to be atomic ?
      
      That's correct as this again is affected by the asynchronous nature of the
      smpboot thread unpark mechanism.
      
      CPU 0				CPU1			CPU2
      write(watchdog_thresh, 6)	
        stop()
          park()
        update()
        start()
          unpark()
      				thread->unpark()
      				  cnt++;
      write(watchdog_thresh, 5)				thread->unpark()
        stop()
          park()			thread->park()
      				   cnt--;		  cnt++;
        update()
        start()
          unpark()
      
      That's not a functional problem, it just affects the informational message.
      
      Convert watchdog_cpus to atomic_t to prevent the problem
      Reported-and-tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDon Zickus <dzickus@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20171101181126.j727fqjmdthjz4xk@redhat.com
      
      42f930da
    • Thomas Gleixner's avatar
      watchdog/harclockup/perf: Revert a33d4484 ("watchdog/hardlockup/perf:... · 9c388a5e
      Thomas Gleixner authored
      watchdog/harclockup/perf: Revert a33d4484 ("watchdog/hardlockup/perf: Simplify deferred event destroy")
      
      Guenter reported a crash in the watchdog/perf code, which is caused by
      cleanup() and enable() running concurrently. The reason for this is:
      
      The watchdog functions are serialized via the watchdog_mutex and cpu
      hotplug locking, but the enable of the perf based watchdog happens in
      context of the unpark callback of the smpboot thread. But that unpark
      function is not synchronous inside the locking. The unparking of the thread
      just wakes it up and leaves so there is no guarantee when the thread is
      executing.
      
      If it starts running _before_ the cleanup happened then it will create a
      event and overwrite the dead event pointer. The new event is then cleaned
      up because the event is marked dead.
      
          lock(watchdog_mutex);
          lockup_detector_reconfigure();
              cpus_read_lock();
      	stop();
      	   park()
      	update();
      	start();
      	   unpark()
      	cpus_read_unlock();		thread runs()
      					  overwrite dead event ptr
      	cleanup();
      	  free new event, which is active inside perf....
          unlock(watchdog_mutex);
      
      The park side is safe as that actually waits for the thread to reach
      parked state.
      
      Commit a33d4484 removed the protection against this kind of scenario
      under the stupid assumption that the hotplug serialization and the
      watchdog_mutex cover everything. 
      
      Bring it back.
      
      Reverts: a33d4484 ("watchdog/hardlockup/perf: Simplify deferred event destroy")
      Reported-and-tested-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarThomas Feels-stupid Gleixner <tglx@linutronix.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Don Zickus <dzickus@redhat.com>
      Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1710312145190.1942@nanos
      
      
      9c388a5e
  4. 28 Sep, 2017 1 commit
  5. 25 Sep, 2017 1 commit
  6. 14 Sep, 2017 8 commits
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Simplify deferred event destroy · a33d4484
      Thomas Gleixner authored
      Now that all functionality is properly serialized against CPU hotplug,
      remove the extra per cpu storage which holds the disabled events for
      cleanup. The core makes sure that cleanup happens before new events are
      created.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194148.340708074@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a33d4484
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Use new perf CPU enable mechanism · 146c9d0e
      Thomas Gleixner authored
      Get rid of the hodgepodge which tries to be smart about perf being
      unavailable and error printout rate limiting.
      
      That's all not required simply because this is never invoked when the perf
      NMI watchdog is not functional.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194148.259651788@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      146c9d0e
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Implement CPU enable replacement · 2a1b8ee4
      Thomas Gleixner authored
      watchdog_nmi_enable() is an unparseable mess, Provide a clean perf specific
      implementation, which will be used when the existing setup/teardown mess is
      replaced.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194148.180215498@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2a1b8ee4
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Implement init time perf validation · 178b9f7a
      Thomas Gleixner authored
      The watchdog tries to create perf events even after it figured out that
      perf is not functional or the requested event is not supported.
      
      That's braindead as this can be done once at init time and if not supported
      the NMI watchdog can be turned off unconditonally.
      
      Implement the perf hardlockup detector functionality for that. This creates
      a new event create function, which will replace the unholy mess of the
      existing one in later patches.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194148.019090547@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      178b9f7a
    • Thomas Gleixner's avatar
      watchdog/core: Remove the park_in_progress obfuscation · 01f0a027
      Thomas Gleixner authored
      Commit:
      
        b94f5118 ("kernel/watchdog: prevent false hardlockup on overloaded system")
      
      tries to fix the following issue:
      
      proc_write()
         set_sample_period()    <--- New sample period becoms visible
      			  <----- Broken starts
         proc_watchdog_update()
           watchdog_enable_all_cpus()		watchdog_hrtimer_fn()
           update_watchdog_all_cpus()		   restart_timer(sample_period)
              watchdog_park_threads()
      
      					thread->park()
      					  disable_nmi()
      			  <----- Broken ends
      
      The reason why this is broken is that the update of the watchdog threshold
      becomes immediately effective and visible for the hrtimer function which
      uses that value to rearm the timer. But the NMI/perf side still uses the
      old value up to the point where it is disabled. If the rate has been
      lowered then the NMI can run fast enough to 'detect' a hard lockup because
      the timer has not fired due to the longer period.
      
      The patch 'fixed' this by adding a variable:
      
      proc_write()
         set_sample_period()
      					<----- Broken starts
         proc_watchdog_update()
           watchdog_enable_all_cpus()		watchdog_hrtimer_fn()
           update_watchdog_all_cpus()		   restart_timer(sample_period)
               watchdog_park_threads()
      	  park_in_progress = 1
      					<----- Broken ends
      				        nmi_watchdog()
      					  if (park_in_progress)
      					     return;
      
      The only effect of this variable was to make the window where the breakage
      can hit small enough that it was not longer observable in testing. From a
      correctness point of view it is a pointless bandaid which merily papers
      over the root cause: the unsychronized update of the variable.
      
      Looking deeper into the related code pathes unearthed similar problems in
      the watchdog_start()/stop() functions.
      
       watchdog_start()
      	perf_nmi_event_start()
      	hrtimer_start()
      
       watchdog_stop()
      	hrtimer_cancel()
      	perf_nmi_event_stop()
      
      In both cases the call order is wrong because if the tasks gets preempted
      or the VM gets scheduled out long enough after the first call, then there is
      a chance that the next NMI will see a stale hrtimer interrupt count and
      trigger a false positive hard lockup splat.
      
      Get rid of park_in_progress so the code can be gradually deobfuscated and
      pruned from several layers of duct tape papering over the root cause,
      which has been either ignored or not understood at all.
      
      Once this is removed the underlying problem will be fixed by rewriting the
      proc interface to do a proper synchronized update.
      
      Address the start/stop() ordering problem as well by reverting the call
      order, so this part is at least correct now.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1709052038270.2393@nanosSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      01f0a027
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Prevent CPU hotplug deadlock · 941154bd
      Thomas Gleixner authored
      The following deadlock is possible in the watchdog hotplug code:
      
        cpus_write_lock()
          ...
            takedown_cpu()
              smpboot_park_threads()
                smpboot_park_thread()
                  kthread_park()
                    ->park() := watchdog_disable()
                      watchdog_nmi_disable()
                        perf_event_release_kernel();
                          put_event()
                            _free_event()
                              ->destroy() := hw_perf_event_destroy()
                                x86_release_hardware()
                                  release_ds_buffers()
                                    get_online_cpus()
      
      when a per cpu watchdog perf event is destroyed which drops the last
      reference to the PMU hardware. The cleanup code there invokes
      get_online_cpus() which instantly deadlocks because the hotplug percpu
      rwsem is write locked.
      
      To solve this add a deferring mechanism:
      
        cpus_write_lock()
      			   kthread_park()
      			    watchdog_nmi_disable(deferred)
      			      perf_event_disable(event);
      			      move_event_to_deferred(event);
      			   ....
        cpus_write_unlock()
        cleaup_deferred_events()
          perf_event_release_kernel()
      
      This is still properly serialized against concurrent hotplug via the
      cpu_add_remove_lock, which is held by the task which initiated the hotplug
      event.
      
      This is also used to handle event destruction when the watchdog threads are
      parked via other mechanisms than CPU hotplug.
      Analyzed-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Reported-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194146.884469246@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      941154bd
    • Thomas Gleixner's avatar
      watchdog/hardlockup/perf: Remove broken self disable on failure · 20d853fd
      Thomas Gleixner authored
      The self disabling feature is broken vs. CPU hotplug locking:
      
      CPU 0			   CPU 1
      cpus_write_lock();
       cpu_up(1)
         wait_for_completion()
      			   ....
      			   unpark_watchdog()
      			   ->unpark()
      			     perf_event_create() <- fails
      			       watchdog_enable &= ~NMI_WATCHDOG;
      			   ....
      cpus_write_unlock();
      			   CPU 2
      cpus_write_lock()
       cpu_down(2)
         wait_for_completion()
      			   wakeup(watchdog);
      			     watchdog()
      			     if (!(watchdog_enable & NMI_WATCHDOG))
      				watchdog_nmi_disable()
      				  perf_event_disable()
      				  ....
      				  cpus_read_lock();
      
      			   stop_smpboot_threads()
      			     park_watchdog();
      			       wait_for_completion(watchdog->parked);
      
      Result: End of hotplug and instantaneous full lockup of the machine.
      
      There is a similar problem with disabling the watchdog via the user space
      interface as the sysctl function fiddles with watchdog_enable directly.
      
      It's very debatable whether this is required at all. If the watchdog works
      nicely on N CPUs and it fails to enable on the N + 1 CPU either during
      hotplug or because the user space interface disabled it via sysctl cpumask
      and then some perf user grabbed the counter which is then unavailable for
      the watchdog when the sysctl cpumask gets changed back.
      
      There is no real justification for this.
      
      One of the reasons WHY this is done is the utter stupidity of the init code
      of the perf NMI watchdog. Instead of checking upfront at boot whether PERF
      is available and functional at all, it just does this check at run time
      over and over when user space fiddles with the sysctl. That's broken beyond
      repair along with the idiotic error code dependent warn level printks and
      the even more silly printk rate limiting.
      
      If the init code checks whether perf works at boot time, then this mess can
      be more or less avoided completely. Perf does not come magically into life
      at runtime. Brain usage while coding is overrated.
      
      Remove the cruft and add a temporary safe guard which gets removed later.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194146.806708429@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      20d853fd
    • Peter Zijlstra's avatar
      watchdog/hardlockup: Provide interface to stop/restart perf events · d0b6e0a8
      Peter Zijlstra authored
      Provide an interface to stop and restart perf NMI watchdog events on all
      CPUs. This is only usable during init and especially for handling the perf
      HT bug on Intel machines. It's safe to use it this way as nothing can
      start/stop the NMI watchdog in parallel.
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Sebastian Siewior <bigeasy@linutronix.de>
      Cc: Ulrich Obergfell <uobergfe@redhat.com>
      Link: http://lkml.kernel.org/r/20170912194146.167649596@linutronix.deSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d0b6e0a8
  7. 18 Aug, 2017 1 commit
    • Thomas Gleixner's avatar
      kernel/watchdog: Prevent false positives with turbo modes · 7edaeb68
      Thomas Gleixner authored
      The hardlockup detector on x86 uses a performance counter based on unhalted
      CPU cycles and a periodic hrtimer. The hrtimer period is about 2/5 of the
      performance counter period, so the hrtimer should fire 2-3 times before the
      performance counter NMI fires. The NMI code checks whether the hrtimer
      fired since the last invocation. If not, it assumess a hard lockup.
      
      The calculation of those periods is based on the nominal CPU
      frequency. Turbo modes increase the CPU clock frequency and therefore
      shorten the period of the perf/NMI watchdog. With extreme Turbo-modes (3x
      nominal frequency) the perf/NMI period is shorter than the hrtimer period
      which leads to false positives.
      
      A simple fix would be to shorten the hrtimer period, but that comes with
      the side effect of more frequent hrtimer and softlockup thread wakeups,
      which is not desired.
      
      Implement a low pass filter, which checks the perf/NMI period against
      kernel time. If the perf/NMI fires before 4/5 of the watchdog period has
      elapsed then the event is ignored and postponed to the next perf/NMI.
      
      That solves the problem and avoids the overhead of shorter hrtimer periods
      and more frequent softlockup thread wakeups.
      
      Fixes: 58687acb ("lockup_detector: Combine nmi_watchdog and softlockup detector")
      Reported-and-tested-by: default avatarKan Liang <Kan.liang@intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: dzickus@redhat.com
      Cc: prarit@redhat.com
      Cc: ak@linux.intel.com
      Cc: babu.moger@oracle.com
      Cc: peterz@infradead.org
      Cc: eranian@google.com
      Cc: acme@redhat.com
      Cc: stable@vger.kernel.org
      Cc: atomlin@redhat.com
      Cc: akpm@linux-foundation.org
      Cc: torvalds@linux-foundation.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1708150931310.1886@nanos
      7edaeb68
  8. 12 Jul, 2017 2 commits
  9. 02 Mar, 2017 1 commit
  10. 23 Feb, 2017 1 commit
    • Prarit Bhargava's avatar
      kernel/watchdog.c: do not hardcode CPU 0 as the initial thread · 8dcde9de
      Prarit Bhargava authored
      When CONFIG_BOOTPARAM_HOTPLUG_CPU0 is enabled, the socket containing the
      boot cpu can be replaced.  During the hot add event, the message
      
      NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
      
      is output implying that the NMI watchdog was disabled at some point.  This
      is not the case and the message has caused confusion for users of systems
      that support the removal of the boot cpu socket.
      
      The watchdog code is coded to assume that cpu 0 is always the first cpu to
      initialize the watchdog, and the last to stop its watchdog thread.  That
      is not the case for initializing if cpu 0 has been removed and added.  The
      removal case has never been correct because the smpboot code will remove
      the watchdog threads starting with the lowest cpu number.
      
      This patch adds watchdog_cpus to track the number of cpus with active NMI
      watchdog threads so that the first and last thread can be used to set and
      clear the value of firstcpu_err.  firstcpu_err is set when the first
      watchdog thread is enabled, and cleared when the last watchdog thread is
      disabled.
      
      Link: http://lkml.kernel.org/r/1480425321-32296-1-git-send-email-prarit@redhat.comSigned-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Acked-by: default avatarDon Zickus <dzickus@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Joshua Hunt <johunt@akamai.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Babu Moger <babu.moger@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8dcde9de
  11. 25 Jan, 2017 1 commit
  12. 15 Dec, 2016 1 commit