All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Doug Anderson <dianders@chromium.org>,
	kgdb-bugreport@lists.sourceforge.net,
	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] kernel: debug: Handle breakpoints in kernel .init.text section
Date: Wed, 24 Feb 2021 10:59:20 +0530	[thread overview]
Message-ID: <CAFA6WYO9TRyavbTgXMZkHi1YoffrnV8+HxCg-WA=Qf2=-Bcw5Q@mail.gmail.com> (raw)
In-Reply-To: <20210223125447.7penkj42hd6ito4i@maple.lan>

On Tue, 23 Feb 2021 at 18:24, Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Tue, Feb 23, 2021 at 02:33:50PM +0530, Sumit Garg wrote:
> > Thanks Doug for your comments.
> >
> > On Tue, 23 Feb 2021 at 05:28, Doug Anderson <dianders@chromium.org> wrote:
> > > > To be clear there is still a very small window between call to
> > > > free_initmem() and system_state = SYSTEM_RUNNING which can lead to
> > > > removal of freed .init.text section breakpoints but I think we can live
> > > > with that.
> > >
> > > I know kdb / kgdb tries to keep out of the way of the rest of the
> > > system and so there's a bias to just try to infer the state of the
> > > rest of the system, but this feels like a halfway solution when really
> > > a cleaner solution really wouldn't intrude much on the main kernel.
> > > It seems like it's at least worth asking if we can just add a call
> > > like kgdb_drop_init_breakpoints() into main.c.  Then we don't have to
> > > try to guess the state...
>
> Just for the record, +1. This would be a better approach.
>
>
> > Sounds reasonable, will post RFC for this. I think we should call such
> > function as kgdb_free_init_mem() in similar way as:
> > - kprobe_free_init_mem()
> > - ftrace_free_init_mem()
>
> As is matching the names...
>
>
> > @@ -378,8 +382,13 @@ int dbg_deactivate_sw_breakpoints(void)
> >         int i;
> >
> >         for (i = 0; i < KGDB_MAX_BREAKPOINTS; i++) {
> > -               if (kgdb_break[i].state != BP_ACTIVE)
> > +               if (kgdb_break[i].state < BP_ACTIVE_INIT)
> > +                       continue;
> > +               if (system_state >= SYSTEM_RUNNING &&
> > +                   kgdb_break[i].state == BP_ACTIVE_INIT) {
> > +                       kgdb_break[i].state = BP_UNDEFINED;
> >                         continue;
> > +               }
> >                 error = kgdb_arch_remove_breakpoint(&kgdb_break[i]);
> >                 if (error) {
> >                         pr_info("BP remove failed: %lx\n",
> >
> > >
> > > > +                       kgdb_break[i].state = BP_ACTIVE;
> > > > +               else
> > > > +                       kgdb_break[i].state = BP_ACTIVE_INIT;
> > >
> > > I don't really see what the "BP_ACTIVE_INIT" state gets you.  Why not
> > > just leave it as "BP_ACTIVE" and put all the logic fully in
> > > dbg_deactivate_sw_breakpoints()?
> >
> > Please see my response above.
> >
> > [which was]
> > > "BP_ACTIVE_INIT" state is added specifically to handle this scenario
> > > as to keep track of breakpoints that actually belong to the .init.text
> > > section. And we should be able to again set breakpoints after free
> > > since below change in this patch would mark them as "BP_UNDEFINED":
>
> This answer does not say whether the BP_ACTIVE_INIT state needs to be
> per-breakpoint state or whether we can infer it from the global state.
>
> Changing the state of breakpoints in .init is a one-shot activity
> whether it is triggered explicitly (e.g. kgdb_free_init_mem) or implicitly
> (run the first time dbg_deactivate_sw_breakpoints is called with the system
> state >= running).
>
> As Doug has suggested it is quite possible to unify all the logic to
> handle .init within a single function by running that function when the
> state changes globally.
>

Ah, I see. Thanks for further clarification. Will get rid of
BP_ACTIVE_INIT state.

-Sumit

>
> Daniel.

      reply	other threads:[~2021-02-24  5:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-19  8:01 [PATCH] kernel: debug: Handle breakpoints in kernel .init.text section Sumit Garg
2021-02-22 23:58 ` Doug Anderson
2021-02-23  9:03   ` Sumit Garg
2021-02-23 12:54     ` Daniel Thompson
2021-02-24  5:29       ` Sumit Garg [this message]

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='CAFA6WYO9TRyavbTgXMZkHi1YoffrnV8+HxCg-WA=Qf2=-Bcw5Q@mail.gmail.com' \
    --to=sumit.garg@linaro.org \
    --cc=daniel.thompson@linaro.org \
    --cc=dianders@chromium.org \
    --cc=jason.wessel@windriver.com \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qy15sije@cip.cs.fau.de \
    --cc=stefan.saecherl@fau.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.