22 Feb, 2018

1 commit

  • commit 4675ff05de2d76d167336b368bd07f3fef6ed5a6 upstream.

    Fix up makefiles, remove references, and git rm kmemcheck.

    Link: http://lkml.kernel.org/r/20171007030159.22241-4-alexander.levin@verizon.com
    Signed-off-by: Sasha Levin
    Cc: Steven Rostedt
    Cc: Vegard Nossum
    Cc: Pekka Enberg
    Cc: Michal Hocko
    Cc: Eric W. Biederman
    Cc: Alexander Potapenko
    Cc: Tim Hansen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Levin, Alexander (Sasha Levin)
     

17 Feb, 2018

1 commit

  • commit e7c52b84fb18f08ce49b6067ae6285aca79084a8 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 3f181b4d8652 ("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:
    3cd890dbe2a4 ("media: dvb-frontends: fix i2c access helpers for KASAN")
    16c3ada89cff ("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 c5caf21ab0cf8. 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 3f181b4d8652 ("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.de
    Signed-off-by: Arnd Bergmann
    Acked-by: Andrey Ryabinin
    Cc: Mauro Carvalho Chehab
    Cc: Andrey Ryabinin
    Cc: Alexander Potapenko
    Cc: Dmitry Vyukov
    Cc: Andrey Konovalov
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Signed-off-by: Greg Kroah-Hartman

    Arnd Bergmann
     

25 Dec, 2017

1 commit

  • commit 11af847446ed0d131cf24d16a7ef3d5ea7a49554 upstream.

    Rename the unwinder config options from:

    CONFIG_ORC_UNWINDER
    CONFIG_FRAME_POINTER_UNWINDER
    CONFIG_GUESS_UNWINDER

    to:

    CONFIG_UNWINDER_ORC
    CONFIG_UNWINDER_FRAME_POINTER
    CONFIG_UNWINDER_GUESS

    ... in order to give them a more logical config namespace.

    Suggested-by: Ingo Molnar
    Signed-off-by: Josh Poimboeuf
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar
    Signed-off-by: Greg Kroah-Hartman

    Josh Poimboeuf
     

15 Oct, 2017

1 commit


14 Oct, 2017

2 commits

  • 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:
    >
    > 28a903f63ec0 ("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: Johan Hovold
    Debugged-by: Johan Hovold
    Reported-by: Johan Hovold
    Cc: Arnd Bergmann
    Cc: Byungchul Park
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: Tony Lindgren
    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.com
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • Expand the "Runtime testing" menu by including more entries inside it
    instead of after it. This is just Kconfig symbol movement.

    This causes the (arch-independent) Runtime tests to be presented
    (listed) all in one place instead of in multiple places.

    Link: http://lkml.kernel.org/r/c194e5c4-2042-bf94-a2d8-7aa13756e257@infradead.org
    Signed-off-by: Randy Dunlap
    Acked-by: Kees Cook
    Cc: Dave Hansen
    Cc: "Luis R. Rodriguez"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

23 Sep, 2017

1 commit

  • The parisc architecture has larger stack frames than most other
    architectures on 32-bit kernels.

    Increase the maximum allowed stack frame to 1280 bytes for parisc to
    avoid warnings in the do_sys_poll() and pat_memconfig() functions.

    Signed-off-by: Helge Deller

    Helge Deller
     

09 Sep, 2017

1 commit

  • Add a test module that allows testing that CONFIG_DEBUG_VIRTUAL works
    correctly, at least that it can catch invalid calls to virt_to_phys()
    against the non-linear kernel virtual address map.

    Link: http://lkml.kernel.org/r/20170808164035.26725-1-f.fainelli@gmail.com
    Signed-off-by: Florian Fainelli
    Cc: "Luis R. Rodriguez"
    Cc: Kees Cook
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Florian Fainelli
     

05 Sep, 2017

2 commits

  • Pull locking updates from Ingo Molnar:

    - Add 'cross-release' support to lockdep, which allows APIs like
    completions, where it's not the 'owner' who releases the lock, to be
    tracked. It's all activated automatically under
    CONFIG_PROVE_LOCKING=y.

    - Clean up (restructure) the x86 atomics op implementation to be more
    readable, in preparation of KASAN annotations. (Dmitry Vyukov)

    - Fix static keys (Paolo Bonzini)

    - Add killable versions of down_read() et al (Kirill Tkhai)

    - Rework and fix jump_label locking (Marc Zyngier, Paolo Bonzini)

    - Rework (and fix) tlb_flush_pending() barriers (Peter Zijlstra)

    - Remove smp_mb__before_spinlock() and convert its usages, introduce
    smp_mb__after_spinlock() (Peter Zijlstra)

    * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (56 commits)
    locking/lockdep/selftests: Fix mixed read-write ABBA tests
    sched/completion: Avoid unnecessary stack allocation for COMPLETION_INITIALIZER_ONSTACK()
    acpi/nfit: Fix COMPLETION_INITIALIZER_ONSTACK() abuse
    locking/pvqspinlock: Relax cmpxchg's to improve performance on some architectures
    smp: Avoid using two cache lines for struct call_single_data
    locking/lockdep: Untangle xhlock history save/restore from task independence
    locking/refcounts, x86/asm: Disable CONFIG_ARCH_HAS_REFCOUNT for the time being
    futex: Remove duplicated code and fix undefined behaviour
    Documentation/locking/atomic: Finish the document...
    locking/lockdep: Fix workqueue crossrelease annotation
    workqueue/lockdep: 'Fix' flush_work() annotation
    locking/lockdep/selftests: Add mixed read-write ABBA tests
    mm, locking/barriers: Clarify tlb_flush_pending() barriers
    locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS truly non-interactive
    locking/lockdep: Explicitly initialize wq_barrier::done::map
    locking/lockdep: Rename CONFIG_LOCKDEP_COMPLETE to CONFIG_LOCKDEP_COMPLETIONS
    locking/lockdep: Reword title of LOCKDEP_CROSSRELEASE config
    locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING
    locking/refcounts, x86/asm: Implement fast refcount overflow protection
    locking/lockdep: Fix the rollback and overwrite detection logic in crossrelease
    ...

    Linus Torvalds
     
  • Pull x86 asm updates from Ingo Molnar:

    - Introduce the ORC unwinder, which can be enabled via
    CONFIG_ORC_UNWINDER=y.

    The ORC unwinder is a lightweight, Linux kernel specific debuginfo
    implementation, which aims to be DWARF done right for unwinding.
    Objtool is used to generate the ORC unwinder tables during build, so
    the data format is flexible and kernel internal: there's no
    dependency on debuginfo created by an external toolchain.

    The ORC unwinder is almost two orders of magnitude faster than the
    (out of tree) DWARF unwinder - which is important for perf call graph
    profiling. It is also significantly simpler and is coded defensively:
    there has not been a single ORC related kernel crash so far, even
    with early versions. (knock on wood!)

    But the main advantage is that enabling the ORC unwinder allows
    CONFIG_FRAME_POINTERS to be turned off - which speeds up the kernel
    measurably:

    With frame pointers disabled, GCC does not have to add frame pointer
    instrumentation code to every function in the kernel. The kernel's
    .text size decreases by about 3.2%, resulting in better cache
    utilization and fewer instructions executed, resulting in a broad
    kernel-wide speedup. Average speedup of system calls should be
    roughly in the 1-3% range - measurements by Mel Gorman [1] have shown
    a speedup of 5-10% for some function execution intense workloads.

    The main cost of the unwinder is that the unwinder data has to be
    stored in RAM: the memory cost is 2-4MB of RAM, depending on kernel
    config - which is a modest cost on modern x86 systems.

    Given how young the ORC unwinder code is it's not enabled by default
    - but given the performance advantages the plan is to eventually make
    it the default unwinder on x86.

    See Documentation/x86/orc-unwinder.txt for more details.

    - Remove lguest support: its intended role was that of a temporary
    proof of concept for virtualization, plus its removal will enable the
    reduction (removal) of the paravirt API as well, so Rusty agreed to
    its removal. (Juergen Gross)

    - Clean up and fix FSGS related functionality (Andy Lutomirski)

    - Clean up IO access APIs (Andy Shevchenko)

    - Enhance the symbol namespace (Jiri Slaby)

    * 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (47 commits)
    objtool: Handle GCC stack pointer adjustment bug
    x86/entry/64: Use ENTRY() instead of ALIGN+GLOBAL for stub32_clone()
    x86/fpu/math-emu: Add ENDPROC to functions
    x86/boot/64: Extract efi_pe_entry() from startup_64()
    x86/boot/32: Extract efi_pe_entry() from startup_32()
    x86/lguest: Remove lguest support
    x86/paravirt/xen: Remove xen_patch()
    objtool: Fix objtool fallthrough detection with function padding
    x86/xen/64: Fix the reported SS and CS in SYSCALL
    objtool: Track DRAP separately from callee-saved registers
    objtool: Fix validate_branch() return codes
    x86: Clarify/fix no-op barriers for text_poke_bp()
    x86/switch_to/64: Rewrite FS/GS switching yet again to fix AMD CPUs
    selftests/x86/fsgsbase: Test selectors 1, 2, and 3
    x86/fsgsbase/64: Report FSBASE and GSBASE correctly in core dumps
    x86/fsgsbase/64: Fully initialize FS and GS state in start_thread_common
    x86/asm: Fix UNWIND_HINT_REGS macro for older binutils
    x86/asm/32: Fix regs_get_register() on segment registers
    x86/xen/64: Rearrange the SYSCALL entries
    x86/asm/32: Remove a bunch of '& 0xffff' from pt_regs segment reads
    ...

    Linus Torvalds
     

25 Aug, 2017

1 commit


18 Aug, 2017

1 commit

  • 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: 58687acba592 ("lockup_detector: Combine nmi_watchdog and softlockup detector")
    Reported-and-tested-by: Kan Liang
    Signed-off-by: Thomas Gleixner
    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

    Thomas Gleixner
     

17 Aug, 2017

4 commits

  • … truly non-interactive

    The syntax to turn Kconfig options into non-interactive ones is to not offer
    interactive prompt help texts. Remove them.

    Cc: Boqun Feng <boqun.feng@gmail.com>
    Cc: Byungchul Park <byungchul.park@lge.com>
    Cc: Lai Jiangshan <jiangshanlai@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar <mingo@kernel.org>

    Ingo Molnar
     
  • 'complete' is an adjective and LOCKDEP_COMPLETE sounds like 'lockdep is complete',
    so pick a better name that uses a noun.

    Signed-off-by: Byungchul Park
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kernel-team@lge.com
    Link: http://lkml.kernel.org/r/1502960261-16206-3-git-send-email-byungchul.park@lge.com
    Signed-off-by: Ingo Molnar

    Byungchul Park
     
  • Lockdep doesn't have to be made to work with crossrelease and just works
    with them. Reword the title so that what the option does is clear.

    Signed-off-by: Byungchul Park
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kernel-team@lge.com
    Link: http://lkml.kernel.org/r/1502960261-16206-2-git-send-email-byungchul.park@lge.com
    Signed-off-by: Ingo Molnar

    Byungchul Park
     
  • Crossrelease support added the CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETE
    options. It makes little sense to enable them when PROVE_LOCKING is disabled.

    Make them non-interative options and part of PROVE_LOCKING to simplify the UI.

    Signed-off-by: Byungchul Park
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: kernel-team@lge.com
    Link: http://lkml.kernel.org/r/1502960261-16206-1-git-send-email-byungchul.park@lge.com
    Signed-off-by: Ingo Molnar

    Byungchul Park
     

10 Aug, 2017

2 commits

  • 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: Byungchul Park
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    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.com
    Signed-off-by: Ingo Molnar

    Byungchul Park
     
  • 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: Byungchul Park
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    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.com
    Signed-off-by: Ingo Molnar

    Byungchul Park
     

26 Jul, 2017

2 commits

  • 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: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Jiri Slaby
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: live-patching@vger.kernel.org
    Link: http://lkml.kernel.org/r/9985fb91ce5005fe33ea5cc2a20f14bd33c61d03.1500938583.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf
     
  • 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: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: Borislav Petkov
    Cc: Brian Gerst
    Cc: Denys Vlasenko
    Cc: H. Peter Anvin
    Cc: Jiri Slaby
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: live-patching@vger.kernel.org
    Link: http://lkml.kernel.org/r/0a6cbfb40f8da99b7a45a1a8302dc6aef16ec812.1500938583.git.jpoimboe@redhat.com
    [ Extended the changelog. ]
    Signed-off-by: Ingo Molnar

    Josh Poimboeuf
     

16 Jul, 2017

2 commits

  • Pull random updates from Ted Ts'o:
    "Add wait_for_random_bytes() and get_random_*_wait() functions so that
    callers can more safely get random bytes if they can block until the
    CRNG is initialized.

    Also print a warning if get_random_*() is called before the CRNG is
    initialized. By default, only one single-line warning will be printed
    per boot. If CONFIG_WARN_ALL_UNSEEDED_RANDOM is defined, then a
    warning will be printed for each function which tries to get random
    bytes before the CRNG is initialized. This can get spammy for certain
    architecture types, so it is not enabled by default"

    * tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
    random: reorder READ_ONCE() in get_random_uXX
    random: suppress spammy warnings about unseeded randomness
    random: warn when kernel uses unseeded randomness
    net/route: use get_random_int for random counter
    net/neighbor: use get_random_u32 for 32-bit hash random
    rhashtable: use get_random_u32 for hash_rnd
    ceph: ensure RNG is seeded before using
    iscsi: ensure RNG is seeded before use
    cifs: use get_random_u32 for 32-bit lock random
    random: add get_random_{bytes,u32,u64,int,long,once}_wait family
    random: add wait_for_random_bytes() API

    Linus Torvalds
     
  • 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: Theodore Ts'o

    Theodore Ts'o
     

15 Jul, 2017

1 commit

  • 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 ]
    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.org
    Signed-off-by: Luis R. Rodriguez
    Cc: Jessica Yu
    Cc: Shuah Khan
    Cc: Rusty Russell
    Cc: Michal Marek
    Cc: Petr Mladek
    Cc: Greg Kroah-Hartman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Luis R. Rodriguez
     

13 Jul, 2017

2 commits

  • Split SOFTLOCKUP_DETECTOR from LOCKUP_DETECTOR, and split
    HARDLOCKUP_DETECTOR_PERF from HARDLOCKUP_DETECTOR.

    LOCKUP_DETECTOR implies the general boot, sysctl, and programming
    interfaces for the lockup detectors.

    An architecture that wants to use a hard lockup detector must define
    HAVE_HARDLOCKUP_DETECTOR_PERF or HAVE_HARDLOCKUP_DETECTOR_ARCH.

    Alternatively an arch can define HAVE_NMI_WATCHDOG, which provides the
    minimum arch_touch_nmi_watchdog, and it otherwise does its own thing and
    does not implement the LOCKUP_DETECTOR interfaces.

    sparc is unusual in that it has started to implement some of the
    interfaces, but not fully yet. It should probably be converted to a full
    HAVE_HARDLOCKUP_DETECTOR_ARCH.

    [npiggin@gmail.com: fix]
    Link: http://lkml.kernel.org/r/20170617223522.66c0ad88@roar.ozlabs.ibm.com
    Link: http://lkml.kernel.org/r/20170616065715.18390-4-npiggin@gmail.com
    Signed-off-by: Nicholas Piggin
    Reviewed-by: Don Zickus
    Reviewed-by: Babu Moger
    Tested-by: Babu Moger [sparc]
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Michael Ellerman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Nicholas Piggin
     
  • The existing tools/testing/selftests/sysctl/ tests include two test
    cases, but these use existing production kernel sysctl interfaces. We
    want to expand test coverage but we can't just be looking for random
    safe production values to poke at, that's just insane!

    Instead just dedicate a test driver for debugging purposes and port the
    existing scripts to use it. This will make it easier for further tests
    to be added.

    Subsequent patches will extend our test coverage for sysctl.

    The stress test driver uses a new license (GPL on Linux, copyleft-next
    outside of Linux). Linus was fine with this [0] and later due to Ted's
    and Alans's request ironed out an "or" language clause to use [1] which
    is already present upstream.

    [0] https://lkml.kernel.org/r/CA+55aFyhxcvD+q7tp+-yrSFDKfR0mOHgyEAe=f_94aKLsOu0Og@mail.gmail.com
    [1] https://lkml.kernel.org/r/1495234558.7848.122.camel@linux.intel.com

    Link: http://lkml.kernel.org/r/20170630224431.17374-2-mcgrof@kernel.org
    Signed-off-by: Luis R. Rodriguez
    Acked-by: Kees Cook
    Cc: "Eric W. Biederman"
    Cc: Shuah Khan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Luis R. Rodriguez
     

11 Jul, 2017

1 commit

  • Patch series "lib/interval_tree_test: some debugging improvements".

    Here are some patches that update the interval_tree_test module allowing
    users to pass finer grained options to run the actual test.

    This patch (of 4):

    It is a tristate after all, and also serves well for quick debugging.

    Link: http://lkml.kernel.org/r/20170518174936.20265-2-dave@stgolabs.net
    Signed-off-by: Davidlohr Bueso
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Davidlohr Bueso
     

04 Jul, 2017

2 commits

  • Pull documentation updates from Jonathan Corbet:
    "There has been a fair amount of activity in the docs tree this time
    around. Highlights include:

    - Conversion of a bunch of security documentation into RST

    - The conversion of the remaining DocBook templates by The Amazing
    Mauro Machine. We can now drop the entire DocBook build chain.

    - The usual collection of fixes and minor updates"

    * tag 'docs-4.13' of git://git.lwn.net/linux: (90 commits)
    scripts/kernel-doc: handle DECLARE_HASHTABLE
    Documentation: atomic_ops.txt is core-api/atomic_ops.rst
    Docs: clean up some DocBook loose ends
    Make the main documentation title less Geocities
    Docs: Use kernel-figure in vidioc-g-selection.rst
    Docs: fix table problems in ras.rst
    Docs: Fix breakage with Sphinx 1.5 and upper
    Docs: Include the Latex "ifthen" package
    doc/kokr/howto: Only send regression fixes after -rc1
    docs-rst: fix broken links to dynamic-debug-howto in kernel-parameters
    doc: Document suitability of IBM Verse for kernel development
    Doc: fix a markup error in coding-style.rst
    docs: driver-api: i2c: remove some outdated information
    Documentation: DMA API: fix a typo in a function name
    Docs: Insert missing space to separate link from text
    doc/ko_KR/memory-barriers: Update control-dependencies example
    Documentation, kbuild: fix typo "minimun" -> "minimum"
    docs: Fix some formatting issues in request-key.rst
    doc: ReSTify keys-trusted-encrypted.txt
    doc: ReSTify keys-request-key.txt
    ...

    Linus Torvalds
     
  • Pull locking updates from Ingo Molnar:
    "The main changes in this cycle were:

    - Add CONFIG_REFCOUNT_FULL=y to allow the disabling of the 'full'
    (robustness checked) refcount_t implementation with slightly lower
    runtime overhead. (Kees Cook)

    The lighter weight variant is the default. The two variants use the
    same API. Having this variant was a precondition by some
    maintainers to merge refcount_t cleanups.

    - Add lockdep support for rtmutexes (Peter Zijlstra)

    - liblockdep fixes and improvements (Sasha Levin, Ben Hutchings)

    - ... misc fixes and improvements"

    * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (30 commits)
    locking/refcount: Remove the half-implemented refcount_sub() API
    locking/refcount: Create unchecked atomic_t implementation
    locking/rtmutex: Don't initialize lockdep when not required
    locking/selftest: Add RT-mutex support
    locking/selftest: Remove the bad unlock ordering test
    rt_mutex: Add lockdep annotations
    MAINTAINERS: Claim atomic*_t maintainership
    locking/x86: Remove the unused atomic_inc_short() methd
    tools/lib/lockdep: Remove private kernel headers
    tools/lib/lockdep: Hide liblockdep output from test results
    tools/lib/lockdep: Add dummy current_gfp_context()
    tools/include: Add IS_ERR_OR_NULL to err.h
    tools/lib/lockdep: Add empty __is_[module,kernel]_percpu_address
    tools/lib/lockdep: Include err.h
    tools/include: Add (mostly) empty include/linux/sched/mm.h
    tools/lib/lockdep: Use LDFLAGS
    tools/lib/lockdep: Remove double-quotes from soname
    tools/lib/lockdep: Fix object file paths used in an out-of-tree build
    tools/lib/lockdep: Fix compilation for 4.11
    tools/lib/lockdep: Don't mix fd-based and stream IO
    ...

    Linus Torvalds
     

20 Jun, 2017

1 commit

  • 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: Jason A. Donenfeld
    Signed-off-by: Theodore Ts'o

    Jason A. Donenfeld
     

09 Jun, 2017

5 commits

  • 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: Ingo Molnar
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     
  • 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: Paul E. McKenney

    Paul E. McKenney
     
  • 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: Ingo Molnar
    Signed-off-by: Paul E. McKenney
    Cc: Fengguang Wu

    Paul E. McKenney
     
  • 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: Paul E. McKenney
    Cc: Ingo Molnar

    Paul E. McKenney
     
  • 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: Linus Torvalds
    Signed-off-by: Paul E. McKenney

    Paul E. McKenney
     

08 Jun, 2017

1 commit

  • Now that (PI) futexes have their own private RT-mutex interface and
    implementation we can easily add lockdep annotations to the existing
    RT-mutex interface.

    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

16 May, 2017

1 commit


09 May, 2017

2 commits

  • Extract the linked list sorting test code into its own source file, to
    allow to compile it either to a loadable module, or builtin into the
    kernel.

    Link: http://lkml.kernel.org/r/1488287219-15832-4-git-send-email-geert@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven
    Reviewed-by: Andy Shevchenko
    Cc: Arnd Bergmann
    Cc: Paul Gortmaker
    Cc: Shuah Khan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     
  • Allow to compile the array-based sort test code either to a loadable
    module, or builtin into the kernel.

    Link: http://lkml.kernel.org/r/1488287219-15832-3-git-send-email-geert@linux-m68k.org
    Signed-off-by: Geert Uytterhoeven
    Reviewed-by: Andy Shevchenko
    Cc: Arnd Bergmann
    Cc: Paul Gortmaker
    Cc: Shuah Khan
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Geert Uytterhoeven
     

03 May, 2017

1 commit

  • Pull documentation update from Jonathan Corbet:
    "A reasonably busy cycle for documentation this time around. There is a
    new guide for user-space API documents, rather sparsely populated at
    the moment, but it's a start. Markus improved the infrastructure for
    converting diagrams. Mauro has converted much of the USB documentation
    over to RST. Plus the usual set of fixes, improvements, and tweaks.

    There's a bit more than the usual amount of reaching out of
    Documentation/ to fix comments elsewhere in the tree; I have acks for
    those where I could get them"

    * tag 'docs-4.12' of git://git.lwn.net/linux: (74 commits)
    docs: Fix a couple typos
    docs: Fix a spelling error in vfio-mediated-device.txt
    docs: Fix a spelling error in ioctl-number.txt
    MAINTAINERS: update file entry for HSI subsystem
    Documentation: allow installing man pages to a user defined directory
    Doc/PM: Sync with intel_powerclamp code behavior
    zr364xx.rst: usb/devices is now at /sys/kernel/debug/
    usb.rst: move documentation from proc_usb_info.txt to USB ReST book
    convert philips.txt to ReST and add to media docs
    docs-rst: usb: update old usbfs-related documentation
    arm: Documentation: update a path name
    docs: process/4.Coding.rst: Fix a couple of document refs
    docs-rst: fix usb cross-references
    usb: gadget.h: be consistent at kernel doc macros
    usb: composite.h: fix two warnings when building docs
    usb: get rid of some ReST doc build errors
    usb.rst: get rid of some Sphinx errors
    usb/URB.txt: convert to ReST and update it
    usb/persist.txt: convert to ReST and add to driver-api book
    usb/hotplug.txt: convert to ReST and add to driver-api book
    ...

    Linus Torvalds
     

01 May, 2017

1 commit