Re: [PATCH] perf tools: fix build for various architectures
On Tue, Nov 27, 2012 at 12:16:31PM +, Mark Rutland wrote: > The UAPI changes broke the perf tool, and as of 3.7-rc7, it > still won't build for arm: > > In file included from util/../perf.h:81:0, >from util/cache.h:7, >from perf.c:12: > util/../../../arch/arm/include/asm/unistd.h:16:29: fatal error: > uapi/asm/unistd.h: No such file or directory > compilation terminated. > make: *** [perf.o] Error 1 > > It seems the perf tool build infrastructure can't map paths, > and several architectures (arm, arm64, ia64, mips, parisc, powerpc, > s390) include from their . > > This patch copies 77626081: "perf tools: Fix build on sparc." in simply > changing the path to use arch/arm/include/uapi/asm/unistd.h directly for > all of these cases. > > I've tested this on arm, but I don't have the necessary toolchains to > check the other cases. For the arm/arm64 parts: Acked-by: Will Deacon Cheers, Will -- 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/
Re: udelay function delays the wrong time interval in multiprocessor system, if ARCH_HAS_READ_CURRENT_TIMER is not defined and on current timer is used.
On Sat, Mar 16, 2013 at 03:32:43AM +, chpoph wrote:
> On Sat, Mar 16, 2013 at 2:14 AM, Russell King - ARM Linux
> wrote:
> > We don't support different CPUs running at different frequencies with
> > the delay loop. Sorry.
>
> Does it means that a timer-based delay implementation must be used to
> get an accurate delay in SMP. I think it should print a warning
> message if the CPU delay loop is used in SMP. In my system, the wrong
> delay interval fluctuated with CPU frequencies caused a control
> problem.
I've been playing around with loops_per_jiffy recently, in an attempt to
clean up the cpufreq scaling code so that the SMP-ness is in core code,
rather than being duplicated by every architecture:
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git lpj
With those changes, it's pretty easy to get different delays depending on
the current CPU, but it would require preempt_{enable,disable} calls around
the delay, which I haven't convinced myself about.
Do you actually have an ARM platform that can scale the CPU frequencies
independently?
Will
--
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/
Re: [PATCH v2, part3 02/12] mm/ARM64: kill poison_init_mem()
On Sat, Mar 16, 2013 at 05:03:23PM +, Jiang Liu wrote:
> Use free_reserved_area() to kill poison_init_mem() on ARM64.
>
> Signed-off-by: Jiang Liu
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm64/mm/init.c | 17 +++--
> 1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index e58dd7f..b87bdb8 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -197,14 +197,6 @@ void __init bootmem_init(void)
> max_pfn = max_low_pfn = max;
> }
>
> -/*
> - * Poison init memory with an undefined instruction (0x0).
> - */
> -static inline void poison_init_mem(void *s, size_t count)
> -{
> - memset(s, 0, count);
> -}
> -
> #ifndef CONFIG_SPARSEMEM_VMEMMAP
> static inline void free_memmap(unsigned long start_pfn, unsigned long
> end_pfn)
> {
> @@ -386,8 +378,7 @@ void __init mem_init(void)
>
> void free_initmem(void)
> {
> - poison_init_mem(__init_begin, __init_end - __init_begin);
> - free_initmem_default(-1);
> + free_initmem_default(0);
This change looks unrelated to $subject. We should probably just poison with
0 from the outset, when free_initmem_default is introduced.
Will
--
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/
[PATCH] alpha: makefile: don't enforce small data model for kernel builds
Due to all of the goodness being packed into today's kernels, the resulting image isn't as slim as it once was. In light of this, don't pass -msmall-data to the tools, which results in link failures due to impossible relocations when compiling anything but the most trivial configurations. Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Signed-off-by: Will Deacon --- arch/alpha/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/alpha/Makefile b/arch/alpha/Makefile index 4759fe7..2cc3cc5 100644 --- a/arch/alpha/Makefile +++ b/arch/alpha/Makefile @@ -12,7 +12,7 @@ NM := $(NM) -B LDFLAGS_vmlinux:= -static -N #-relax CHECKFLAGS += -D__alpha__ -m64 -cflags-y := -pipe -mno-fp-regs -ffixed-8 -msmall-data +cflags-y := -pipe -mno-fp-regs -ffixed-8 cflags-y += $(call cc-option, -fno-jump-tables) cpuflags-$(CONFIG_ALPHA_EV4) := -mcpu=ev4 -- 1.8.0 -- 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/
[PATCH 2/2] alpha: irq: remove deprecated use of IRQF_DISABLED
Interrupt handlers are always invoked with interrupts disabled, so
remove all uses of the deprecated IRQF_DISABLED flag.
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Signed-off-by: Will Deacon
---
arch/alpha/include/asm/floppy.h | 2 +-
arch/alpha/kernel/irq_alpha.c | 1 -
arch/alpha/kernel/sys_titan.c | 14 +++---
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/alpha/include/asm/floppy.h b/arch/alpha/include/asm/floppy.h
index 46cefbd..bae97eb 100644
--- a/arch/alpha/include/asm/floppy.h
+++ b/arch/alpha/include/asm/floppy.h
@@ -26,7 +26,7 @@
#define fd_disable_irq()disable_irq(FLOPPY_IRQ)
#define fd_cacheflush(addr,size) /* nothing */
#define fd_request_irq()request_irq(FLOPPY_IRQ, floppy_interrupt,\
- IRQF_DISABLED, "floppy", NULL)
+ 0, "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL)
#ifdef CONFIG_PCI
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 1216dfb..f433fc1 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -229,7 +229,6 @@ process_mcheck_info(unsigned long vector, unsigned long
la_ptr,
struct irqaction timer_irqaction = {
.handler= timer_interrupt,
- .flags = IRQF_DISABLED,
.name = "timer",
};
diff --git a/arch/alpha/kernel/sys_titan.c b/arch/alpha/kernel/sys_titan.c
index 5cf4a48..a53cf03 100644
--- a/arch/alpha/kernel/sys_titan.c
+++ b/arch/alpha/kernel/sys_titan.c
@@ -280,15 +280,15 @@ titan_late_init(void)
* all reported to the kernel as machine checks, so the handler
* is a nop so it can be called to count the individual events.
*/
- titan_request_irq(63+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(63+16, titan_intr_nop, 0,
"CChip Error", NULL);
- titan_request_irq(62+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(62+16, titan_intr_nop, 0,
"PChip 0 H_Error", NULL);
- titan_request_irq(61+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(61+16, titan_intr_nop, 0,
"PChip 1 H_Error", NULL);
- titan_request_irq(60+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(60+16, titan_intr_nop, 0,
"PChip 0 C_Error", NULL);
- titan_request_irq(59+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(59+16, titan_intr_nop, 0,
"PChip 1 C_Error", NULL);
/*
@@ -348,9 +348,9 @@ privateer_init_pci(void)
* Hook a couple of extra err interrupts that the
* common titan code won't.
*/
- titan_request_irq(53+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(53+16, titan_intr_nop, 0,
"NMI", NULL);
- titan_request_irq(50+16, titan_intr_nop, IRQF_DISABLED,
+ titan_request_irq(50+16, titan_intr_nop, 0,
"Temperature Warning", NULL);
/*
--
1.8.0
--
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/
[PATCH 1/2] alpha: irq: run all handlers with interrupts disabled
Linux has expected that interrupt handlers are executed with local
interrupts disabled for a while now, so ensure that this is the case on
Alpha even for non-device interrupts such as IPIs.
Without this patch, secondary boot results in the following backtrace:
[ cut here ]
warning: at kernel/softirq.c:139 __local_bh_enable+0xb8/0xd0()
modules linked in:
fc867c70 fc876618 fc330628 0200
fc88e1b0 fc868000
fc331594 fc8c79a0 fc85fac0 0001
fc3597e0 0008 fc31b3b4 0001
0001 fc315c4c fc8b88f8
fc856e20 fc856b00 fc0001a060c0 0007
trace:
[] __local_bh_enable+0xb8/0xd0
[] irq_enter+0x74/0xa0
[] scheduler_ipi+0x50/0x100
[] handle_ipi+0x84/0x260
[] do_entint+0x1ac/0x2e0
[] irq_exit+0x60/0xa0
[] handle_irq+0x98/0x100
[] do_entint+0x2c8/0x2e0
[] ret_from_sys_call+0x0/0x10
[] load_balance+0x3e4/0x870
[] cpu_idle+0x24/0x80
[] rcu_eqs_enter_common.isra.38+0x0/0x120
[] cpu_idle+0x40/0x80
[] rest_init+0xc0/0xe0
[] _stext+0x1c/0x20
---[ end trace 5bbac1dc3a0ec32e ]---
A similar dump occurs if you try to reboot using magic-sysrq.
Cc: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Signed-off-by: Will Deacon
---
arch/alpha/kernel/irq.c | 7 ---
arch/alpha/kernel/irq_alpha.c | 9 -
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
index 2872acc..7b2be25 100644
--- a/arch/alpha/kernel/irq.c
+++ b/arch/alpha/kernel/irq.c
@@ -117,13 +117,6 @@ handle_irq(int irq)
return;
}
- /*
-* From here we must proceed with IPL_MAX. Note that we do not
-* explicitly enable interrupts afterwards - some MILO PALcode
-* (namely LX164 one) seems to have severe problems with RTI
-* at IPL 0.
-*/
- local_irq_disable();
irq_enter();
generic_handle_irq_desc(irq, desc);
irq_exit();
diff --git a/arch/alpha/kernel/irq_alpha.c b/arch/alpha/kernel/irq_alpha.c
index 772ddfdb..1216dfb 100644
--- a/arch/alpha/kernel/irq_alpha.c
+++ b/arch/alpha/kernel/irq_alpha.c
@@ -45,6 +45,14 @@ do_entInt(unsigned long type, unsigned long vector,
unsigned long la_ptr, struct pt_regs *regs)
{
struct pt_regs *old_regs;
+
+ /*
+* Disable interrupts during IRQ handling.
+* Note that there is no matching local_irq_enable() due to
+* severe problems with RTI at IPL0 and some MILO PALcode
+* (namely LX164).
+*/
+ local_irq_disable();
switch (type) {
case 0:
#ifdef CONFIG_SMP
@@ -62,7 +70,6 @@ do_entInt(unsigned long type, unsigned long vector,
{
long cpu;
- local_irq_disable();
smp_percpu_timer_interrupt(regs);
cpu = smp_processor_id();
if (cpu != boot_cpuid) {
--
1.8.0
--
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/
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
Hi Santosh,
On Mon, Mar 18, 2013 at 06:51:30AM +, Santosh Shilimkar wrote:
> On Friday 15 March 2013 10:30 AM, Will Deacon wrote:
> > Furthermore, I was under the impression that hw_breakpoint did actually
> > work on panda, which implies that a cold boot *does* manage to reset the
> > registers (can you please confirm this by looking in your dmesg during
> > boot?). In that case, it seems as though a PM cycle is powering down a
> > bunch of debug logic that was powered up during boot, and then we trip over
> > because we can't access the register bank.
> >
> Actually it seems to be without PM. Thanks to analysis from Lokesh, the issue
> can be seen even with just suspend or cpu hotplug. So cold boot as such is
> fine.
Right, so what you're saying is that monitor-mode hardware debug only works
until the first pm/suspend/hotplug operation, then it's dead in the water?
> > The proper solution to this problem requires us to establish exactly what is
> > turning off the debug registers, and then having an OMAP PM notifier to
> > enable it again. Assuming this has always been the case, I expect hardware
> > debug across PM fails silently with older kernels.
> >
> This has been always the case it seems with CPU power cycle.
> After the CPU is power cycled, 'DBGAUTHSTATUS' reads '0xaa' rather
> than '0xaf' which means 'DBGEN = 0' and hence code fails to enable
> monitor mode. This happens on both secure and GP devices and it can not
> be patched since the secure code is ROM'ed. We didn't notice so far
> because hw_breakpoint support was not default enabled on OMAP till the
> multi-platform build.
That really sucks :( Does this affect all OMAP-based boards?
> >> I was also wondering whether we should just warn once rather
> >> than continuous warnings in the notifier. Patch is end of the
> >> email.
> >
> > Could do, but I'd like to see a fix for the real issue before we simply hide
> > the warnings :)
> >
> Agree here too. As evident above, the feature won't work on OMAP4
> devices with PM and hence some solution is needed.
>
> What you think of below ?
Comments inline...
>
> From d74b4264f6a5967b0f7ada96aad77ab0ac30dbed Mon Sep 17 00:00:00 2001
> From: Santosh Shilimkar
> Date: Mon, 18 Mar 2013 11:59:04 +0530
> Subject: [PATCH] ARM: hw_breakpoints: Check for CPU debug availability before
> enabling it
>
> CPU debug features like hardware break, watchpoints can be used only when
> the debug mode is enabled and available for non-secure mode.
>
> Hence check 'DBGAUTHSTATUS.DBGEN' before proceeding to enable the
> features.
>
> Thanks to Will for pointers and Lokesh for the analysis of the issue on
> OMAP4 where after a CPU power cycle, debug mode gets disabled.
>
> Cc: Will Deacon
>
> Tested-by: Lokesh Vutla
> Signed-off-by: Santosh Shilimkar
> ---
> arch/arm/kernel/hw_breakpoint.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
> index 96093b7..683a7cf 100644
> --- a/arch/arm/kernel/hw_breakpoint.c
> +++ b/arch/arm/kernel/hw_breakpoint.c
> @@ -930,6 +930,14 @@ static void reset_ctrl_regs(void *unused)
> int i, raw_num_brps, err = 0, cpu = smp_processor_id();
> u32 val;
>
> + /* Check if we have access to CPU debug features */
> + ARM_DBG_READ(c7, c14, 6, val);
> + if ((val & 0x1) == 0) {
> + pr_warn_once("CPU %d debug is unavailable\n", cpu);
> + cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
> + return;
> + }
There are a few of problems here:
1. That is only checking for non-secure access, which precludes
running Linux in secure mode.
2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
set for v7.1 processors.
3. DBGAUTHSTATUS doesn't exist in ARMv6.
4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
Assuming that your pr_warn_once is emitted, this implies that
DBGEN is driven high from cold boot, yet the NSE bit is low,
implying that DBGEN is also low. That's contradictory, so I have
no idea what's going on...
Apart from that, it's fine!
Will
--
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/
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Mon, Mar 18, 2013 at 03:46:28PM +, Santosh Shilimkar wrote:
> On Monday 18 March 2013 08:37 PM, Will Deacon wrote:
> > That really sucks :( Does this affect all OMAP-based boards?
> >
> All OMAP4 based boards..
Brilliant. Is there any way that the secure code can be fixed in future
products?
> >> + /* Check if we have access to CPU debug features */
> >> + ARM_DBG_READ(c7, c14, 6, val);
> >> + if ((val & 0x1) == 0) {
> >> + pr_warn_once("CPU %d debug is unavailable\n", cpu);
> >> + cpumask_or(&debug_err_mask, &debug_err_mask, cpumask_of(cpu));
> >> + return;
> >> + }
> >
> > There are a few of problems here:
> >
> > 1. That is only checking for non-secure access, which precludes
> >running Linux in secure mode.
> >
> We can check bit 4 as well to take care linux running in secure mode.
It still doesn't help unless we know whether Linux is running secure or
non-secure.
> > 2. DBGAUTHSTATUS accesses are UNPREDICTABLE when the double-lock is
> >set for v7.1 processors.
> >
> > 3. DBGAUTHSTATUS doesn't exist in ARMv6.
> >
> We cans skip the code for these versions like...
> if (!ARM_DEBUG_ARCH_V7_ECP14 == get_debug_arch())
> goto skip_dbgsts_read;
Sure, I was just pointing out that the code needs fixing for this.
> > 4. CPUs without the security extensions have DBGAUTHSTATUS.NSE == 0
> >
> Which bit is that ? I don't find this bit in Cortex-A9 docs. With all
> these checks, may be a separate function like 'is_debug_available()'
> would be better.
NSE is bit 0 (the one you're checking).
>
> > 5. Accessing DBGAUTHSTATUS requires DBGEN to be driven high.
> >Assuming that your pr_warn_once is emitted, this implies that
> >DBGEN is driven high from cold boot, yet the NSE bit is low,
> >implying that DBGEN is also low. That's contradictory, so I have
> >no idea what's going on...
> >
> Me neither. The warning is emitted at least.
Any chance you could follow up with your firmware/hardware guys about this
please? I'd really like to understand how we end up in this state in case we
can do something in the architecture to stop it from happening in future.
> > Apart from that, it's fine!
> >
> If you agree, I can update patch accordingly.
> BTW, do you have any better trick to take care of
> above scenraio ?
Well, we could just add the warn_once prints but that doesn't stop debug
from breaking after the first pm/suspend/hotplug operation.
Will
--
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/
Re: [PATCH 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
On Mon, Mar 18, 2013 at 05:03:49PM +, Stephen Boyd wrote: > On 03/17/13 07:28, Will Deacon wrote: > > On Wed, Mar 13, 2013 at 01:32:01AM +, Stephen Boyd wrote: > >> Some early versions of the Krait CPU design incorrectly indicate > >> that they only support the UDIV and SDIV instructions in Thumb > >> mode when they actually support them in ARM and Thumb mode. It > >> seems that these CPUs follow the DDI0406B ARM ARM which has two > >> possible values for the divide instructions field, instead of the > >> DDI0406C document which has three possible values. > >> > >> Work around this problem by checking the MIDR against Krait CPUs > >> with this faulty ISAR0 register and force the detection code > >> to indicate support in both modes. > >> > >> Cc: Will Deacon > >> Cc: Stepan Moskovchenko > >> Signed-off-by: Stephen Boyd > >> --- > >> arch/arm/kernel/setup.c | 8 > >> 1 file changed, 8 insertions(+) > > After all this, you might as well just pass the relevant HWCAPs for your > > krait entry in proc-v7.S rather than have an exception in the CPU-agnostic > > code. > > Ok. Care to ack the previous patch I sent then? Gah, I can't find the original one. If you resend the series with the changes I suggested in the other mail, I'll add the necessary acks there. Will -- 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/
Re: [PATCHv2 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
On Mon, Mar 18, 2013 at 06:28:57PM +, Stephen Boyd wrote: > From: Stepan Moskovchenko > > Some early versions of the Krait CPU design incorrectly indicate > that they only support the UDIV and SDIV instructions in Thumb > mode when they actually support them in ARM and Thumb mode. It > seems that these CPUs follow the DDI0406B ARM ARM which has two > possible values for the divide instructions field, instead of the > DDI0406C document which has three possible values. > > Work around this problem by checking the MIDR against Krait CPUs > with this faulty ISAR0 register and force the hwcaps to indicate > support in both modes. > > Cc: Will Deacon > Signed-off-by: Stepan Moskovchenko > [sboyd: Rewrote commit text to reflect real reasoning now that > we autodetect udiv/sdiv] > Signed-off-by: Stephen Boyd > --- > arch/arm/mm/proc-v7.S | 15 +++++++ > 1 file changed, 15 insertions(+) Acked-by: Will Deacon Will -- 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/
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Tue, Mar 19, 2013 at 06:39:38AM +, Santosh Shilimkar wrote: > On Monday 18 March 2013 10:36 PM, Will Deacon wrote: > > Any chance you could follow up with your firmware/hardware guys about this > > please? I'd really like to understand how we end up in this state in case we > > can do something in the architecture to stop it from happening in future. > > > I will check on this part and update you when I hear from them. Ok, thanks. Dietmar -- I seem to remember that you thought GDB did actually work with hardware breakpoints on Pandaboard across low-power states. Can you confirm/deny this please? > > Well, we could just add the warn_once prints but that doesn't stop debug > > from breaking after the first pm/suspend/hotplug operation. > > > Probably we should drop the $subject patch approach and use warn_once > at least for current rc. Ofcourse it doesn't help to get working > hw_breakpoint support. Patch end of the email with warn_once. Yeah, I'll merge that, but it's a real shame that this breaks hardware debug on one of the few platforms where it was reported to work. Will -- 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/
Re: [PATCH] arm: Preserve TPIDRURW on context switch
On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote:
> Am 06.02.2013 23:51, schrieb Russell King - ARM Linux:
> > On Wed, Feb 06, 2013 at 11:43:10PM +0100, André Hentschel wrote:
> >> There are more and more applications coming to WinRT, Wine could support
> >> them,
> >> but mostly they expect to have the thread environment block (TEB) in
> >> TPIDRURW.
> >> This register must be preserved per thread instead of being cleared.
> >
> > I'd prefer this was done a little more sensitively to those CPUs where
> > loads/stores are expensive, namely:
> >
> >> +
> >> + @ preserve TPIDRURW register state
> >> + get_tls2r3, r4, r5
> >> + str r3, [r1, #TI_TP2_VALUE]
> >> + ldr r3, [r2, #TI_TP2_VALUE]
> >> + set_tls2r3, r4, r5
> >
> > those two loads/stores get omitted from the thread switching if the CPU
> > doesn't support it. Do you think that's something you could do?
>
> No, i'm not sure how to improve this. How does the process can continue, can
> you or someone else fix that and add his Signed-off-by?
How about something like the (completely untested) diff below?
Andre: if this works for you, I'm happy to write a commit message etc.
Cheers,
Will
--->8
diff --git a/arch/arm/include/asm/thread_info.h
b/arch/arm/include/asm/thread_info.h
index cddda1f..d90be6d 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -58,7 +58,7 @@ struct thread_info {
struct cpu_context_save cpu_context;/* cpu context */
__u32 syscall;/* syscall number */
__u8used_cp[16];/* thread used copro */
- unsigned long tp_value;
+ unsigned long tp_value[2];/* TLS registers */
#ifdef CONFIG_CRUNCH
struct crunch_state crunchstate;
#endif
diff --git a/arch/arm/include/asm/tls.h b/arch/arm/include/asm/tls.h
index 73409e6..e1b09d32 100644
--- a/arch/arm/include/asm/tls.h
+++ b/arch/arm/include/asm/tls.h
@@ -6,9 +6,9 @@
.endm
.macro set_tls_v6k, tp, tmp1, tmp2
- mcr p15, 0, \tp, c13, c0, 3 @ set TLS register
- mov \tmp1, #0
- mcr p15, 0, \tmp1, c13, c0, 2 @ clear user r/w TLS register
+ ldrd\tmp1, \tmp2, [\tp]
+ mcr p15, 0, \tmp1, c13, c0, 3 @ set user r/o TLS register
+ mcr p15, 0, \tmp2, c13, c0, 2 @ set user r/w TLS register
.endm
.macro set_tls_v6, tp, tmp1, tmp2
@@ -16,15 +16,17 @@
ldr \tmp1, [\tmp1, #0]
mov \tmp2, #0x0fff
tst \tmp1, #HWCAP_TLS @ hardware TLS available?
- mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register
- movne \tmp1, #0
- mcrne p15, 0, \tmp1, c13, c0, 2 @ clear user r/w TLS register
- streq \tp, [\tmp2, #-15] @ set TLS value at 0x0ff0
+ ldrdne \tmp1, \tmp2, [\tp]
+ ldreq \tmp1, [\tp]
+ mcrne p15, 0, \tmp1, c13, c0, 3 @ yes, set user r/o TLS register
+ mcrne p15, 0, \tmp2, c13, c0, 2 @ set user r/w TLS register
+ streq \tmp1, [\tmp2, #-15]@ set TLS value at 0x0ff0
.endm
.macro set_tls_software, tp, tmp1, tmp2
- mov \tmp1, #0x0fff
- str \tp, [\tmp1, #-15] @ set TLS value at 0x0ff0
+ ldr \tmp1, [\tp]
+ mov \tmp2, #0x0fff
+ str \tmp1, [\tmp2, #-15]@ set TLS value at 0x0ff0
.endm
#endif
diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index 0f82098..a0a8fe3 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -728,7 +728,7 @@ ENTRY(__switch_to)
UNWIND(.fnstart )
UNWIND(.cantunwind)
add ip, r1, #TI_CPU_SAVE
- ldr r3, [r2, #TI_TP_VALUE]
+ add r3, r2, #TI_TP_VALUE
ARM( stmia ip!, {r4 - sl, fp, sp, lr} )@ Store most regs on stack
THUMB(stmia ip!, {r4 - sl, fp} )@ Store most regs on
stack
THUMB(str sp, [ip], #4 )
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index c6dec5f..ea298d2 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -400,7 +400,7 @@ copy_thread(unsigned long clone_flags, unsigned long
stack_start,
clear_ptrace_hw_breakpoint(p);
if (clone_flags & CLONE_SETTLS)
- thread->tp_value = childregs->ARM_r3;
+ thread->tp_value[0] = childregs->ARM_r3;
thread_notify(THREAD_NOTIFY_COPY, thread);
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 03deeff..2bc1514 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -849,7 +849,7 @@ long arch_ptrace(struct task_struct *child, long request,
#endif
case PTRACE_GET_THREAD_AREA:
- ret = put_user(task_thread_info(c
Re: [PATCH] arm: Preserve TPIDRURW on context switch
Hi Andre, On Tue, Feb 12, 2013 at 02:02:59PM +, André Hentschel wrote: > Am 08.02.2013 16:48, schrieb Will Deacon: > > On Wed, Feb 06, 2013 at 11:01:23PM +, André Hentschel wrote: > >> No, i'm not sure how to improve this. How does the process can continue, > >> can you or someone else fix that and add his Signed-off-by? > > > > How about something like the (completely untested) diff below? > > > > Andre: if this works for you, I'm happy to write a commit message etc. > > Thx for your effort, but it doesn't work, at least not with my 3.4.6 suse > kernel. > Be free to have another try, i'll be happy to test it. Well, cheers for testing. Can you be more specific about what goes wrong please? What do you see in TPIDRURW? Will -- 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/
Re: [PATCH v4 1/2] arm: introduce psci_smp_ops
Hi Stefano,
On Fri, Mar 29, 2013 at 04:42:49PM +, Stefano Stabellini wrote:
> Rename virt_smp_ops to psci_smp_ops and move them to
> arch/arm/kernel/psci_smp.c.
> Remove mach-virt/platsmp.c, now unused.
> Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP.
>
> Add a cpu_die smp_op based on psci_ops.cpu_off.
>
> Initialize PSCI before setting smp_ops in setup_arch.
> Use psci_smp_ops if the platform doesn't provide its own smp_ops.
>
>
> Signed-off-by: Stefano Stabellini
> CC: will.dea...@arm.com
> CC: a...@arndb.de
> CC: marc.zyng...@arm.com
> CC: li...@arm.linux.org.uk
> CC: n...@linaro.org
> ---
> arch/arm/include/asm/psci.h |9 +
> arch/arm/kernel/Makefile |5 ++-
> arch/arm/kernel/psci.c |3 +-
> arch/arm/kernel/psci_smp.c | 67
> ++
> arch/arm/kernel/setup.c |7 -
> arch/arm/mach-virt/Makefile |1 -
> arch/arm/mach-virt/platsmp.c | 58
> arch/arm/mach-virt/virt.c|3 --
> 8 files changed, 87 insertions(+), 66 deletions(-)
> create mode 100644 arch/arm/kernel/psci_smp.c
> delete mode 100644 arch/arm/mach-virt/platsmp.c
>
> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
> index ce0dbe7..4134dda 100644
> --- a/arch/arm/include/asm/psci.h
> +++ b/arch/arm/include/asm/psci.h
> @@ -32,5 +32,14 @@ struct psci_operations {
> };
>
> extern struct psci_operations psci_ops;
> +extern struct smp_operations psci_smp_ops;
>
> +#ifdef CONFIG_ARM_PSCI
> +int psci_init(void);
> +bool psci_smp_available(void);
> +#else
> +static inline int psci_init(void) { return -ENODEV; }
> +static inline bool psci_smp_available(void) { return false; }
You can probably make psci_init return void now that it's no longer an
initcall (you're not checking it's return value anyway).
> diff --git a/arch/arm/kernel/psci_smp.c b/arch/arm/kernel/psci_smp.c
> new file mode 100644
> index 000..66b0f77
> --- /dev/null
> +++ b/arch/arm/kernel/psci_smp.c
> @@ -0,0 +1,67 @@
> +/*
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Copyright (C) 2012 ARM Limited
> + *
> + * Author: Will Deacon
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +extern void secondary_startup(void);
> +
> +static int __cpuinit psci_boot_secondary(unsigned int cpu,
> + struct task_struct *idle)
> +{
> + if (psci_ops.cpu_on)
> + return psci_ops.cpu_on(cpu_logical_map(cpu),
> +__pa(secondary_startup));
> + return -ENODEV;
> +}
Since this code is now likely to be shared, it could be worth a comment
before each function to describe the expected semantics (e.g. mpidr is used
as the CPUID, additional power state information is zero).
Cheers,
Will
--
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/
Re: [PATCH v5 1/3] arm: introduce psci_smp_ops
On Tue, Apr 02, 2013 at 05:16:12PM +0100, Stefano Stabellini wrote: > Rename virt_smp_ops to psci_smp_ops and move them to > arch/arm/kernel/psci_smp.c. > Remove mach-virt/platsmp.c, now unused. > Compile psci_smp if CONFIG_ARM_PSCI and CONFIG_SMP. > > Add a cpu_die smp_op based on psci_ops.cpu_off. > > Initialize PSCI before setting smp_ops in setup_arch. > Use psci_smp_ops if the platform doesn't provide its own smp_ops. > > > Changes in v5: > - document psci_operations; > - psci_init returns NULL. > > > Signed-off-by: Stefano Stabellini > Acked-by: Nicolas Pitre > Acked-by: Rob Herring > > CC: will.dea...@arm.com > CC: a...@arndb.de > CC: marc.zyng...@arm.com > CC: li...@arm.linux.org.uk > CC: n...@linaro.org > --- > arch/arm/include/asm/psci.h | 29 ++ > arch/arm/kernel/Makefile |5 ++- > arch/arm/kernel/psci.c |7 ++-- > arch/arm/kernel/psci_smp.c | 67 > ++ > arch/arm/kernel/setup.c |7 - > arch/arm/mach-virt/Makefile |1 - > arch/arm/mach-virt/platsmp.c | 58 > arch/arm/mach-virt/virt.c|3 -- > 8 files changed, 109 insertions(+), 68 deletions(-) > create mode 100644 arch/arm/kernel/psci_smp.c > delete mode 100644 arch/arm/mach-virt/platsmp.c Reviewed-by: Will Deacon Will -- 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/
Re: [PATCH] ARM: Fix typo "CONFIG_LPAE" twice
Hi Paul,
On Fri, Mar 29, 2013 at 01:18:24PM +, Paul Bolle wrote:
> Signed-off-by: Paul Bolle
> ---
> 0) Untested.
>
> 1) This typo was first introduced in v3.4: commit
> e5ab85800820edd907d3f43f285e1232f84d5a41 ("ARM: 7382/1: mm: truncate
> memory banks to fit in 4GB space for classic MMU"). The second instance
> was added in v3.9-rc2: commit d61947a164760ac520cb416768afdf38c33d60e7
> (" ARM: 7657/1: head: fix swapper and idmap population with LPAE and
> big-endian"). So testing is really needed here.
>
> 2) If this passes (review and) testing, this probably needs to go to
> stable too.
>
> arch/arm/kernel/head.S | 2 +-
> arch/arm/kernel/setup.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
> index e0eb9a1..8bac553 100644
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -267,7 +267,7 @@ __create_page_tables:
> addne r6, r6, #1 << SECTION_SHIFT
> strne r6, [r3]
>
> -#if defined(CONFIG_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
> +#if defined(CONFIG_ARM_LPAE) && defined(CONFIG_CPU_ENDIAN_BE8)
> sub r4, r4, #4 @ Fixup page table pointer
> @ for 64-bit descriptors
> #endif
The problem with this code is that there are very few people with platforms
on which they can test it. You need an LPAE-capable CPU (Cortex-A7 or
Cortex-A15) sitting on a big-endian platform. The only platform that I have
for that is KVM, which doesn't have earlyprintk support.
Now, without the offending patch, such a configuration didn't even boot, but
I can't verify that the mapping actually works. Of course, what you have
written was the intended behaviour, so perhaps we should just go with that
for the time being.
Will
--
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/
Re: [PATCH] alpha: makefile: don't enforce small data model for kernel builds
Hi guys, On Mon, Mar 18, 2013 at 04:11:15AM +, Michael Cree wrote: > On 18/03/2013, at 10:48 AM, Will Deacon wrote: > > Due to all of the goodness being packed into today's kernels, the > > resulting image isn't as slim as it once was. > > > > In light of this, don't pass -msmall-data to the tools, which > > results in > > link failures due to impossible relocations when compiling anything > > but > > the most trivial configurations. > > I think many of us have been using -mlarge-data when compiling with > gcc-4.6 or later so maybe it is time to get the change upstream. > > The interesting thing is that the kernel still compiles fine with > gcc-4.5 and the relocation errors only appear if compiling with > gcc-4.6 or later. I had asked before on this forum what had changed > with gcc-4.6 that results in the extra usage of the small data area > but never got an answer. I am still curious to know. > > BTW, the phrase "to the tools" in the commit message makes me think > immediately of the tools directory (containing perf, etc.) which is > not what is intended. > > Matt: Are you able to collect up this and the other patches of Will > and get them sent to Linus? I noticed Matt agreed to this, but I was dropped from CC: https://lkml.org/lkml/2013/3/25/486 Any chance you could send the patches on please? Thanks, Will -- 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/
Re: [PATCH] arm64: Fix task tracing
Hi Christopher, On Wed, Apr 03, 2013 at 07:01:01PM +0100, Christopher Covington wrote: > For accurate accounting call contextidr_thread_switch before a > task is scheduled, rather than after. > > Signed-off-by: Christopher Covington > --- > arch/arm64/kernel/process.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c > index 0337cdb..c2cc249 100644 > --- a/arch/arm64/kernel/process.c > +++ b/arch/arm64/kernel/process.c > @@ -311,11 +311,11 @@ struct task_struct *__switch_to(struct task_struct > *prev, > fpsimd_thread_switch(next); > tls_thread_switch(next); > hw_breakpoint_thread_switch(next); > + contextidr_thread_switch(next); > > /* the actual thread switch */ > last = cpu_switch_to(prev, next); > > - contextidr_thread_switch(next); > return last; > } Catalin and I wondered about this and decided to go with the current approach in case a debugger, in response to the contextidr write, decided to go off and mine information about the *new* task using the sp. If we update the register before we've switched the registers, there's a sizeable window where the debugger will get confused. Do you have a real use-case that has triggered this patch? Cheers, Will -- 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/
Re: [PATCH v3 0/3] introduce static_vm for ARM-specific static mapped area
Hello, On Thu, Jan 24, 2013 at 01:28:51AM +, Joonsoo Kim wrote: > In current implementation, we used ARM-specific flag, that is, > VM_ARM_STATIC_MAPPING, for distinguishing ARM specific static mapped area. > The purpose of static mapped area is to re-use static mapped area when > entire physical address range of the ioremap request can be covered > by this area. > > This implementation causes needless overhead for some cases. > For example, assume that there is only one static mapped area and > vmlist has 300 areas. Every time we call ioremap, we check 300 areas for > deciding whether it is matched or not. Moreover, even if there is > no static mapped area and vmlist has 300 areas, every time we call > ioremap, we check 300 areas in now. > > If we construct a extra list for static mapped area, we can eliminate > above mentioned overhead. > With a extra list, if there is one static mapped area, > we just check only one area and proceed next operation quickly. > > In fact, it is not a critical problem, because ioremap is not frequently > used. But reducing overhead is better idea. > > Another reason for doing this work is for removing vm_struct list management, > entirely. For more information, look at the following link. > http://lkml.org/lkml/2012/12/6/184 First patch looks good (removing the unused vmregion stuff) but I'm not so sure about the rest of it. If you really care about ioremap performance, perhaps it would be better to have a container struct around the vm_struct for static mappings and then stick them in an augmented rbtree so you can efficiently find the mapping encompassing a particular physical address? Will -- 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/
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
On Fri, Feb 22, 2013 at 11:46:18PM +, Stephen Boyd wrote:
> On 2/22/2013 10:27 AM, Will Deacon wrote:
> > Hi guys,
> >
> > On Fri, Feb 22, 2013 at 08:08:05AM +, Stephen Boyd wrote:
> >> From: Steve Muckle
> >>
> >> The subarchitecture field in the fpsid register is 7 bits wide.
> >> The topmost bit is used to designate that the subarchitecture
> >> designer is not ARM. We use this field to determine which VFP
> >> version is supported by the CPU. Since the topmost bit is masked
> >> off we detect non-ARM subarchitectures as supporting only
> >> HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's
> >> processors.
> > I'm struggling to see why this has anything to do with the hwcaps being set
> > incorrectly. What value do you have in fpsid? As far as I can tell, the
> > subarchitecture bits 6:0 should start at 0x40 for you, right?
>
> Yes it does.
Ok, good. Could you share the different subarchitecture encodings that you
have please? (assumedly some/all of these are compatible with a variant of
VFP).
> >
> > I can see cases for changing this code, I just don't see why it would go
> > wrong in the case you're describing.
>
> VFP_arch = (vfpsid & FPSID_ARCH_MASK) >> FPSID_ARCH_BIT;
>
> causes VFP_arch to be equal to 0 because 0x40 & 0xf == 0.
>
> and then a little bit later we have
>
>if (VFP_arch >= 2) {
> elf_hwcap |= HWCAP_VFPv3;
>
>
> The branch is not taken so we never set VFPv3.
Ah, that's what I feared: the low bits are zero yet you are compatible with
VFPv3. That's fine, but the proposed fix feels like a kludge; the only reason
we'd choose on VFPv3 is because the implementor is not ARM, which may not hold
true for other vendors. I think it would be better if we translated
vendor-specific subarchitectures that are compatible with VFPvN into the
corresponding architecture number instead. This would also allow us to add
extra hwcaps for extensions other than VFP.
Cheers,
Will
--
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/
Re: [PATCH] arm: Preserve TPIDRURW on context switch
Hi Andre, On Wed, Feb 20, 2013 at 07:34:37PM +, André Hentschel wrote: > Am 12.02.2013 16:02, schrieb Matthieu CASTET: > > The tls value is never saved to : thread->tp_value[1]. > > > > Also I don't know if you can avoid the extra ldr in the software case. > > seems like Matthieu is right, any update on this? Yeah, I'll get round to this after the merge window and send a v2. I have a nice long flight to Hong Kong on the horizon, which may well drive me to writing patches :) Cheers, Will -- 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/
Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width
Hi guys, On Fri, Feb 22, 2013 at 08:08:05AM +, Stephen Boyd wrote: > From: Steve Muckle > > The subarchitecture field in the fpsid register is 7 bits wide. > The topmost bit is used to designate that the subarchitecture > designer is not ARM. We use this field to determine which VFP > version is supported by the CPU. Since the topmost bit is masked > off we detect non-ARM subarchitectures as supporting only > HWCAP_VFP and not HWCAP_VFPv3 as it should be for Qualcomm's > processors. I'm struggling to see why this has anything to do with the hwcaps being set incorrectly. What value do you have in fpsid? As far as I can tell, the subarchitecture bits 6:0 should start at 0x40 for you, right? I can see cases for changing this code, I just don't see why it would go wrong in the case you're describing. Cheers, Will -- 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/
Re: [PATCH] ARM: hw_breakpoint: Enable debug powerdown only if system supports 'has_ossr'
On Thu, Mar 14, 2013 at 01:08:00PM +0530, Santosh Shilimkar wrote:
> Will,
Hi guys,
I'm out of the office at the moment and have really terrible connectivity,
so I can't do too much until next week. However, I don't think adding the
has_ossr check is the right fix for this problem.
> On Wednesday 13 March 2013 05:59 PM, Lokesh Vutla wrote:
> > Hi Dietmar,
> > On Wednesday 13 March 2013 05:35 PM, Dietmar Eggemann wrote:
> >> On 13/03/13 06:52, Lokesh Vutla wrote:
> >>> Commit {9a6eb31 ARM: hw_breakpoint: Debug powerdown support for
> >>> self-hosted
> >>> debug} introduces debug powerdown support for self-hosted debug.
> >>> While merging the patch 'has_ossr' check was removed which
> >>> was needed for hardwares which doesn't support self-hosted debug.
> >>> Pandaboard (A9) is one such hardware and Dietmar's orginial
> >>> patch did mention this issue.
> >>> Without that check on Panda with CPUIDLE enabled, a flood of
> >>> below messages thrown.
> >>>
> >>> [ 3.597930] hw-breakpoint: CPU 0 failed to disable vector catch
> >>> [ 3.597991] hw-breakpoint: CPU 1 failed to disable vector catch
Ok, so this means that we've taken an undefined instruction exception while
trying to reset the debug registers on the PM_EXIT path. Now, the code there
deals with CPUs that don't have the save/restore registers just fine, so
that shouldn't have anything to do with this problem, particularly if the
bit that is tripping us up is related to clearing vector catch.
Furthermore, I was under the impression that hw_breakpoint did actually
work on panda, which implies that a cold boot *does* manage to reset the
registers (can you please confirm this by looking in your dmesg during
boot?). In that case, it seems as though a PM cycle is powering down a
bunch of debug logic that was powered up during boot, and then we trip over
because we can't access the register bank.
The proper solution to this problem requires us to establish exactly what is
turning off the debug registers, and then having an OMAP PM notifier to
enable it again. Assuming this has always been the case, I expect hardware
debug across PM fails silently with older kernels.
> I was also wondering whether we should just warn once rather
> than continuous warnings in the notifier. Patch is end of the
> email.
Could do, but I'd like to see a fix for the real issue before we simply hide
the warnings :)
Cheers,
Will
--
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/
Re: [PATCH 3/3] ARM: Work around faulty ISAR0 register in some Krait CPUs
On Wed, Mar 13, 2013 at 01:32:01AM +, Stephen Boyd wrote: > Some early versions of the Krait CPU design incorrectly indicate > that they only support the UDIV and SDIV instructions in Thumb > mode when they actually support them in ARM and Thumb mode. It > seems that these CPUs follow the DDI0406B ARM ARM which has two > possible values for the divide instructions field, instead of the > DDI0406C document which has three possible values. > > Work around this problem by checking the MIDR against Krait CPUs > with this faulty ISAR0 register and force the detection code > to indicate support in both modes. > > Cc: Will Deacon > Cc: Stepan Moskovchenko > Signed-off-by: Stephen Boyd > --- > arch/arm/kernel/setup.c | 8 > 1 file changed, 8 insertions(+) After all this, you might as well just pass the relevant HWCAPs for your krait entry in proc-v7.S rather than have an exception in the CPU-agnostic code. Thanks for adding the detection code though -- we can use that for A7/A15. Will -- 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/
Re: [PATCH 1/3] ARM: Clear IDIVT hwcap if CONFIG_ARM_THUMB=n
On Wed, Mar 13, 2013 at 01:31:59AM +, Stephen Boyd wrote: > Don't advertise support for the SDIV/UDIV thumb instructions if > the kernel is not compiled with support for thumb userspace. This > is in line with how we remove the THUMB hwcap in these > configurations. > > Cc: Will Deacon > Cc: Stepan Moskovchenko > Signed-off-by: Stephen Boyd Acked-by: Will Deacon Will -- 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/
Re: [PATCH 2/3] ARM: Detect support for SDIV/UDIV from ISAR0 register
On Wed, Mar 13, 2013 at 01:32:00AM +, Stephen Boyd wrote:
> The ISAR0 register indicates support for the SDIV and UDIV
> instructions in both the Thumb and ARM instruction set. Read the
> register to detect the supported instructions and update the
> elf_hwcap mask as appropriate. This is better than adding more
> and more cpuid checks in proc-v7.S for each new cpu variant that
> supports these instructions.
>
> Cc: Will Deacon
> Cc: Stepan Moskovchenko
> Signed-off-by: Stephen Boyd
> ---
> arch/arm/kernel/setup.c | 20
> arch/arm/mm/proc-v7.S | 4 ++--
> 2 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index e2c8bbf..bd27a70 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -353,6 +353,23 @@ void __init early_print(const char *str, ...)
> printk("%s", buf);
> }
>
> +static void __init idiv_setup(void)
> +{
> + unsigned int divide_instrs;
> +
> + if (cpu_architecture() < CPU_ARCH_ARMv7)
> + return;
> +
> + divide_instrs = (read_cpuid_ext(CPUID_EXT_ISAR0) & 0x0f00) >> 24;
> +
> + switch (divide_instrs) {
> + case 2:
> + elf_hwcap |= HWCAP_IDIVA;
> + case 1:
> + elf_hwcap |= HWCAP_IDIVT;
> + }
> +}
> +
> static void __init feat_v6_fixup(void)
> {
> int id = read_cpuid_id();
> @@ -483,6 +500,9 @@ static void __init setup_processor(void)
> snprintf(elf_platform, ELF_PLATFORM_SIZE, "%s%c",
>list->elf_name, ENDIANNESS);
> elf_hwcap = list->elf_hwcap;
> +
> + idiv_setup();
Perhaps give this a more generic name (cpuid_init_hwcaps) so we can add more
probing later on (we could probe swp, for example).
With that minor change:
Acked-by: Will Deacon
Will
--
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/
Re: [Suggestion] Latest randconfig build errors for CONFIG_MMU=no
On Thu, Mar 14, 2013 at 01:25:56PM +, Jonathan Austin wrote: > On 14/03/13 03:44, Chen Gang wrote: > > Hello Maintainers: > > > >when use randconfig: > > make V=1 EXTRA_CFLAGS=-W ARCH=arm randconfig > >(and "grep CONFIG_MMU .config" outputs "# CONFIG_MMU is not set") > > > >the error information: > > arch/arm/kernel/suspend.c: 在函数‘cpu_suspend’中: > > arch/arm/kernel/suspend.c:56:32: 错误：提领指向不完全类型的指针 > > arch/arm/kernel/suspend.c:70:3: 错误：隐式声明函数‘cpu_switch_mm’ > > [-Werror=implicit-function-declaration] > > arch/arm/kernel/suspend.c:71:3: 错误：隐式声明函数‘local_flush_bp_all’ > > [-Werror=implicit-function-declaration] > > arch/arm/kernel/suspend.c:72:3: 错误：隐式声明函数‘local_flush_tlb_all’ > > [-Werror=implicit-function-declaration] > > > >I want to be sure whether we can bear it ? > > > > You're right that at the moment that suspend code is broken for NOMMU. > > However, Will Deacon has a patch to fix it in his nommu branch on > kernel.org: > > https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/commit/?h=nommu > > I'll let Will comment on how/when he might look at proposing that code > to be merged. I can probably bring that up to speed with -rc2 if people are interested. The tricky part is testing -- I used a software model that had a magic control block for killing off CPUs when I wrote this originally. Will -- 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/
Re: [PATCH] ARM: MSM: Implement read_current_timer for msm timers
On Mon, Aug 27, 2012 at 10:18:39PM +0100, Stephen Boyd wrote: > Setup the same timer used as the clocksource to be used as the > read_current_timer implementation. This allows us to support a > stable udelay implementation on MSMs where it's possible for the > CPUs to scale speeds independently of one another. > > Signed-off-by: Stephen Boyd > --- > > I have some patches to send that add DT support to the MSM timer that > this conflicts with slightly. I'm not too concerned though, but we may > want to decide what tree this goes through when I send out those patches. Cheers Stephen, this looks good to me. After looking at this code some more I think I'll change the read_current_timer function pointer type to be: unsigned long (*read_current_timer)(void); since it doesn't make sense to return an error code from the platform implementation (in fact, it will cause havoc in the delay loop). I'll post a new patch -- rebasing your code should be trivial. Cheers, Will -- 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/
Re: [PATCH] ARM: ux500: Fix build error due to missing include of asm/pmu.h in cpu-db8500.c
On Mon, Sep 03, 2012 at 11:47:51AM +0100, Linus Walleij wrote: > On Sun, Sep 2, 2012 at 2:25 PM, Axel Lin wrote: > > > Include asm/pmu.h to fix below build error: > > > > CC arch/arm/mach-ux500/cpu-db8500.o > > arch/arm/mach-ux500/cpu-db8500.c:118:8: error: variable > > 'db8500_pmu_platdata' has initializer but incomplete type > > arch/arm/mach-ux500/cpu-db8500.c:119:2: error: unknown field 'handle_irq' > > specified in initializer > > arch/arm/mach-ux500/cpu-db8500.c:119:2: warning: excess elements in struct > > initializer [enabled by default] > > arch/arm/mach-ux500/cpu-db8500.c:119:2: warning: (near initialization for > > 'db8500_pmu_platdata') [enabled by default] > > make[1]: *** [arch/arm/mach-ux500/cpu-db8500.o] Error 1 > > make: *** [arch/arm/mach-ux500] Error 2 > > > > Signed-off-by: Axel Lin > > That's on linux-next not on v3.6-rcN right? > > I've applied it to my ux500 branch and will carry it unless Will Deacon > express an interest in it, PMU is his territory... I've already sent a pull for those patches, so please can you carry the fixup? u8500 is the only platform using the arm_pmu_platdata at the moment so it has to keep the include. Cheers, Will -- 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/
[PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE
From: Steve Capper Different architectures have slightly different pre-requisites for supporting Transparent Huge Pages. To simplify the layout of mm/Kconfig, a new option HAVE_ARCH_TRANSPARENT_HUGEPAGE is introduced and set in each architecture's Kconfig file (at the moment x86, with ARM being set in a future patch). Signed-off-by: Steve Capper Signed-off-by: Will Deacon --- arch/x86/Kconfig |4 mm/Kconfig |2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 8ec3a1a..7decdcf 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1297,6 +1297,10 @@ config ILLEGAL_POINTER_VALUE default 0 if X86_32 default 0xdead if X86_64 +config HAVE_ARCH_TRANSPARENT_HUGEPAGE + def_bool y + depends on MMU + source "mm/Kconfig" config HIGHPTE diff --git a/mm/Kconfig b/mm/Kconfig index d5c8019..3322342 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS config TRANSPARENT_HUGEPAGE bool "Transparent Hugepage Support" - depends on X86 && MMU + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE select COMPACTION help Transparent Hugepages allows the kernel to use huge pages and -- 1.7.4.1 -- 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/
[PATCH 2/3] mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c
From: Catalin Marinas The update_mmu_cache() takes a pointer (to pte_t by default) as the last argument but the huge_memory.c passes a pmd_t value. The patch changes the argument to the pmd_t * pointer. Signed-off-by: Catalin Marinas Signed-off-by: Steve Capper Signed-off-by: Will Deacon --- mm/huge_memory.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 57c4b93..4aa6d02 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -934,7 +934,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, entry = pmd_mkyoung(orig_pmd); entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); if (pmdp_set_access_flags(vma, haddr, pmd, entry, 1)) - update_mmu_cache(vma, address, entry); + update_mmu_cache(vma, address, pmd); ret |= VM_FAULT_WRITE; goto out_unlock; } @@ -986,7 +986,7 @@ int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma, pmdp_clear_flush_notify(vma, haddr, pmd); page_add_new_anon_rmap(new_page, vma, haddr); set_pmd_at(mm, haddr, pmd, entry); - update_mmu_cache(vma, address, entry); + update_mmu_cache(vma, address, pmd); page_remove_rmap(page); put_page(page); ret |= VM_FAULT_WRITE; @@ -1989,7 +1989,7 @@ static void collapse_huge_page(struct mm_struct *mm, BUG_ON(!pmd_none(*pmd)); page_add_new_anon_rmap(new_page, vma, address); set_pmd_at(mm, address, pmd, _pmd); - update_mmu_cache(vma, address, _pmd); + update_mmu_cache(vma, address, pmd); prepare_pmd_huge_pte(pgtable, mm); spin_unlock(&mm->page_table_lock); -- 1.7.4.1 -- 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/
[PATCH 0/3] Minor changes to common hugetlb code for ARM
Hello, A few changes are required to common hugetlb code before the ARM support can be merged. I posted the main one previously, which has been picked up by akpm: http://marc.info/?l=linux-mm&m=134573987631394&w=2 The remaining three patches (included here) are all fairly minor but do affect other architectures. All comments welcome, Will Catalin Marinas (2): mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear() mm: thp: Fix the update_mmu_cache() last argument passing in mm/huge_memory.c Steve Capper (1): mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE arch/x86/Kconfig |4 include/asm-generic/pgtable.h |2 +- mm/Kconfig|2 +- mm/huge_memory.c |6 +++--- 4 files changed, 9 insertions(+), 5 deletions(-) -- 1.7.4.1 -- 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/
[PATCH 1/3] mm: thp: Fix the pmd_clear() arguments in pmdp_get_and_clear()
From: Catalin Marinas
The CONFIG_TRANSPARENT_HUGEPAGE implementation of pmdp_get_and_clear()
calls pmd_clear() with 3 arguments instead of 1.
Cc: Arnd Bergmann
Signed-off-by: Catalin Marinas
Signed-off-by: Steve Capper
Signed-off-by: Will Deacon
---
include/asm-generic/pgtable.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index ff4947b..f7e0206 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -87,7 +87,7 @@ static inline pmd_t pmdp_get_and_clear(struct mm_struct *mm,
pmd_t *pmdp)
{
pmd_t pmd = *pmdp;
- pmd_clear(mm, address, pmdp);
+ pmd_clear(pmdp);
return pmd;
}
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
--
1.7.4.1
--
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/
Re: [PATCH 0/3] Minor changes to common hugetlb code for ARM
On Wed, Sep 12, 2012 at 04:27:59PM +0100, Michal Hocko wrote: > On Tue 11-09-12 17:47:13, Will Deacon wrote: > > A few changes are required to common hugetlb code before the ARM support > > can be merged. I posted the main one previously, which has been picked up > > by akpm: > > > > http://marc.info/?l=linux-mm&m=134573987631394&w=2 > > > > The remaining three patches (included here) are all fairly minor but do > > affect other architectures. > > I am quite confused. Why THP changes are required for hugetlb code for > ARM? Sorry, I was being too vague. We add ARM support for THP in the same patch series as hugetlb, so I was loosely referring to that lot. > Besides that I would suggest adding Andrea to the CC (added now the > whole series can be found here http://lkml.org/lkml/2012/9/11/322) list > for all THP changes. Thanks for that, I'll add Andrew to future submissions. Will -- 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/
Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE
On Wed, Sep 12, 2012 at 07:06:43PM +0100, Chris Metcalf wrote: > On 9/12/2012 11:32 AM, Michal Hocko wrote: > > Makes sense if there are going to be more archs to support THP. > > The tile architecture currently supports it in our in-house tree, > though we haven't returned it to the community yet. That's a similar situation for AArch64. We hope to post the arm patches pretty soon though, just ironing out some issues with the thp code. Unfortunately, it looks like there might be one more change to the core code as we don't have hardware page aging and need to manipulate the YOUNG bit explicitly. Will -- 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/
Re: [PATCH 3/3] mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE
Hi Andrew,
On Thu, Sep 13, 2012 at 08:05:14PM +0100, Andrew Morton wrote:
> On Tue, 11 Sep 2012 17:47:16 +0100
> Will Deacon wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index d5c8019..3322342 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -318,7 +318,7 @@ config NOMMU_INITIAL_TRIM_EXCESS
> >
> > config TRANSPARENT_HUGEPAGE
> > bool "Transparent Hugepage Support"
> > - depends on X86 && MMU
> > + depends on HAVE_ARCH_TRANSPARENT_HUGEPAGE
> > select COMPACTION
> > help
> > Transparent Hugepages allows the kernel to use huge pages and
>
> We need to talk with Gerald concerning
> http://ozlabs.org/~akpm/mmotm/broken-out/thp-x86-introduce-have_arch_transparent_hugepage.patch
>
>
> I did this. Please check.
[...]
We missed Gerald's patch for s390 and, having picked it into our tree, it
acts as a drop-in replacement for what we came up with. So I think you
can just drop our patch ("mm: Introduce HAVE_ARCH_TRANSPARENT_HUGEPAGE")
altogether.
Cheers,
Will
--
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/
Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On Tue, Oct 02, 2012 at 01:34:28AM +0100, Stephen Boyd wrote: > On 09/24/12 10:19, Will Deacon wrote: > > Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit > > 55cb726797c7). I'll post them to the list after the merge window, but please > > do take them for a spin if you get a chance. > > > > Forgot to reply here. Took them for a spin last week with that commit. > No more boot hangs but I can't say much else beyond that. When you post > to the list I'll add my tested-by. Thanks Stephen. I've also got some patches for OS save/restore of the debug registers using the various hardware locking and readout mechanisms, so that debug state can be persisted across low-power states. Do any of the Qualcomm chips (v7 as opposed to v7.1) implement the save/restore registers? Will -- 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/
[PATCH v2] mm: thp: Set the accessed flag for old pages on access fault.
On x86 memory accesses to pages without the ACCESSED flag set result in the
ACCESSED flag being set automatically. With the ARM architecture a page access
fault is raised instead (and it will continue to be raised until the ACCESSED
flag is set for the appropriate PTE/PMD).
For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively
setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will only
be called for a write fault.
This patch ensures that faults on transparent hugepages which do not result
in a CoW update the access flags for the faulting pmd.
Cc: Andrea Arcangeli
Cc: Chris Metcalf
Signed-off-by: Steve Capper
Signed-off-by: Will Deacon
---
v2: - Use pmd_trans_huge_lock to guard against splitting pmds
- Propogate dirty (write) flag to low-level pmd modifier
include/linux/huge_mm.h |2 ++
mm/huge_memory.c|8
mm/memory.c |9 -
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 4c59b11..5eb9b06 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -8,6 +8,8 @@ extern int do_huge_pmd_anonymous_page(struct mm_struct *mm,
extern int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
struct vm_area_struct *vma);
+extern void huge_pmd_set_accessed(struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmd, int dirty);
extern int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct
*vma,
unsigned long address, pmd_t *pmd,
pmd_t orig_pmd);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d684934..1de3f9b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -914,6 +914,14 @@ out_free_pages:
goto out;
}
+void huge_pmd_set_accessed(struct vm_area_struct *vma, unsigned long address,
+ pmd_t *pmd, int dirty)
+{
+ pmd_t entry = pmd_mkyoung(*pmd);
+ if (pmdp_set_access_flags(vma, address & HPAGE_PMD_MASK, pmd, entry,
dirty))
+ update_mmu_cache(vma, address, pmd);
+}
+
int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct *vma,
unsigned long address, pmd_t *pmd, pmd_t orig_pmd)
{
diff --git a/mm/memory.c b/mm/memory.c
index 5736170..f12f859 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3524,7 +3524,8 @@ retry:
barrier();
if (pmd_trans_huge(orig_pmd)) {
- if (flags & FAULT_FLAG_WRITE &&
+ int dirty = flags & FAULT_FLAG_WRITE;
+ if (dirty &&
!pmd_write(orig_pmd) &&
!pmd_trans_splitting(orig_pmd)) {
ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
@@ -3537,7 +3538,13 @@ retry:
if (unlikely(ret & VM_FAULT_OOM))
goto retry;
return ret;
+ } else if (pmd_trans_huge_lock(pmd, vma) == 1) {
+ if (likely(pmd_same(*pmd, orig_pmd)))
+ huge_pmd_set_accessed(vma, address, pmd,
+ dirty);
+ spin_unlock(&mm->page_table_lock);
}
+
return 0;
}
}
--
1.7.4.1
--
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/
Re: [PATCH v2] mm: thp: Set the accessed flag for old pages on access fault.
On Tue, Oct 02, 2012 at 11:01:04PM +0100, Andrew Morton wrote:
> On Tue, 2 Oct 2012 17:59:11 +0100
> Will Deacon wrote:
>
> > On x86 memory accesses to pages without the ACCESSED flag set result in the
> > ACCESSED flag being set automatically. With the ARM architecture a page
> > access
> > fault is raised instead (and it will continue to be raised until the
> > ACCESSED
> > flag is set for the appropriate PTE/PMD).
> >
> > For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively
> > setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will
> > only
> > be called for a write fault.
> >
> > This patch ensures that faults on transparent hugepages which do not result
> > in a CoW update the access flags for the faulting pmd.
>
> Alas, the code you're altering has changed so much in linux-next that I
> am reluctant to force this fix in there myself. Can you please
> redo/retest/resend? You can do that on 3.7-rc1 if you like, then we
> can feed this into -rc2.
No problem. I'll rebase the entire ARM series at -rc1 prior to posting
anyway, so this can be included in that lot.
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -3524,7 +3524,8 @@ retry:
> >
> > barrier();
> > if (pmd_trans_huge(orig_pmd)) {
> > - if (flags & FAULT_FLAG_WRITE &&
> > + int dirty = flags & FAULT_FLAG_WRITE;
>
> `flags' is `unsigned int', so making `dirty' match that is nicer.
I'll fold that in with the above.
Cheers,
Will
--
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/
Re: [PATCH] rbtree: include linux/compiler.h for definition of __always_inline
On Mon, Oct 22, 2012 at 10:56:21PM +0100, Michel Lespinasse wrote: > On Mon, Oct 22, 2012 at 10:01 AM, Will Deacon wrote: > > rb_erase_augmented is a static function annotated with __always_inline. > > This causes a compile failure when attempting to use the rbtree > > implementation as a library (e.g. kvm tool): > > > > rbtree_augmented.h:125:24: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or > > ‘__attribute__’ before ‘void’ > > > > This patch includes linux/compiler.h in rbtree_augmented.h so that the > > __always_inline macro is resolved correctly. > > > > Cc: Pekka Enberg > > Cc: Michel Lespinasse > > Cc: Ingo Molnar > > Signed-off-by: Will Deacon > > Just curious - what are you going to implement with augmented rbtrees > in kvm tool ? > > If the basic rbtree or the interval tree implementations are > sufficient for your usage, you should try using that (in which case > you won't need this header fix). kvm tool uses interval rbtrees for things like keeping track of virtual devices, although it looks like Ingo implemented the augment callbacks while moving to -rc1. > But either way, the header fix is correct and will be required when > someone wants to use augmented rbtrees outside of the kernel. I just > didn't think that day would come so fast :) > > Reviewed-by: Michel Lespinasse Thanks Michel! Will -- 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/
Re: [PATCH v2] mm: thp: Set the accessed flag for old pages on access fault.
On Mon, Oct 22, 2012 at 07:18:43PM +0100, Andrew Morton wrote:
> On Mon, 22 Oct 2012 11:35:03 +0100
> Will Deacon wrote:
>
> > On Fri, Oct 19, 2012 at 07:49:55PM +0100, Andrew Morton wrote:
> > > Ho hum. I'll drop
> > > mm-thp-set-the-accessed-flag-for-old-pages-on-access-fault.patch and
> > > shall assume that you'll sort things out at the appropriate time.
> >
> > Happy to sort it out once I work out what's going wrong!
>
> The patch "ARM: mm: Transparent huge page support for LPAE systems" is
> not present in linux-next, so this patch ("mm: thp: Set the accessed
> flag for old pages on access fault") will not compile?
This patch ("mm: thp: Set the accessed flag for old pages on access fault")
doesn't depend on "ARM: mm: Transparent huge page support for LPAE systems"
because currently transparent huge pages cannot be enabled for ARM in
mainline (or linux-next). update_mmu_cache_pmd is only called from
mm/huge_memory.c, which depends on CONFIG_TRANSPARENT_HUGEPAGE=y.
As for the new huge_pmd_set_accessed function... there's a similar situation
for the do_huge_pmd_wp_page function: it's called from mm/memory.c but is
only defined in mm/huge_memory.c. Looks like the compiler optimises those
calls away because pmd_trans_huge and friends constant-fold to 0.
Will
--
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/
Re: [PATCH v2 1/3] mm: highmem: export kmap_to_page for modules
On Tue, Oct 23, 2012 at 12:55:57AM +0100, Rusty Russell wrote: > Will Deacon writes: > > > Some virtio device drivers (9p) need to translate high virtual addresses > > to physical addresses, which are inserted into the virtqueue for > > processing by userspace. > > > > This patch exports the kmap_to_page symbol, so that the affected drivers > > can be compiled as modules. > > Thanks Will! > > I've applied these, and add cc:stable. I'll push them to Linus after a > little time in linux-next. Cheers Rusty. Andrew's right about this affecting highmem on x86 too (I guess that's what Sasha saw with the 9p memory issues), so stable makes sense. Will -- 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/
Re: ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined
On Tue, Oct 23, 2012 at 03:48:21PM +0100, Kukjin Kim wrote: > Hi all, > > Now, v3.7-rc2 happens following build error with s3c2410_defconfig... > > ERROR: "read_current_timer" [fs/ext4/ext4.ko] undefined! > make[2]: *** [__modpost] Error 1 > make[1]: *** [modules] Error 2 > make[1]: *** Waiting for unfinished jobs > > Any idea on this? A fix for this is queued in rmk's fixes branch. Will -- 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/
Re: [PATCH v2] mm: thp: Set the accessed flag for old pages on access fault.
On Tue, Oct 23, 2012 at 10:50:27PM +0100, Andrew Morton wrote:
> On Tue, 23 Oct 2012 11:11:25 +0100
> Will Deacon wrote:
> > This patch ("mm: thp: Set the accessed flag for old pages on access fault")
> > doesn't depend on "ARM: mm: Transparent huge page support for LPAE systems"
> > because currently transparent huge pages cannot be enabled for ARM in
> > mainline (or linux-next). update_mmu_cache_pmd is only called from
> > mm/huge_memory.c, which depends on CONFIG_TRANSPARENT_HUGEPAGE=y.
> >
> > As for the new huge_pmd_set_accessed function... there's a similar situation
> > for the do_huge_pmd_wp_page function: it's called from mm/memory.c but is
> > only defined in mm/huge_memory.c. Looks like the compiler optimises those
> > calls away because pmd_trans_huge and friends constant-fold to 0.
>
> Ah, OK.
>
> "mm: thp: Set the accessed flag for old pages on access fault" clashes
> in a non-trivial way with linux-next changes, due to the sched-numa
> changes (sigh). This is a problem for me, because I either need to
> significantly alter your patch (so it isn't applicable to mainline) or
> I need to stage your patch ahead of linux-next, then fix up linux-next
> every day after I've pulled and re-merged it.
>
> I'm unsure what your timing is. Can you carry "mm: thp: Set the
> accessed flag for old pages on access fault" until either the whole
> patchset is ready to merge or until the sched-numa situation has been
> cleared up?
I think DaveM may want this patch for sparc, so I'll keep it separate from
the ARM patches and have a go at reworking it when the sched-numa stuff has
settled down. Is that all in linux-next btw? If so, I can use that as a
starting point to dealing with the mess.
Cheers,
Will
--
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/
Re: [PATCHv3] ARM: Sort exception table at compile time
On Thu, Oct 25, 2012 at 01:44:42AM +0100, Stephen Boyd wrote: > Add the ARM machine identifier to sortextable and select the > config option so that we can sort the exception table at compile > time. sortextable relies on a section named __ex_table existing > in the vmlinux, but ARM's linker script places the exception > table in the data section. Give the exception table its own > section so that sortextable can find it. > > This allows us to skip the sorting step during boot. > > Cc: David Daney > Signed-off-by: Stephen Boyd > --- Just had a play with this for my A15 platform and it seems to work fine when targetting either ARM or Thumb-2 kernels. Tested-by: Will Deacon Cheers, Will -- 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/
[PATCH v3] mm: thp: Set the accessed flag for old pages on access fault.
On x86 memory accesses to pages without the ACCESSED flag set result in the
ACCESSED flag being set automatically. With the ARM architecture a page access
fault is raised instead (and it will continue to be raised until the ACCESSED
flag is set for the appropriate PTE/PMD).
For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively
setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will only
be called for a write fault.
This patch ensures that faults on transparent hugepages which do not result
in a CoW update the access flags for the faulting pmd.
Cc: Chris Metcalf
Cc: Kirill A. Shutemov
Cc: Andrea Arcangeli
Signed-off-by: Will Deacon
---
Ok chaps, I rebased this thing onto today's next (which basically
necessitated a rewrite) so I've reluctantly dropped my acks and kindly
ask if you could eyeball the new code, especially where the locking is
concerned. In the numa code (do_huge_pmd_prot_none), Peter checks again
that the page is not splitting, but I can't see why that is required.
Cheers,
Will
include/linux/huge_mm.h |4
mm/huge_memory.c| 22 ++
mm/memory.c |7 ++-
3 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
index 4f0f948..766fb27 100644
--- a/include/linux/huge_mm.h
+++ b/include/linux/huge_mm.h
@@ -8,6 +8,10 @@ extern int do_huge_pmd_anonymous_page(struct mm_struct *mm,
extern int copy_huge_pmd(struct mm_struct *dst_mm, struct mm_struct *src_mm,
pmd_t *dst_pmd, pmd_t *src_pmd, unsigned long addr,
struct vm_area_struct *vma);
+extern void huge_pmd_set_accessed(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long address, pmd_t *pmd,
+ pmd_t orig_pmd, int dirty);
extern int do_huge_pmd_wp_page(struct mm_struct *mm, struct vm_area_struct
*vma,
unsigned long address, pmd_t *pmd,
pmd_t orig_pmd);
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 3c14a96..f024d98 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -932,6 +932,28 @@ out:
return ret;
}
+void huge_pmd_set_accessed(struct mm_struct *mm,
+ struct vm_area_struct *vma,
+ unsigned long address,
+ pmd_t *pmd, pmd_t orig_pmd,
+ int dirty)
+{
+ pmd_t entry;
+ unsigned long haddr;
+
+ spin_lock(&mm->page_table_lock);
+ if (unlikely(!pmd_same(*pmd, orig_pmd)))
+ goto unlock;
+
+ entry = pmd_mkyoung(orig_pmd);
+ haddr = address & HPAGE_PMD_MASK;
+ if (pmdp_set_access_flags(vma, haddr, pmd, entry, dirty))
+ update_mmu_cache_pmd(vma, address, pmd);
+
+unlock:
+ spin_unlock(&mm->page_table_lock);
+}
+
static int do_huge_pmd_wp_page_fallback(struct mm_struct *mm,
struct vm_area_struct *vma,
unsigned long address,
diff --git a/mm/memory.c b/mm/memory.c
index f21ac1c..bcbc084 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3650,12 +3650,14 @@ retry:
barrier();
if (pmd_trans_huge(orig_pmd) && !pmd_trans_splitting(orig_pmd))
{
+ unsigned int dirty = flags & FAULT_FLAG_WRITE;
+
if (pmd_numa(vma, orig_pmd)) {
do_huge_pmd_numa_page(mm, vma, address, pmd,
flags, orig_pmd);
}
- if ((flags & FAULT_FLAG_WRITE) && !pmd_write(orig_pmd))
{
+ if (dirty && !pmd_write(orig_pmd)) {
ret = do_huge_pmd_wp_page(mm, vma, address, pmd,
orig_pmd);
/*
@@ -3665,6 +3667,9 @@ retry:
*/
if (unlikely(ret & VM_FAULT_OOM))
goto retry;
+ } else {
+ huge_pmd_set_accessed(mm, vma, address, pmd,
+ orig_pmd, dirty);
}
return ret;
--
1.7.4.1
--
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/
Re: [PATCH v3] mm: thp: Set the accessed flag for old pages on access fault.
On Fri, Oct 26, 2012 at 08:44:35AM +0100, Kirill A. Shutemov wrote: > On Thu, Oct 25, 2012 at 05:44:31PM +0100, Will Deacon wrote: > > On x86 memory accesses to pages without the ACCESSED flag set result in the > > ACCESSED flag being set automatically. With the ARM architecture a page > > access > > fault is raised instead (and it will continue to be raised until the > > ACCESSED > > flag is set for the appropriate PTE/PMD). > > > > For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively > > setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will > > only > > be called for a write fault. > > > > This patch ensures that faults on transparent hugepages which do not result > > in a CoW update the access flags for the faulting pmd. > > > > Cc: Chris Metcalf > > Cc: Kirill A. Shutemov > > Cc: Andrea Arcangeli > > Signed-off-by: Will Deacon > > --- > > > > Ok chaps, I rebased this thing onto today's next (which basically > > necessitated a rewrite) so I've reluctantly dropped my acks and kindly > > ask if you could eyeball the new code, especially where the locking is > > concerned. In the numa code (do_huge_pmd_prot_none), Peter checks again > > that the page is not splitting, but I can't see why that is required. > > In handle_mm_fault() we check if the pmd is under splitting without > page_table_lock. It's kind of speculative cheap check. We need to re-check > if the PMD is really not under splitting after taking page_table_lock. I appreciate the need to check whether the thing is splitting, but I thought that the pmd_same(*pmd, orig_pmd) check after taking the page_table_lock would be sufficient, because we know that the entry hasn't changed and that it wasn't splitting before we took the lock. This also mirrors the approach taken by do_huge_pmd_wp_page. Is there something I'm missing? Cheers, Will -- 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/
Re: [PATCH v3] mm: thp: Set the accessed flag for old pages on access fault.
On Fri, Oct 26, 2012 at 07:19:55AM +0100, Ni zhan Chen wrote: > On 10/26/2012 12:44 AM, Will Deacon wrote: > > On x86 memory accesses to pages without the ACCESSED flag set result in the > > ACCESSED flag being set automatically. With the ARM architecture a page > > access > > fault is raised instead (and it will continue to be raised until the > > ACCESSED > > flag is set for the appropriate PTE/PMD). > > > > For normal memory pages, handle_pte_fault will call pte_mkyoung (effectively > > setting the ACCESSED flag). For transparent huge pages, pmd_mkyoung will > > only > > be called for a write fault. > > > > This patch ensures that faults on transparent hugepages which do not result > > in a CoW update the access flags for the faulting pmd. > > Could you write changlog? >From v2? I included something below my SoB. The code should do exactly the same as before, it's just rebased onto next so that I can play nicely with Peter's patches. > > > > Cc: Chris Metcalf > > Cc: Kirill A. Shutemov > > Cc: Andrea Arcangeli > > Signed-off-by: Will Deacon > > --- > > > > Ok chaps, I rebased this thing onto today's next (which basically > > necessitated a rewrite) so I've reluctantly dropped my acks and kindly > > ask if you could eyeball the new code, especially where the locking is > > concerned. In the numa code (do_huge_pmd_prot_none), Peter checks again > > that the page is not splitting, but I can't see why that is required. > > > > Cheers, > > > > Will > > Could you explain why you not call pmd_trans_huge_lock to confirm the > pmd is splitting or stable as Andrea point out? The way handle_mm_fault is now structured after the numa changes means that we only enter the huge pmd page aging code if the entry wasn't splitting before taking the lock, so it seemed a bit gratuitous to jump through those hoops again in pmd_trans_huge_lock. Will -- 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/
Re: [RESEND PATCH 1/4] asm-generic: io: remove {read,write} string functions
On Fri, Oct 26, 2012 at 02:29:03PM +0100, Arnd Bergmann wrote:
> On Wednesday 17 October 2012, Will Deacon wrote:
> > The {read,write}s{b,w,l} functions are not defined across all
> > architectures and therefore shouldn't be used by portable drivers. We
> > should encourage driver writers to use the io{read,write}{8,16,32}_rep
> > functions instead.
> >
> > This patch removes the {read,write} string functions for the generic IO
> > header as they have no place in a new architecture port.
> >
> > Cc: Arnd Bergmann
> > Cc: Mike Frysinger
> > Cc: Ben Herrenschmidt
> > Signed-off-by: Will Deacon
>
> Acked-by: Arnd Bergmann
Cheers Arnd!
> What should we do with the series? I can take them through the asm-generic
> tree if you like, or we can let Catalin take them through the arm64 tree.
Can you take patch 2/4 via asm-generic please? I'll respin the rest of the
series and try and update some more drivers in the process so that the
removal of the generic stream functions doesn't cause breakage for drivers
that aren't arch-specific already.
Thanks,
Will
--
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/
Re: [PATCH 1/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name
On Fri, Nov 02, 2012 at 10:43:36AM +, jgq...@gmail.com wrote:
> From: Xiao Jiang
>
> Add related name for A5/A7/A15 which are consistent with the OProfile
> user ABI.
>
> Signed-off-by: Xiao Jiang
> ---
> arch/arm/oprofile/common.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> index 99c63d4b..ec10db1 100644
> --- a/arch/arm/oprofile/common.c
> +++ b/arch/arm/oprofile/common.c
> @@ -37,8 +37,11 @@ static struct op_perf_name {
> { "xscale1","arm/xscale2" },
> { "v6", "arm/armv6" },
> { "v6mpcore", "arm/mpcore"},
> + { "ARMv7 Cortex-A5","arm/armv7-ca5" },
> + { "ARMv7 Cortex-A7","arm/armv7-ca7" },
> { "ARMv7 Cortex-A8","arm/armv7" },
> { "ARMv7 Cortex-A9","arm/armv7-ca9" },
> + { "ARMv7 Cortex-A15", "arm/armv7-ca15" },
> };
>
> char *op_name_from_perf_id(void)
I'd rather not go down this route now that we have the operf tool as part of
oprofile, which can use the perf syscall directly and doesn't need this
string translation.
Will
--
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/
Re: [PATCH 1/4] arch/arm: add syscall_get_arch
On Fri, Nov 02, 2012 at 12:14:57AM +, Kees Cook wrote:
> From: Will Drewry
>
> Provide an ARM implementation of syscall_get_arch. This is a pre-requisite
> for CONFIG_HAVE_ARCH_SECCOMP_FILTER.
>
> Signed-off-by: Will Drewry
> Signed-off-by: Kees Cook
> ---
> arch/arm/include/asm/syscall.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/asm/syscall.h b/arch/arm/include/asm/syscall.h
> index 9fdded6..803f433 100644
> --- a/arch/arm/include/asm/syscall.h
> +++ b/arch/arm/include/asm/syscall.h
> @@ -7,6 +7,8 @@
> #ifndef _ASM_ARM_SYSCALL_H
> #define _ASM_ARM_SYSCALL_H
>
> +#include /* for AUDIT_ARCH_* */
> +#include /* for ELF_EM */
> #include
> #include
>
> @@ -95,4 +97,15 @@ static inline void syscall_set_arguments(struct
> task_struct *task,
> memcpy(®s->ARM_r0 + i, args, n * sizeof(args[0]));
> }
>
> +static inline int syscall_get_arch(struct task_struct *task,
> +struct pt_regs *regs)
> +{
> + /* ARM tasks don't change audit architectures on the fly. */
> +#ifdef __ARMEB__
> + return AUDIT_ARCH_ARMEB;
> +#else
> + return AUDIT_ARCH_ARM;
> +#endif
> +}
I think you can just use AUDIT_ARCH_ARM unconditionally here as the syscall
ABI is not related to the endianness of the CPU. I believe AUDIT_ARCH_ARMEB
was added accidentally because somebody incorrectly thought the -EB suffix
signified EABI.
If it wasn't in a user-header I'd be all for deleting the old definition...
Will
--
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/
[PATCH] kbuild: kvm: make export of linux/kvm_para.h unconditional
The asm-generic version of kvm_para.h is always exported, confusing the Kbuild wildcarding that tries to detect whether the source architecture is exporting the header, since asm-* matches the generic version. This patch unconditionally exports linux/kvm_para.h and fixes the few remaining architectures without asm/kvm_para.h to use the generic version. I also took the liberty of removing some dead lines from the wildcarding which was searcing for asm-$(SRCARCH) directores under $(srctree). Cc: Arnd Bergmann Cc: Avi Kivity Tested-by: Geert Uytterhoeven Signed-off-by: Will Deacon --- arch/cris/include/asm/Kbuild |2 ++ arch/m32r/include/asm/Kbuild |2 ++ include/asm-generic/Kbuild.asm | 12 +++- include/linux/Kbuild |8 +--- 4 files changed, 8 insertions(+), 16 deletions(-) diff --git a/arch/cris/include/asm/Kbuild b/arch/cris/include/asm/Kbuild index 04d02a5..2fde49c 100644 --- a/arch/cris/include/asm/Kbuild +++ b/arch/cris/include/asm/Kbuild @@ -7,3 +7,5 @@ header-y += ethernet.h header-y += etraxgpio.h header-y += rs485.h header-y += sync_serial.h + +generic-y += kvm_para.h diff --git a/arch/m32r/include/asm/Kbuild b/arch/m32r/include/asm/Kbuild index c68e168..78c505e 100644 --- a/arch/m32r/include/asm/Kbuild +++ b/arch/m32r/include/asm/Kbuild @@ -1 +1,3 @@ include include/asm-generic/Kbuild.asm + +generic-y += kvm_para.h diff --git a/include/asm-generic/Kbuild.asm b/include/asm-generic/Kbuild.asm index c5d2e5d..f180c99 100644 --- a/include/asm-generic/Kbuild.asm +++ b/include/asm-generic/Kbuild.asm @@ -1,15 +1,8 @@ -ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h \ - $(srctree)/include/asm-$(SRCARCH)/kvm.h),) +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h),) header-y += kvm.h endif -ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h \ - $(srctree)/include/asm-$(SRCARCH)/kvm_para.h),) -header-y += kvm_para.h -endif - -ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h \ - $(srctree)/include/asm-$(SRCARCH)/a.out.h),) +ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h),) header-y += a.out.h endif @@ -21,6 +14,7 @@ header-y += fcntl.h header-y += ioctl.h header-y += ioctls.h header-y += ipcbuf.h +header-y += kvm_para.h header-y += mman.h header-y += msgbuf.h header-y += param.h diff --git a/include/linux/Kbuild b/include/linux/Kbuild index 8760be3..048abc6 100644 --- a/include/linux/Kbuild +++ b/include/linux/Kbuild @@ -23,20 +23,13 @@ header-y += wimax/ objhdr-y += version.h ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/a.out.h \ - $(srctree)/include/asm-$(SRCARCH)/a.out.h \ $(INSTALL_HDR_PATH)/include/asm-*/a.out.h),) header-y += a.out.h endif ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm.h \ - $(srctree)/include/asm-$(SRCARCH)/kvm.h \ $(INSTALL_HDR_PATH)/include/asm-*/kvm.h),) header-y += kvm.h endif -ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/include/asm/kvm_para.h \ - $(srctree)/include/asm-$(SRCARCH)/kvm_para.h \ - $(INSTALL_HDR_PATH)/include/asm-*/kvm_para.h),) -header-y += kvm_para.h -endif header-y += acct.h header-y += adb.h @@ -229,6 +222,7 @@ header-y += kernel-page-flags.h header-y += kexec.h header-y += keyboard.h header-y += keyctl.h +header-y += kvm_para.h header-y += l2tp.h header-y += limits.h header-y += llc.h -- 1.7.4.1 -- 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/
Re: [PATCH 2/2] arm: pmu: add support for per-cpu PMU interrupts.
Hi Chris, On Mon, Jul 30, 2012 at 03:32:12PM +0100, Chris Smith wrote: > We have systems where the PMU interrupts are PPIs, and so per-cpu. This > patch adds support for per-cpu PMU interrupts to the perf event code. > > Note that because the dev_id passed to request_percpu_irq has to be > percpu data, we now pass cpu_hw_events as the dev_id rather than armpmu. > This only place the dev_id was used was in armpmu_platform_irq, which is > fixed up accordingly. > > Signed-off-by: Chris Smith > --- I'm actually in the process of moving request/free IRQ into an armpmu callback, so this patch would fit more neatly into that. I should have something available this week that you can take a look at. Will -- 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/
Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On Thu, Sep 20, 2012 at 06:35:56PM +0100, Will Deacon wrote:
> On Thu, Sep 20, 2012 at 05:57:40PM +0100, Stephen Boyd wrote:
> > +/* Determine if halting mode is enabled */
> > +static int halting_mode_enabled(void)
> > +{
> > + u32 dscr;
> > +
> > + ARM_DBG_READ(c1, 0, dscr);
> > +
> > + if (WARN_ONCE(dscr & ARM_DSCR_HDBGEN,
> > + "halting debug mode enabled. Unable to access hardware
> > resources.\n")) {
> > + return -EPERM;
> > + }
> > + return 0;
> > +}
>
> ...it looks like debug arch 7.1 defines this bit as UNKNOWN when the OS lock
> is clear, so we probably shouldn't be reading it at all. I'll pour myself a
> stiff drink and start reading the debug arch docs to work out what on Earth
> we should do.
>
> Stay tuned.
Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit
55cb726797c7). I'll post them to the list after the merge window, but please
do take them for a spin if you get a chance.
Will
--
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/
Re: [PATCH] ARM: hw_breakpoint: Clear breakpoints before enabling monitor mode
On Mon, Sep 24, 2012 at 07:04:56PM +0100, Stephen Boyd wrote: > On 09/24/12 10:19, Will Deacon wrote: > > Ok, I've pushed a bunch of patches to my hw-breakpoint branch (head commit > > 55cb726797c7). I'll post them to the list after the merge window, but please > > do take them for a spin if you get a chance. > > > > Sure, I'll try them later today. I would say just send them out so > people can add tested and reviewed tags. Otherwise we should all start > planning week long vacations every 7 to 8 weeks to coincide with the > merge window. I like the idea of that! However, it's more that most people are worrying about getting their trees into shape rather than reviewing new code at the moment, so I suspect that posting it now will go largely un-noticed and I don't think this is a critical fix (see below). > Also, it would be nice if we could fix this in 3.7 or even 3.6. Booting > on an MSM8660 is very fragile right now and this patch fixes it for me. Whilst I appreciate that it solves your problem, I'm *really* wary about changing this stuff without giving it a thorough airing beforehand. The debug reset path is extremely error-prone and its behaviour is tangled up with the state of various external signals into the core, meaning that different platforms with the same CPU can take different paths at runtime. I can definitely CC stable once we're happy with this, but I'd rather avoid rushing the patches in before 3.8. Cheers, Will -- 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/
Re: [PATCH] sched_clock: fix postinit no sched_clock function check
On Wed, Oct 02, 2013 at 05:55:28PM +0100, Santosh Shilimkar wrote: > The sched_clock code uses 2 levels of function pointers, sched_clock_func() > and read_sched_clock() but the no sched_clock check in postinit() just > checks read_sched_clock(). > > This leads to kernel falling back to jiffy based sched clock even in > presence of sched_clock_func() which is not desirable. > > Fix the postinit() check to avoid the issue. Probably the issue is hidden > so far on most of the arm SOCs because of already existing sched_clock > registrations apart from arch_timer sched_clock. One can reproduce the > issue by just have arch_timer as sched_clock Isn't this just an issue with the arch timer driver not calling setup_sched_clock? Instead, we munge around with sched_clock_func directly, which doesn't appear to be the way anybody else deals with this. I'm not sure of the history though, so perhaps there's a reason for this... Will -- 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/
Re: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
On Fri, Jul 19, 2013 at 12:59:44AM +0100, John Stultz wrote: > On 07/18/2013 04:21 PM, Stephen Boyd wrote: > > This patchset adds support for 64 bit counters in the generic > > sched_clock code and converts drivers over to use it. Based > > on v3.11-rc1. > > > > Changes since v3: > > * Move to use seqcount to fix issues with 64-bit cyc counters > > * Move to hrtimer to fix underflow/overflow errors in wraparound > > calculation > > * Use of 1 hour in clocks_calc_mult_shift > > * Converted over drivers in drivers/clocksource > > I've not been able to take a deep review yet, but this looks pretty much > like what we discussed last week, so I'm happy with it so far. Has this > gotten much testing (on both 32 and 64bit systems?) > > One detail: Most of this is likely to go in via tip/timers/core, but the > 5/17 "arch_timer: Move to generic sched_clock" will need some > synchronization with Catalin to make sure its ok to go in via tip. Not > sure what other arm64 changes are pending that would depend or collide > with that change. I wouldn't expect anything more than a trivial Kconfig clash with the arm64 tree, if that. Will -- 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/
Re: [PATCH v4 05/17] arch_timer: Move to generic sched_clock framework
Hi Stephen,
On Fri, Jul 19, 2013 at 12:21:18AM +0100, Stephen Boyd wrote:
> Register with the generic sched_clock framework now that it
> supports 64 bits. This fixes two problems with the current
> sched_clock support for machines using the architected timers.
> First off, we don't subtract the start value from subsequent
> sched_clock calls so we can potentially start off with
> sched_clock returning gigantic numbers. Second, there is no
> support for suspend/resume handling so problems such as discussed
> in 6a4dae5 (ARM: 7565/1: sched: stop sched_clock() during
> suspend, 2012-10-23) can happen without this patch. Finally, it
> allows us to move the sched_clock setup into drivers clocksource
> out of the arch ports.
Sorry, this one slipped through the cracks.
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> index 221f07b..1791f12 100644
> --- a/arch/arm/kernel/arch_timer.c
> +++ b/arch/arm/kernel/arch_timer.c
> @@ -11,7 +11,6 @@
> #include
> #include
> #include
> -#include
>
> #include
>
> @@ -22,13 +21,6 @@ static unsigned long arch_timer_read_counter_long(void)
> return arch_timer_read_counter();
> }
>
> -static u32 sched_clock_mult __read_mostly;
> -
> -static unsigned long long notrace arch_timer_sched_clock(void)
> -{
> - return arch_timer_read_counter() * sched_clock_mult;
> -}
> -
> static struct delay_timer arch_delay_timer;
>
> static void __init arch_timer_delay_timer_register(void)
> @@ -48,11 +40,5 @@ int __init arch_timer_arch_init(void)
>
> arch_timer_delay_timer_register();
>
> - /* Cache the sched_clock multiplier to save a divide in the hot path. */
> - sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
> - sched_clock_func = arch_timer_sched_clock;
> - pr_info("sched_clock: ARM arch timer >56 bits at %ukHz, resolution
> %uns\n",
> - arch_timer_rate / 1000, sched_clock_mult);
> -
> return 0;
> }
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9737e97..e32b471 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -14,6 +14,7 @@ config ARM64
> select GENERIC_IOMAP
> select GENERIC_IRQ_PROBE
> select GENERIC_IRQ_SHOW
> + select GENERIC_SCHED_CLOCK
> select GENERIC_SMP_IDLE_THREAD
> select GENERIC_TIME_VSYSCALL
> select HARDIRQS_SW_RESEND
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index 03dc371..29c39d5 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -61,13 +61,6 @@ unsigned long profile_pc(struct pt_regs *regs)
> EXPORT_SYMBOL(profile_pc);
> #endif
>
> -static u64 sched_clock_mult __read_mostly;
> -
> -unsigned long long notrace sched_clock(void)
> -{
> - return arch_timer_read_counter() * sched_clock_mult;
> -}
> -
> void __init time_init(void)
> {
> u32 arch_timer_rate;
> @@ -78,9 +71,6 @@ void __init time_init(void)
> if (!arch_timer_rate)
> panic("Unable to initialise architected timer.\n");
>
> - /* Cache the sched_clock multiplier to save a divide in the hot path. */
> - sched_clock_mult = NSEC_PER_SEC / arch_timer_rate;
> -
> /* Calibrate the delay loop directly */
> lpj_fine = arch_timer_rate / HZ;
> }
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 053d846..2facf14 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -281,6 +282,9 @@ static int __init arch_timer_register(void)
> timecounter_init(&timecounter, &cyclecounter,
>arch_counter_get_cntvct());
>
> + /* 56 bits minimum, so we assume worst case rollover */
> + sched_clock_register(arch_timer_read_counter, 56, arch_timer_rate);
We've got the same assumption elsewhere in the kernel (e.g. vdso) but at
some point we should probably deal with >56 bits in case somebody makes a
high-frequency timer with more significant bits.
However, I think this patch is going in the right direction:
Acked-by: Will Deacon
Will
--
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/
Re: [PATCH] sched_clock: fix postinit no sched_clock function check
On Wed, Oct 02, 2013 at 06:42:40PM +0100, Stephen Boyd wrote: > On 10/02/13 10:27, Santosh Shilimkar wrote: > > Really... I have not created patch out of fun. > > Its broken on my keystone machine at least where the sched_clock is > > falling back on jiffy based sched_clock even in presence of arch_timer > > sched_clock. > > How is that possible? sched_clock_func is only assigned by > arch/arm/kernel/arch_timer.c when the architected timer is detected and > sched_clock() in kernel/time/sched_clock.c calls that function pointer > unconditionally. The only way I see this happening is if the architected > timer rate is zero. ^^ *cough* CNTFRQ *cough* :) Will -- 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/
Re: [PATCH v4 00/17] 64-bit friendly generic sched_clock()
On Wed, Oct 02, 2013 at 07:02:58PM +0100, John Stultz wrote: > On 10/02/2013 10:47 AM, Will Deacon wrote: > > On Fri, Jul 19, 2013 at 12:59:44AM +0100, John Stultz wrote: > >> On 07/18/2013 04:21 PM, Stephen Boyd wrote: > >>> This patchset adds support for 64 bit counters in the generic > >>> sched_clock code and converts drivers over to use it. Based > >>> on v3.11-rc1. > >>> > >>> Changes since v3: > >>> * Move to use seqcount to fix issues with 64-bit cyc counters > >>> * Move to hrtimer to fix underflow/overflow errors in wraparound > >>> calculation > >>> * Use of 1 hour in clocks_calc_mult_shift > >>> * Converted over drivers in drivers/clocksource > >> I've not been able to take a deep review yet, but this looks pretty much > >> like what we discussed last week, so I'm happy with it so far. Has this > >> gotten much testing (on both 32 and 64bit systems?) > >> > >> One detail: Most of this is likely to go in via tip/timers/core, but the > >> 5/17 "arch_timer: Move to generic sched_clock" will need some > >> synchronization with Catalin to make sure its ok to go in via tip. Not > >> sure what other arm64 changes are pending that would depend or collide > >> with that change. > > I wouldn't expect anything more than a trivial Kconfig clash with the arm64 > > tree, if that. > > So I also have a branch with these changes based on a branch with only > the prereqs that are already merged, so I can provide a pull request > that can go in via the aarch64 tree and won't collide with tip. Would > that be preferrable? I think it's simpler for us if you just take the lot via your tree, unless you have any objections. Cheers, Will -- 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/
Re: [PATCH v2 3/3] asm-generic: syscall_get/set_arguments accept zero for number of arguments
[extending CC list to add the ftrace guys] On Thu, Oct 03, 2013 at 06:47:46AM +0100, AKASHI Takahiro wrote: > There is a possibility of calling syscall_get_arguments() with zero as > 'number of arguments(n)' in ftrace_syscall_enter(). > The comments in syscall_get_argumets() as well as syscall_set_arugments() > are corrected to clarify that. Probably also worth mentioning that all architectures deal with n + i == 0 (after your first two patches fixing up arm and arm64, anyway). > Signed-off-by: AKASHI Takahiro > --- > include/asm-generic/syscall.h |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/asm-generic/syscall.h b/include/asm-generic/syscall.h > index 5b09392..49b35ab 100644 > --- a/include/asm-generic/syscall.h > +++ b/include/asm-generic/syscall.h > @@ -106,7 +106,7 @@ void syscall_set_return_value(struct task_struct *task, > struct pt_regs *regs, > * @task:task of interest, must be blocked > * @regs:task_pt_regs() of @task > * @i: argument index [0,5] > - * @n: number of arguments; n+i must be [1,6]. > + * @n: number of arguments; n+i must be [0,6]. > * @args:array filled with argument values > * > * Fetches @n arguments to the system call starting with the @i'th argument > @@ -126,7 +126,7 @@ void syscall_get_arguments(struct task_struct *task, > struct pt_regs *regs, > * @task:task of interest, must be in system call entry tracing > * @regs:task_pt_regs() of @task > * @i: argument index [0,5] > - * @n: number of arguments; n+i must be [1,6]. > + * @n: number of arguments; n+i must be [0,6]. > * @args:array of argument values to store > * > * Changes @n arguments to the system call starting with the @i'th argument. Acked-by: Will Deacon Will -- 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/
Re: [RFC] ARM: lockless get_user_pages_fast()
On Thu, Oct 03, 2013 at 06:15:15PM +0100, Zi Shen Lim wrote:
> Futex uses GUP. Currently on ARM, the default __get_user_pages_fast
> being used always returns 0, leading to a forever loop in get_futex_key :(
>
> Implementing GUP solves this problem.
>
> Tested on vexpress-A15 on QEMU.
> 8<>8
>
> Implement get_user_pages_fast without locking in the fastpath on ARM.
> This work is derived from the x86 version and adapted to ARM.
This looks pretty much like an exact copy of the x86 version, which will
likely also result in another exact copy for arm64. Can none of this code be
made common? Furthermore, the fact that you've lifted the code and not
provided much of an explanation in the cover letter hints that you might not
be aware of all the subtleties involved here...
> +static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
> + int write, struct page **pages, int *nr)
> +{
> + unsigned long next;
> + pmd_t *pmdp;
> +
> + pmdp = pmd_offset(&pud, addr);
> + do {
> + pmd_t pmd = *pmdp;
> +
> + next = pmd_addr_end(addr, end);
> + /*
> + * The pmd_trans_splitting() check below explains why
> + * pmdp_splitting_flush has to flush the tlb, to stop
> + * this gup-fast code from running while we set the
> + * splitting bit in the pmd. Returning zero will take
> + * the slow path that will call wait_split_huge_page()
> + * if the pmd is still in splitting state. gup-fast
> + * can't because it has irq disabled and
> + * wait_split_huge_page() would never return as the
> + * tlb flush IPI wouldn't run.
> + */
> + if (pmd_none(pmd) || pmd_trans_splitting(pmd))
> + return 0;
> + if (unlikely(pmd_huge(pmd))) {
> + if (!gup_huge_pmd(pmd, addr, next, write, pages, nr))
> + return 0;
> + } else {
> + if (!gup_pte_range(pmd, addr, next, write, pages, nr))
> + return 0;
> + }
> + } while (pmdp++, addr = next, addr != end);
...case in point: we don't (usually) require IPIs to shoot down TLB entries
in SMP systems, so this is racy under thp splitting.
Will
--
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/
Re: [RFC] ARM: lockless get_user_pages_fast()
Hi Steve,
[adding linux-mm, since this has turned into a discussion about THP
splitting]
On Fri, Oct 04, 2013 at 11:31:42AM +0100, Steve Capper wrote:
> On Thu, Oct 03, 2013 at 11:07:44AM -0700, Zi Shen Lim wrote:
> > On Thu, Oct 3, 2013 at 10:27 AM, Will Deacon wrote:
> > > On Thu, Oct 03, 2013 at 06:15:15PM +0100, Zi Shen Lim wrote:
> > >> Futex uses GUP. Currently on ARM, the default __get_user_pages_fast
> > >> being used always returns 0, leading to a forever loop in get_futex_key
> > >> :(
> > >
> > > This looks pretty much like an exact copy of the x86 version, which will
> > > likely also result in another exact copy for arm64. Can none of this code
> > > be
> > > made common? Furthermore, the fact that you've lifted the code and not
> > > provided much of an explanation in the cover letter hints that you might
> > > not
> > > be aware of all the subtleties involved here...
[...]
> > >> +static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long
> > >> end,
> > >> + int write, struct page **pages, int *nr)
> > >> +{
> > >> + unsigned long next;
> > >> + pmd_t *pmdp;
> > >> +
> > >> + pmdp = pmd_offset(&pud, addr);
> > >> + do {
> > >> + pmd_t pmd = *pmdp;
> > >> +
> > >> + next = pmd_addr_end(addr, end);
> > >> + /*
> > >> + * The pmd_trans_splitting() check below explains why
> > >> + * pmdp_splitting_flush has to flush the tlb, to stop
> > >> + * this gup-fast code from running while we set the
> > >> + * splitting bit in the pmd. Returning zero will take
> > >> + * the slow path that will call wait_split_huge_page()
> > >> + * if the pmd is still in splitting state. gup-fast
> > >> + * can't because it has irq disabled and
> > >> + * wait_split_huge_page() would never return as the
> > >> + * tlb flush IPI wouldn't run.
> > >> + */
> > >> + if (pmd_none(pmd) || pmd_trans_splitting(pmd))
> > >> + return 0;
> > >> + if (unlikely(pmd_huge(pmd))) {
> > >> + if (!gup_huge_pmd(pmd, addr, next, write, pages,
> > >> nr))
> > >> + return 0;
> > >> + } else {
> > >> + if (!gup_pte_range(pmd, addr, next, write, pages,
> > >> nr))
> > >> + return 0;
> > >> + }
> > >> + } while (pmdp++, addr = next, addr != end);
> > >
> > > ...case in point: we don't (usually) require IPIs to shoot down TLB
> > > entries
> > > in SMP systems, so this is racy under thp splitting.
[...]
> As Will pointed out, ARM does not usually require IPIs to shoot down TLB
> entries. So the local_irq_disable will not necessarily block pagetables being
> freed when fast_gup is running.
>
> Transparent huge pages when splitting will set the pmd splitting bit then
> perform a tlb invalidate, then proceed with the split. Thus a splitting THP
> will not always be blocked by local_irq_disable on ARM. This does not only
> affect fast_gup, futexes are also affected. From my understanding of futex on
> THP tail case in kernel/futex.c, it looks like an assumption is made there
> also
> that splitting pmds can be blocked by disabling local irqs.
>
> PowerPC and SPARC, like ARM do not necessarily require IPIs for TLB shootdown
> either so they make use of tlb_remove_table (CONFIG_HAVE_RCU_TABLE_FREE). This
> identifies pages backing pagetables that have multiple users and batches them
> up, and then performs a dummy IPI before freeing them en masse. This reduces
> the performance impact from the IPIs (by doing considerably fewer of them),
> and
> guarantees that pagetables cannot be freed from under the fast_gup.
> Unfortunately this also means that the fast_gup has to be aware of ptes/pmds
> changing from under it.
[...]
> There's also the possibility of blocking without an IPI, but it's not obvious
> to me how to do that (that would probably necessitate a change to
> kernel/futex.c). I've just picked this up recently and am still trying to
> understand it fully.
The IPI solution looks like a hack to me and essentially moves the
synchronisation down into the csd_lock on the spli
Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper
On Wed, Jul 10, 2013 at 11:42:25AM +0100, Ashish Sangwan wrote:
> Any heads up on this?
>
> or could someone just advice what can we do to debug this?
>
> The ret_from_fork currently looks like following:
> /*
> * This is how we return from a fork.
> */
> ENTRY(ret_from_fork)
> bl schedule_tail
> cmp r5, #0
> movne r0, r4
> adrne lr, BSYM(1f)
> movne pc, r5
> 1: get_thread_info tsk
> b ret_slow_syscall
> ENDPROC(ret_from_fork)
>
> Is this a real issue? Because we are getting this just for static binaries.
Ok, I've finally got to the bottom of this, but I'm not sure on the best way
to fix it. The issue is that libc expects r0 to contain a function pointer
to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
this pointer is NULL, then it is ignored. We actually zero this pointer in
our ELF_PLAT_INIT macro.
At the same time, we have this strange code called next from the ARM ELF
loader:
regs->ARM_r2 = stack[2];/* r2 (envp) */ \
regs->ARM_r1 = stack[1];/* r1 (argv) */ \
regs->ARM_r0 = stack[0];/* r0 (argc) */ \
which puts argc into r0. Usually this gets overwritten by the return value
of execve (0), so everything hangs together. With kernel threads this is
different since we do the exec from call_usermodehelper on the stack and
then return to the new application via ret_from_fork, which takes the
slowpath; popping r0 from pt_regs and making argc visible to the library.
When the application exits and libc starts running its exit functions, we
jump to hyperspace.
My inclination would be to remove the stack popping above (patch below),
but it's a user-visible change and I'm not sure if something like OABI
requires it.
Will
--->8
diff --git a/arch/arm/include/asm/processor.h b/arch/arm/include/asm/processor.h
index 06e7d50..413f387 100644
--- a/arch/arm/include/asm/processor.h
+++ b/arch/arm/include/asm/processor.h
@@ -54,7 +54,6 @@ struct thread_struct {
#define start_thread(regs,pc,sp) \
({ \
- unsigned long *stack = (unsigned long *)sp; \
memset(regs->uregs, 0, sizeof(regs->uregs));\
if (current->personality & ADDR_LIMIT_32BIT)\
regs->ARM_cpsr = USR_MODE; \
@@ -65,9 +64,6 @@ struct thread_struct {
regs->ARM_cpsr |= PSR_ENDSTATE; \
regs->ARM_pc = pc & ~1; /* pc */\
regs->ARM_sp = sp; /* sp */\
- regs->ARM_r2 = stack[2];/* r2 (envp) */ \
- regs->ARM_r1 = stack[1];/* r1 (argv) */ \
- regs->ARM_r0 = stack[0];/* r0 (argc) */ \
nommu_start_thread(regs); \
})
--
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/
Re: Seg fault occurs when running statically compiled binary from kernel using call_usermodehelper
On Wed, Jul 10, 2013 at 07:52:00PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 10, 2013 at 05:34:11PM +0100, Will Deacon wrote:
> > Ok, I've finally got to the bottom of this, but I'm not sure on the best way
> > to fix it.
>
> I don't think you have! You need to look back at the older ARM kernels
> to really get to the bottom of this...
It's hard enough looking at the current kernel with the internet connection
I'm currently on! Anyway, what I meant was that I can see why the
application is falling over.
> > The issue is that libc expects r0 to contain a function pointer
> > to be invoked at exit (rtld_fini), to clean up after a dynamic linker. If
> > this pointer is NULL, then it is ignored. We actually zero this pointer in
> > our ELF_PLAT_INIT macro.
> >
> > At the same time, we have this strange code called next from the ARM ELF
> > loader:
> >
> > regs->ARM_r2 = stack[2];/* r2 (envp) */ \
> > regs->ARM_r1 = stack[1];/* r1 (argv) */ \
> > regs->ARM_r0 = stack[0];/* r0 (argc) */ \
> >
> > which puts argc into r0.
>
> You're sort of right. It dates from the days when we had a.out binaries,
> those required argc, argv and envp in r0/r1/r2 - and ARM kernels carried
> this hack in binfmt_aout.c to make it work in conjunction with the above:
>
> static int load_aout_binary(struct linux_binprm * bprm)
> {
> ...
> start_thread(regs, ex.a_entry, current->mm->start_stack);
> #ifndef __arm__
> return 0;
> #else
> return regs->ARM_r0;
> #endif
> }
>
> ELF, on the other hand, never had that hack - ELF has always been zero
> in r0, and it's always retrieved the argc/argv/envp off the stack.
Aha, I was missing the a.out part, thanks. The ELF loader does call:
ELF_PLAT_INIT(regs, reloc_func_desc);
start_thread(regs, elf_entry, bprm->p);
back-to-back, which zeroes ARM_r0 and then promptly sticks argc there
straight away. libc uses the stack for everything (ARM_r0 gets clobbered
again with the return value of execve anyway), so we just have to assume
that nobody is using argv and/or envp from r1 and r2. I think that's a
sensible assumption.
> As the above hack got dropped from the kernel (I don't think it ever made
> it into mainline), I think we should be safe getting rid of this
> initialization of regs->ARM_r0 to r2, leaving them all as zeros.
>
> We should probably also remove the selection of HAVE_AOUT from
> arch/arm/Kconfig too as this definitely won't work with any recent
> kernel (certainly not without binfmt_aout.c hacked in the above way.)
Sounds like a good idea, I'll write a patch...
Will
--
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/
Re: [PATCH v2 2/2] perf tools: Make Power7 events available for perf
On Tue, Jul 09, 2013 at 04:05:30PM +0100, Vince Weaver wrote: > On Tue, 9 Jul 2013, Peter Zijlstra wrote: > > > On Mon, Jul 08, 2013 at 10:24:34PM -0400, Vince Weaver wrote: > > > > > > So something like they have on ARM? > > > > > > vince@pandaboard:/sys/bus/event_source/devices$ ls -l > > > lrwxrwxrwx 1 root root 0 Jul 8 21:57 ARMv7 Cortex-A9 -> > > > ../../../devices/ARMv7 Cortex-A9 > > > lrwxrwxrwx 1 root root 0 Jul 8 21:57 breakpoint -> > > > ../../../devices/breakpoint > > > lrwxrwxrwx 1 root root 0 Jul 8 21:57 software -> > > > ../../../devices/software > > > lrwxrwxrwx 1 root root 0 Jul 8 21:57 tracepoint -> > > > ../../../devices/tracepoint > > > > Right so what I remember of the ARM case is that their /proc/cpuinfo isn't > > sufficient to identify their PMU. And they don't have a cpuid like > > instruction > > at all. > > libpfm4 uses the >CPU part : 0xc09 > line in /proc/cpuinfo on ARM, and that's enough for the processors PAPI > supports (Cortex A8/A9/A15 plus the 1176 on the raspberry-pi). I'm > guessing it wouldn't be enough if we wanted to support *all* ARMs with > PMUs. The CPU part you cite is actually A9-specific, so you probably want to probe each CPU specifically. Take a look at the cpuinfo parsing in OProfile (used by operf). > And speaking of ARM, I should be railing at them for breaking the ABI too, > with their (understandable yet still ABI breaking) decision to remove > BogoMIPS from /proc/cpuinfo. That change will impact PAPI as well as > various other programs I maintain that have the misfortune of parsing that > file. Really? Why are you checking for that line at all? Will -- 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/
Re: [PATCH 3/4] perf tools: Check libunwind for availability of dwarf parsing feature
Arnaldo, Ingo, On Mon, Sep 16, 2013 at 10:17:32AM +0100, Jean Pihet wrote: > The newly added dwarf unwinding feature [1] requires: > . a recent version (>= 1.1) of libunwind, > . libunwind to be configured with --enable-debug-frame. > > [1] http://www.spinics.net/lists/kernel/msg1598951.html > > Add the corresponding API test in the feature check list. > > Signed-off-by: Jean Pihet > --- > tools/perf/config/Makefile | 2 +- > tools/perf/config/feature-tests.mak | 11 ++- > 2 files changed, 11 insertions(+), 2 deletions(-) Can I have an ack for this and the following patch please? (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-September/198531.html) Then I can stick these into -next for some more exposure before I queue them for 3.13. Cheers, Will -- 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/
Re: [RFC] Kernel semantics of relaxed MMIO accessors
[expanding CC list and bumping since the merge window is now over]
On Mon, Sep 09, 2013 at 12:44:49PM +0100, Will Deacon wrote:
> Hello,
>
> During the review of a recent patch to add support for atomic MMIO
> read-modify-write sequences between drivers on ARM, it was suggested
> that this code could be made generic and used by other architectures.
>
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/194178.html
>
> However, making this generic requires the availability of relaxed MMIO
> accessors across all architectures because { readX(); modify(); writeX(); }
> is an extremely expensive sequence on ARM. This expense is due to heavyweight
> barriers inside our accessor macros to satisfy the conclusions from this
> earlier thread with respect to cacheable memory ordering (which do make sense
> from a driver writer's perspective):
>
>
> http://www.gossamer-threads.com/lists/linux/kernel/932153?do=post_view_threaded#932153
>
> The problem with relaxed accessors (which is also mentioned in the thread
> above) is that they don't seem to have well defined semantics across all
> architectures. For example, the table below illustrates a few architectures
> and their behaviour in this area (please correct any mistakes or add any
> interesting architectures):
>
>
> Ordered against: | IO (same device) | Cacheable accesses | Spin lock/unlock |
> -+--++--+
> ARM/ARM64| || |
> readX/writeX |Y | Y |Y |
> _relaxed |Y | N |Y |
> | || |
> Alpha| || |
> readX/writeX |Y | Y |Y |
> _relaxed |N*| N |Y |
> | || |
> PowerPC**| || |
> readX/writeX |Y | Y |Y |
> _relaxed |Y | Y |Y |
> | || |
> x86 | || |
> readX/writeX |Y | Y |Y |
> _relaxed***|N | N |Y |
>
> * Depends on specific machine afaict.
> ** _relaxed accessors just #defined as non-relaxed variants, so could be
> improved.
> *** Potential for re-ordering by the compiler.
>
>
> On top of that, there is the concept of relaxed transactions in PCI-X and
> PCI-E, which seem to permit re-ordering of accesses to the same address!
> I think this is also behind the reason that, whilst readX_relaxed is
> implemented on almost all architectures, writeX_relaxed is very uncommon.
>
> Documentation/memory-barriers.txt states vaguely that readX_relaxed is
> "not guaranteed to be ordered in any way" whilst
> Documentation/DocBook/deviceiobook.tmpl explicitly ties the relaxed ordering
> to IO accesses and DMA writes from a device.
>
> So this email is a bit of a cry for help. I'd like to try and define some
> common semantics for relaxed I/O accessors so that they can be implemented
> by all architectures and relied upon by driver writers, including the
> addition of relaxed writes.
>
> My basic proposal would be to copy the ARM definition of _relaxed accessors
> (i.e. only relax ordering against cacheable accesses), which is the semantic
> hinted at by Nick when this was last discussed:
>
>
> http://www.gossamer-threads.com/lists/linux/kernel/932390?do=post_view_threaded#932390
>
> This should allow for significant performance improvements in drivers which
> don't care about normal memory ordering most of the time yet do have strict
> requirements on ordering of I/O accesses (I think this is the common case).
>
> All feedback/suggestions/war stories welcome!
>
> Will
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arch" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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/
Re: Commit breaks strace: ARM: entry: allow ARM-private syscalls to be restarted
On Tue, Sep 17, 2013 at 10:57:49PM +0100, Jason Gunthorpe wrote:
> Hi Will,
Hi Jason,
> I was just testing v3.12-rc1 (on kirkwood) and noticed that strace is
> not working:
Thanks for the report!
> $ strace /bin/ls
> mmap2(0xb6f79000, 9552, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f79000
> close(3)= 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0xb6fad000
> set_tls(0xb6fad4c0, 0xb6fadb98, 0xb6fb1050, 0xb6fad4c0, 0xb6fb1050) = -1
> ENOSYS (Function not implemented)
> writev(2, [{"cannot set up thread-local stora"..., 36}, {"unknown error",
> 13}, {"\n", 1}], 3cannot set up thread-local storage: unknown error
> ) = 50
> exit_group(127) = ?
> +++ exited with 127 +++
>
> I determined that reverting your commit below makes strace work again.
> I've tested 3.10.12 and it is OK.
Hmm, so if you don't run with strace, does `/bin/ls' work as expected? From
the trace above, it seems that set_tls is failing rather than anything in
strace (unless of course, the trace is just plain wrong).
> This happens with the latest git head for strace, as well as the 4.7
> release.
>
> Hopefully you can cook up a fix :)
I'll take a look today, thanks.
Will
--
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/
Re: Commit breaks strace: ARM: entry: allow ARM-private syscalls to be restarted
On Wed, Sep 18, 2013 at 10:17:48AM +0100, Will Deacon wrote: > On Tue, Sep 17, 2013 at 10:57:49PM +0100, Jason Gunthorpe wrote: > > This happens with the latest git head for strace, as well as the 4.7 > > release. > > > > Hopefully you can cook up a fix :) > > I'll take a look today, thanks. Ok, looks like the backwards branch to the syscall dispatching logic from the trace entry is busted. Can you try the patch below please? I might also take a look at unifying the function prototypes for arm_syscall and syscall_trace_enter, since it should help us remove some of the argument shuffling in the trace path. Will --->8 diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S index 74ad15d1..bc6bd96 100644 --- a/arch/arm/kernel/entry-common.S +++ b/arch/arm/kernel/entry-common.S @@ -442,10 +442,10 @@ local_restart: ldrcc pc, [tbl, scno, lsl #2] @ call sys_* routine add r1, sp, #S_OFF - cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE) +2: cmp scno, #(__ARM_NR_BASE - __NR_SYSCALL_BASE) eor r0, scno, #__NR_SYSCALL_BASE@ put OS number back bcs arm_syscall -2: mov why, #0 @ no longer a real syscall + mov why, #0 @ no longer a real syscall b sys_ni_syscall @ not private func #if defined(CONFIG_OABI_COMPAT) || !defined(CONFIG_AEABI) -- 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/
Re: 3.12-rc1: no longer compiles for Nokia n900 (omap based)
On Thu, Sep 19, 2013 at 10:30:02AM +0100, Pavel Machek wrote: > Hi! > > I get: > > CC arch/arm/kernel/machine_kexec.o > /tmp/ccCFXeXG.s: Assembler messages: > /tmp/ccCFXeXG.s:217: Error: garbage following instruction -- `dsb > nshst' > /tmp/ccCFXeXG.s:225: Error: garbage following instruction -- `dsb nsh' > make[1]: *** [arch/arm/kernel/suspend.o] Error 1 > make[1]: *** Waiting for unfinished jobs > > pavel@amd:/data/l/linux-n900$ arm-linux-gnueabi-gcc --version > arm-linux-gnueabi-gcc (Debian 4.3.5-4) 4.3.5 > > Minimum required gcc is 3.2, so I'm safe. Please check your binutils. >= 2.22 has been reported to work. Will1 -- 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/
[PATCH] lockref: use cmpxchg64 explicitly for lockless updates
The cmpxchg() function tends not to support 64-bit arguments on 32-bit
architectures. This could be either due to use of unsigned long arguments
(like on ARM) or lack of instruction support (cmpxchgq on x86). However,
these architectures may implement a specific cmpxchg64() function to
provide 64-bit cmpxchg support instead.
Since the lockref code requires a 64-bit cmpxchg and relies on the
architecture selecting ARCH_USE_CMPXCHG_LOCKREF, move to using cmpxchg64
instead of cmpxchg and allow 32-bit architectures to make use of the
lockless lockref implementation.
Cc: Waiman Long
Signed-off-by: Will Deacon
---
An alternative to this patch is to go through the 32-bit architectures
that implement cmpxchg64, reworking their cmpxchg definitions to switch
to the 64-bit version based on the sizeof the argument.
lib/lockref.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lockref.c b/lib/lockref.c
index e2cd2c0..677d036 100644
--- a/lib/lockref.c
+++ b/lib/lockref.c
@@ -14,8 +14,8 @@
while (likely(arch_spin_value_unlocked(old.lock.rlock.raw_lock))) {
\
struct lockref new = old, prev = old;
\
CODE
\
- old.lock_count = cmpxchg(&lockref->lock_count,
\
-old.lock_count, new.lock_count);
\
+ old.lock_count = cmpxchg64(&lockref->lock_count,
\
+ old.lock_count, new.lock_count);
\
if (likely(old.lock_count == prev.lock_count)) {
\
SUCCESS;
\
}
\
--
1.8.2.2
--
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/
Re: [PATCH] lockref: use cmpxchg64 explicitly for lockless updates
On Thu, Sep 19, 2013 at 07:11:32PM +0100, Linus Torvalds wrote: > On Thu, Sep 19, 2013 at 1:06 PM, Will Deacon wrote: > > The cmpxchg() function tends not to support 64-bit arguments on 32-bit > > architectures. This could be either due to use of unsigned long arguments > > (like on ARM) or lack of instruction support (cmpxchgq on x86). However, > > these architectures may implement a specific cmpxchg64() function to > > provide 64-bit cmpxchg support instead > > I'm certainly ok with this, but I wonder how much point there is to > use the cmpxchg alternatives for 32-bit architectures at all... > > From a performance standpoint, lockref really is expected to mainly > help with big machines. Only insane people would do big machines with > 32-bit kernels these days. Our definitions of "big" machines probably differ significantly, but it would be interesting to see if this *does* make a difference on some of the multi-cluster ARMv7 hardware. Unfortunately, my development boards are all I/O bound, so I'll need to leave a strategically placed crate of non-poisoned beer next to the server guys' office... > Of course, it may be that cmpxchg is actually faster on some > architectures, but at least on x86-32, cmpxchg8b is traditionally > quite slow. On ARMv7, our double-word exclusives shouldn't be slower than the word exclusives (hell, everything apart from the machine registers will be >= 64-bit). > In other words, I'd actually like to see some numbers if there are > loads where this actually helps and matters... That's fair enough; I just saw the new lockref stuff, thought "that's a cool hack" then looked at playing with it on ARM. I'll go see what this AIM7 thing is all about... Cheers, Will -- 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/
Re: [PATCH] lockref: use cmpxchg64 explicitly for lockless updates
On Fri, Sep 20, 2013 at 11:08:06AM +0100, Will Deacon wrote: > On Thu, Sep 19, 2013 at 07:11:32PM +0100, Linus Torvalds wrote: > > From a performance standpoint, lockref really is expected to mainly > > help with big machines. Only insane people would do big machines with > > 32-bit kernels these days. > > Our definitions of "big" machines probably differ significantly, but it > would be interesting to see if this *does* make a difference on some of the > multi-cluster ARMv7 hardware. [...] > > In other words, I'd actually like to see some numbers if there are > > loads where this actually helps and matters... > > That's fair enough; I just saw the new lockref stuff, thought "that's a cool > hack" then looked at playing with it on ARM. I'll go see what this AIM7 > thing is all about... Right, turns out I can get some interesting numbers from your simple t.c program on my dual-cluster, 5 CPU ARMv7 machine. The new cmpxchg-based lockref code gives ~50% improvement, but the fun part is that implementing cmpxchg64 without memory barriers doubles this win to ~100% over current mainline. If we can guarantee that the CODE just messes around with the lockref, those barriers probably aren't needed... As for AIM7/re-aim, I'm having a hard time getting repeatable numbers out of it to establish a baseline, so it's not proving to be especially helpful. Will -- 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/
Re: [PATCH] lockref: use cmpxchg64 explicitly for lockless updates
On Fri, Sep 20, 2013 at 05:00:19PM +0100, Linus Torvalds wrote: > On Fri, Sep 20, 2013 at 10:45 AM, Will Deacon wrote: > > If we can guarantee that the CODE just messes around with the lockref, those > > barriers probably aren't needed... > > Yes. I've been thyinking about the barrier issue, and as far as I can > see, as long as the lockref code only ever messes with the reference > count, a totally unordered cmpxchg is fine. The only problem then is the use of cmpxchg64 by the sched_clock code. Whilst most sched_clock() implementations probably have barrier semantics due to I/O access, that's certainly not true everywhere so I don't think the cmpxchg64 there can be relaxed safely. We could add cmpxchg64_relaxed (at the risk of confusing it with the relaxed I/O accessors, which aren't well defined)? That might help Tony with ia64 too. > And at least right now we indeed only ever mess with the reference count. > > I have been idly toying with the concept of using the cmpxchg also for > possibly taking the lock (for the "xyz_or_lock" versions), but every > time I look at it it seems unlikely to help, and it would require > memory ordering and various architecture-dependent issues, so I > suspect it's never going to make much sense. So yes, an unordered > cmpxchg64 should be perfectly fine. Yikes, using cmpxchg for the locking sounds scary. For the contended case, I think spinlocks would be better since they might have back-off and/or fairness logic which we'd lose if we somehow moved exclusively to cmpxchg. > > As for AIM7/re-aim, I'm having a hard time getting repeatable numbers out of > > it to establish a baseline, so it's not proving to be especially helpful. > > That's fine, and yeah, I doubt the t.c improvement really shows > anywhere else (it's kind of extreme), but your numbers are certainly > already sufficient to say "ok, it makes sense even on 32-bit > machines". Great, thanks. Will -- 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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
Hi Christoph, On Tue, Sep 03, 2013 at 03:39:57PM +0100, Christoph Lameter wrote: > On Fri, 30 Aug 2013, Will Deacon wrote: > > ...so I don't think this is quite right, and indeed, we get a bunch of > > errors > > from GCC: > > > > arch/arm/kernel/hw_breakpoint.c: In function ‘arch_install_hw_breakpoint’: > > arch/arm/kernel/hw_breakpoint.c:347:33: error: incompatible types when > > assigning to type ‘struct perf_event *[16]’ from type ‘struct perf_event **’ > > arch/arm/kernel/hw_breakpoint.c:347:1: error: incompatible types when > > assigning to type ‘struct perf_event *[16]’ from type ‘struct perf_event **’ > > arch/arm/kernel/hw_breakpoint.c:347:1: error: incompatible types when > > assigning to type ‘struct perf_event *[16]’ from type ‘struct perf_event **’ > > arch/arm/kernel/hw_breakpoint.c:347:1: error: incompatible types when > > assigning to type ‘struct perf_event *[16]’ from type ‘struct perf_event **’ > > Did you apply the first patch of this series which is a bug fix? No, sorry, I didn't see that. Do you have a branch anywhere that I can play with? > > changing to match your recipe still doesn't work, however: > > > > arch/arm/kernel/hw_breakpoint.c: In function ‘arch_install_hw_breakpoint’: > > arch/arm/kernel/hw_breakpoint.c:347:33: error: cast specifies array type > > Yep that is the macro bug that was fixed in the first patch. Ok. Sorry for the noise. > > > > > > WARN_ON(preemptible()); > > > > > > - if (local_inc_return(&__get_cpu_var(mde_ref_count)) == 1) > > > + if (this_cpu_inc_return(mde_ref_count) == 1) > > > enable = DBG_MDSCR_MDE; > > > > I'm not sure that this is safe. We rely on local_inc_return to be atomic > > with respect to the current CPU, which will end up being a wrapper around > > atomic64_inc_return. However, this_cpu_inc_return simply uses a lock, so > > other people accessing the count in a different manner (local_dec_and_test > > below) may break local atomicity unless we start disabling interrupts or > > something horrible like that. > > I do not see any special code for ARM for this_cpu_inc_return. The > fallback solution in the core code is to disable interrupts for the > inc_return and arch/arm/include/asm/percpu.h includes > asm-generic/percpu.h. > > Where did you see it using a lock? God knows! You're completely right, and we simply disable interrupts which I somehow misread as taking a lock. However, is it guaranteed that mixing an atomic64_* access with a this_cpu_inc_return will retain atomicity between the two? E.g. if you get interrupted during an atomic64_xchg operation, the interrupt handler issues this_cpu_inc_return, then on return to the xchg operation it must reissue any reads that had been executed prior to the interrupt. This should work on ARM/ARM64 (returning from the interrupt will clear the exclusive monitor) but I don't know about other architectures. Will -- 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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
On Wed, Sep 04, 2013 at 03:17:09PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
> > God knows! You're completely right, and we simply disable interrupts which I
> > somehow misread as taking a lock. However, is it guaranteed that mixing
> > an atomic64_* access with a this_cpu_inc_return will retain atomicity
> > between the two? E.g. if you get interrupted during an atomic64_xchg
> > operation, the interrupt handler issues this_cpu_inc_return, then on return
> > to the xchg operation it must reissue any reads that had been executed
> > prior to the interrupt. This should work on ARM/ARM64 (returning from the
> > interrupt will clear the exclusive monitor) but I don't know about other
> > architectures.
>
> You cannot get interrupted during an atomic64_xchg operation. atomic and
> this_cpu operations are stricly serialzed since both should be behaving
> like single instructions. __this_cpu ops relax that requirement in case
> the arch code incurs significant overhead to make that happen. In cases
> where we know that preemption/interrupt disable etc takes care of things
> __this_cpu ops come into play.
Hmm, why can't you get interrupted during atomic64_xchg? On ARM, we have the
following sequence:
static inline u64 atomic64_xchg(atomic64_t *ptr, u64 new)
{
u64 result;
unsigned long tmp;
smp_mb();
__asm__ __volatile__("@ atomic64_xchg\n"
"1: ldrexd %0, %H0, [%3]\n"
" strexd %1, %4, %H4, [%3]\n"
" teq %1, #0\n"
" bne 1b"
: "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
: "r" (&ptr->counter), "r" (new)
: "cc");
smp_mb();
return result;
}
which relies on interrupts clearing the exclusive monitor to force us back
around the loop in the inline asm. I could imagine other architectures doing
similar, but only detecting the other writer if it used the same
instructions.
Will
--
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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
On Wed, Sep 04, 2013 at 03:54:04PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
>
> > Hmm, why can't you get interrupted during atomic64_xchg? On ARM, we have the
> > following sequence:
>
> AFAICT atomic means one uninterruptible action.
I think it's more subtle than that, but this is all moot for ARM.
> > static inline u64 atomic64_xchg(atomic64_t *ptr, u64 new)
> > {
> > u64 result;
> > unsigned long tmp;
> >
> > smp_mb();
> >
> > __asm__ __volatile__("@ atomic64_xchg\n"
> > "1: ldrexd %0, %H0, [%3]\n"
> > " strexd %1, %4, %H4, [%3]\n"
> > " teq %1, #0\n"
> > " bne 1b"
> > : "=&r" (result), "=&r" (tmp), "+Qo" (ptr->counter)
> > : "r" (&ptr->counter), "r" (new)
> > : "cc");
> >
> > smp_mb();
> >
> > return result;
> > }
> >
> > which relies on interrupts clearing the exclusive monitor to force us back
> > around the loop in the inline asm. I could imagine other architectures doing
> > similar, but only detecting the other writer if it used the same
> > instructions.
>
> Well I have never done ARM asm but this looks vaguely like a cmpxchg loop?
> That would either perform an atomic change or fail and retry?
Correct! The strexd instruction can fail if another access clears the
exclusive monitor.
> If so it still fits the definition of atomic. The change or fail operation
> is atomic.
On ARM, yes. I'm worried that there may be an architecture where the change-
or-fail operation would only fail if the access from the interrupt handler
*also* used that change-or-fail instruction, which isn't the case with
this_cpu_inc.
I have no idea if such an architecture exists :)
Will
--
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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
On Wed, Sep 04, 2013 at 07:09:04PM +0100, Christoph Lameter wrote:
> On Wed, 4 Sep 2013, Will Deacon wrote:
>
> > On ARM, yes. I'm worried that there may be an architecture where the change-
> > or-fail operation would only fail if the access from the interrupt handler
> > *also* used that change-or-fail instruction, which isn't the case with
> > this_cpu_inc.
> >
> > I have no idea if such an architecture exists :)
>
> Atomic operations use atomic_t. this_cpu operations can only use regular
> scalars. So the set of variables that are updated by each should be
> distinct.
Right, except that your patch contained the following hunk:
Index: linux/arch/arm64/kernel/debug-monitors.c
===
--- linux.orig/arch/arm64/kernel/debug-monitors.c 2013-08-26
13:48:40.956794980 -0500
+++ linux/arch/arm64/kernel/debug-monitors.c2013-08-26 13:48:40.952795024
-0500
@@ -98,11 +98,11 @@ void enable_debug_monitors(enum debug_el
WARN_ON(preemptible());
- if (local_inc_return(&__get_cpu_var(mde_ref_count)) == 1)
+ if (this_cpu_inc_return(mde_ref_count) == 1)
enable = DBG_MDSCR_MDE;
if (el == DBG_ACTIVE_EL1 &&
- local_inc_return(&__get_cpu_var(kde_ref_count)) == 1)
+ this_cpu_inc_return(kde_ref_count) == 1)
enable |= DBG_MDSCR_KDE;
if (enable && debug_enabled) {
Then we have:
#define local_inc_return(l) atomic_long_inc_return(&(l)->a)
static inline long atomic_long_inc_return(atomic_long_t *l)
{
atomic_t *v = (atomic_t *)l;
return (long)atomic_inc_return(v);
}
So that casting lets the two interfaces overlap (and indeed they do after
your patch, since local_dec_and_test is still used to the same variable).
Will
--
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/
Re: [PATCH 3/3] perf: parse the .debug_frame section in case .eh_frame is not present
Hi Jean,
[adding Michael, since I know he was interested in this]
On Wed, Sep 04, 2013 at 07:04:14PM +0100, Jean Pihet wrote:
> On ARM the debug info is not present in the .eh_frame sections but
> instead in .debug_frame.
> Use libunwind to load and parse the debug info.
How have you tested this? Regardless of whether or not I apply this patch, I
get the same (broken/truncated) callchains for userspace in perf report.
E.g. the following stupid program (built with -O0 -g):
--->8
void bar(void)
{
int i;
for (i = 0; i < 100; ++i)
asm volatile("nop" ::: "memory");
}
void foo(void)
{
bar();
}
int main(void)
{
foo();
return 0;
}
8<---
Gives me an incomplete callchain:
# Overhead Command Shared Object Symbol
# . ...
#
0.00% unwindme unwindme [.] bar
|
--- bar
This is the same with or without your patch.
Will
--
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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
Hi again Christoph, On Wed, Sep 04, 2013 at 09:58:31PM +0100, Christoph Lameter wrote: > Here is a patch to be applied after the earlier one to convert the local_t > use to this_cpu. Not sure if I got the local_dec_and_test conversion > right. [...] > @@ -118,11 +117,11 @@ void disable_debug_monitors(enum debug_e > > WARN_ON(preemptible()); > > - if (local_dec_and_test(this_cpu_ptr(&mde_ref_count))) > + if (this_cpu_dec_return(mde_ref_count)) > disable = ~DBG_MDSCR_MDE; > > if (el == DBG_ACTIVE_EL1 && > - local_dec_and_test(this_cpu_ptr(&kde_ref_count))) > + this_cpu_dec_return(kde_ref_count)) > disable &= ~DBG_MDSCR_KDE; Almost! I think we just need an '== 0' check on the result from the decrement, since local_dec_and_test is simply a way to check that we've decremented to zero, so this patch would otherwise invert the meaning. Will -- 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/
Re: [PATCH 3/3] perf: parse the .debug_frame section in case .eh_frame is not present
On Thu, Sep 05, 2013 at 02:17:30PM +0100, Ard Biesheuvel wrote: > On 5 September 2013 15:05, Jean Pihet wrote: > [..] > > Here are the commands I have been using: > > perf record -g dwarf -- > > perf report --sort symbol --call-graph --stdio > > > > Ah, I failed to add the 'dwarf' after -g, however, in that case, my > perf report segfaults: Same SEGV here. Will -- 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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
On Thu, Sep 05, 2013 at 03:24:25PM +0100, Christoph Lameter wrote: > On Thu, 5 Sep 2013, Will Deacon wrote: > > > > > > > if (el == DBG_ACTIVE_EL1 && > > > - local_dec_and_test(this_cpu_ptr(&kde_ref_count))) > > > + this_cpu_dec_return(kde_ref_count)) > > > disable &= ~DBG_MDSCR_KDE; > > > > Almost! I think we just need an '== 0' check on the result from the > > decrement, since local_dec_and_test is simply a way to check that we've > > decremented to zero, so this patch would otherwise invert the meaning. > > Ok can you take it from here and modify it? I have no build and test > environment set up for ARM. Sure. Does that include the original arm/arm64 patches from your v3 series as well as these two fixups? Will -- 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/
Re: [gcv v3 27/35] arm: Replace __get_cpu_var uses
On Thu, Sep 05, 2013 at 06:52:19PM +0100, Christoph Lameter wrote:
> On Thu, 5 Sep 2013, Will Deacon wrote:
>
> > > Ok can you take it from here and modify it? I have no build and test
> > > environment set up for ARM.
> >
> > Sure. Does that include the original arm/arm64 patches from your v3 series
> > as well as these two fixups?
>
> I think so. Take whatever you can and I will make another pass after the
> merge and pick up anything that was missed.
Ok, I had a crack at putting something together on top of HEAD, but I still
see some errors due to pcpu array types (even with your patch in mainline).
I think some of your conversions to __this_cpu_read should use this_cpu_ptr
instead, but could you have a quick look at my fixup below please?
Will
--->8
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index e7e6eca..3d44660 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -344,13 +344,13 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
/* Breakpoint */
ctrl_base = ARM_BASE_BCR;
val_base = ARM_BASE_BVR;
- slots = (struct perf_event **)__this_cpu_read(bp_on_reg);
+ slots = this_cpu_ptr(bp_on_reg);
max_slots = core_num_brps;
} else {
/* Watchpoint */
ctrl_base = ARM_BASE_WCR;
val_base = ARM_BASE_WVR;
- slots = (struct perf_event **)__this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
max_slots = core_num_wrps;
}
@@ -396,12 +396,12 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE) {
/* Breakpoint */
base = ARM_BASE_BCR;
- slots = (struct perf_event **)__this_cpu_read(bp_on_reg);
+ slots = this_cpu_ptr(bp_on_reg);
max_slots = core_num_brps;
} else {
/* Watchpoint */
base = ARM_BASE_WCR;
- slots = (struct perf_event **)__this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
max_slots = core_num_wrps;
}
@@ -697,7 +697,7 @@ static void watchpoint_handler(unsigned long addr, unsigned
int fsr,
struct arch_hw_breakpoint *info;
struct arch_hw_breakpoint_ctrl ctrl;
- slots = (struct perf_event **)__this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
for (i = 0; i < core_num_wrps; ++i) {
rcu_read_lock();
@@ -768,7 +768,7 @@ static void watchpoint_single_step_handler(unsigned long pc)
struct perf_event *wp, **slots;
struct arch_hw_breakpoint *info;
- slots = (struct perf_event **)__this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
for (i = 0; i < core_num_wrps; ++i) {
rcu_read_lock();
@@ -802,7 +802,7 @@ static void breakpoint_handler(unsigned long unknown,
struct pt_regs *regs)
struct arch_hw_breakpoint *info;
struct arch_hw_breakpoint_ctrl ctrl;
- slots = (struct perf_event **)__this_cpu_read(bp_on_reg);
+ slots = this_cpu_ptr(bp_on_reg);
/* The exception entry code places the amended lr in the PC. */
addr = regs->ARM_pc;
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index 53dc018..ff516f6 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -184,14 +184,14 @@ int arch_install_hw_breakpoint(struct perf_event *bp)
/* Breakpoint */
ctrl_reg = AARCH64_DBG_REG_BCR;
val_reg = AARCH64_DBG_REG_BVR;
- slots = __this_cpu_read(bp_on_reg);
+ slots = this_cpu_ptr(bp_on_reg);
max_slots = core_num_brps;
reg_enable = !debug_info->bps_disabled;
} else {
/* Watchpoint */
ctrl_reg = AARCH64_DBG_REG_WCR;
val_reg = AARCH64_DBG_REG_WVR;
- slots = __this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
max_slots = core_num_wrps;
reg_enable = !debug_info->wps_disabled;
}
@@ -230,12 +230,12 @@ void arch_uninstall_hw_breakpoint(struct perf_event *bp)
if (info->ctrl.type == ARM_BREAKPOINT_EXECUTE) {
/* Breakpoint */
base = AARCH64_DBG_REG_BCR;
- slots = __this_cpu_read(bp_on_reg);
+ slots = this_cpu_ptr(bp_on_reg);
max_slots = core_num_brps;
} else {
/* Watchpoint */
base = AARCH64_DBG_REG_WCR;
- slots = __this_cpu_read(wp_on_reg);
+ slots = this_cpu_ptr(wp_on_reg);
max_slots = core_num_wrps
Re: [PATCH 2/5] arm: LLVMLinux: use current_stack_pointer for percpu
Hi guys,
On Sat, Sep 07, 2013 at 06:12:03AM +0100, Nicolas Pitre wrote:
> On Fri, 6 Sep 2013, beh...@converseincode.com wrote:
> > From: Behan Webster
> >
> > The existing code uses named registers to get the value of the stack
> > pointer.
> > The new current_stack_pointer macro is more readable and allows for a
> > central
> > portable implementation of how to get the stack pointer with ASM. This
> > change
> > supports being able to compile the kernel with both gcc and Clang.
> >
> > Signed-off-by: Mark Charlebois
> > Signed-off-by: Behan Webster
> > Reviewed-by: Jan-Simon Möller
> > ---
> > arch/arm/include/asm/percpu.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
> > index 209e650..629a975 100644
> > --- a/arch/arm/include/asm/percpu.h
> > +++ b/arch/arm/include/asm/percpu.h
> > @@ -30,14 +30,14 @@ static inline void set_my_cpu_offset(unsigned long off)
> > static inline unsigned long __my_cpu_offset(void)
> > {
> > unsigned long off;
> > - register unsigned long *sp asm ("sp");
> > + unsigned long sp = current_stack_pointer;
> >
> > /*
> > * Read TPIDRPRW.
> > * We want to allow caching the value, so avoid using volatile and
> > * instead use a fake stack read to hazard against barrier().
> > */
> > - asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (*sp));
> > + asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (sp));
>
> This change doesn't look to be equivalent. Previously the *sp implied a
> memory location which doesn't appear to be the case anymore.
Having looked at the other comments in this thread, I had a crack with the
following diff:
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
index 209e650..ae0ac4e 100644
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -30,7 +30,8 @@ static inline void set_my_cpu_offset(unsigned long off)
static inline unsigned long __my_cpu_offset(void)
{
unsigned long off;
- register unsigned long *sp asm ("sp");
+// register unsigned long *sp asm ("sp");
+ unsigned long *sp = (unsigned long *)current_stack_pointer;
/*
* Read TPIDRPRW.
diff --git a/arch/arm/include/asm/thread_info.h
b/arch/arm/include/asm/thread_info.h
index 2b8114f..88a587c 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -89,6 +89,15 @@ struct thread_info {
#define init_stack (init_thread_union.stack)
/*
+ * how to get the current stack pointer from C
+ */
+#define current_stack_pointer ({ \
+ unsigned long current_sp; \
+ asm ("mov %0, r13" : "=r" (current_sp)); \
+ current_sp; \
+})
+
+/*
* how to get the thread information struct from C
*/
static inline struct thread_info *current_thread_info(void)
__attribute_const__;
> this sp trickery was introduced in commit 509eb76ebf97 to solve bad code
> generation (the commit log has the details). It would be good if Will
> Deacon could confirm that his test case still works fine with your
> change.
I resurrected your original test case for the patch in question (see below)
and the code is worse with the new sp accessor, since it insists on moving
sp into r3, which forces us to push r4 onto the stack:
Before:
c001ce6c: ee1d3f90mrc 15, 0, r3, cr13, cr0, {4}
c001ce70: e790c103ldr ip, [r0, r3, lsl #2]
c001ce74: ee1d3f90mrc 15, 0, r3, cr13, cr0, {4}
c001ce78: e7911103ldr r1, [r1, r3, lsl #2]
c001ce7c: e7d22003ldrbr2, [r2, r3]
c001ce80: ee1d3f90mrc 15, 0, r3, cr13, cr0, {4}
c001ce84: e7903103ldr r3, [r0, r3, lsl #2]
c001ce88: e08c0001add r0, ip, r1
c001ce8c: e082add r0, r0, r2
c001ce90: e083add r0, r0, r3
c001ce94: e12fff1ebx lr
After:
c001ce74: e52d4004push{r4}; (str r4, [sp, #-4]!)
c001ce78: e1a0300dmov r3, sp
c001ce7c: ee1dcf90mrc 15, 0, ip, cr13, cr0, {4}
c001ce80: e790410cldr r4, [r0, ip, lsl #2]
c001ce84: ee1dcf90mrc 15, 0, ip, cr13, cr0, {4}
c001ce88: e791110cldr r1, [r1, ip, lsl #2]
c001ce8c: e7d2200cldrbr2, [r2, ip]
c001ce90: ee1d3f90mrc 15, 0, r3, cr13, cr0, {4}
c001ce94: e7903103ldr r3, [r0, r3, lsl #2]
c001ce98: e0840001add r0, r4, r1
c001ce9c: e08
[PATCH] alpha: perf: fix out-of-bounds array access triggered from raw event
Vince's perf fuzzer uncovered the following issue on Alpha:
Unable to handle kernel paging request at virtual address fbfe4e46a0e8
CPU 0 perf_fuzzer(1278): Oops 0
pc = [] ra = [] ps = 0007Not tainted
pc is at alpha_perf_event_set_period+0x60/0xf0
ra is at alpha_pmu_enable+0x1a4/0x1c0
v0 = t0 = 000f t1 = fc007b3f5800
t2 = fbff275faa94 t3 = c9b9bd89 t4 = fbfe4e46a098
t5 = 0020 t6 = fbfe4e46a0b8 t7 = fc007f4c8000
s0 = s1 = fc0001b0c018 s2 = fc0001b0c020
s3 = fc007b3f5800 s4 = 0001 s5 = c9b9bd85
s6 = 0001
a0 = 0006 a1 = fc007b3f5908 a2 = fbfe4e46a098
a3 = 0005000108c0 a4 = a5 =
t8 = 0001 t9 = 0001 t10= 27829f6f
t11= 0020 pv = fc31fb60 at = fc950900
gp = fc940900 sp = fc007f4cbca8
Disabling lock debugging due to kernel taint
Trace:
[] alpha_pmu_enable+0x1a4/0x1c0
[] perf_pmu_enable+0x48/0x60
[] __perf_install_in_context+0x15c/0x230
[] remote_function+0x80/0xa0
[] __perf_install_in_context+0x0/0x230
[] smp_call_function_single+0x1b4/0x1d0
[] task_function_call+0x60/0x80
[] __perf_install_in_context+0x0/0x230
[] task_function_call+0x34/0x80
[] perf_install_in_context+0x9c/0x150
[] __perf_install_in_context+0x0/0x230
[] SYSC_perf_event_open+0x360/0xac0
[] entSys+0xa4/0xc0
This is due to the raw event encoding being used as an index directly
into the ev67_mapping array, rather than being validated against the
ev67_pmc_event_type enumeration instead. Unlike other architectures,
which allow raw events to propagate into the hardware counters with
little interference, the limited number of events on Alpha and the
strict event <-> counter relationships mean that raw events actually
correspond to the Linux-specific Alpha events, rather than anything
defined by the architecture.
This patch adds a new callback to alpha_pmu_t for validating the raw
event encoding with the Linux event types for the PMU, preventing the
out-of-bounds array access.
Cc: Peter Zijlstra
Cc: Michael Cree
Cc: Matt Turner
Signed-off-by: Will Deacon
---
arch/alpha/kernel/perf_event.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/alpha/kernel/perf_event.c b/arch/alpha/kernel/perf_event.c
index d821b17..c52e7f0 100644
--- a/arch/alpha/kernel/perf_event.c
+++ b/arch/alpha/kernel/perf_event.c
@@ -83,6 +83,8 @@ struct alpha_pmu_t {
long pmc_left[3];
/* Subroutine for allocation of PMCs. Enforces constraints. */
int (*check_constraints)(struct perf_event **, unsigned long *, int);
+ /* Subroutine for checking validity of a raw event for this PMU. */
+ int (*raw_event_valid)(u64 config);
};
/*
@@ -203,6 +205,12 @@ success:
}
+static int ev67_raw_event_valid(u64 config)
+{
+ return config >= EV67_CYCLES && config < EV67_LAST_ET;
+};
+
+
static const struct alpha_pmu_t ev67_pmu = {
.event_map = ev67_perfmon_event_map,
.max_events = ARRAY_SIZE(ev67_perfmon_event_map),
@@ -211,7 +219,8 @@ static const struct alpha_pmu_t ev67_pmu = {
.pmc_count_mask = {EV67_PCTR_0_COUNT_MASK, EV67_PCTR_1_COUNT_MASK, 0},
.pmc_max_period = {(1UL<<20) - 1, (1UL<<20) - 1, 0},
.pmc_left = {16, 4, 0},
- .check_constraints = ev67_check_constraints
+ .check_constraints = ev67_check_constraints,
+ .raw_event_valid = ev67_raw_event_valid,
};
@@ -609,7 +618,9 @@ static int __hw_perf_event_init(struct perf_event *event)
} else if (attr->type == PERF_TYPE_HW_CACHE) {
return -EOPNOTSUPP;
} else if (attr->type == PERF_TYPE_RAW) {
- ev = attr->config & 0xff;
+ if (!alpha_pmu->raw_event_valid(attr->config))
+ return -EINVAL;
+ ev = attr->config;
} else {
return -EOPNOTSUPP;
}
--
1.8.3.2
--
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/
Re: [PATCH v5 1/5] ARM: add basic Trusted Foundations support
Hi guys,
On Mon, Sep 09, 2013 at 07:15:31AM +0100, Alexandre Courbot wrote:
> On Fri, Sep 6, 2013 at 3:35 AM, Rob Herring wrote:
> > On 09/04/2013 10:27 PM, Alexandre Courbot wrote:
> >> Trusted Foundations is a TrustZone-based secure monitor for ARM that
> >> can be invoked using a consistent SMC-based API on all supported
> >> platforms. This patch adds initial basic support for Trusted
> >> Foundations using the ARM firmware API. Current features are limited
> >> to the ability to boot secondary processors.
[...]
> >> +Example:
> >> + firmware {
> >> + compatible = "tl,trusted-foundations";
> >> + version-major = <2>;
> >> + version-minor = <8>;
> >> + };
> >
> > I'm wondering how we fit this in with PSCI bindings? Both are pieces of
> > firmware functionality and may co-exist. There's nothing incompatible
> > here, but there should be some commonality. Will future versions of
> > Trusted Foundations follow the SMC calling conventions doc? What about
> > armv8 support.
>
> I don't have any information about the future of TF unfortunately,
> excepted that it should remain backward-compatible. What is this SMC
> calling convention doc your are talking about btw? Is there a standard
> calling convention defined by ARM?
SMC calling convention:
https://silver.arm.com/download/download.tm?pv=1435186
PSCI:
https://silver.arm.com/download/download.tm?pv=1421585
Although access to these documents requires you to go through a
click-through license.
Will
--
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/
Re: [RFC PATCH v2 04/25] smp, ARM: kill SMP single function call interrupt
On Wed, Sep 11, 2013 at 05:07:08PM +0100, Jiang Liu wrote: > From: Jiang Liu > > Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic > similar to smp_call_function_single()" has unified the way to handle > single and multiple cross-CPU function calls. Now only one interrupt > is needed for architecture specific code to support generic SMP function > call interfaces, so kill the redundant single function call interrupt. Acked-by: Will Deacon Will -- 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/
Re: [RFC PATCH v2 05/25] smp, ARM64: kill SMP single function call interrupt
On Wed, Sep 11, 2013 at 05:07:09PM +0100, Jiang Liu wrote: > From: Jiang Liu > > Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic > similar to smp_call_function_single()" has unified the way to handle > single and multiple cross-CPU function calls. Now only one interrupt > is needed for architecture specific code to support generic SMP function > call interfaces, so kill the redundant single function call interrupt. Acked-by: Will Deacon Will -- 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/
Re: [PATCH 0/3] perf: parse the dwarf backtrace info from .debug_frame section
On Thu, Sep 12, 2013 at 01:19:53PM +0100, Peter Zijlstra wrote: > On Thu, Sep 12, 2013 at 02:07:23PM +0200, Jean Pihet wrote: > > Hi, > > > > -- Adding more maintainers in the To: list -- > > > > Ping about the patch set, is this one acceptable for mainline? > > The below looks to be mostly ARM bits and I would suspect Will to take > care of them. I wrote those bits too, so I'm happy to take them via my tree. I'd rather wait for the last patch to have an ack from somebody like Acme (or for them to take it in the tip/perf tree) before I push anything though. Cheers, Will -- 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/
Re: [PATCH] net: smsc: remove deprecated IRQF_DISABLED
[adding David Brown] On Fri, Sep 13, 2013 at 05:27:47AM +0100, Michael Opdenacker wrote: > This patch proposes to remove the IRQF_DISABLED flag from > code in drivers/net/ethernet/smsc/ > > It's a NOOP since 2.6.35 and it will be removed one day. > > Signed-off-by: Michael Opdenacker > --- > drivers/net/ethernet/smsc/smc91x.h | 2 +- > drivers/net/ethernet/smsc/smsc9420.c | 3 +-- > 2 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ethernet/smsc/smc91x.h > b/drivers/net/ethernet/smsc/smc91x.h > index 370e13d..5730fe2 100644 > --- a/drivers/net/ethernet/smsc/smc91x.h > +++ b/drivers/net/ethernet/smsc/smc91x.h > @@ -271,7 +271,7 @@ static inline void mcf_outsw(void *a, unsigned char *p, > int l) > #define SMC_insw(a, r, p, l) mcf_insw(a + r, p, l) > #define SMC_outsw(a, r, p, l)mcf_outsw(a + r, p, l) > > -#define SMC_IRQ_FLAGS(IRQF_DISABLED) > +#define SMC_IRQ_FLAGS0 After this change, the only machine that defines the flags to anything other than IRQF_TRIGGER_RISING is MSM, which uses IRQF_TRIGGER_HIGH. David: do you actually need this? The irq_chip code under mach-msm doesn't seem to distinguish between the two. Will -- 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/
Re: [PATCH 5/5] ARM64: Add support for ILP32 ABI.
On Fri, Sep 13, 2013 at 07:18:48AM +0100, Andrew Pinski wrote: > On Wed, Sep 11, 2013 at 7:32 AM, Catalin Marinas > wrote: > > On Mon, Sep 09, 2013 at 10:32:59PM +0100, Andrew Pinski wrote: > >> This patch adds full support of the ABI to the ARM64 target. > > > > This description is too short. Please describe what the ABI is, what are > > the commonalities with AArch64 and AArch32, what other non-obvious > > things had to be done (like __kernel_long_t being long long). Split this > > patch into multiple patches like base syscall handling, signal handling, > > pselect6/ppoll, vdso etc. It's too much to review at once. > > Ok. I will do so after my vacation next week. > > > > > On top of these, I would really like to see > > Documentation/arm64/ilp32.txt describing the ABI. > > No other target does not, not even x86_64 for x32. Well, I'm sure they wouldn't mind if you submitted documentation for them too. > > I would also like to know (you can state this in the cover letter) the > > level of testing for all 3 types of ABI. I'm worried that at least this > > patch breaks the current compat ABI (has LTP reported anything?). > > We did test LTP on an earlier version of this patch for all three > ABIs, I will make sure that the next version I send out is tested on > all three ABIs also. We also tested ILP32/LP64 on big-endian at the > same time which we will continue to do (I should push for our team > here to push out the big-endian patches). We also have some BE patches internally, but obviously they just target LP64 and AArch32 compat. I'd hope to get these out shortly (the current issue is extensive testing, since we don't have much of a BE userspace). > >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > >> index cc64df5..7fdc994 100644 > >> --- a/arch/arm64/Kconfig > >> +++ b/arch/arm64/Kconfig > >> @@ -248,7 +248,7 @@ source "fs/Kconfig.binfmt" > >> > >> config COMPAT > >> def_bool y > >> - depends on ARM64_AARCH32 > >> + depends on ARM64_AARCH32 || ARM64_ILP32 > >> select COMPAT_BINFMT_ELF > >> > >> config ARM64_AARCH32 (nitpick) We used to have an option like this, called CONFIG_AARCH32_EMULATION, which I think is clearer than CONFIG_ARM64_AARCH32. > >> diff --git a/arch/arm64/kernel/vdsoilp32/Makefile > >> b/arch/arm64/kernel/vdsoilp32/Makefile > >> new file mode 100644 > >> index 000..ec93f3f > >> --- /dev/null > >> +++ b/arch/arm64/kernel/vdsoilp32/Makefile > > > > Could we not keep vdso in the same directory? > > I started out that way but "make clean ARCH=arm64" did not clean the > vdso files all the time. Can you elaborate please? I'd much rather we fix broken make rules instead of botching around the issue by creating new directories. Will -- 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/
Re: [PATCH 5/5] ARM64: Add support for ILP32 ABI.
On Fri, Sep 13, 2013 at 10:57:40AM +0100, Catalin Marinas wrote: > On Fri, Sep 13, 2013 at 10:47:12AM +0100, Will Deacon wrote: > > On Fri, Sep 13, 2013 at 07:18:48AM +0100, Andrew Pinski wrote: > > > On Wed, Sep 11, 2013 at 7:32 AM, Catalin Marinas > > > wrote: > > > > On Mon, Sep 09, 2013 at 10:32:59PM +0100, Andrew Pinski wrote: > > > >> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > > > >> index cc64df5..7fdc994 100644 > > > >> --- a/arch/arm64/Kconfig > > > >> +++ b/arch/arm64/Kconfig > > > >> @@ -248,7 +248,7 @@ source "fs/Kconfig.binfmt" > > > >> > > > >> config COMPAT > > > >> def_bool y > > > >> - depends on ARM64_AARCH32 > > > >> + depends on ARM64_AARCH32 || ARM64_ILP32 > > > >> select COMPAT_BINFMT_ELF > > > >> > > > >> config ARM64_AARCH32 > > > > (nitpick) We used to have an option like this, called > > CONFIG_AARCH32_EMULATION, which I think is clearer than > > CONFIG_ARM64_AARCH32. > > I think avoiding "EMULATION" is better, we don't actually emulate the > instruction set ;). Bah, you suggest something better then! Will -- 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/
Re: [PATCH] perf tools: Check libunwind for availability of dwarf parsing feature
Hi Jean, On Fri, Sep 13, 2013 at 06:08:41PM +0100, Jean Pihet wrote: > The newly added dwarf unwinding feature [1] requires: > . a recent version (>= 1.1) of libunwind, > . libunwind to be configured with --enable-debug-frame. > > [1] http://www.spinics.net/lists/kernel/msg1598951.html > > Add the corresponding API test in the feature check list. Any reason not to merge this in with the third patch in original series? I don't think it's been picked up by anybody yet, so it would make sense to repost with this fixup after the merge window. Will -- 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/
Re: [PATCH 3/4] perf tools: Check libunwind for availability of dwarf parsing feature
On Tue, Oct 08, 2013 at 03:28:30PM +0100, Arnaldo Carvalho de Melo wrote: > Em Tue, Oct 08, 2013 at 04:15:40PM +0200, Jean Pihet escreveu: > > >> On 26 September 2013 14:48, Jiri Olsa wrote: > > > >> > Acked-by: Jiri Olsa > > > -- adding Arnaldo in the loop -- > > Arnaldo, are you OK with the changes [1]? Jiri acked the patches > > already; Will is willing (no pun intended) to take the ARM specific > > patches [2] in his tree. > > As Jiri acked, go ahead and pick as much as you can via Will's tree, I'd > say. :-) Cheers guys, that suits me! Will -- 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/
Kernel warning triggered with trinity on 3.12-rc4
Hi guys, I've been running trinity on my ARMv7 Cortex-A15 system and managed to trigger the following kernel warning: 8<--- [15333.257972] [ cut here ] [15333.259328] WARNING: CPU: 1 PID: 18717 at fs/aio.c:474 free_ioctx+0x1d0/0x1d4() [15333.259894] Modules linked in: [15333.260643] CPU: 1 PID: 18717 Comm: kworker/1:0 Not tainted 3.12.0-rc4 #3 [15333.261580] Workqueue: events free_ioctx [15333.261978] [] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14) [15333.263231] [] (show_stack+0x10/0x14) from [] (dump_stack+0x98/0xd4) [15333.264106] [] (dump_stack+0x98/0xd4) from [] (warn_slowpath_common+0x6c/0x88) [15333.265132] [] (warn_slowpath_common+0x6c/0x88) from [] (warn_slowpath_null+0x1c/0x24) [15333.266053] [] (warn_slowpath_null+0x1c/0x24) from [] (free_ioctx+0x1d0/0x1d4) [15333.267097] [] (free_ioctx+0x1d0/0x1d4) from [] (process_one_work+0xf4/0x35c) [15333.267822] [] (process_one_work+0xf4/0x35c) from [] (worker_thread+0x138/0x3d4) [15333.268766] [] (worker_thread+0x138/0x3d4) from [] (kthread+0xb4/0xb8) [15333.269746] [] (kthread+0xb4/0xb8) from [] (ret_from_fork+0x14/0x3c) [15333.270455] ---[ end trace d2466d8d496fd5c9 ]--- --->8 So this looks like either somebody else is messing with ctx->reqs_available on the ctx freeing path, or we're inadvertently incrementing the reqs_available count beyond the queue size. I'm really not familiar with this code, but the conditional assignment to avail looks pretty scary given that I don't think we hold the ctx->completion_lock and potentially read the tail pointer more than once. Any ideas? I've not been able to reproduce the problem again with further fuzzing (yet). Cheers, Will -- 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/
Re: [PATCH] arm64: add PAGE_ALIGNED_DATA to linker script
On Tue, Oct 08, 2013 at 09:37:39PM +0100, Mark Salter wrote: > The arm64 linker script doesn't use the PAGE_ALIGNED_DATA macro which > leads to a ".data..page_aligned" section being placed between the end > of .data and start of .bss: > > % readelf -e vmlinux >... > Section to Segment mapping: > Segment Sections... >00 .head.text .text .text.init .rodata __ksymtab __ksymtab_gpl \ > __ksymtab_strings __param __modver __ex_table .notes \ > .init.text .init.data .data..percpu .data .data..page_aligned .bss > > This causes problems for the EFI stub which may have to relocate the > kernel image based on stext and _edata symbols. > > This patch adds PAGE_ALIGNED_DATA() to the linker script inside the > the .data section. > > Signed-off-by: Mark Salter > --- > arch/arm64/kernel/vmlinux.lds.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S > index f8ab9d8..e441556 100644 > --- a/arch/arm64/kernel/vmlinux.lds.S > +++ b/arch/arm64/kernel/vmlinux.lds.S > @@ -110,6 +110,7 @@ SECTIONS >*/ > INIT_TASK_DATA(THREAD_SIZE) > NOSAVE_DATA > + PAGE_ALIGNED_DATA(PAGE_SIZE) > CACHELINE_ALIGNED_DATA(64) > READ_MOSTLY_DATA(64) Can we just replace this chunk with RW_DATA_SECTION(64, PAGE_SIZE, THREAD_SIZE) instead? Will -- 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/
Re: SDIV / UDIV Question
On Wed, Oct 09, 2013 at 08:08:05AM +0100, Wang, Yalin wrote: > I have a question about sdiv/ udiv instructions : > In armv7 A/R TRM, it said sdiv/udiv will cause > Divide by zero as undefined exception or just return zero > (decided by implementation) . > > So in kernel , should we need register a undef hook to > Get this undef exception and send SIGFPE to user space > Process ? As far as I can see, this can only happen for R-class cores, based on SCTLR.DZ. Will -- 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/
[PATCH] init: calibrate: don't print out bogomips value on boot
BogoMIPs is a confusing concept to the ill-informed, so allow
architectures to print it only if they find it worthwhile. The delay
calibration code should stick to lpj and avoid trying to draw any
correlation with BogoMIPs, which may be a fixed value derived from a
timer frequency independent of the CPU clock speed.
Acked-by: Nicolas Pitre
Acked-by: Marc Zyngier
Signed-off-by: Will Deacon
---
This is mostly cosmetic, but we've killed bogomips from the cpuinfo
on ARM and arm64, so this would be the final nail on the coffin...
init/calibrate.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/init/calibrate.c b/init/calibrate.c
index 520702d..eabc2ca 100644
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -135,13 +135,13 @@ static unsigned long calibrate_delay_direct(void)
if ((measured_times[max] - estimate) <
(estimate - measured_times[min])) {
printk(KERN_NOTICE "calibrate_delay_direct() dropping "
- "min bogoMips estimate %d = %lu\n",
+ "min delay estimate %d = %lu\n",
min, measured_times[min]);
measured_times[min] = 0;
min = max;
} else {
printk(KERN_NOTICE "calibrate_delay_direct() dropping "
- "max bogoMips estimate %d = %lu\n",
+ "max delay estimate %d = %lu\n",
max, measured_times[max]);
measured_times[max] = 0;
max = min;
@@ -295,9 +295,7 @@ void calibrate_delay(void)
}
per_cpu(cpu_loops_per_jiffy, this_cpu) = lpj;
if (!printed)
- pr_cont("%lu.%02lu BogoMIPS (lpj=%lu)\n",
- lpj/(50/HZ),
- (lpj/(5000/HZ)) % 100, lpj);
+ pr_cont("lpj=%lu\n", lpj);
loops_per_jiffy = lpj;
printed = true;
--
1.8.2.2
--
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/
Re: SDIV / UDIV Question
[Adding Jonny] On Thu, Oct 10, 2013 at 06:04:41AM +0100, Wang, Yalin wrote: > Oh , I see , > Thanks for your clarification ! > So R-class cores will not run linux ? R-class cores can run Linux, but I don't reckon we touch SCTLR.DZ. I've added Jonny, so he can clarify the behaviour here. (I'm also not sure which cores have these instructions either). Will > -Original Message- > From: Will Deacon [mailto:will.dea...@arm.com] > Sent: Wednesday, October 09, 2013 6:54 PM > To: Wang, Yalin > Cc: 'linux-arm-msm-ow...@vger.kernel.org'; linux-kernel@vger.kernel.org > Subject: Re: SDIV / UDIV Question > > On Wed, Oct 09, 2013 at 08:08:05AM +0100, Wang, Yalin wrote: > > I have a question about sdiv/ udiv instructions : > > In armv7 A/R TRM, it said sdiv/udiv will cause Divide by zero as > > undefined exception or just return zero (decided by implementation) . > > > > So in kernel , should we need register a undef hook to Get this > > undef exception and send SIGFPE to user space Process ? > > As far as I can see, this can only happen for R-class cores, based on > SCTLR.DZ. > > Will > -- 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/
