08 Apr, 2020

2 commits

  • The 'data_breakpoint' test code is the only modular user of
    kallsyms_lookup_name(), which was exported as part of fixing the test in
    f60d24d2ad04 ("hw-breakpoints: Fix broken hw-breakpoint sample module").

    In preparation for un-exporting this symbol, switch the test over to using
    __symbol_get(), which can be used to place breakpoints on exported
    symbols.

    Signed-off-by: Will Deacon
    Signed-off-by: Andrew Morton
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Masami Hiramatsu
    Reviewed-by: Quentin Perret
    Cc: K.Prasad
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Frederic Weisbecker
    Cc: Alexei Starovoitov
    Cc: Miroslav Benes
    Cc: Petr Mladek
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/20200221114404.14641-3-will@kernel.org
    Signed-off-by: Linus Torvalds

    Will Deacon
     
  • Patch series "Unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()".

    Despite having just a single modular in-tree user that I could spot,
    kallsyms_lookup_name() is exported to modules and provides a mechanism
    for out-of-tree modules to access and invoke arbitrary, non-exported
    kernel symbols when kallsyms is enabled.

    This patch series fixes up that one user and unexports the symbol along
    with kallsyms_on_each_symbol(), since that could also be abused in a
    similar manner.

    I would like to avoid out-of-tree modules being easily able to call
    functions that are not exported. kallsyms_lookup_name() makes this
    trivial to the point that there is very little incentive to rework these
    modules to either use upstream interfaces correctly or propose
    functionality which may be otherwise missing upstream. Both of these
    latter solutions would be pre-requisites to upstreaming these modules, and
    the current state of things actively discourages that approach.

    The background here is that we are aiming for Android devices to be able
    to use a generic binary kernel image closely following upstream, with any
    vendor extensions coming in as kernel modules. In this case, we (Google)
    end up maintaining the binary module ABI within the scope of a single LTS
    kernel. Monitoring and managing the ABI surface is not feasible if it
    effectively includes all data and functions via kallsyms_lookup_name().
    Of course, we could just carry this patch in the Android kernel tree, but
    we're aiming to carry as little as possible (ideally nothing) and I think
    it's a sensible change in its own right. I'm surprised you object to it,
    in all honesty.

    Now, you could turn around and say "that's not upstream's problem", but it
    still seems highly undesirable to me to have an upstream bypass for
    exported symbols that isn't even used by upstream modules. It's ripe for
    abuse and encourages people to work outside of the upstream tree. The
    usual rule is that we don't export symbols without a user in the tree and
    that seems especially relevant in this case.

    Joe Lawrence said:

    : FWIW, kallsyms was historically used by the out-of-tree kpatch support
    : module to resolve external symbols as well as call set_memory_r{w,o}()
    : API. All of that support code has been merged upstream, so modern kpatch
    : modules* no longer leverage kallsyms by default.
    :
    : That said, there are still some users who still use the deprecated support
    : module with newer kernels, but that is not officially supported by the
    : project.

    This patch (of 3):

    Given the name of a kernel symbol, the 'data_breakpoint' test claims to
    "report any write operations on the kernel symbol". However, it creates
    the breakpoint using both HW_BREAKPOINT_W and HW_BREAKPOINT_R, which menas
    it also fires for read access.

    Drop HW_BREAKPOINT_R from the breakpoint attributes.

    Signed-off-by: Will Deacon
    Signed-off-by: Andrew Morton
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Masami Hiramatsu
    Reviewed-by: Quentin Perret
    Cc: K.Prasad
    Cc: Thomas Gleixner
    Cc: Greg Kroah-Hartman
    Cc: Frederic Weisbecker
    Cc: Alexei Starovoitov
    Cc: Miroslav Benes
    Cc: Petr Mladek
    Cc: Joe Lawrence
    Link: http://lkml.kernel.org/r/20200221114404.14641-2-will@kernel.org
    Signed-off-by: Linus Torvalds

    Will Deacon
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version this program is distributed in the
    hope that it will be useful but without any warranty without even
    the implied warranty of merchantability or fitness for a particular
    purpose see the gnu general public license for more details you
    should have received a copy of the gnu general public license along
    with this program if not write to the free software foundation inc
    59 temple place suite 330 boston ma 02111 1307 usa

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 1334 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Reviewed-by: Richard Fontana
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

21 May, 2019

1 commit


01 Jul, 2011

2 commits

  • The perf_event overflow handler does not receive any caller-derived
    argument, so many callers need to resort to looking up the perf_event
    in their local data structure. This is ugly and doesn't scale if a
    single callback services many perf_events.

    Fix by adding a context parameter to perf_event_create_kernel_counter()
    (and derived hardware breakpoints APIs) and storing it in the perf_event.
    The field can be accessed from the callback as event->overflow_handler_context.
    All callers are updated.

    Signed-off-by: Avi Kivity
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1309362157-6596-2-git-send-email-avi@redhat.com
    Signed-off-by: Ingo Molnar

    Avi Kivity
     
  • The nmi parameter indicated if we could do wakeups from the current
    context, if not, we would set some state and self-IPI and let the
    resulting interrupt do the wakeup.

    For the various event classes:

    - hardware: nmi=0; PMI is in fact an NMI or we run irq_work_run from
    the PMI-tail (ARM etc.)
    - tracepoint: nmi=0; since tracepoint could be from NMI context.
    - software: nmi=[0,1]; some, like the schedule thing cannot
    perform wakeups, and hence need 0.

    As one can see, there is very little nmi=1 usage, and the down-side of
    not using it is that on some platforms some software events can have a
    jiffy delay in wakeup (when arch_irq_work_raise isn't implemented).

    The up-side however is that we can remove the nmi parameter and save a
    bunch of conditionals in fast paths.

    Signed-off-by: Peter Zijlstra
    Cc: Michael Cree
    Cc: Will Deacon
    Cc: Deng-Cheng Zhu
    Cc: Anton Blanchard
    Cc: Eric B Munson
    Cc: Heiko Carstens
    Cc: Paul Mundt
    Cc: David S. Miller
    Cc: Frederic Weisbecker
    Cc: Jason Wessel
    Cc: Don Zickus
    Link: http://lkml.kernel.org/n/tip-agjev8eu666tvknpb3iaj0fg@git.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

31 Mar, 2011

1 commit


27 Feb, 2010

1 commit

  • Add __percpu sparse annotations to hw_breakpoint.

    These annotations are to make sparse consider percpu variables to be
    in a different address space and warn if accessed without going
    through percpu accessors. This patch doesn't affect normal builds.

    In kernel/hw_breakpoint.c, per_cpu(nr_task_bp_pinned, cpu)'s will
    trigger spurious noderef related warnings from sparse. Changing it to
    &per_cpu(nr_task_bp_pinned[0], cpu) will work around the problem but
    deemed to ugly by the maintainer. Leave it alone until better
    solution can be found.

    Signed-off-by: Tejun Heo
    Cc: Stephen Rothwell
    Cc: K.Prasad
    LKML-Reference:
    Signed-off-by: Frederic Weisbecker

    Tejun Heo
     

06 Dec, 2009

1 commit

  • struct perf_event::event callback was called when a breakpoint
    triggers. But this is a rather opaque callback, pretty
    tied-only to the breakpoint API and not really integrated into perf
    as it triggers even when we don't overflow.

    We prefer to use overflow_handler() as it fits into the perf events
    rules, being called only when we overflow.

    Reported-by: Peter Zijlstra
    Signed-off-by: Frederic Weisbecker
    Cc: Paul Mackerras
    Cc: Arnaldo Carvalho de Melo
    Cc: "K. Prasad"

    Frederic Weisbecker
     

27 Nov, 2009

1 commit

  • Kernel breakpoints are created using functions in which we pass
    breakpoint parameters as individual variables: address, length
    and type.

    Although it fits well for x86, this just does not scale across
    architectures that may support this api later as these may have
    more or different needs. Pass in a perf_event_attr structure
    instead because it is meant to evolve as much as possible into
    a generic hardware breakpoint parameter structure.

    Reported-by: K.Prasad
    Signed-off-by: Frederic Weisbecker
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

26 Nov, 2009

1 commit

  • This simplifies the error handling when we create a breakpoint.
    We don't need to check the NULL return value corner case anymore
    since we have improved perf_event_create_kernel_counter() to
    always return an error code in the failure case.

    Signed-off-by: Frederic Weisbecker
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Paul Mackerras
    Cc: Steven Rostedt
    Cc: Prasad
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

24 Nov, 2009

1 commit


10 Nov, 2009

1 commit


03 Jun, 2009

1 commit