1. 22 5月, 2019 1 次提交
  2. 04 8月, 2018 1 次提交
  3. 06 6月, 2018 1 次提交
  4. 07 4月, 2018 1 次提交
    • T
      pstore: fix crypto dependencies without compression · e698aaf3
      Tobias Regnery 提交于
      Commit 58eb5b67 ("pstore: fix crypto dependencies") fixed up the crypto
      dependencies but missed the case when no compression is selected.
      
      With CONFIG_PSTORE=y, CONFIG_PSTORE_COMPRESS=n  and CONFIG_CRYPTO=m we see
      the following link error:
      
      fs/pstore/platform.o: In function `pstore_register':
      (.text+0x1b1): undefined reference to `crypto_has_alg'
      (.text+0x205): undefined reference to `crypto_alloc_base'
      fs/pstore/platform.o: In function `pstore_unregister':
      (.text+0x3b0): undefined reference to `crypto_destroy_tfm'
      
      Fix this by checking at compile-time if CONFIG_PSTORE_COMPRESS is enabled.
      
      Fixes: 58eb5b67 ("pstore: fix crypto dependencies")
      Signed-off-by: NTobias Regnery <tobias.regnery@gmail.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      e698aaf3
  5. 16 3月, 2018 1 次提交
    • A
      pstore: fix crypto dependencies · 58eb5b67
      Arnd Bergmann 提交于
      The new crypto API use causes some problems with Kconfig dependencies,
      including this link error:
      
      fs/pstore/platform.o: In function `pstore_register':
      platform.c:(.text+0x248): undefined reference to `crypto_has_alg'
      platform.c:(.text+0x2a0): undefined reference to `crypto_alloc_base'
      fs/pstore/platform.o: In function `pstore_unregister':
      platform.c:(.text+0x498): undefined reference to `crypto_destroy_tfm'
      crypto/lz4hc.o: In function `lz4hc_sdecompress':
      lz4hc.c:(.text+0x1a): undefined reference to `LZ4_decompress_safe'
      crypto/lz4hc.o: In function `lz4hc_decompress_crypto':
      lz4hc.c:(.text+0x5a): undefined reference to `LZ4_decompress_safe'
      crypto/lz4hc.o: In function `lz4hc_scompress':
      lz4hc.c:(.text+0xaa): undefined reference to `LZ4_compress_HC'
      crypto/lz4hc.o: In function `lz4hc_mod_init':
      lz4hc.c:(.init.text+0xf): undefined reference to `crypto_register_alg'
      lz4hc.c:(.init.text+0x1f): undefined reference to `crypto_register_scomp'
      lz4hc.c:(.init.text+0x2f): undefined reference to `crypto_unregister_alg'
      
      The problem is that with CONFIG_CRYPTO=m, we must not 'select CRYPTO_LZ4'
      from a bool symbol, or call crypto API functions from a built-in
      module.
      
      This turns the sub-options into 'tristate' ones so the dependencies
      are honored, and makes the pstore itself select the crypto core
      if necessary.
      
      Fixes: cb3bee03 ("pstore: Use crypto compress API")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      58eb5b67
  6. 10 3月, 2018 1 次提交
    • G
      pstore: Use crypto compress API · cb3bee03
      Geliang Tang 提交于
      In the pstore compression part, we use zlib/lzo/lz4/lz4hc/842
      compression algorithm API to implement pstore compression backends. But
      there are many repeat codes in these implementations. This patch uses
      crypto compress API to simplify these codes.
      
      1) rewrite allocate_buf_for_compression, free_buf_for_compression,
      pstore_compress, pstore_decompress functions using crypto compress API.
      2) drop compress, decompress, allocate, free functions in pstore_zbackend,
      and add zbufsize function to get each different compress buffer size.
      3) use late_initcall to call ramoops_init later, to make sure the crypto
      subsystem has already initialized.
      4) use 'unsigned int' type instead of 'size_t' in pstore_compress,
      pstore_decompress functions' length arguments.
      5) rename 'zlib' to 'deflate' to follow the crypto API's name convention.
      Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
      [kees: tweaked error messages on allocation failures and Kconfig help]
      Signed-off-by: NKees Cook <keescook@chromium.org>
      cb3bee03
  7. 08 3月, 2018 1 次提交
    • K
      pstore: Select compression at runtime · fe1d4758
      Kees Cook 提交于
      To allow for easier build test coverage and run-time testing, this allows
      multiple compression algorithms to be built into pstore. Still only one
      is supported to operate at a time (which can be selected at build time
      or at boot time, similar to how LSMs are selected).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      fe1d4758
  8. 07 3月, 2018 2 次提交
  9. 29 11月, 2017 1 次提交
  10. 22 11月, 2017 1 次提交
    • K
      treewide: Switch DEFINE_TIMER callbacks to struct timer_list * · 24ed960a
      Kees Cook 提交于
      This changes all DEFINE_TIMER() callbacks to use a struct timer_list
      pointer instead of unsigned long. Since the data argument has already been
      removed, none of these callbacks are using their argument currently, so
      this renames the argument to "unused".
      
      Done using the following semantic patch:
      
      @match_define_timer@
      declarer name DEFINE_TIMER;
      identifier _timer, _callback;
      @@
      
       DEFINE_TIMER(_timer, _callback);
      
      @change_callback depends on match_define_timer@
      identifier match_define_timer._callback;
      type _origtype;
      identifier _origarg;
      @@
      
       void
      -_callback(_origtype _origarg)
      +_callback(struct timer_list *unused)
       { ... }
      Signed-off-by: NKees Cook <keescook@chromium.org>
      24ed960a
  11. 12 11月, 2017 1 次提交
    • A
      pstore: Use ktime_get_real_fast_ns() instead of __getnstimeofday() · df27067e
      Arnd Bergmann 提交于
      __getnstimeofday() is a rather odd interface, with a number of quirks:
      
      - The caller may come from NMI context, but the implementation is not NMI safe,
        one way to get there from NMI is
      
            NMI handler:
              something bad
                panic()
                  kmsg_dump()
                    pstore_dump()
                       pstore_record_init()
                         __getnstimeofday()
      
      - The calling conventions are different from any other timekeeping functions,
        to deal with returning an error code during suspended timekeeping.
      
      Address the above issues by using a completely different method to get the
      time: ktime_get_real_fast_ns() is NMI safe and has a reasonable behavior
      when timekeeping is suspended: it returns the time at which it got
      suspended. As Thomas Gleixner explained, this is safe, as
      ktime_get_real_fast_ns() does not call into the clocksource driver that
      might be suspended.
      
      The result can easily be transformed into a timespec structure. Since
      ktime_get_real_fast_ns() was not exported to modules, add the export.
      
      The pstore behavior for the suspended case changes slightly, as it now
      stores the timestamp at which timekeeping was suspended instead of storing
      a zero timestamp.
      
      This change is not addressing y2038-safety, that's subject to a more
      complex follow up patch.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Anton Vorontsov <anton@enomsg.org>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Colin Cross <ccross@android.com>
      Link: https://lkml.kernel.org/r/20171110152530.1926955-1-arnd@arndb.de
      df27067e
  12. 06 11月, 2017 1 次提交
  13. 05 10月, 2017 1 次提交
    • K
      timer: Remove expires and data arguments from DEFINE_TIMER · 1d27e3e2
      Kees Cook 提交于
      Drop the arguments from the macro and adjust all callers with the
      following script:
      
        perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
          $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # for m68k parts
      Acked-by: Guenter Roeck <linux@roeck-us.net> # for watchdog parts
      Acked-by: David S. Miller <davem@davemloft.net> # for networking parts
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: Kalle Valo <kvalo@codeaurora.org> # for wireless parts
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: linux-mips@linux-mips.org
      Cc: Petr Mladek <pmladek@suse.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Lai Jiangshan <jiangshanlai@gmail.com>
      Cc: Sebastian Reichel <sre@kernel.org>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: linux1394-devel@lists.sourceforge.net
      Cc: Chris Metcalf <cmetcalf@mellanox.com>
      Cc: linux-s390@vger.kernel.org
      Cc: linux-wireless@vger.kernel.org
      Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
      Cc: Wim Van Sebroeck <wim@iguana.be>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Ursula Braun <ubraun@linux.vnet.ibm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Harish Patil <harish.patil@cavium.com>
      Cc: Stephen Boyd <sboyd@codeaurora.org>
      Cc: Michael Reed <mdr@sgi.com>
      Cc: Manish Chopra <manish.chopra@cavium.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: linux-pm@vger.kernel.org
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Julian Wiedmann <jwi@linux.vnet.ibm.com>
      Cc: John Stultz <john.stultz@linaro.org>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: linux-watchdog@vger.kernel.org
      Cc: linux-scsi@vger.kernel.org
      Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Cc: netdev@vger.kernel.org
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
      Link: https://lkml.kernel.org/r/1507159627-127660-11-git-send-email-keescook@chromium.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1d27e3e2
  14. 06 7月, 2017 1 次提交
    • D
      pstore: Implement show_options · 349d7438
      David Howells 提交于
      Implement the show_options superblock op for pstore as part of a bid to get
      rid of s_options and generic_show_options() to make it easier to implement
      a context-based mount where the mount options can be passed individually
      over a file descriptor.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Kees Cook <keescook@chromium.org>
      cc: Anton Vorontsov <anton@enomsg.org>
      cc: Colin Cross <ccross@android.com>
      cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      349d7438
  15. 28 6月, 2017 1 次提交
  16. 01 6月, 2017 5 次提交
  17. 28 4月, 2017 1 次提交
    • K
      pstore: Solve lockdep warning by moving inode locks · 3a7d2fd1
      Kees Cook 提交于
      Lockdep complains about a possible deadlock between mount and unlink
      (which is technically impossible), but fixing this improves possible
      future multiple-backend support, and keeps locking in the right order.
      
      The lockdep warning could be triggered by unlinking a file in the
      pstore filesystem:
      
        -> #1 (&sb->s_type->i_mutex_key#14){++++++}:
               lock_acquire+0xc9/0x220
               down_write+0x3f/0x70
               pstore_mkfile+0x1f4/0x460
               pstore_get_records+0x17a/0x320
               pstore_fill_super+0xa4/0xc0
               mount_single+0x89/0xb0
               pstore_mount+0x13/0x20
               mount_fs+0xf/0x90
               vfs_kern_mount+0x66/0x170
               do_mount+0x190/0xd50
               SyS_mount+0x90/0xd0
               entry_SYSCALL_64_fastpath+0x1c/0xb1
      
        -> #0 (&psinfo->read_mutex){+.+.+.}:
               __lock_acquire+0x1ac0/0x1bb0
               lock_acquire+0xc9/0x220
               __mutex_lock+0x6e/0x990
               mutex_lock_nested+0x16/0x20
               pstore_unlink+0x3f/0xa0
               vfs_unlink+0xb5/0x190
               do_unlinkat+0x24c/0x2a0
               SyS_unlinkat+0x16/0x30
               entry_SYSCALL_64_fastpath+0x1c/0xb1
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(&sb->s_type->i_mutex_key#14);
                                      lock(&psinfo->read_mutex);
                                      lock(&sb->s_type->i_mutex_key#14);
         lock(&psinfo->read_mutex);
      Reported-by: NMarta Lofstedt <marta.lofstedt@intel.com>
      Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Acked-by: NNamhyung Kim <namhyung@kernel.org>
      3a7d2fd1
  18. 08 3月, 2017 17 次提交
  19. 25 2月, 2017 1 次提交