1. 01 Nov, 2018 1 commit
    • Philippe Gerum's avatar
      genirq: add generic I-pipe core · d9f057db
      Philippe Gerum authored
      This commit provides the arch-independent bits for implementing the
      interrupt pipeline core, a lightweight layer introducing a separate,
      high-priority execution stage for handling all IRQs in pseudo-NMI
      mode, which cannot be delayed by the regular kernel code. See
      Documentation/ipipe.rst for details about interrupt pipelining.
      
      Architectures which support interrupt pipelining should select
      HAVE_IPIPE_SUPPORT, along with implementing the required arch-specific
      code. In such a case, CONFIG_IPIPE becomes available to the user via
      the Kconfig interface for enabling the feature.
      d9f057db
  2. 22 Feb, 2018 1 commit
  3. 16 Feb, 2018 1 commit
    • Arnd Bergmann's avatar
      kasan: rework Kconfig settings · 062cd346
      Arnd Bergmann authored
      commit e7c52b84 upstream.
      
      We get a lot of very large stack frames using gcc-7.0.1 with the default
      -fsanitize-address-use-after-scope --param asan-stack=1 options, which can
      easily cause an overflow of the kernel stack, e.g.
      
        drivers/gpu/drm/i915/gvt/handlers.c:2434:1: warning: the frame size of 46176 bytes is larger than 3072 bytes
        drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5650:1: warning: the frame size of 23632 bytes is larger than 3072 bytes
        lib/atomic64_test.c:250:1: warning: the frame size of 11200 bytes is larger than 3072 bytes
        drivers/gpu/drm/i915/gvt/handlers.c:2621:1: warning: the frame size of 9208 bytes is larger than 3072 bytes
        drivers/media/dvb-frontends/stv090x.c:3431:1: warning: the frame size of 6816 bytes is larger than 3072 bytes
        fs/fscache/stats.c:287:1: warning: the frame size of 6536 bytes is larger than 3072 bytes
      
      To reduce this risk, -fsanitize-address-use-after-scope is now split out
      into a separate CONFIG_KASAN_EXTRA Kconfig option, leading to stack
      frames that are smaller than 2 kilobytes most of the time on x86_64.  An
      earlier version of this patch also prevented combining KASAN_EXTRA with
      KASAN_INLINE, but that is no longer necessary with gcc-7.0.1.
      
      All patches to get the frame size below 2048 bytes with CONFIG_KASAN=y
      and CONFIG_KASAN_EXTRA=n have been merged by maintainers now, so we can
      bring back that default now.  KASAN_EXTRA=y still causes lots of
      warnings but now defaults to !COMPILE_TEST to disable it in
      allmodconfig, and it remains disabled in all other defconfigs since it
      is a new option.  I arbitrarily raise the warning limit for KASAN_EXTRA
      to 3072 to reduce the noise, but an allmodconfig kernel still has around
      50 warnings on gcc-7.
      
      I experimented a bit more with smaller stack frames and have another
      follow-up series that reduces the warning limit for 64-bit architectures
      to 1280 bytes (without CONFIG_KASAN).
      
      With earlier versions of this patch series, I also had patches to address
      the warnings we get with KASAN and/or KASAN_EXTRA, using a
      "noinline_if_stackbloat" annotation.
      
      That annotation now got replaced with a gcc-8 bugfix (see
      https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715) and a workaround for
      older compilers, which means that KASAN_EXTRA is now just as bad as
      before and will lead to an instant stack overflow in a few extreme
      cases.
      
      This reverts parts of commit 3f181b4d ("lib/Kconfig.debug: disable
      -Wframe-larger-than warnings with KASAN=y").  Two patches in linux-next
      should be merged first to avoid introducing warnings in an allmodconfig
      build:
        3cd890db ("media: dvb-frontends: fix i2c access helpers for KASAN")
        16c3ada8 ("media: r820t: fix r820t_write_reg for KASAN")
      
      Do we really need to backport this?
      
      I think we do: without this patch, enabling KASAN will lead to
      unavoidable kernel stack overflow in certain device drivers when built
      with gcc-7 or higher on linux-4.10+ or any version that contains a
      backport of commit c5caf21a.  Most people are probably still on
      older compilers, but it will get worse over time as they upgrade their
      distros.
      
      The warnings we get on kernels older than this should all be for code
      that uses dangerously large stack frames, though most of them do not
      cause an actual stack overflow by themselves.The asan-stack option was
      added in linux-4.0, and commit 3f181b4d ("lib/Kconfig.debug:
      disable -Wframe-larger-than warnings with KASAN=y") effectively turned
      off the warning for allmodconfig kernels, so I would like to see this
      fix backported to any kernels later than 4.0.
      
      I have done dozens of fixes for individual functions with stack frames
      larger than 2048 bytes with asan-stack, and I plan to make sure that
      all those fixes make it into the stable kernels as well (most are
      already there).
      
      Part of the complication here is that asan-stack (from 4.0) was
      originally assumed to always require much larger stacks, but that
      turned out to be a combination of multiple gcc bugs that we have now
      worked around and fixed, but sanitize-address-use-after-scope (from
      v4.10) has a much higher inherent stack usage and also suffers from at
      least three other problems that we have analyzed but not yet fixed
      upstream, each of them makes the stack usage more severe than it should
      be.
      
      Link: http://lkml.kernel.org/r/20171221134744.2295529-1-arnd@arndb.deSigned-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Andrey Konovalov <andreyknvl@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      062cd346
  4. 25 Dec, 2017 1 commit
  5. 14 Oct, 2017 1 commit
    • Ingo Molnar's avatar
      locking/lockdep: Disable cross-release features for now · b483cf3b
      Ingo Molnar authored
      Johan Hovold reported a big lockdep slowdown on his system, caused by lockdep:
      
      > I had noticed that the BeagleBone Black boot time appeared to have
      > increased significantly with 4.14 and yesterday I finally had time to
      > investigate it.
      >
      > Boot time (from "Linux version" to login prompt) had in fact doubled
      > since 4.13 where it took 17 seconds (with my current config) compared to
      > the 35 seconds I now see with 4.14-rc4.
      >
      > I quick bisect pointed to lockdep and specifically the following commit:
      >
      >	28a903f6 ("locking/lockdep: Handle non(or multi)-acquisition of a crosslock")
      
      Because the final v4.14 release is close, disable the cross-release lockdep
      features for now.
      Bisected-by: default avatarJohan Hovold <johan@kernel.org>
      Debugged-by: default avatarJohan Hovold <johan@kernel.org>
      Reported-by: default avatarJohan Hovold <johan@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Byungchul Park <byungchul.park@lge.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: kernel-team@lge.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-mm@kvack.org
      Cc: linux-omap@vger.kernel.org
      Link: http://lkml.kernel.org/r/20171014072659.f2yr6mhm5ha3eou7@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b483cf3b
  6. 13 Oct, 2017 1 commit
  7. 22 Sep, 2017 1 commit
  8. 09 Sep, 2017 1 commit
  9. 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
  10. 17 Aug, 2017 4 commits
  11. 10 Aug, 2017 2 commits
    • Byungchul Park's avatar
      locking/lockdep: Apply crossrelease to completions · cd8084f9
      Byungchul Park authored
      Although wait_for_completion() and its family can cause deadlock, the
      lock correctness validator could not be applied to them until now,
      because things like complete() are usually called in a different context
      from the waiting context, which violates lockdep's assumption.
      
      Thanks to CONFIG_LOCKDEP_CROSSRELEASE, we can now apply the lockdep
      detector to those completion operations. Applied it.
      Signed-off-by: default avatarByungchul Park <byungchul.park@lge.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: boqun.feng@gmail.com
      Cc: kernel-team@lge.com
      Cc: kirill@shutemov.name
      Cc: npiggin@gmail.com
      Cc: walken@google.com
      Cc: willy@infradead.org
      Link: http://lkml.kernel.org/r/1502089981-21272-10-git-send-email-byungchul.park@lge.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      cd8084f9
    • Byungchul Park's avatar
      locking/lockdep: Implement the 'crossrelease' feature · b09be676
      Byungchul Park authored
      Lockdep is a runtime locking correctness validator that detects and
      reports a deadlock or its possibility by checking dependencies between
      locks. It's useful since it does not report just an actual deadlock but
      also the possibility of a deadlock that has not actually happened yet.
      That enables problems to be fixed before they affect real systems.
      
      However, this facility is only applicable to typical locks, such as
      spinlocks and mutexes, which are normally released within the context in
      which they were acquired. However, synchronization primitives like page
      locks or completions, which are allowed to be released in any context,
      also create dependencies and can cause a deadlock.
      
      So lockdep should track these locks to do a better job. The 'crossrelease'
      implementation makes these primitives also be tracked.
      Signed-off-by: default avatarByungchul Park <byungchul.park@lge.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: akpm@linux-foundation.org
      Cc: boqun.feng@gmail.com
      Cc: kernel-team@lge.com
      Cc: kirill@shutemov.name
      Cc: npiggin@gmail.com
      Cc: walken@google.com
      Cc: willy@infradead.org
      Link: http://lkml.kernel.org/r/1502089981-21272-6-git-send-email-byungchul.park@lge.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b09be676
  12. 26 Jul, 2017 2 commits
    • Josh Poimboeuf's avatar
      x86/kconfig: Make it easier to switch to the new ORC unwinder · a34a766f
      Josh Poimboeuf authored
      A couple of Kconfig changes which make it much easier to switch to the
      new CONFIG_ORC_UNWINDER:
      
      1) Remove x86 dependencies on CONFIG_FRAME_POINTER for lockdep,
         latencytop, and fault injection.  x86 has a 'guess' unwinder which
         just scans the stack for kernel text addresses.  It's not 100%
         accurate but in many cases it's good enough.  This allows those users
         who don't want the text overhead of the frame pointer or ORC
         unwinders to still use these features.  More importantly, this also
         makes it much more straightforward to disable frame pointers.
      
      2) Make CONFIG_ORC_UNWINDER depend on !CONFIG_FRAME_POINTER.  While it
         would be possible to have both enabled, it doesn't really make sense
         to do so.  So enforce a sane configuration to prevent the user from
         making a dumb mistake.
      
      With these changes, when you disable CONFIG_FRAME_POINTER, "make
      oldconfig" will ask if you want to enable CONFIG_ORC_UNWINDER.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/9985fb91ce5005fe33ea5cc2a20f14bd33c61d03.1500938583.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a34a766f
    • Josh Poimboeuf's avatar
      x86/unwind: Add the ORC unwinder · ee9f8fce
      Josh Poimboeuf authored
      Add the new ORC unwinder which is enabled by CONFIG_ORC_UNWINDER=y.
      It plugs into the existing x86 unwinder framework.
      
      It relies on objtool to generate the needed .orc_unwind and
      .orc_unwind_ip sections.
      
      For more details on why ORC is used instead of DWARF, see
      Documentation/x86/orc-unwinder.txt - but the short version is
      that it's a simplified, fundamentally more robust debugninfo
      data structure, which also allows up to two orders of magnitude
      faster lookups than the DWARF unwinder - which matters to
      profiling workloads like perf.
      
      Thanks to Andy Lutomirski for the performance improvement ideas:
      splitting the ORC unwind table into two parallel arrays and creating a
      fast lookup table to search a subset of the unwind table.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/0a6cbfb40f8da99b7a45a1a8302dc6aef16ec812.1500938583.git.jpoimboe@redhat.com
      [ Extended the changelog. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ee9f8fce
  13. 15 Jul, 2017 1 commit
    • Theodore Ts'o's avatar
      random: suppress spammy warnings about unseeded randomness · eecabf56
      Theodore Ts'o authored
      Unfortunately, on some models of some architectures getting a fully
      seeded CRNG is extremely difficult, and so this can result in dmesg
      getting spammed for a surprisingly long time.  This is really bad from
      a security perspective, and so architecture maintainers really need to
      do what they can to get the CRNG seeded sooner after the system is
      booted.  However, users can't do anything actionble to address this,
      and spamming the kernel messages log will only just annoy people.
      
      For developers who want to work on improving this situation,
      CONFIG_WARN_UNSEEDED_RANDOM has been renamed to
      CONFIG_WARN_ALL_UNSEEDED_RANDOM.  By default the kernel will always
      print the first use of unseeded randomness.  This way, hopefully the
      security obsessed will be happy that there is _some_ indication when
      the kernel boots there may be a potential issue with that architecture
      or subarchitecture.  To see all uses of unseeded randomness,
      developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      eecabf56
  14. 14 Jul, 2017 1 commit
    • Luis R. Rodriguez's avatar
      kmod: add test driver to stress test the module loader · d9c6a72d
      Luis R. Rodriguez authored
      This adds a new stress test driver for kmod: the kernel module loader.
      The new stress test driver, test_kmod, is only enabled as a module right
      now.  It should be possible to load this as built-in and load tests
      early (refer to the force_init_test module parameter), however since a
      lot of test can get a system out of memory fast we leave this disabled
      for now.
      
      Using a system with 1024 MiB of RAM can *easily* get your kernel OOM
      fast with this test driver.
      
      The test_kmod driver exposes API knobs for us to fine tune simple
      request_module() and get_fs_type() calls.  Since these API calls only
      allow each one parameter a test driver for these is rather simple.
      Other factors that can help out test driver though are the number of
      calls we issue and knowing current limitations of each.  This exposes
      configuration as much as possible through userspace to be able to build
      tests directly from userspace.
      
      Since it allows multiple misc devices its will eventually (once we add a
      knob to let us create new devices at will) also be possible to perform
      more tests in parallel, provided you have enough memory.
      
      We only enable tests we know work as of right now.
      
      Demo screenshots:
      
       # tools/testing/selftests/kmod/kmod.sh
      kmod_test_0001_driver: OK! - loading kmod test
      kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0001_fs: OK! - loading kmod test
      kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      kmod_test_0002_driver: OK! - loading kmod test
      kmod_test_0002_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0002_fs: OK! - loading kmod test
      kmod_test_0002_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      kmod_test_0003: OK! - loading kmod test
      kmod_test_0003: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0004: OK! - loading kmod test
      kmod_test_0004: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0005: OK! - loading kmod test
      kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0006: OK! - loading kmod test
      kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0005: OK! - loading kmod test
      kmod_test_0005: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      kmod_test_0006: OK! - loading kmod test
      kmod_test_0006: OK! - Return value: 0 (SUCCESS), expected SUCCESS
      XXX: add test restult for 0007
      Test completed
      
      You can also request for specific tests:
      
       # tools/testing/selftests/kmod/kmod.sh -t 0001
      kmod_test_0001_driver: OK! - loading kmod test
      kmod_test_0001_driver: OK! - Return value: 256 (MODULE_NOT_FOUND), expected MODULE_NOT_FOUND
      kmod_test_0001_fs: OK! - loading kmod test
      kmod_test_0001_fs: OK! - Return value: -22 (-EINVAL), expected -EINVAL
      Test completed
      
      Lastly, the current available number of tests:
      
       # tools/testing/selftests/kmod/kmod.sh --help
      Usage: tools/testing/selftests/kmod/kmod.sh [ -t <4-number-digit> ]
      Valid tests: 0001-0009
      
      0001 - Simple test - 1 thread  for empty string
      0002 - Simple test - 1 thread  for modules/filesystems that do not exist
      0003 - Simple test - 1 thread  for get_fs_type() only
      0004 - Simple test - 2 threads for get_fs_type() only
      0005 - multithreaded tests with default setup - request_module() only
      0006 - multithreaded tests with default setup - get_fs_type() only
      0007 - multithreaded tests with default setup test request_module() and get_fs_type()
      0008 - multithreaded - push kmod_concurrent over max_modprobes for request_module()
      0009 - multithreaded - push kmod_concurrent over max_modprobes for get_fs_type()
      
      The following test cases currently fail, as such they are not currently
      enabled by default:
      
       # tools/testing/selftests/kmod/kmod.sh -t 0008
       # tools/testing/selftests/kmod/kmod.sh -t 0009
      
      To be sure to run them as intended please unload both of the modules:
      
        o test_module
        o xfs
      
      And ensure they are not loaded on your system prior to testing them.  If
      you use these paritions for your rootfs you can change the default test
      driver used for get_fs_type() by exporting it into your environment.  For
      example of other test defaults you can override refer to kmod.sh
      allow_user_defaults().
      
      Behind the scenes this is how we fine tune at a test case prior to
      hitting a trigger to run it:
      
      cat /sys/devices/virtual/misc/test_kmod0/config
      echo -n "2" > /sys/devices/virtual/misc/test_kmod0/config_test_case
      echo -n "ext4" > /sys/devices/virtual/misc/test_kmod0/config_test_fs
      echo -n "80" > /sys/devices/virtual/misc/test_kmod0/config_num_threads
      cat /sys/devices/virtual/misc/test_kmod0/config
      echo -n "1" > /sys/devices/virtual/misc/test_kmod0/config_num_threads
      
      Finally to trigger:
      
      echo -n "1" > /sys/devices/virtual/misc/test_kmod0/trigger_config
      
      The kmod.sh script uses the above constructs to build different test cases.
      
      A bit of interpretation of the current failures follows, first two
      premises:
      
      a) When request_module() is used userspace figures out an optimized
         version of module order for us.  Once it finds the modules it needs, as
         per depmod symbol dep map, it will finit_module() the respective
         modules which are needed for the original request_module() request.
      
      b) We have an optimization in place whereby if a kernel uses
         request_module() on a module already loaded we never bother userspace
         as the module already is loaded.  This is all handled by kernel/kmod.c.
      
      A few things to consider to help identify root causes of issues:
      
      0) kmod 19 has a broken heuristic for modules being assumed to be
         built-in to your kernel and will return 0 even though request_module()
         failed.  Upgrade to a newer version of kmod.
      
      1) A get_fs_type() call for "xfs" will request_module() for "fs-xfs",
         not for "xfs".  The optimization in kernel described in b) fails to
         catch if we have a lot of consecutive get_fs_type() calls.  The reason
         is the optimization in place does not look for aliases.  This means two
         consecutive get_fs_type() calls will bump kmod_concurrent, whereas
         request_module() will not.
      
      This one explanation why test case 0009 fails at least once for
      get_fs_type().
      
      2) If a module fails to load --- for whatever reason (kmod_concurrent
         limit reached, file not yet present due to rootfs switch, out of
         memory) we have a period of time during which module request for the
         same name either with request_module() or get_fs_type() will *also*
         fail to load even if the file for the module is ready.
      
      This explains why *multiple* NULLs are possible on test 0009.
      
      3) finit_module() consumes quite a bit of memory.
      
      4) Filesystems typically also have more dependent modules than other
         modules, its important to note though that even though a get_fs_type()
         call does not incur additional kmod_concurrent bumps, since userspace
         loads dependencies it finds it needs via finit_module_fd(), it *will*
         take much more memory to load a module with a lot of dependencies.
      
      Because of 3) and 4) we will easily run into out of memory failures with
      certain tests.  For instance test 0006 fails on qemu with 1024 MiB of RAM.
      It panics a box after reaping all userspace processes and still not
      having enough memory to reap.
      
      [arnd@arndb.de: add dependencies for test module]
        Link: http://lkml.kernel.org/r/20170630154834.3689272-1-arnd@arndb.de
      Link: http://lkml.kernel.org/r/20170628223155.26472-3-mcgrof@kernel.orgSigned-off-by: default avatarLuis R. Rodriguez <mcgrof@kernel.org>
      Cc: Jessica Yu <jeyu@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d9c6a72d
  15. 12 Jul, 2017 2 commits
  16. 10 Jul, 2017 1 commit
  17. 20 Jun, 2017 1 commit
    • Jason A. Donenfeld's avatar
      random: warn when kernel uses unseeded randomness · d06bfd19
      Jason A. Donenfeld authored
      This enables an important dmesg notification about when drivers have
      used the crng without it being seeded first. Prior, these errors would
      occur silently, and so there hasn't been a great way of diagnosing these
      types of bugs for obscure setups. By adding this as a config option, we
      can leave it on by default, so that we learn where these issues happen,
      in the field, will still allowing some people to turn it off, if they
      really know what they're doing and do not want the log entries.
      
      However, we don't leave it _completely_ by default. An earlier version
      of this patch simply had `default y`. I'd really love that, but it turns
      out, this problem with unseeded randomness being used is really quite
      present and is going to take a long time to fix. Thus, as a compromise
      between log-messages-for-all and nobody-knows, this is `default y`,
      except it is also `depends on DEBUG_KERNEL`. This will ensure that the
      curious see the messages while others don't have to.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      d06bfd19
  18. 09 Jun, 2017 5 commits
    • Paul E. McKenney's avatar
      rcu: Move RCU debug Kconfig options to kernel/rcu · 43a0a2a7
      Paul E. McKenney authored
      RCU's debugging Kconfig options are in the unintuitive location
      lib/Kconfig.debug, and there are enough of them that it would be good for
      them to be more centralized.  This commit therefore extracts RCU's Kconfig
      options from init/Kconfig into a new kernel/rcu/Kconfig.debug file.
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      43a0a2a7
    • Paul E. McKenney's avatar
      rcu: Remove debugfs tracing · ae91aa0a
      Paul E. McKenney authored
      RCU's debugfs tracing used to be the only reasonable low-level debug
      information available, but ftrace and event tracing has since surpassed
      the RCU debugfs level of usefulness.  This commit therefore removes
      RCU's debugfs tracing.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      ae91aa0a
    • Paul E. McKenney's avatar
      rcu: Remove SPARSE_RCU_POINTER Kconfig option · 41a2901e
      Paul E. McKenney authored
      The sparse-based checking for non-RCU accesses to RCU-protected pointers
      has been around for a very long time, and it is now the only type of
      sparse-based checking that is optional.  This commit therefore makes
      it unconditional.
      Reported-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Fengguang Wu <fengguang.wu@intel.com>
      41a2901e
    • Paul E. McKenney's avatar
      rcu: Remove the now-obsolete PROVE_RCU_REPEATEDLY Kconfig option · c4a09ff7
      Paul E. McKenney authored
      The PROVE_RCU_REPEATEDLY Kconfig option was initially added due to
      the volume of messages from PROVE_RCU: Doing just one per boot would
      have required excessive numbers of boots to locate them all.  However,
      PROVE_RCU messages are now relatively rare, so there is no longer any
      reason to need more than one such message per boot.  This commit therefore
      removes the PROVE_RCU_REPEATEDLY Kconfig option.
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      c4a09ff7
    • Paul E. McKenney's avatar
      rcu: Remove *_SLOW_* Kconfig options · 90040c9e
      Paul E. McKenney authored
      The RCU_TORTURE_TEST_SLOW_PREINIT, RCU_TORTURE_TEST_SLOW_PREINIT_DELAY,
      RCU_TORTURE_TEST_SLOW_PREINIT_DELAY, RCU_TORTURE_TEST_SLOW_INIT,
      RCU_TORTURE_TEST_SLOW_INIT_DELAY, RCU_TORTURE_TEST_SLOW_CLEANUP,
      and RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY Kconfig options are only
      useful for torture testing, and there are the rcutree.gp_cleanup_delay,
      rcutree.gp_init_delay, and rcutree.gp_preinit_delay kernel boot parameters
      that rcutorture can use instead.  The effect of these parameters is to
      artificially slow down grace period initialization and cleanup in order
      to make some types of race conditions happen more often.
      
      This commit therefore simplifies Tree RCU a bit by removing the Kconfig
      options and adding the corresponding kernel parameters to rcutorture's
      .boot files instead.  However, this commit also leaves out the kernel
      parameters for TREE02, TREE04, and TREE07 in order to have about the
      same number of tests slowed as not slowed.  TREE01, TREE03, TREE05,
      and TREE06 are slowed, and the rest are not slowed.
      Reported-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      90040c9e
  19. 08 Jun, 2017 1 commit
  20. 16 May, 2017 1 commit
  21. 09 May, 2017 2 commits
  22. 01 May, 2017 1 commit
  23. 18 Apr, 2017 1 commit
    • Daniel Jordan's avatar
      sparc64: Use LOCKDEP_SMALL, not PROVE_LOCKING_SMALL · 395102db
      Daniel Jordan authored
      CONFIG_PROVE_LOCKING_SMALL shrinks the memory usage of lockdep so the
      kernel text, data, and bss fit in the required 32MB limit, but this
      option is not set for every config that enables lockdep.
      
      A 4.10 kernel fails to boot with the console output
      
          Kernel: Using 8 locked TLB entries for main kernel image.
          hypervisor_tlb_lock[2000000:0:8000000071c007c3:1]: errors with f
          Program terminated
      
      with these config options
      
          CONFIG_LOCKDEP=y
          CONFIG_LOCK_STAT=y
          CONFIG_PROVE_LOCKING=n
      
      To fix, rename CONFIG_PROVE_LOCKING_SMALL to CONFIG_LOCKDEP_SMALL, and
      enable this option with CONFIG_LOCKDEP=y so we get the reduced memory
      usage every time lockdep is turned on.
      
      Tested that CONFIG_LOCKDEP_SMALL is set to 'y' if and only if
      CONFIG_LOCKDEP is set to 'y'.  When other lockdep-related config options
      that select CONFIG_LOCKDEP are enabled (e.g. CONFIG_LOCK_STAT or
      CONFIG_PROVE_LOCKING), verified that CONFIG_LOCKDEP_SMALL is also
      enabled.
      
      Fixes: e6b5f1be ("config: Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc")
      Signed-off-by: default avatarDaniel Jordan <daniel.m.jordan@oracle.com>
      Reviewed-by: default avatarBabu Moger <babu.moger@oracle.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      395102db
  24. 17 Mar, 2017 1 commit
  25. 25 Feb, 2017 2 commits
  26. 24 Feb, 2017 1 commit
  27. 10 Feb, 2017 2 commits
    • Kees Cook's avatar
      time: Remove CONFIG_TIMER_STATS · dfb4357d
      Kees Cook authored
      Currently CONFIG_TIMER_STATS exposes process information across namespaces:
      
      kernel/time/timer_list.c print_timer():
      
              SEQ_printf(m, ", %s/%d", tmp, timer->start_pid);
      
      /proc/timer_list:
      
       #11: <0000000000000000>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570
      
      Given that the tracer can give the same information, this patch entirely
      removes CONFIG_TIMER_STATS.
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
      Cc: linux-doc@vger.kernel.org
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Xing Gao <xgao01@email.wm.edu>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Jessica Frazelle <me@jessfraz.com>
      Cc: kernel-hardening@lists.openwall.com
      Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Richard Cochran <richardcochran@gmail.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Michal Marek <mmarek@suse.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linux-api@vger.kernel.org
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Link: http://lkml.kernel.org/r/20170208192659.GA32582@beastSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      dfb4357d
    • Peter Zijlstra's avatar
      refcount_t: Introduce a special purpose refcount type · f405df5d
      Peter Zijlstra authored
      Provide refcount_t, an atomic_t like primitive built just for
      refcounting.
      
      It provides saturation semantics such that overflow becomes impossible
      and thereby 'spurious' use-after-free is avoided.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f405df5d