1. 24 7月, 2017 2 次提交
    • L
      Properly alphabetize MAINTAINERS file · 7683e9e5
      Linus Torvalds 提交于
      This adds a perl script to actually parse the MAINTAINERS file, clean up
      some whitespace in it, warn about errors in it, and then properly sort
      the end result.
      
      My perl-fu is atrocious, so the script has basically been created by
      randomly putting various characters in a pile, mixing them around, and
      then looking it the end result does anything interesting when used as a
      perl script.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7683e9e5
    • L
      Fix up MAINTAINERS file problems · f47e07bc
      Linus Torvalds 提交于
      Prepping for scripting the MAINTAINERS file cleanup (and possible split)
      showed a couple of cases where the headers for a couple of entries were
      bogus.
      
      There's a few different kinds of bogosities:
      
       - the X-GENE SOC EDAC case was confused and split over two lines
      
       - there were four entries for "GREYBUS PROTOCOLS DRIVERS" that were all
         different things.
      
       - the NOKIA N900 CAMERA SUPPORT" was duplicated
      
      all of which were more obvious when you started doing associative arrays
      in perl to track these things by the header (so that we can alphabetize
      this thing properly, and so that we might split it up by the data too).
      
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f47e07bc
  2. 22 7月, 2017 1 次提交
  3. 18 7月, 2017 1 次提交
  4. 17 7月, 2017 1 次提交
  5. 15 7月, 2017 3 次提交
    • L
      kmod: add test driver to stress test the module loader · d9c6a72d
      Luis R. Rodriguez 提交于
      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: NLuis 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d9c6a72d
    • L
      MAINTAINERS: give kmod some maintainer love · 062b8740
      Luis R. Rodriguez 提交于
      As suggested by Jessica, I've been actively working on kmod, so might as
      well reflect its maintained status.
      
      Changes are expected to go through akpm's tree.
      
      Link: http://lkml.kernel.org/r/20170628223155.26472-2-mcgrof@kernel.orgSigned-off-by: NLuis R. Rodriguez <mcgrof@kernel.org>
      Suggested-by: NJessica 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: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      062b8740
    • L
      MAINTAINERS: move the befs tree to kernel.org · 5624a8b0
      Luis de Bethencourt 提交于
      Update the location of the befs git tree and my email address.
      
      Link: http://lkml.kernel.org/r/20170709110012.2991-1-luisbg@kernel.orgSigned-off-by: NLuis de Bethencourt <luisbg@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5624a8b0
  6. 11 7月, 2017 7 次提交
  7. 08 7月, 2017 1 次提交
  8. 07 7月, 2017 1 次提交
  9. 06 7月, 2017 3 次提交
    • S
      NTB: Add IDT 89HPESxNTx PCIe-switches support · bf2a952d
      Serge Semin 提交于
      IDT 89HPESxNTx device series is PCIe-switches, which support
      Non-Transparent bridging between domains connected to the device ports.
      Since new NTB API exposes multi-port interface and messaging API, the
      IDT NT-functions can be now supported in the kernel. This driver adds
      the following functionality:
      1) Multi-port NTB API to have information of possible NT-functions
      activated in compliance with available device ports.
      2) Memory windows of direct and look up table based address translation
      with all possible combinations of BARs setup.
      3) Traditional doorbell NTB API.
      4) One-on-one messaging NTB API.
      
      There are some IDT PCIe-switch setups, which must be done before any of
      the NTB peers started. It can be performed either by system BIOS via
      IDT SMBus-slave interface or by pre-initialized IDT PCIe-switch EEPROM:
      1) NT-functions of corresponding ports must be activated using
      SWPARTxCTL and SWPORTxCTL registers.
      2) BAR0 must be configured to expose NT-function configuration
      registers map.
      3) The rest of the BARs must have at least one memory window
      configured, otherwise the driver will just return an error.
      Temperature sensor of IDT PCIe-switches can be also optionally
      activated by BIOS or EEPROM.
      (See IDT documentations for details of how the pre-initialization can
      be done)
      Signed-off-by: NSerge Semin <fancer.lancer@gmail.com>
      Acked-by: NAllen Hubbe <Allen.Hubbe@dell.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      bf2a952d
    • J
      lib: add errseq_t type and infrastructure for handling it · 84cbadad
      Jeff Layton 提交于
      An errseq_t is a way of recording errors in one place, and allowing any
      number of "subscribers" to tell whether an error has been set again
      since a previous time.
      
      It's implemented as an unsigned 32-bit value that is managed with atomic
      operations. The low order bits are designated to hold an error code
      (max size of MAX_ERRNO). The upper bits are used as a counter.
      
      The API works with consumers sampling an errseq_t value at a particular
      point in time. Later, that value can be used to tell whether new errors
      have been set since that time.
      
      Note that there is a 1 in 512k risk of collisions here if new errors
      are being recorded frequently, since we have so few bits to use as a
      counter. To mitigate this, one bit is used as a flag to tell whether the
      value has been sampled since a new value was recorded. That allows
      us to avoid bumping the counter if no one has sampled it since it
      was last bumped.
      
      Later patches will build on this infrastructure to change how writeback
      errors are tracked in the kernel.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NNeilBrown <neilb@suse.com>
      Reviewed-by: NJan Kara <jack@suse.cz>
      84cbadad
    • S
      MAINTAINERS: da9062/61 updates to the Dialog Semiconductor search terms · 34026764
      Steve Twiss 提交于
      Additions to search terms for files supported by Dialog Semiconductor.
      This update will allow Dialog support to follow files for device tree
      bindings (onkey, thermal and watchdog) and source code for chip thermal
      monitoring drivers.
      Signed-off-by: NSteve Twiss <stwiss.opensource@diasemi.com>
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      34026764
  10. 05 7月, 2017 2 次提交
  11. 04 7月, 2017 1 次提交
  12. 03 7月, 2017 4 次提交
  13. 02 7月, 2017 2 次提交
  14. 29 6月, 2017 1 次提交
  15. 28 6月, 2017 3 次提交
  16. 27 6月, 2017 1 次提交
  17. 26 6月, 2017 1 次提交
  18. 24 6月, 2017 2 次提交
  19. 23 6月, 2017 3 次提交