[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200219164638.GE2935@paulmck-ThinkPad-P72>
Date: Wed, 19 Feb 2020 08:46:38 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, mingo@...nel.org,
joel@...lfernandes.org, gregkh@...uxfoundation.org,
gustavo@...eddedor.com, tglx@...utronix.de, josh@...htriplett.org,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
luto@...nel.org, tony.luck@...el.com, frederic@...nel.org,
dan.carpenter@...cle.com, mhiramat@...nel.org
Subject: Re: [PATCH v3 04/22] x86/doublefault: Make memmove() notrace/NOKPROBE
On Wed, Feb 19, 2020 at 05:34:09PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 19, 2020 at 08:27:47AM -0800, Paul E. McKenney wrote:
> > On Wed, Feb 19, 2020 at 11:12:28AM -0500, Steven Rostedt wrote:
> > > On Wed, 19 Feb 2020 17:04:42 +0100
> > > Peter Zijlstra <peterz@...radead.org> wrote:
> > >
> > > > > - memmove(&gpregs->ip, (void *)regs->sp, 5*8);
> > > > > + for (i = 0; i < count; i++) {
> > > > > + int idx = (dst <= src) ? i : count - i;
> > > >
> > > > That's an off-by-one for going backward; 'count - 1 - i' should work
> > > > better, or I should just stop typing for today ;-)
> > >
> > > Or, we could just cut and paste the current memmove and make a notrace
> > > version too. Then we don't need to worry bout bugs like this.
> >
> > OK, I will bite...
> >
> > Can we just make the core be an inline function and make a notrace and
> > a trace caller? Possibly going one step further and having one call
> > the other? (Presumably the traceable version invoking the notrace
> > version, but it has been one good long time since I have looked at
> > function preambles.)
>
> One complication is that GCC (and others) are prone to stick their own
> implementation of memmove() (and other string functions) in at 'random'.
> That is, it is up to the compiler's discretion wether or not to put a
> call to memmove() in or just emit some random giberish they feel has the
> same effect.
>
> So if we go play silly games like that, we need be careful (or just call
> __memmove I suppose, which is supposed to avoid that IIRC).
Urgh, good point. :-/
Thanx, Paul
Powered by blists - more mailing lists