archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <>
To: Petr Mladek <>
	Masami Hiramatsu <>,
	Andrew Morton <>,
	Peter Zijlstra <>,
	Ingo Molnar <>,
	Josh Poimboeuf <>,
	Jiri Kosina <>, Miroslav Benes <>,
Subject: Re: [PATCH 3/3 v7] livepatch: Use the default ftrace_ops instead of REGS when ARGS is available
Date: Thu, 19 Nov 2020 09:12:35 -0500	[thread overview]
Message-ID: <20201119091235.60be696e@gandalf.local.home> (raw)
In-Reply-To: <X7ZcYIWJEPXW6Z9s@alley>

On Thu, 19 Nov 2020 12:52:00 +0100
Petr Mladek <> wrote:

> > -static inline void klp_arch_set_pc(struct pt_regs *regs, unsigned long ip)
> > +static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned long ip)
> >  {
> > +	struct pt_regs *regs = ftrace_get_regs(fregs);  
> Should we check for NULL pointer here?

As mentioned in my last email. regs could have been NULL for the same
reasons before this patch, and we didn't check it then. Why should we check
it now?

The ftrace_get_regs() only makes sure that a ftrace_ops that set
FL_SAVE_REGS gets it, and those that did not, don't.

But that's not entirely true either. If there's two callbacks to the same
function, and one has FL_SAVE_REGS set, they both can have access to the
regs (before and after this patch). It's just that the one that did not
have FL_SAVE_REGS set, isn't guaranteed to have it.

-- Steve

> > +
> >  	regs->nip = ip;
> >  }

  reply	other threads:[~2020-11-19 14:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2020-11-13 17:18 ` [PATCH 3/3 v7] livepatch: Use the default ftrace_ops instead of REGS when ARGS is available Steven Rostedt
2020-11-19 11:52   ` Petr Mladek
2020-11-19 14:12     ` Steven Rostedt [this message]
2020-11-19 16:07       ` Petr Mladek

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:

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

  git send-email \
    --in-reply-to=20201119091235.60be696e@gandalf.local.home \ \ \ \ \ \ \ \ \ \ \ \

* 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).