[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1354904322.8263.20.camel@linaro1.home>
Date: Fri, 07 Dec 2012 18:18:42 +0000
From: "Jon Medhurst (Tixy)" <tixy@...aro.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Russell King - ARM Linux <linux@....linux.org.uk>,
linux-arm-kernel@...ts.infradead.org,
Ingo Molnar <mingo@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Rabin Vincent <rabin@....in>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ARM: ftrace: Ensure code modifications are synchronised
across all cpus
On Fri, 2012-12-07 at 13:06 -0500, Steven Rostedt wrote:
> >
> > However, wouldn't we need any of this breakpoint malarkey, why not just
> > just use a 16-bit branch instruction which branches over the second half
> > of the nop? :-)
>
> If you can get away with that, sure. Or better yet. If the arch supports
> it, you can do what I did with powerpc. That was just replace the nop
> with the 32bit branch, and the 32bit branch with a 32bit nop. No nops.
> No multiple steps in between. I just did the swap of all function
> tracepoints in one fell swoop, and then did the icache sync.
But that gets back to the original problem that the 32bit instructions
can straddle two cache lines.
>
> Now that's if the arch doesn't have issues with swapping code like this.
> Can a 32bit branch-and-link be spread across cache lines?
Yes, Thumb2 instructions are either 16 or 32bit and are aligned to 16bit
boundaries. So 16bit instructions never cross cache lines and all 32bit
instructions can.
> On x86 the
> call is 5 bytes and can be. Thus, we were forced to do the breakpoint
> because we don't know how the instructions are laid out on the cache
> lines.
>
> If 32bit can't be swapped but 16bit never crosses cache lines, then your
> approach may also work.
It should.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists