LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Jiri Kosina <jikos@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] livepatch: Remove duplicate warning about missing reliable stacktrace support
Date: Tue, 7 May 2019 07:03:50 -0500	[thread overview]
Message-ID: <20190507120350.gpazr6xivzwvd3az@treble> (raw)
In-Reply-To: <20190507112950.wejw6nmfwzmm3vaf@pathway.suse.cz>

On Tue, May 07, 2019 at 01:29:50PM +0200, Petr Mladek wrote:
> On Mon 2019-05-06 20:43:32, Josh Poimboeuf wrote:
> > On Mon, May 06, 2019 at 07:40:32PM -0500, Josh Poimboeuf wrote:
> > > On Tue, Apr 30, 2019 at 11:10:48AM +0200, Petr Mladek wrote:
> > > > WARN_ON_ONCE() could not be called safely under rq lock because
> > > > of console deadlock issues. Fortunately, there is another check
> > > > for the reliable stacktrace support in klp_enable_patch().
> > > > 
> > > > Signed-off-by: Petr Mladek <pmladek@suse.com>
> > > > ---
> > > >  kernel/livepatch/transition.c | 9 ++++++++-
> > > >  1 file changed, 8 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> > > > index 9c89ae8b337a..8e0274075e75 100644
> > > > --- a/kernel/livepatch/transition.c
> > > > +++ b/kernel/livepatch/transition.c
> > > > @@ -263,8 +263,15 @@ static int klp_check_stack(struct task_struct *task, char *err_buf)
> > > >  	trace.nr_entries = 0;
> > > >  	trace.max_entries = MAX_STACK_ENTRIES;
> > > >  	trace.entries = entries;
> > > > +
> > > >  	ret = save_stack_trace_tsk_reliable(task, &trace);
> > > > -	WARN_ON_ONCE(ret == -ENOSYS);
> > > > +	/*
> > > > +	 * pr_warn() under task rq lock might cause a deadlock.
> > > > +	 * Fortunately, missing reliable stacktrace support has
> > > > +	 * already been handled when the livepatch was enabled.
> > > > +	 */
> > > > +	if (ret == -ENOSYS)
> > > > +		return ret;
> > > 
> > > I find the comment to be a bit wordy and confusing (and vague).
> 
> Then please provide a better one. I have no idea what might make
> you happy and am not interested into an endless disputing.

Something like this would be clearer:

	if (ret == -ENOSYS) {
		/*
		 * This arch doesn't support reliable stack tracing.  No
		 * need to print a warning; that has already been done
		 * by klp_enable_patch().
		 */
		return ret;
	}

But my next point was that changing the code would be even better than
fixing the comment.

> > > Also this check is effectively the same as the klp_have_reliable_stack()
> > > check which is done in kernel/livepatch/core.c.  So I think it would be
> > > clearer and more consistent if the same check is done here:
> > > 
> > > 	if (!klp_have_reliable_stack())
> > > 		return -ENOSYS;
> 
> Huh, it smells with over engineering to me.

How so?  It makes the code more readable and the generated code should
be much better because it becomes a build-time check.

But I think Miroslav's suggestion to revert 1d98a69e5cef would be even
better.

> > > 	ret = save_stack_trace_tsk_reliable(task, &trace);
> > > 
> > > 	[ no need to check ret for ENOSYS here ]
> > > 
> > > Then, IMO, no comment is needed.
> > 
> > BTW, if you agree with this approach then we can leave the
> > WARN_ON_ONCE() in save_stack_trace_tsk_reliable() after all.
> 
> I really like the removal of the WARN_ON_ONCE(). I consider
> it an old fashioned way used when people are lazy to handle
> errors. It might make sense when the backtrace helps to locate
> the context but the context is well known here. Finally,
> WARN() should be used with care. It might cause reboot
> with panic_on_warn.

The warning makes the function consistent with the other weak functions
in stacktrace.c and clarifies that it should never be called unless an
arch has misconfigured something.  And if we aren't even checking the
specific ENOSYS error as I proposed then this warning would make the
error more obvious.

-- 
Josh

  reply	other threads:[~2019-05-07 12:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30  9:10 [PATCH v2 0/2] livepatch: Clean up of reliable stacktrace warnings Petr Mladek
2019-04-30  9:10 ` [PATCH v2 1/2] livepatch: Remove duplicate warning about missing reliable stacktrace support Petr Mladek
2019-04-30 11:30   ` Miroslav Benes
2019-04-30 11:56   ` Kamalesh Babulal
2019-05-07  0:40   ` Josh Poimboeuf
2019-05-07  1:43     ` Josh Poimboeuf
2019-05-07 11:29       ` Petr Mladek
2019-05-07 12:03         ` Josh Poimboeuf [this message]
2019-05-07 14:28           ` Petr Mladek
2019-05-07 21:24             ` Josh Poimboeuf
2019-05-09  7:24               ` Miroslav Benes
2019-05-13 10:43               ` Petr Mladek
2019-05-13 16:46                 ` Josh Poimboeuf
2019-05-07  8:58     ` Miroslav Benes
2019-04-30  9:10 ` [PATCH v2 2/2] livepatch: Use static buffer for debugging messages under rq lock Petr Mladek
2019-04-30 11:32   ` Miroslav Benes
2019-04-30 12:30   ` Kamalesh Babulal
2019-05-07  0:43   ` Josh Poimboeuf
2019-05-07 11:50     ` Petr Mladek
2019-05-07 13:19       ` Josh Poimboeuf

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=20190507120350.gpazr6xivzwvd3az@treble \
    --to=jpoimboe@redhat.com \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=kamalesh@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=pmladek@suse.com \
    /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).