On Wed, 2012-08-22 at 18:41 +, Arnd Bergmann wrote:
> On Wednesday 22 August 2012, Nicolas Pitre wrote:
> > On Wed, 22 Aug 2012, Arnd Bergmann wrote:
> > > >
> > > > The ldrex/strex instructions are available on ARMv6. It's only the d
> > > > variants (strexd/ldrexd) which are only available
On Thu, 2012-08-23 at 12:09 +, Arnd Bergmann wrote:
> commit abfef4db8731591fbb721262bd4712662aaa6d14
> Author: Arnd Bergmann
> Date: Thu Aug 16 07:49:31 2012 +
>
> ARM: kprobes: make more tests conditional
>
> The mls instruction is not available in ARMv6K or below, so we
number of patching attempts since it was introduced for various
> > problems, and I've seen quite a number of builds fail for various
> > reasons in this file (none which I could be bothered to investigate.)
> >
> As for build failures with that test code, I'd sugges
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/
eeds the real Thumb2 instructions, not empty macros, and
indeed it doesn't use them, because it is only compiled when
CONFIG_THUMB2_KERNEL=y and that selects CONFIG_ARM_ASM_UNIFIED and those
'it' macro's are guarded by #ifndef CONFIG_ARM_ASM_UNIFIED.
Note, there are other files whi
gt; int id, const struct gpio_led_platform_data *pdata);
>
> +/* For the leds-mmio driver */
> +
> +struct mmio_led;
> +
> +#if defined(CONFIG_LEDS_MMIO)
> +/* Returns ERR_PTR in case of error */
> +struct mmio_led *mmio_led_register(struct device *parent, spinlock_t *lock,
> +
On Mon, 2012-11-05 at 12:55 +, Pawel Moll wrote:
> On Mon, 2012-11-05 at 09:39 +, 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
> ---
> Hi Rafael,
>
> Probably we can get this patch in for 3.12? The second one can go in 3.13.
>
> These are compile tested only at my end. Tixy reported these and probably can
> give his tested-by once he is done testing them.
>
> drivers/cpufreq/cpufreq.c |
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
ct device
> *dev,
>
> new_cpu = cpufreq_nominate_new_policy_cpu(policy, cpu, frozen);
> if (new_cpu >= 0) {
> - WARN_ON(lock_policy_rwsem_write(cpu));
> update_policy_cpu(policy, new_cpu);
> -
that sched_clock is never going to get
read before time_init() has actually started the clock it reads? Are we
making things more fragile?
(My testing was on a 3.11-rc6 based Linaro kernel on TC2 because that's
what I had to hand. So it's not a vanilla mainline kernel and I have
other vexpress changes in my tree.)
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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?
Y
e up with some sensible suggestions on a
cleaner solution; because I feel that as they stand they aren't really
suitable for inclusion in the kernel.
Rabin, what tree/commit are your patches based on? (They don't seem to
apply cleanly to 3.6 or 3.7-rc1.) I want to apply them locally
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
onditional, so you can't reverse decode the
instruction stream reliably to even detect such code.
And further, it's implementation defined (up to who every creates the
silicon) whether an undefined instructions actually causes an abort when
it occurs in such an 'it' block, it m
On Fri, 2012-12-07 at 09:03 -0500, Steven Rostedt wrote:
> On Fri, 2012-12-07 at 09:22 +, 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.
>
er ways. It's part of the remove stomp_machine()
> crusade ;-)
Indeed, when I first cam across stop_machine(), I though 'yuck!',
especially when I realised Linux scheduling seems to mean the system
goes idle until the the next tick triggers scheduling of these 'highest
prio
breakpoint malarkey, why not just
just use a 16-bit branch instruction which branches over the second half
of the nop? :-)
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
structions 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
ction?
Also, kprobes currently uses patch_text() which only uses stop_machine
for Thumb2 instructions which straddle a word boundary, so this needs
changing?
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
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
ded();
> +}
> +EXPORT_SYMBOL_GPL(vexpress_spc_check_loaded);
> +
> +static int __init vexpress_spc_early_init(void)
> +{
> + __vexpress_spc_check_loaded();
> + return vexpress_spc_load_result;
> +}
> +early_initcall(vexpress_spc_early_init);
[...]
--
Tixy
--
To unsubscribe fro
> + * make the functionality check available to loadable
> + * modules, when early boot init functions have been
> + * already freed from kernel address space.
> + */
> +bool vexpress_spc_check_loaded(void)
> +{
> + return spc_check_loaded();
> +}
> +EXPORT_SYMBOL_GPL(vexpress_s
func, offset, data,
> + MAX_SCHEDULE_TIMEOUT);
> +}
> +
> +static inline int vexpress_config_write(struct vexpress_config_func *func,
> + int offset, u32 data)
> +{
> + return vexpress_config_write_timeout(func, offset, data,
> + MAX_SCHEDULE_TIMEOUT);
> +}
>
> /* Platform control */
>
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
init arch_timer_register(void)
> {
> int err;
> @@ -316,11 +347,17 @@ static int __init arch_timer_register(void)
> if (err)
> goto out_free_irq;
>
> + err = arch_timer_cpu_pm_init();
> + if (err)
> + goto out_unreg_notify;
>
ts.c:2:
include/uapi/linux/types.h:4:23: fatal error: asm/types.h: No such file or
directory
[...]
WRAParch/arm/include/generated/asm/types.h
These makefile and scripts are a bit beyond my immediate understanding
so can't suggest a fix.
--
Tixy
--
To unsubscribe from this list
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
;
except in the case status==VEXPRESS_CONFIG_STATUS_WAIT.
Or, does the call to func_exec cause vexpress_config_complete() to be
called later? (It hadn't better be called synchronously or we get a
deadlock).
Actually, if it is called later, there is still a problem because if the
call to func_exec returns VEXPRESS_CONFIG_STAT
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:
567bfab 4567c0ab
4567c1ab 4567c2ab 4567c3ab 4567c4ab
4567c5ab 4567c6ab 4567c7ab 4567c8ab
strh r3, [r13, #-64-8]! @ e16d34b8
strhr4, [r14, #-64-8]! @ e16e44b8
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
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@ e10
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
>
> Pas
ps non-secure mode will always read FIQ flag as zero in such a
case?)
So in the end I thought the only robust way of writing the tests would
be to ignore the values of the A and F flags.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
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
matsu
> Cc: Wang Nan
Seems strange cc'ing yourself :-) That should be Signed-off-by instead,
as you're the person sending out the patch.
[rest of patch trimmed]
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
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
un the tests on an A9 CPU and get the Oops on the nop
after the 'wfi' instruction test. So looks like the problem isn't
related to particular test cases.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
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:
> >>>
egs_normal},
> + [PROBES_BITFIELD] = {.checker = arm_check_regs_normal},
> + [PROBES_LDMSTM] = {.checker = arm_check_regs_ldmstm},
> + [PROBES_MOV_IP_SP] = {.checker = arm_check_regs_mov_ip_sp},
> + [PROBES_LDRSTRD] = {.checker = arm_check_regs_ldrdstrd},
> +
patch applies my review comments on "[PATCH v19 10/11] ARM:
kprobes: check register usage for probed instruction."
It is also rebased on top of the kprobes-opt branch at
git://git.linaro.org/people/tixy/kernel.git
arch/arm/include/asm/probes.h | 1 +
arch/arm/probe
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
her a branch in a
git repository for those patches, or I'm more than happy to do that if
you like. Then I can give the series a final test and we can send a pull
request to Russell King.
Thanks all
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
t;
> #include
>
> -#include "patch.h"
> +#include
To keep alphabetical ordering of headers this should be above the
#include
Don't bother resending the patch, I'll just update the patch in the git
branch I'm putting together.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 +, Jon Medhurst (Tixy) wrote:
> > On Fri, 2015-01-09 at 14:37 +0800, Wang Nan wrote:
> > > + " and r4, sp, #4\n"
> > > +
x?
I guess the answer is yes if we want to catch uses of BX in inline
assembly. A quick and not very thorough grep of arch/arm for 'bx'
doesn't seem to turn up any existing dodgy uses, except in the kprobes
test code I wrote :-(
--
Tixy
--
To unsubscribe from this list: send the
intainer's tree with our other work.
[1] http://marc.info/?l=linux-kernel&m=142045769001242&w=2
(kprobes: Pass the original kprobe for preparing optimized kprobe)
Thanks
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
istency between driver and a draft doc I have
but before commenting on things like that it would be good to have the
final version of the document instead.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
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
is
one being currently used by the out-of-tree code).
Also, I believe that both display outputs share the same clock, and so
pxlclk0 and pxlclk1 can't be controlled independently. But I guess these
device-tree entries are for the interface to the SCP firmware, not the
hardware, and if that p
+1675,8 @@ static int __init run_all_tests(void)
out:
if (ret == 0)
+ ret = tests_failed;
+ if (ret == 0)
pr_info("Finished kprobe tests OK\n");
else
pr_err("kprobe tests failed\n");
--
Tixy
--
To unsub
27;:
> arch/arm/kernel/probes.c:68:2: error: implicit declaration of function
> 'BUG_ON' [-Werror=implicit-function-declaration]
> make[2]: *** [arch/arm/kernel/probes.o] Error 1
>
> This is because linux/kprobes.h includes linux/bug.h, which would provide
> the requi
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:
> > >
_to_virt(fixmap) + (uintaddr & ~PAGE_MASK));
How does fixmap cope with cache colouring? Looking at the implementation
it looks like it doesn't and so fixmap use on ARM is possibly buggy.
For the text patching case where we know there are no writeable mappings
[1] this should be OK if we used set_fixmap_
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
| of_have_populated_dt();
> }
>
> /**
Doesn't this now make this code in regulator_init_complete()
redundant..?
if (of_have_populated_dt())
has_full_constraints = true;
Or is keeping this to avoid one less variable check a worthwhile
optimisation?
--
Tixy
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)
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
low 4GB for 32-bit devices without an iommu).
For reference, the mail archives for this series is at
http://lkml.org/lkml/2014/2/28/237
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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.
cpu_stop+0xc0/0x114) from
> [] (cpu_stopper_thread+0xd8/0x164)
> [ 34.247266] [] (cpu_stopper_thread+0xd8/0x164) from
> [] (kthread+0xc8/0xd8)
> [ 34.247323] [] (kthread+0xc8/0xd8) from []
> (ret_from_fork+0x14/0x20)
>
> Using local_flush_tlb_kernel_range() fixed it though.
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
isters and page
tables at any given time, the CPU can speculatively use that address
translation and read that memory. And if it's marked cacheable, pull it
into the cache. Oh, and if there is a dirty cacheline in another
CPU/clusters cache, move that dirty entry over into it's own cache (I
b
t; >> place.
> >>
> >>>
> >>>> Are you aware of similar situations on other arches?
> >>>
> >>> I think there were some problems a long time ago on x86 for rodata too.
> >>
> >> It would be good to get this kexec case fixed --
e(start, end)
> + * - start - virtual start address of region
> + * - end - virtual end address of region
> + */
> +ENTRY(__dma_flush_range)
> + dcache_line_size x2, x3
> + sub x3, x2, #1
> + bic x0, x0, x3
> +1: dc civac, x0
struct decode_header *);
> +
Adding 'const' above will also have the knock on effect of requiring
const on all the 'custom decode' functions as well.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
nsn, struct arch_specific_insn *asi,
> struct decode_header *d)
> {
The above removal of 'static' appears to be an unneeded accidental
change?
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
H_SUPPORTS_UPROBES
> - depends on KPROBES
> def_bool y
>
> config ARCH_HAS_DMA_SET_COHERENT_MASK
Was this patch meant to have other contents? If not, it seems a bit
pointless as all it does is remove a line added in the previous patch,
so should just be folded into that one.
-
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
the parsing.
Assuming my comment about 'const' use in patch 5 is addressed, then for
patches 2 to 14 you can add:
Acked-by: Jon Medhurst
Thanks Dave for persevering.
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
> + PROBES_T16_WFE,
> + PROBES_T16_IT,
> + PROBES_T16_CMP,
> + PROBES_T16_ADDSUB,
> + PROBES_T16_LOGICAL,
> + PROBES_T16_BLX,
> + PROBES_T16_HIREGOPS,
> + PROBES_T16_LDR_LIT,
> + PROBES_T16_LDRHSTRH,
> + PROBES_T16_LDRSTR,
> + PROBES_T16_ADR
fine branch_displacement(insn) sign_extend(((insn) & 0xff) << 2, 25)
> +#include "probes.h"
Rather than include "probes.h" after "kprobes.h" here, (and in the other
7 places in this patch, and other patches) I think it would make more
sense to have kp
umb code reorg of moving code from kprobes-thumb.c to
probes-thumb.c
I've no other comments on the patch so trimmed the rest...
--
Tixy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
1 - 100 of 207 matches
Mail list logo
