linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Sumit Garg <sumit.garg@linaro.org>
Cc: kgdb-bugreport@lists.sourceforge.net,
	Andrew Morton <akpm@linux-foundation.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Jason Wessel <jason.wessel@windriver.com>,
	Peter Zijlstra <peterz@infradead.org>,
	stefan.saecherl@fau.de, qy15sije@cip.cs.fau.de,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kgdb: Fix to kill breakpoints on initmem after boot
Date: Wed, 24 Feb 2021 10:09:25 -0800	[thread overview]
Message-ID: <CAD=FV=VOdf1TyXWQOyP=y2xaLxY6_c+xm-VSSUkFasJD1Cbgpw@mail.gmail.com> (raw)
In-Reply-To: <20210224081652.587785-1-sumit.garg@linaro.org>

Hi,

On Wed, Feb 24, 2021 at 12:17 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Currently breakpoints in kernel .init.text section are not handled
> correctly while allowing to remove them even after corresponding pages
> have been freed.
>
> Fix it via killing .init.text section breakpoints just prior to initmem
> pages being freed.

It might be worth it to mention that HW breakpoints aren't handled by
this patch but it's probably not such a big deal.


> Suggested-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  include/linux/kgdb.h      |  2 ++
>  init/main.c               |  1 +
>  kernel/debug/debug_core.c | 11 +++++++++++
>  3 files changed, 14 insertions(+)
>
> diff --git a/include/linux/kgdb.h b/include/linux/kgdb.h
> index 57b8885708e5..3aa503ef06fc 100644
> --- a/include/linux/kgdb.h
> +++ b/include/linux/kgdb.h
> @@ -361,9 +361,11 @@ extern atomic_t                    kgdb_active;
>  extern bool dbg_is_early;
>  extern void __init dbg_late_init(void);
>  extern void kgdb_panic(const char *msg);
> +extern void kgdb_free_init_mem(void);
>  #else /* ! CONFIG_KGDB */
>  #define in_dbg_master() (0)
>  #define dbg_late_init()
>  static inline void kgdb_panic(const char *msg) {}
> +static inline void kgdb_free_init_mem(void) { }
>  #endif /* ! CONFIG_KGDB */
>  #endif /* _KGDB_H_ */
> diff --git a/init/main.c b/init/main.c
> index c68d784376ca..a446ca3d334e 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1417,6 +1417,7 @@ static int __ref kernel_init(void *unused)
>         async_synchronize_full();
>         kprobe_free_init_mem();
>         ftrace_free_init_mem();
> +       kgdb_free_init_mem();
>         free_initmem();
>         mark_readonly();
>
> diff --git a/kernel/debug/debug_core.c b/kernel/debug/debug_core.c
> index 229dd119f430..319381e95d1d 100644
> --- a/kernel/debug/debug_core.c
> +++ b/kernel/debug/debug_core.c
> @@ -465,6 +465,17 @@ int dbg_remove_all_break(void)
>         return 0;
>  }
>
> +void kgdb_free_init_mem(void)
> +{
> +       int i;
> +
> +       /* Clear init memory breakpoints. */
> +       for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
> +               if (init_section_contains((void *)kgdb_break[i].bpt_addr, 0))

A nit, but instead of 0 should this be passing "BREAK_INSTR_SIZE" ?

Also: even if memory is about to get freed it still seems like it'd be
wise to call this:

  kgdb_arch_remove_breakpoint(&kgdb_break[i]);

It looks like it shouldn't matter today but just in case an
architecture decides to do something fancy in the future it might not
hurt to tell it that the breakpoint is going away.


Everything here is pretty nitty, though.  This looks good to me now.

Reviewed-by: Douglas Anderson <dianders@chromium.org>

  reply	other threads:[~2021-02-24 18:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-24  8:16 [PATCH] kgdb: Fix to kill breakpoints on initmem after boot Sumit Garg
2021-02-24 18:09 ` Doug Anderson [this message]
2021-02-24 18:20   ` Andrew Morton
2021-02-26  6:56     ` Sumit Garg
2021-02-26  6:56   ` Sumit Garg
2021-02-25 15:56 ` Daniel Thompson
2021-02-26  7:02   ` Sumit Garg
2021-02-26  7:31     ` Greg KH
2021-02-26  9:32       ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD=FV=VOdf1TyXWQOyP=y2xaLxY6_c+xm-VSSUkFasJD1Cbgpw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.thompson@linaro.org \
    --cc=jason.wessel@windriver.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qy15sije@cip.cs.fau.de \
    --cc=rostedt@goodmis.org \
    --cc=stefan.saecherl@fau.de \
    --cc=sumit.garg@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).