linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Thompson <daniel.thompson@linaro.org>
To: Doug Anderson <dianders@chromium.org>
Cc: Jason Wessel <jason.wessel@windriver.com>,
	Sumit Garg <sumit.garg@linaro.org>,
	kgdb-bugreport@lists.sourceforge.net,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kgdb: Avoid suspicious RCU usage warning
Date: Wed, 3 Jun 2020 13:00:51 +0100	[thread overview]
Message-ID: <20200603120051.dxpavvsxvsxnvuct@holly.lan> (raw)
In-Reply-To: <CAD=FV=UJLTuMp0uvTY0rC51ir_GgRKYxiPCK_w8TY+MBzkqjeA@mail.gmail.com>

On Tue, Jun 02, 2020 at 03:56:33PM -0700, Doug Anderson wrote:
> > > 2. Perhaps remove the whole irq saving / restoring in kgdb_cpu_enter().
> >
> > Are you feeling lucky?
> >
> > I think there will come a time when bravery is called for but I'd rather
> > see this as part of a bigger rewrite instead of a single high risk
> > change.
> 
> Hrm, maybe.  I guess it depends on whether we want to take baby steps
> there or try to do it all at once.  If we take baby steps we will
> occasionally fall down but we'll slowly start getting things cleaned
> up.  If we wait for a full rewrite then we might be waiting for a long
> time.  It'll also be harder to figure out which of the big changes in
> the major rewrite broken someone.  ...or if the major rewrite comes in
> 20 small/bisectable patches it may be hard to revert patch 2 out of 20
> if the future patches all build upon it.  If we do one small high-risk
> change and then wait before building upon it then it'll be easy for
> someone to bisect and then yell for a revert.

My views are a bit too nuanced for me to agree or disagree with this.
I'm not against baby steps and I definitely *don't* want kgdb to
continue to be preserved in aspic.

However I'm still reluctant to start our baby steps with a "let's see
if this breaks something" patch given we know it could be a very large
number of kernel cycles before we get an answer. I would be much
happier if those baby steps started, for example, with refactoring to
decompose the beast into clearer (and dare I say better documented)
functions.

Or put another way, even if someone sent me 20 small bisectable patches
in a single kernel cycle I'd still want the high risk bits to be
towards the end of the patch set.


Daniel.

  reply	other threads:[~2020-06-03 12:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 22:53 [PATCH] kgdb: Avoid suspicious RCU usage warning Douglas Anderson
2020-05-19 10:41 ` Daniel Thompson
2020-05-28  0:02   ` Doug Anderson
2020-06-01 16:19     ` Daniel Thompson
2020-06-02 22:56       ` Doug Anderson
2020-06-03 12:00         ` Daniel Thompson [this message]
2020-06-04 17:46           ` Doug Anderson

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=20200603120051.dxpavvsxvsxnvuct@holly.lan \
    --to=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=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).