On Sat, 2013-03-30 at 20:46 +0100, Andreas Schwab wrote:
> "Jon Medhurst (Tixy)" writes:
>
> > For builds which succeed I see this order:
> >
> > WRAParch/arm/include/generated/asm/types.h
> > [...]
> > GEN include/generated/
On Fri, 2013-03-29 at 11:50 -0700, Tim Bird wrote:
> Hi all,
>
> A while ago I was working on supporting link-time optimization
> for ARM, and I'm just now getting around to submitting some of
> the patches from my work. I'll explain more below, but the
> executive summary is this: Andi Kleen's L
On Thu, 2012-11-01 at 17:58 +, Pawel Moll wrote:
> LEDs are often controlled by writing to memory mapped
> register. This patch adds:
>
> 1. Generic functions for platform code and drivers to create
>class device for LEDs controlled by arbitrary bit masks.
>The control register value i
On Mon, 2012-11-05 at 12:55 +, Pawel Moll wrote:
> On Mon, 2012-11-05 at 09:39 +0000, Jon Medhurst (Tixy) wrote:
> > > +static void mmio_led_brightness_set(struct led_classdev *cdev,
> > > + enum led_brightness brightness)
> > > +{
> > > + s
On Thu, 2013-08-01 at 19:45 -0400, David Long wrote:
> From: "David A. Long"
>
> Separate the kprobe-only functions from the functions needed by
> both kprobes and uprobes.
>
> Signed-off-by: David A. Long
> ---
This re-factoring looks a bit back-to-front to me, e.g. the instruction
emulation
On Thu, 2013-08-01 at 19:45 -0400, David Long wrote:
> From: "David A. Long"
>
> Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes
> support on ARM.
>
> Caveats:
>
> - Thumb is not supported
Do you know if there any plans for this to be worked on? I believe most
distros targ
On Mon, 2013-09-16 at 20:40 +0530, Viresh Kumar wrote:
> Current code looks like this:
>
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> unlock_policy_rwsem_write(cpu);
>
> {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's
On Mon, 2013-09-16 at 22:38 +0530, Viresh Kumar wrote:
> On 16 September 2013 21:57, Jon Medhurst (Tixy) wrote:
> > If I take mainline code and just change the line above to:
>
> You meant this line by above line?
>
> unlock_policy_rwsem_write(cpu);
Yes.
>
On Mon, 2013-09-16 at 20:40 +0530, Viresh Kumar wrote:
> lock_policy_rwsem_{read|write}() currently has return type of int but it
> always
> return zero and hence its return type must be void instead. This patch makes
> its
> return type void and fixes all users of it as well.
>
> Reported-by: J
On Tue, 2013-09-17 at 10:22 +0530, Viresh Kumar wrote:
> Current code looks like this:
>
> WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> unlock_policy_rwsem_write(cpu);
>
> {lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's
On Thu, 2013-08-29 at 20:16 +0200, Sebastian Hesselbarth wrote:
> On 08/29/13 15:35, Arnd Bergmann wrote:
> > On Tuesday 27 August 2013, Sebastian Hesselbarth wrote:
> >> @@ -422,16 +419,8 @@ void __init v2m_dt_init_early(void)
> >> pr_warning("vexpress: DT HBI (%x) is not
On Wed, 2012-10-10 at 12:04 +0100, Morten Rasmussen wrote:
> Hi Tixy,
>
> Could you have a look at my code stealing patch below? Since it is
> basically a trimmed version of one of your patches I would prefer to
> put you as author and have your SOB on it. What is your opinion?
Yes, I can agree w
On Mon, 2012-10-15 at 18:44 +0100, Dave Martin wrote:
> On Mon, Oct 15, 2012 at 01:44:55PM +0200, Rabin Vincent wrote:
> > 2012/10/15 Dave Martin :
> > > On Sun, Oct 14, 2012 at 09:23:13PM +0200, Rabin Vincent wrote:
> > >> Add basic uprobes support for ARM.
> > >>
> > >> perf probe --exec and Syst
When the generic ftrace implementation modifies code for trace-points it
uses stop_machine() to call ftrace_modify_all_code() on one CPU. This
ultimately calls the ARM specific function ftrace_modify_code() which
updates the instruction and then does flush_icache_range(). As this
cache flushing onl
On Thu, 2012-12-06 at 14:19 -0500, Steven Rostedt wrote:
> Hmm, your use of "may or may not" seems as you may not know this answer.
> I wonder if you can use the break point method as x86 does now, and
> remove the stop machine completely. Basically this is how it works:
>
> add sw breakpoints to
On Fri, 2012-12-07 at 09:03 -0500, Steven Rostedt wrote:
> On Fri, 2012-12-07 at 09:22 +0000, Jon Medhurst (Tixy) wrote:
> > On Thu, 2012-12-06 at 14:19 -0500, Steven Rostedt wrote:
> > > Hmm, your use of "may or may not" seems as you may not know this answer.
>
On Fri, 2012-12-07 at 10:28 -0500, Steven Rostedt wrote:
> I'm not NACKing your previous patch, I was just suggesting to bring ARM
> up to the future :-)
ARM is the future ;-)
>
> I have no problems with the patch, but I just want to put it out there
> that there's better ways. It's part of the
On Fri, 2012-12-07 at 12:13 -0500, Steven Rostedt wrote:
> I'll make my question more general:
>
> If I have a nop, that is a size of a call (branch and link), which is
> near the beginning of a function and not part of any conditional, and I
> want to convert it into a call (branch and link), wou
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
On Fri, 2012-12-07 at 19:02 +, Will Deacon wrote:
> For ARMv7, there are small subsets of instructions for ARM and Thumb which
> are guaranteed to be atomic wrt concurrent modification and execution of
> the instruction stream between different processors:
>
> Thumb:The 16-bit encoding
On Mon, 2012-12-10 at 10:04 +, Will Deacon wrote:
> Hi Jon,
>
> Back-pedalling a bit here, but I'm confused by one of your points below:
>
> On Fri, Dec 07, 2012 at 05:45:47PM +, Jon Medhurst (Tixy) wrote:
> > On Fri, 2012-12-07 at 12:13 -0500, Steven Rostedt
On Thu, 2012-11-08 at 15:23 -0500, Sasha Levin wrote:
> Just use BUG_ON() instead of constructions such as:
>
> if (...)
> BUG()
>
> A simplified version of the semantic patch that makes this transformation
> is as follows: (http://coccinelle.lip6.fr/)
>
> //
> @@
> expressi
On Wed, 2013-06-05 at 12:46 +0100, Lorenzo Pieralisi wrote:
[...]
> +
> +static bool __init __vexpress_spc_check_loaded(void);
> +static bool (*spc_check_loaded)(void) = &__vexpress_spc_check_loaded;
We get a section mismatch warning from the above because
__vexpress_spc_check_loaded is marked __i
On Wed, 2013-06-05 at 12:46 +0100, Lorenzo Pieralisi wrote:
[...]
> +static const struct of_device_id vexpress_spc_ids[] __initconst = {
> + { .compatible = "arm,vexpress-spc,v2p-ca15_a7" },
> + { .compatible = "arm,vexpress-spc" },
> + {},
> +};
> +
> +static int __init vexpress_spc_in
On Fri, 2013-05-24 at 13:53 +0100, Lorenzo Pieralisi wrote:
> In case some transactions to the Serial Power Controller (SPC) are lost owing
> to multiple operations handled at once by the M3 controller the OS needs to
> rely on a configuration API that can time out so that failures do not result
>
On Mon, 2013-06-03 at 12:52 +0100, Lorenzo Pieralisi wrote:
> On Mon, Jun 03, 2013 at 11:15:32AM +0100, Jon Medhurst (Tixy) wrote:
> > On Fri, 2013-05-24 at 13:53 +0100, Lorenzo Pieralisi wrote:
> > > In case some transactions to the Serial Power Controller (SPC) are lost
&g
On Tue, 2013-06-18 at 18:07 +0100, Sudeep KarkadaNagesha wrote:
> From: Sudeep KarkadaNagesha
>
> Few control settings done in architected timer as part of initialisation
> are lost when CPU enters deeper power states. They need to be re-initialised
> when the CPU is (warm)reset again.
>
> This
On Fri, 2013-03-08 at 13:31 +0530, Prabhakar Lad wrote:
> Usually for building uImage I follow this steps,
> 1: do a clean distclean
> 2: make ARCH=arm CROSS_COMPILE=xxx xxxdefconfig
> 3: make ARCH=arm CROSS_COMPILE=xxx uImage
>
> This used to work until 3.8, for 3.9 I see the following error:
On Mon, 2013-07-22 at 15:56 +0900, Alexandre Courbot wrote:
> When decompressing into memory, the output buffer length is set to some
> arbitrarily high value (0x7fff) to indicate the output is,
> virtually, unlimited in size.
>
> The problem with this is that some platforms have their physica
On Wed, 2013-04-24 at 17:31 +0100, Pawel Moll wrote:
> The config transactions "scheduler" was hopelessly broken,
> repeating completed transaction instead of picking up
> next pending one.
>
> Fixed now. Also improved debug messages.
>
> Signed-off-by: Pawel Moll
> ---
> drivers/mfd/vexpress-c
On Thu, 2013-04-25 at 18:14 +0100, Pawel Moll wrote:
> The config transactions "scheduler" was hopelessly broken,
> repeating completed transaction instead of picking up
> next pending one.
>
> Fixed now. Also improved debug messages.
>
> Signed-off-by: Pawel Moll
Yes, looks really fixed now. :
When a kernel is built to support multiple hardware types it's possible
that CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is set but the hardware the
kernel is run on doesn't support cpuidle and therefore doesn't load a
driver for it. In this case, when the system is shut down,
cpuidle_coupled_cpu_notify() g
On Wed, 2015-10-07 at 23:09 +0530, Viresh Kumar wrote:
[...]
> And why not fix it properly by doing this:
>
> diff --git a/drivers/cpufreq/arm_big_little.c
> b/drivers/cpufreq/arm_big_little.c
> index f1e42f8ce0fc..5b36657a76d6 100644
> --- a/drivers/cpufreq/arm_big_little.c
> +++ b/drivers/cpufr
On Mon, 2015-10-12 at 14:20 +0100, Sudeep Holla wrote:
>
> On 08/10/15 10:23, Jon Medhurst (Tixy) wrote:
> [...]
>
> > diff --git a/drivers/cpufreq/arm_big_little.c
> > b/drivers/cpufreq/arm_big_little.c
> > index f1e42f8..59115a4 100644
> > --- a/driver
On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
>
> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
[...]
> > But then we wouldn't get the WARN_ON and pr_err triggered when we detect
> > the clock rate isn't set, which surely is half the reason for the
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by bL_cpufreq_get_rat
On Wed, 2015-10-14 at 09:48 +0100, Sudeep Holla wrote:
>
> On 14/10/15 08:12, Jon Medhurst (Tixy) wrote:
> > On Tue, 2015-10-13 at 11:36 +0100, Sudeep Holla wrote:
> >>
> >> On 13/10/15 08:19, Jon Medhurst (Tixy) wrote:
> > [...]
> >>> But then
The check for correct frequency being set in bL_cpufreq_set_rate is
broken when the big.LITTLE switcher is active, for two reasons.
1. The 'new_rate' variable gets overwritten before the test by the
code calculating the frequency of the old cluster.
2. The frequency returned by bL_cpufreq_get_rat
; reexecute them, this patch call singlestep to emulate/simulate the insn
> > directly. Futher patch can optimize this behavior.
> >
> > Signed-off-by: Wang Nan
> > Acked-by: Masami Hiramatsu
> > Cc: Jon Medhurst (Tixy)
> > Cc: Russell King - ARM Linux
> > Cc:
On Tue, 2014-12-09 at 10:14 +0800, Wang Nan wrote:
> Hi all,
>
> Looks like v15 patch solves the problems found in patch v13 and v14. I run
> Tixy's test
> cases in a loop for a whole night on two real unpublished Hisilicon ARM A15
> SoCs (I
> backported kprobes to 3.10 kernel), no problem arise
On Tue, 2014-12-09 at 19:14 +0900, Masami Hiramatsu wrote:
> (2014/12/08 20:50), Jon Medhurst (Tixy) wrote:> arch_optimize_kprobes is
> calling __arch_optimize_kprobes, which is
> > iterating over a list of probes and removing each one in turn, if this
> > is happen
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
setup_test_context
These have extra 'checker' functions associated with them so lets make
sure those get covered by testing. As they may create uninitialised
space on the stack we also update the test code to ensure such space is
consistent between test runs. This is done by disabling interrupts in
setup_test_context
On Wed, 2014-12-10 at 16:23 +0800, Wang Nan wrote:
> Hi Tixy,
>
> I experienced another FAIL during test:
>
> [11567.220477] Miscellaneous instructions
> [11567.265397] -
> [11567.342626] mrsr0, cpsr@ e10f
> [11568.612656] FA
Hi Masami Hiramatsu
How should this patch find its way into the mainline? Is it OK to submit
this as part of the ARM kprobe changes (which presumably will go in via
Russell's tree)?
--
Tixy
On Mon, 2014-12-08 at 22:09 +0800, Wang Nan wrote:
> From: Masami Hiramatsu
>
> Pass the original kpro
On Wed, 2014-12-10 at 21:18 +0800, Wang Nan wrote:
[...]
> Well, I'm just working on a patch which introducing a TEST_INTOFF and disable
> interrupts
> for "MRS" testcase. Do you think it is inappropriate?
That's what I started to do, implementing in a similar way to
DONT_TEST_IN_ITBLOCK, and tho
branch instruction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang
Looks like the source file reorg caused the author of this patch to
change. It should be...
From: Jon Medhurst
On Thu, 2014-12-04 at 13:35 +0800, Wang Nan wrote:
> These have extra 'checker' functions associated with them so
> lets make sure those get covered by testing.
>
> Signed-off-by: Jon
On Thu, 2014-12-04 at 13:35 +0800, Wang Nan wrote:
> From: Masami Hiramatsu
>
> Pass the original kprobe for preparing an optimized kprobe arch-dep
> part, since for some architecture (e.g. ARM32) requires the information
> in original kprobe.
>
> Signed-off-by: Masami Hiramatsu
> Cc: Wang Nan
On Fri, 2014-12-05 at 11:38 +0800, Wang Nan wrote:
> On 2014/12/5 0:21, Jon Medhurst (Tixy) wrote:
> > On Thu, 2014-12-04 at 13:36 +0800, Wang Nan wrote:
> >
>
> [trim some text]
>
> >
> > I have retested this patch and on one of the arm test cases I get an
On Fri, 2014-12-05 at 18:32 +0800, Wang Nan wrote:
> Both your and mine failure are related to ldrd/h instruction. What
> about your second failed testcase?
Can't remember exactly, but it was some instruction that didn't access
memory I remember that much.
I've also just run the tests on an A9 CP
On Fri, 2014-12-05 at 10:10 +, Jon Medhurst (Tixy) wrote:
[...]
> I'm worried because this whole optimised kprobes has some rather
> complicated interactions, e.g. can the background thread that changes
> breakpoints to jumps (or back again?) could occur at the same time
&g
branch instruction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang
On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
> On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
> > On Mon, 2014-12-08 at 14:28 +0800, Wang Nan wrote:
> >> This patch introduce kprobeopt for ARM 32.
> >>
> >> Limitations:
> >> - Currently o
On Mon, 2014-12-08 at 20:31 +0800, Wang Nan wrote:
> On 2014/12/8 20:06, Wang Nan wrote:
> > On 2014/12/8 19:50, Jon Medhurst (Tixy) wrote:
> >> On Mon, 2014-12-08 at 19:15 +0800, Wang Nan wrote:
> >>> On 2014/12/8 19:04, Jon Medhurst (Tixy) wrote:
> >>>
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
> This patch utilizes previous introduced checker to check register usage
> for probed ARM instruction and saves it in a mask. Futher patch will
> use such information to avoid simuation or emulation.
There's a couple of spelling mistakes above an
This patch utilizes the previously introduced checker to check
register usage for probed ARM instruction and saves it in a mask.
A further patch will use such information to avoid simulation or
emulation.
Signed-off-by: Wang Nan
Reviewed-by: Jon Medhurst
Signed-off-by: Jon Medhurst
---
This pa
On Mon, 2015-01-05 at 19:29 +0800, Wang Nan wrote:
> There are 3 actions which is never used:
>
> PROBES_MOV_HALFWORD,
> PROBES_SEV,
> PROBES_WFE,
>
> This patch removes them.
>
> Signed-off-by: Wang Nan
I think that PROBES_MOV_HALFWORD should be used, for MOVW and MOVT.
Currently those ins
branch instruction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wan
I think that the patches up to 09/11 inclusive have been though more
that enough review and revisions to think about getting them merged,
there doesn't seem much point in continuously resending them whilst new
features are built on top of them.
Masami Hiramatsu, are you happy for your patch to gen
On Fri, 2015-01-09 at 10:19 +0800, Wang Nan wrote:
> In discussion on LKML (https://lkml.org/lkml/2014/11/28/158), Russell
> King suggests to move all probe related code to arch/arm/probes. This
> patch does the work. Due to dependency on 'arch/arm/kernel/patch.h', this
> patch also moves patch.h t
branch instruction before optimizer is called. Different from x86_64,
> which only copy the probed insn after optprobe_template_end and
> reexecute them, this patch call singlestep to emulate/simulate the insn
> directly. Futher patch can optimize this behavior.
>
> Signed-off-by: Wang
On Fri, 2015-01-09 at 16:35 +, Russell King - ARM Linux wrote:
> On Fri, Jan 09, 2015 at 10:25:54AM +0000, Jon Medhurst (Tixy) wrote:
> > On Fri, 2015-01-09 at 14:37 +0800, Wang Nan wrote:
> > > + " and r4, sp, #4\n"
> > > +
On Fri, 2015-01-09 at 17:57 +, Russell King - ARM Linux wrote:
[...]
> For me:
>
> $ echo 'asm ("bx r2\n");' | arm-linux-gcc -x c -c -marm -march=armv4 -v - -o
> o.o
>
> calls the assembler thusly:
>
> /usr/local/lib/gcc/arm-linux-gnueabi/4.7.4/../../../../arm-linux-gnueabi/bin/as
> \
> -v
Hi All
I'm wondering what the correct route is for getting kprobes patches into
mainline Linux. In particular I'm interested in a patch from Masami
Hiramatsu [1] which is a dependency for some ARM kprobes work we want to
merge. If acceptable, we could submit that one though the ARM
maintainer's tr
On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> Hi,
>
> This patch series adds support for:
> 1. SCPI(System Control and Power Interface) mailbox protocol
> driver.
Is there a public document with the final protocol specification?
I have spotted an inconsistency between dr
iver provides interface for all the client drivers using
> SCPI to make use of the features offered by the SCP.
>
> Signed-off-by: Sudeep Holla
> Cc: Rob Herring
> Cc: Mark Rutland
> CC: Jassi Brar
> Cc: Liviu Dudau
> Cc: Lorenzo Pieralisi
> Cc: Jon Medhurst (Ti
On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
> On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
> > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
[...]
> >> + int ret;
> >> + u8 token, chan;
> >> + struct scpi_xfer *msg;
&g
On Wed, 2015-04-29 at 12:43 +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2015-04-29 at 11:53 +0100, Sudeep Holla wrote:
> > On 28/04/15 14:54, Jon Medhurst (Tixy) wrote:
> > > On Mon, 2015-04-27 at 12:40 +0100, Sudeep Holla wrote:
> [...]
> > >> + int
On Wed, 2015-04-29 at 13:25 +0100, Jon Medhurst (Tixy) wrote:
> diff --git a/drivers/mailbox/scpi_protocol.c
> b/drivers/mailbox/scpi_protocol.c
> index c74575b..5818d9b 100644
> --- a/drivers/mailbox/scpi_protocol.c
> +++ b/drivers/mailbox/scpi_protocol.c
> @@ -286,14 +286
On Mon, 2015-06-08 at 11:40 +0100, Sudeep Holla wrote:
[...]
> +
> + scpi {
> + compatible = "arm,scpi";
> + mboxes = <&mailbox 1>;
> + shmem = <&cpu_scp_hpri>;
> +
> + clocks {
> + compatible = "arm,scpi-clocks";
> +
> +
On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long"
>
> jprobe kernel selftests are not supported for thumb kernels. Conditionally
> disable them in the kernel kprobes-test module.
I don't think it's fair to say they aren't supported, it's just that the
implementation of
On Fri, 2014-02-28 at 10:12 +, Russell King - ARM Linux wrote:
> On Mon, Feb 10, 2014 at 02:38:58AM -0500, David Long wrote:
> > diff --git a/arch/arm/kernel/probes.c b/arch/arm/kernel/probes.c
> > index 7cd1763..179deac 100644
> > --- a/arch/arm/kernel/probes.c
> > +++ b/arch/arm/kernel/probes
On Tue, 2014-04-01 at 18:29 +0100, Catalin Marinas wrote:
> On Tue, Apr 01, 2014 at 05:10:57PM +0100, Jon Medhurst (Tixy) wrote:
> > On Mon, 2014-03-31 at 18:52 +0100, Catalin Marinas wrote:
> > > The following changes since commit
> > > cfbf8d4857c26
On Wed, 2014-04-02 at 10:20 +0100, Catalin Marinas wrote:
> On Wed, Apr 02, 2014 at 09:52:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2014-04-01 at 18:29 +0100, Catalin Marinas wrote:
> > > +1: tst x0, x3 // start cache line
> >
On Wed, 2014-04-02 at 10:20 +0100, Catalin Marinas wrote:
> On Wed, Apr 02, 2014 at 09:52:02AM +0100, Jon Medhurst (Tixy) wrote:
> > On Tue, 2014-04-01 at 18:29 +0100, Catalin Marinas wrote:
> > > On Tue, Apr 01, 2014 at 05:10:57PM +0100, Jon Medhurst (Tixy) wrote:
> > >
On Fri, 2014-04-04 at 23:27 +0200, Rabin Vincent wrote:
> Use fixmaps for text patching when the kernel text is read-only,
> inspired by x86. This makes jump labels and kprobes work with the
> currently available CONFIG_DEBUG_SET_MODULE_RONX and the upcoming
> CONFIG_DEBUG_RODATA options.
>
> Sig
On Thu, 2014-01-09 at 12:54 +0200, Taras Kondratiuk wrote:
> On 3 January 2014 17:53, Jon Medhurst (Tixy) wrote:
> > On Mon, 2013-12-23 at 18:19 +0200, Taras Kondratiuk wrote:
> >> From: Ben Dooks
> >>
> >> Ensure we read instructions in the correct endi
On Wed, 2013-11-27 at 16:24 +, Mark Brown wrote:
> From: Mark Brown
>
> Eliminate the gap between DT becoming available and this being used to say
> we have full constraints by checking directly for DT every time we check
> for full constraints. This improves interoperaton with optional regul
On Thu, 2013-10-17 at 12:38 +0100, Will Deacon wrote:
> [adding Tixy for stop_machine() question below]
>
> On Thu, Oct 17, 2013 at 07:19:35AM +0100, Jiang Liu wrote:
[...]
> > +int __kprobes aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int
> > cnt)
> > +{
> > + struct aarch64_insn_
On Fri, 2013-10-18 at 09:56 +0100, Will Deacon wrote:
> Hi Tixy,
>
> On Thu, Oct 17, 2013 at 04:24:01PM +0100, Jon Medhurst (Tixy) wrote:
> > On Thu, 2013-10-17 at 12:38 +0100, Will Deacon wrote:
> > > On Thu, Oct 17, 2013 at 07:19:35A
On Wed, 2014-01-15 at 14:31 -0500, David Long wrote:
> On 12/20/13 09:58, Jon Medhurst (Tixy) wrote:
> > On Sun, 2013-12-15 at 23:08 -0500, David Long wrote:
[...]
> >> {
> >> #ifdef CONFIG_THUMB2_KERNEL
> >>if (thumb) {
> >> @@ -253,7 +25
On Sun, 2014-03-02 at 13:40 +0800, Grant Likely wrote:
> On Fri, 28 Feb 2014 14:42:50 +0100, Marek Szyprowski
> wrote:
> > This patch adds code for automated assignment of reserved memory regions
> > to struct device. reserved_mem->ops->device_init()/device_cleanup()
> > callbacks are called to p
On Mon, 2014-04-07 at 11:04 -0700, Kees Cook wrote:
> On Mon, Apr 7, 2014 at 6:57 AM, Jon Medhurst (Tixy) wrote:
> > On Fri, 2014-04-04 at 23:27 +0200, Rabin Vincent wrote:
> >> Use fixmaps for text patching when the kernel text is read-only,
> >> inspired by x86.
On Fri, 2014-04-04 at 17:07 -0700, Kees Cook wrote:
> On Fri, Apr 4, 2014 at 12:58 PM, Rabin Vincent wrote:
[...]
> > You need a TLB flush. I had a flush_tlb_all() in my example patch,
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244335.html,
> > but the following is proba
On Tue, 2014-04-08 at 09:01 -0700, Kees Cook wrote:
> On Tue, Apr 8, 2014 at 5:41 AM, Jon Medhurst (Tixy) wrote:
> > On Fri, 2014-04-04 at 17:07 -0700, Kees Cook wrote:
> >> On Fri, Apr 4, 2014 at 12:58 PM, Rabin Vincent wrote:
> > [...]
> >> > You need a TL
On Tue, 2014-04-08 at 21:48 +0200, Rabin Vincent wrote:
[...]
> For any other CPU to pull in the writable entry it would have to get a
> TLB miss inside the loop in multi_cpu_stop(), after the state transition
> to MULTI_STOP_RUN and before the state transition to MULTI_STOP_EXIT.
> This is unlikel
On Sun, 2014-03-23 at 16:21 -0600, Kees Cook wrote:
> On Sun, Mar 23, 2014 at 12:47 PM, Laura Abbott wrote:
> > On 2/17/2014 4:34 AM, Dave Martin wrote:
> >> On Fri, Feb 14, 2014 at 11:11:07AM -0800, Kees Cook wrote:
> >>> On Fri, Feb 14, 2014 at 8:22 AM, Dave Martin wrote:
> On Thu, Feb 13,
On Mon, 2014-03-31 at 18:52 +0100, Catalin Marinas wrote:
> The following changes since commit cfbf8d4857c26a8a307fb7cd258074c9dcd8c691:
>
> Linux 3.14-rc4 (2014-02-23 17:40:03 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
>
On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long"
>
> Make the instruction interpreter call back to semantic action functions
> through a function pointer array provided by the invoker. The interpreter
> decodes the instructions into groups and uses the group number to
On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long"
>
> Change the generic ARM probes code to pass in the opcode and
> architecture-specific
> structure separately instead of using struct kprobe, so we do not pollute
> code being used only for uprobes or other non-kprobe
On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long"
>
> Now that arm uprobes support has been made separate from the arm kprobes code
> the Kconfig can be changed to reflect that.
>
> Signed-off-by: David A. Long
> ---
> arch/arm/Kconfig | 1 -
> 1 file changed, 1 dele
On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long"
>
> Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes
> support on ARM.
>
> Caveats:
>
> - Thumb is not supported
>
> Signed-off-by: David A. Long
As this is based on Rabin's work, and the new fil
On Thu, 2014-01-23 at 15:05 -0500, David Long wrote:
> From: "David A. Long"
>
> This patch series adds basic uprobes support to ARM. It is based on patches
> developed earlier by Rabin Vincent. That approach of adding hooks into
> the kprobes instruction parsing code was not well received. This
On Sun, 2013-12-15 at 23:08 -0500, David Long wrote:
> From: "David A. Long"
>
> Move the thumb version of the kprobes instruction parsing code into more
> generic
> files from where it can be used by uprobes and possibly other subsystems. The
> symbol names will be made more generic in a subseq
On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long"
>
> Move the thumb version of the kprobes instruction parsing code into more
> generic
This patch is moving the 'ARM' instructions, not 'thumb' instructions,
so both description and title needs fixing for that.
Actual
On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long"
>
> When interpreting instructions use a client-supplied array of functions
> to take action. This array can then be provided by krpobes, uprobes, or
'to take action' sounds a bit weird to me, how about 'to specify
act
On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long"
>
> Instead of depending on include/asm/kprobes.h to provide a dummy definition
> for struct arch_specific_insn, do so in include/linux/kprobes.h.
That change description doesn't quite seem to quite make sense to me.
A
On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> From: "David A. Long"
>
> Use the prefix "probes_" for APIs and definitions to be shared between
> kprobes and uprobes. Pass additional information into the lower-level decoding
> functions to avoid having to duplicate architecture-specfific
On Thu, 2013-11-14 at 11:02 +0900, Masami Hiramatsu wrote:
> (2013/11/14 2:13), Jon Medhurst (Tixy) wrote:
> > On Tue, 2013-10-15 at 17:04 -0400, David Long wrote:
> >> From: "David A. Long"
> >>
> >> Instead of depending on include/asm/kprobes.h
1 - 100 of 204 matches
Mail list logo
