* [RFC] minimum gcc version for kernel: raise to gcc-4.3 or 4.6?
From: Kees Cook @ 2017-04-20 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a2C2WhWjzF=HrzU15Ncg0juR+nstZukBEpqCrVNW5pnDA@mail.gmail.com>
On Thu, Apr 20, 2017 at 3:15 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sun, Apr 16, 2017 at 9:52 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> The original gcc-4.3 release was in early 2008. If we decide to still
>>>> support that, we probably want the first 10 quirks in this series,
>>>> while gcc-4.6 (released in 2011) requires none of them.
>>
>> I'd be in support of raising the minimum to gcc 4.6. (I'd actually
>> prefer 4.7, just to avoid some 4.6 packaging issues, and for better
>> gcc plugin support.)
>>
>> I'm curious what gcc 4.6 binaries are common in the wild besides
>> old-stable Debian (unsupported in maybe a year from now?) and 12.04
>> Ubuntu (going fully unsupported in 2 weeks). It looks like 4.6 was
>> used only in Fedora 15 and 16 (both EOL).
>
> I think we are better off defining two versions: One that we know
> a lot of people care about, and we actively try to make that work
> well in all configurations (e.g. 4.6, 4.7 or 4.8), fixing all warnings
> we run into, and an older version that we try not to break
> intentionally (e.g. 3.4, 4.1 or 4.3) but that we only fix when
> someone actually runs into a problem they can't work around
> by upgrading to a more modern compiler.
For "working well everywhere" I feel like 4.8 is the better of those
three (I'd prefer 4.9). I think we should avoid 4.6 -- it seems not
widely used.
For an old compiler... yikes. 3.4 sounds insane to me. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Doug Anderson @ 2017-04-20 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mvbaykn1.fsf@eliezer.anholt.net>
Hi,
On Thu, Apr 20, 2017 at 11:54 AM, Eric Anholt <eric@anholt.net> wrote:
> Stefan Wahren <stefan.wahren@i2se.com> writes:
>
>> Hi,
>>
>>> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>>>
>>>
>>> It's hard to know for sure that all of this time is really in
>>> urb_enqueue(). Possible we could have task switched out and been
>>> blocked elsewhere. Using ftrace to get more fine-grained timings
>>> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
>>> friends here if you want to use trace_printk.
>>
>> i'm a newbie to ftrace, so i hope this would be helpful.
>>
>> # connect PL2303 to the onboard hub
>> # echo 0 > options/sleep-time
>> # echo 0 > function_profile_enabled
>> # echo 1 > function_profile_enabled
>> # ./usb_test
>> # Waiting for at least 20 seconds and then disconnect PL2303
>> # echo 0 > function_profile_enabled
>> # cat trace_stat/function0
>>
>> Function Hit Time Avg s^2
>> -------- --- ---- --- ---
>> bcm2835_handle_irq 361347 219567633 us 607.636 us 1485199 us
>> __handle_domain_irq 1082482 212639551 us 196.437 us 3642030 us
>> generic_handle_irq 1082482 100592051 us 92.927 us 50511334 us
>> irq_exit 1082482 98197771 us 90.715 us 29649040 us
>> handle_level_irq 1082482 95812379 us 88.511 us 51910093 us
>
> If I'm reading this output right, we're spending half of our interrupt
> processing time in irq_exit(), so even if dwc2's interrupt was free (the
> generic_handle_irq() chain), we'd be eating about half the CPU getting
> back out of the interrupt handler, right?
>
> I don't really know anything about DWC2 or USB, but is there any way we
> could mitigate the interrupt frequency with this hardware? If nothing
> else, could we loop reading gintsts until it reads back 0?
Take ftrace with a little bit of a grain of salt, especially on older
/ slower ARMs (without the arch timer). Whenever ftrace takes a log
it grabs a timestamp. This can be an expensive (ish) operation. Even
on newer CPUs it's still not free if you call it as much as ftrace,
but on older CPUs it's extra expensive.
I spent a chunk of time working on optimizations for that on exynos
since it showed up in profiles as an expensive operation (Chrome asks
for the time a lot during its internal profiling). Some of that type
of data is in commit 3252a646aa2c ("clocksource: exynos_mct: Only use
32-bits where possible").
^ permalink raw reply
* [PATCH 3/3] bus: fsl-mc: dpio: change CENA regs to be cacheable
From: Haiying Wang @ 2017-04-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492716858-24509-1-git-send-email-Haiying.Wang@nxp.com>
plus non-shareable to meet the performance requirement.
QMan's CENA region contains registers and structures that
are 64byte in size and are inteneded to be accessed using a
single 64 byte bus transaction, therefore this portal
memory should be configured as cache-enabled. Also because
the write allocate stash transcations of QBMan should be
issued as cachable and non-coherent(non-sharable), we
need to configure this region to be non-shareable.
Signed-off-by: Haiying Wang <Haiying.Wang@nxp.com>
---
drivers/staging/fsl-mc/bus/dpio/dpio-driver.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c b/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c
index e36da20..97f909c 100644
--- a/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c
+++ b/drivers/staging/fsl-mc/bus/dpio/dpio-driver.c
@@ -168,10 +168,10 @@ static int dpaa2_dpio_probe(struct fsl_mc_device *dpio_dev)
desc.cpu = next_cpu;
/*
- * Set the CENA regs to be the cache inhibited area of the portal to
- * avoid coherency issues if a user migrates to another core.
+ * Set the CENA regs to be the cache enalbed area of the portal to
+ * archieve the best performance.
*/
- desc.regs_cena = ioremap_wc(dpio_dev->regions[1].start,
+ desc.regs_cena = ioremap_cache_ns(dpio_dev->regions[1].start,
resource_size(&dpio_dev->regions[1]));
desc.regs_cinh = ioremap(dpio_dev->regions[1].start,
resource_size(&dpio_dev->regions[1]));
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] bus: fsl-mc: dpio: enable qbman CENA portal memory access
From: Haiying Wang @ 2017-04-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492716858-24509-1-git-send-email-Haiying.Wang@nxp.com>
Once we enable the cacheable portal memory, we need to do
cache flush for enqueue, vdq, buffer release, and management
commands, as well as invalidate and prefetch for the valid bit
of management command response and next index of dqrr.
Signed-off-by: Haiying Wang <Haiying.Wang@nxp.com>
---
drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
index 2a3ea29..e16121c 100644
--- a/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
+++ b/drivers/staging/fsl-mc/bus/dpio/qbman-portal.c
@@ -99,6 +99,14 @@ enum qbman_sdqcr_fc {
qbman_sdqcr_fc_up_to_3 = 1
};
+#define dccvac(p) { asm volatile("dc cvac, %0;" : : "r" (p) : "memory"); }
+#define dcivac(p) { asm volatile("dc ivac, %0" : : "r"(p) : "memory"); }
+static inline void qbman_inval_prefetch(struct qbman_swp *p, uint32_t offset)
+{
+ dcivac(p->addr_cena + offset);
+ prefetch(p->addr_cena + offset);
+}
+
/* Portal Access */
static inline u32 qbman_read_register(struct qbman_swp *p, u32 offset)
@@ -189,7 +197,7 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
p->addr_cinh = d->cinh_bar;
reg = qbman_set_swp_cfg(p->dqrr.dqrr_size,
- 1, /* Writes Non-cacheable */
+ 0, /* Writes cacheable */
0, /* EQCR_CI stashing threshold */
3, /* RPM: Valid bit mode, RCR in array mode */
2, /* DCM: Discrete consumption ack mode */
@@ -315,6 +323,7 @@ void qbman_swp_mc_submit(struct qbman_swp *p, void *cmd, u8 cmd_verb)
dma_wmb();
*v = cmd_verb | p->mc.valid_bit;
+ dccvac(cmd);
}
/*
@@ -325,6 +334,7 @@ void *qbman_swp_mc_result(struct qbman_swp *p)
{
u32 *ret, verb;
+ qbman_inval_prefetch(p, QBMAN_CENA_SWP_RR(p->mc.valid_bit));
ret = qbman_get_cmd(p, QBMAN_CENA_SWP_RR(p->mc.valid_bit));
/* Remove the valid-bit - command completed if the rest is non-zero */
@@ -435,6 +445,7 @@ int qbman_swp_enqueue(struct qbman_swp *s, const struct qbman_eq_desc *d,
/* Set the verb byte, have to substitute in the valid-bit */
dma_wmb();
p->verb = d->verb | EQAR_VB(eqar);
+ dccvac(p);
return 0;
}
@@ -627,6 +638,7 @@ int qbman_swp_pull(struct qbman_swp *s, struct qbman_pull_desc *d)
/* Set the verb byte, have to substitute in the valid-bit */
p->verb = d->verb | s->vdq.valid_bit;
s->vdq.valid_bit ^= QB_VALID_BIT;
+ dccvac(p);
return 0;
}
@@ -680,8 +692,7 @@ const struct dpaa2_dq *qbman_swp_dqrr_next(struct qbman_swp *s)
s->dqrr.next_idx, pi);
s->dqrr.reset_bug = 0;
}
- prefetch(qbman_get_cmd(s,
- QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx)));
+ qbman_inval_prefetch(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
}
p = qbman_get_cmd(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
@@ -696,8 +707,7 @@ const struct dpaa2_dq *qbman_swp_dqrr_next(struct qbman_swp *s)
* knew from reading PI.
*/
if ((verb & QB_VALID_BIT) != s->dqrr.valid_bit) {
- prefetch(qbman_get_cmd(s,
- QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx)));
+ qbman_inval_prefetch(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
return NULL;
}
/*
@@ -720,7 +730,7 @@ const struct dpaa2_dq *qbman_swp_dqrr_next(struct qbman_swp *s)
(flags & DPAA2_DQ_STAT_EXPIRED))
atomic_inc(&s->vdq.available);
- prefetch(qbman_get_cmd(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx)));
+ qbman_inval_prefetch(s, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
return p;
}
@@ -848,6 +858,7 @@ int qbman_swp_release(struct qbman_swp *s, const struct qbman_release_desc *d,
*/
dma_wmb();
p->verb = d->verb | RAR_VB(rar) | num_buffers;
+ dccvac(p);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory
From: Haiying Wang @ 2017-04-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492716858-24509-1-git-send-email-Haiying.Wang@nxp.com>
NXP arm64 based SoC needs to allocate cacheable and
non-shareable memory for the software portals of
Queue manager, so we extend the arm64 ioremap support
for this memory attribute.
Signed-off-by: Haiying Wang <Haiying.Wang@nxp.com>
---
arch/arm64/include/asm/io.h | 1 +
arch/arm64/include/asm/pgtable-prot.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87..b6f03e7 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -170,6 +170,7 @@ extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
#define ioremap_nocache(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
#define ioremap_wc(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
#define ioremap_wt(addr, size) __ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
+#define ioremap_cache_ns(addr, size) __ioremap((addr), (size), __pgprot(PROT_NORMAL_NS))
#define iounmap __iounmap
/*
diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
index 2142c77..7fc7910 100644
--- a/arch/arm64/include/asm/pgtable-prot.h
+++ b/arch/arm64/include/asm/pgtable-prot.h
@@ -42,6 +42,7 @@
#define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_NC))
#define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL_WT))
#define PROT_NORMAL (PROT_DEFAULT | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
+#define PROT_NORMAL_NS (PTE_TYPE_PAGE | PTE_AF | PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE | PTE_ATTRINDX(MT_NORMAL))
#define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE))
#define PROT_SECT_NORMAL (PROT_SECT_DEFAULT | PMD_SECT_PXN | PMD_SECT_UXN | PMD_ATTRINDX(MT_NORMAL))
--
2.7.4
^ permalink raw reply related
* [PATCH 0/3] bus: fsl-mc: dpio: udpate QMan CENA region
From: Haiying Wang @ 2017-04-20 19:34 UTC (permalink / raw)
To: linux-arm-kernel
This patchset allows the NXP's DPAA2 QMan Software portal
CENA region to be cacheable as designed for the performance
goal. Besides, the write allocate stash feature of the QMan
requires the non-shareable attribute for this cache-enabled
memory.
So this patchset extends the arm64 ioremap with cache-enable
and non-shareable first, then enables the CENA portal memory
access in the QBMan driver, at last changes the ioremap call
in dpio driver where the software portal CENA memory is
mapped to be the correct one.
Haiying Wang (3):
arm64: extend ioremap for cacheable non-shareable memory
bus: fsl-mc: dpio: enable qbman CENA portal memory access
bus: fsl-mc: dpio: change CENA regs to be cacheable
arch/arm64/include/asm/io.h | 1 +
arch/arm64/include/asm/pgtable-prot.h | 1 +
drivers/staging/fsl-mc/bus/dpio/dpio-driver.c | 6 +++---
drivers/staging/fsl-mc/bus/dpio/qbman-portal.c | 23 +++++++++++++++++------
4 files changed, 22 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCHv3 08/14] drivers/perf: arm_pmu: split cpu-local irq request/free
From: Mark Rutland @ 2017-04-20 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVs+JQ3-Lj=TyN5Zi9fAhJROuc7upgFKmCwXVaA8eb1WQ@mail.gmail.com>
On Tue, Apr 18, 2017 at 08:57:04PM +0200, Geert Uytterhoeven wrote:
> On Tue, Apr 18, 2017 at 8:33 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> > I'm somewhat surprised that this patch would have that
> > effect -- I would imagine that the rework this is based on is more
> > likely to. e.g. commit:
> >
> > c09adab01e4aeecf ("drivers/perf: arm_pmu: split irq request from enable")
>
> Bummer. You're right. It's actually due to that commit.
Ok; I understand what's happening, then.
FWIW, the warnings are benign, albeit annoying.
I'll have a go at cleaning this up.
> I searched in my gmail for a patch with the specific title, and blindly
> replied to the first match, not noticing that was not the right patch.
> Sorry for that.
No worries.
> On R-Car Gen3, there's no change in PMU related messages.
> Actual PMU messages are:
>
> hw perfevents: enabled with armv8_cortex_a57 PMU driver, 7
> counters available
> hw perfevents: /soc/pmu_a53: failed to probe PMU!
> hw perfevents: /soc/pmu_a53: failed to register PMU devices!
>
> The last two are due to the CA53 cores being described in DT, but not
> enabled in the firmware.
Ok.
> On SH-Mobile AG5 (sh73a0/kzm9g), it recently (not due to the bad commit)
> started printing:
>
> +hw perfevents: no interrupt-affinity property for /pmu, guessing.
> hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
>
> which looks related.
That's stating that the DTB doesn't provide a interrupt-affinity
property for the PMU nodem so the affinity is guessed based on the
logical CPU ordering, which is dodgy.
I can see that's missing in arch/arm/boot/dts/sh73a0.dtsi.
That should be easy to fix up, as per
arch/arm64/boot/dts/renesas/r8a7795.dtsi, assuming you're aware of which
IRQ corresponds to which CPU.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/2] arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
From: Florian Fainelli @ 2017-04-20 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420190546.7453-1-f.fainelli@gmail.com>
The ARMv8 PMUv3 cache map did not include the L2 cache events, add
them.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/kernel/perf_event.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 4f011cdd756d..a664c575f3fd 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -264,6 +264,11 @@ static const unsigned armv8_pmuv3_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
[C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
+ [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+ [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+
[C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL,
[C(DTLB)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] arm64: pmu: Wire-up Cortex A53 L2 cache events and DTLB refills
From: Florian Fainelli @ 2017-04-20 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420190546.7453-1-f.fainelli@gmail.com>
Add missing L2 cache events: read/write accesses and misses, as well as
the DTLB refills.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/kernel/perf_event.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 57ae9d9ed9bb..4f011cdd756d 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -290,6 +290,12 @@ static const unsigned armv8_a53_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
[C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
+ [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+ [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+
+ [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL,
[C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL,
[C(BPU)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_BR_PRED,
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] arm64: perf: Wire-up Cortex A53 L2 cache events and DTLB refills
From: Florian Fainelli @ 2017-04-20 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420190546.7453-1-f.fainelli@gmail.com>
Add missing L2 cache events: read/write accesses and misses, as well as
the DTLB refills.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm64/kernel/perf_event.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 57ae9d9ed9bb..4f011cdd756d 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -290,6 +290,12 @@ static const unsigned armv8_a53_perf_cache_map[PERF_COUNT_HW_CACHE_MAX]
[C(L1I)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE,
[C(L1I)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_CACHE_REFILL,
+ [C(LL)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+ [C(LL)][C(OP_WRITE)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE,
+ [C(LL)][C(OP_WRITE)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L2D_CACHE_REFILL,
+
+ [C(DTLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1D_TLB_REFILL,
[C(ITLB)][C(OP_READ)][C(RESULT_MISS)] = ARMV8_PMUV3_PERFCTR_L1I_TLB_REFILL,
[C(BPU)][C(OP_READ)][C(RESULT_ACCESS)] = ARMV8_PMUV3_PERFCTR_BR_PRED,
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] arm64: perf: Add L2 cache events for ARMv8 PMuv3 and A53
From: Florian Fainelli @ 2017-04-20 19:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
While investigating why there were no L2 cache events generated for a Cortex
A53-like PMU, it turned out that none of the L2 cache events were mapped.
This is also the case for ARMv8 PMUv3, which seems a little odd considering
they are defined.
Thanks!
Florian Fainelli (2):
arm64: perf: Wire-up Cortex A53 L2 cache events and DTLB refills
arm64: pmu: Wire-up L2 cache events for ARMv8 PMUv3
arch/arm64/kernel/perf_event.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--
2.9.3
^ permalink raw reply
* [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support
From: Peter Zijlstra @ 2017-04-20 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420182318.4ddtfiobxz6hgbo4@yury-N73SV>
On Thu, Apr 20, 2017 at 09:23:18PM +0300, Yury Norov wrote:
> Is there some test to reproduce the locking failure for the case.
Possibly sysvsem stress before commit:
27d7be1801a4 ("ipc/sem.c: avoid using spin_unlock_wait()")
Although a similar scheme is also used in nf_conntrack, see commit:
b316ff783d17 ("locking/spinlock, netfilter: Fix nf_conntrack_lock() barriers")
> I
> ask because I run loctorture for many hours on my qemu (emulating
> cortex-a57), and I see no failures in the test reports. And Jan did it
> on ThunderX, and Adam on QDF2400 without any problems. So even if I
> rework those functions, how could I check them for correctness?
Running them doesn't prove them correct. Memory ordering bugs have been
in the kernel for many years without 'ever' triggering. This is stuff
you have to think about.
> Anyway, regarding the queued_spin_unlock_wait(), is my understanding
> correct that you assume adding smp_mb() before entering the for(;;)
> cycle, and using ldaxr/strxr instead of atomic_read()?
You'll have to ask Will, I always forget the arm64 details.
^ permalink raw reply
* [PATCH] ARM: KVM: Fix idmap stub entry when running Thumb-2 code
From: Christoffer Dall @ 2017-04-20 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420150221.15796-1-marc.zyngier@arm.com>
On Thu, Apr 20, 2017 at 04:02:21PM +0100, Marc Zyngier wrote:
> When entering the hyp stub implemented in the idmap, we try to
> be mindful of the fact that we could be running a Thumb-2 kernel
> by adding 1 to the address we compute. Unfortunately, the assembler
> also knows about this trick, and has already generated an address
> that has bit 0 set in the litteral pool.
>
> Our superfluous correction ends up confusing the CPU entierely,
> as we now branch to the stub in ARM mode instead of Thumb, and on
> a possibly unaligned address for good measure. From that point,
> nothing really good happens.
>
> The obvious fix in to remove this stupid target PC correction.
>
> Fixes: 6bebcecb6c5b ("ARM: KVM: Allow the main HYP code to use the init hyp stub implementation")
> Reported-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
This works, thanks.
Applied to kvmarm/next.
-Christoffer
^ permalink raw reply
* [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support
From: Mark Rutland @ 2017-04-20 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170420182318.4ddtfiobxz6hgbo4@yury-N73SV>
On Thu, Apr 20, 2017 at 09:23:18PM +0300, Yury Norov wrote:
> On Thu, Apr 13, 2017 at 08:12:12PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 11, 2017 at 01:35:04AM +0400, Yury Norov wrote:
> >
> > > +++ b/arch/arm64/include/asm/qspinlock.h
> > > @@ -0,0 +1,20 @@
> > > +#ifndef _ASM_ARM64_QSPINLOCK_H
> > > +#define _ASM_ARM64_QSPINLOCK_H
> > > +
> > > +#include <asm-generic/qspinlock_types.h>
> > > +
> > > +#define queued_spin_unlock queued_spin_unlock
> > > +/**
> > > + * queued_spin_unlock - release a queued spinlock
> > > + * @lock : Pointer to queued spinlock structure
> > > + *
> > > + * A smp_store_release() on the least-significant byte.
> > > + */
> > > +static inline void queued_spin_unlock(struct qspinlock *lock)
> > > +{
> > > + smp_store_release((u8 *)lock, 0);
> > > +}
> >
> > I'm afraid this isn't enough for arm64. I suspect you want your own
> > variant of queued_spin_unlock_wait() and queued_spin_is_locked() as
> > well.
> >
> > Much memory ordering fun to be had there.
>
> Hi Peter,
>
> Is there some test to reproduce the locking failure for the case. I
> ask because I run loctorture for many hours on my qemu (emulating
> cortex-a57), and I see no failures in the test reports.
Even with multi-threaded TCG, a system emulated with QEMU will have far
stronger memory ordering than a real platform. So stress tests on such a
system are useless for testing memory ordering properties.
I would strongly advise that you use a real platform for anything beyond
basic tests when touching code in this area.
> And Jan did it on ThunderX, and Adam on QDF2400 without any problems.
> So even if I rework those functions, how could I check them for
> correctness?
Given the variation the architecture permits, and how difficult it is to
diagnose issues in this area, testing isn't enough here.
You need at least some informal proof as to the primitives doing what
they should, i.e. you should be able to explain why the code is correct.
Thanks,
Mark.
^ permalink raw reply
* usb: dwc2: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 146s
From: Eric Anholt @ 2017-04-20 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <212870399.174480.1492633502649@email.1und1.de>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi,
>
>> Doug Anderson <dianders@chromium.org> hat am 18. April 2017 um 22:41 geschrieben:
>>
>>
>> It's hard to know for sure that all of this time is really in
>> urb_enqueue(). Possible we could have task switched out and been
>> blocked elsewhere. Using ftrace to get more fine-grained timings
>> would be useful. ktime_get(), ktime_sub(), and ktime_to_us() are your
>> friends here if you want to use trace_printk.
>
> i'm a newbie to ftrace, so i hope this would be helpful.
>
> # connect PL2303 to the onboard hub
> # echo 0 > options/sleep-time
> # echo 0 > function_profile_enabled
> # echo 1 > function_profile_enabled
> # ./usb_test
> # Waiting for at least 20 seconds and then disconnect PL2303
> # echo 0 > function_profile_enabled
> # cat trace_stat/function0
>
> Function Hit Time Avg s^2
> -------- --- ---- --- ---
> bcm2835_handle_irq 361347 219567633 us 607.636 us 1485199 us
> __handle_domain_irq 1082482 212639551 us 196.437 us 3642030 us
> generic_handle_irq 1082482 100592051 us 92.927 us 50511334 us
> irq_exit 1082482 98197771 us 90.715 us 29649040 us
> handle_level_irq 1082482 95812379 us 88.511 us 51910093 us
If I'm reading this output right, we're spending half of our interrupt
processing time in irq_exit(), so even if dwc2's interrupt was free (the
generic_handle_irq() chain), we'd be eating about half the CPU getting
back out of the interrupt handler, right?
I don't really know anything about DWC2 or USB, but is there any way we
could mitigate the interrupt frequency with this hardware? If nothing
else, could we loop reading gintsts until it reads back 0?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/bbabadb5/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: sk-rzg1m: add Ether pins
From: Sergei Shtylyov @ 2017-04-20 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Add the (previously omitted) Ether/PHY pin data to the SK-RZG1M board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- refreshed the patch.
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 13 +++++++++++++
1 file changed, 13 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -44,6 +44,16 @@
groups = "scif0_data_d";
function = "scif0";
};
+
+ ether_pins: ether {
+ groups = "eth_link", "eth_mdio", "eth_rmii";
+ function = "eth";
+ };
+
+ phy1_pins: phy1 {
+ groups = "intc_irq0";
+ function = "intc";
+ };
};
&scif0 {
@@ -54,6 +64,9 @@
};
ðer {
+ pinctrl-0 = <ðer_pins &phy1_pins>;
+ pinctrl-names = "default";
+
phy-handle = <&phy1>;
renesas,ether-link-active-low;
status = "okay";
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
From: Sergei Shtylyov @ 2017-04-20 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Add the (previously omitted) SCIF0 pin data to the SK-RZG1M board's
device tree.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 2:
- fixed the SCIF0 data group inside the PFC node.
arch/arm/boot/dts/r8a7743-sk-rzg1m.dts | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
+++ renesas/arch/arm/boot/dts/r8a7743-sk-rzg1m.dts
@@ -1,7 +1,7 @@
/*
* Device Tree Source for the SK-RZG1M board
*
- * Copyright (C) 2016 Cogent Embedded, Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded, Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -39,7 +39,17 @@
clock-frequency = <20000000>;
};
+&pfc {
+ scif0_pins: scif0 {
+ groups = "scif0_data_d";
+ function = "scif0";
+ };
+};
+
&scif0 {
+ pinctrl-0 = <&scif0_pins>;
+ pinctrl-names = "default";
+
status = "okay";
};
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: r8a7743: add PFC support
From: Sergei Shtylyov @ 2017-04-20 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Define the generic R8A7743 part of the PFC device node.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7743.dtsi | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -1,7 +1,7 @@
/*
* Device Tree Source for the r8a7743 SoC
*
- * Copyright (C) 2016 Cogent Embedded Inc.
+ * Copyright (C) 2016-2017 Cogent Embedded Inc.
*
* This file is licensed under the terms of the GNU General Public License
* version 2. This program is licensed "as is" without any warranty of any
@@ -123,6 +123,11 @@
#power-domain-cells = <1>;
};
+ pfc: pin-controller at e6060000 {
+ compatible = "renesas,pfc-r8a7743";
+ reg = <0 0xe6060000 0 0x250>;
+ };
+
dmac0: dma-controller at e6700000 {
compatible = "renesas,dmac-r8a7743",
"renesas,rcar-dmac";
^ permalink raw reply
* [PATCH v2 0/3] Add R8A7743/SK-RZG1M PFC support
From: Sergei Shtylyov @ 2017-04-20 18:51 UTC (permalink / raw)
To: linux-arm-kernel
Hello.
Here's the set of 3 patches against Simon Horman's 'renesas.git' repo,
'renesas-devel-20170420-v4.11-rc7' tag. We're adding the R8A7743 PFC node
and then describing the pins for SCIF0 and Ether devices declared earlier.
These patches depend on the R8A7743 PFC suport in order to work properly.
[1/3] ARM: dts: r8a7743: add PFC support
[2/3] ARM: dts: sk-rzg1m: add SCIF0 pins
[3/3] ARM: dts: sk-rzg1m: add Ether pins
WBR, Sergei
^ permalink raw reply
* [PATCH] arm64: Add ASM modifier for xN register operands
From: Matthias Kaehlcke @ 2017-04-20 18:30 UTC (permalink / raw)
To: linux-arm-kernel
Many inline assembly statements don't include the 'x' modifier when
using xN registers as operands. This is perfectly valid, however it
causes clang to raise warnings like this:
warning: value size does not match register size specified by the
constraint and modifier [-Wasm-operand-widths]
...
arch/arm64/include/asm/barrier.h:62:23: note: expanded from macro
'__smp_store_release'
asm volatile ("stlr %1, %0"
Add the modifier to keep clang happy.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/barrier.h | 4 ++--
arch/arm64/include/asm/io.h | 24 ++++++++++++------------
arch/arm64/include/asm/kvm_hyp.h | 10 +++++-----
arch/arm64/include/asm/kvm_mmu.h | 12 ++++++------
arch/arm64/include/asm/percpu.h | 4 ++--
arch/arm64/include/asm/sysreg.h | 4 ++--
arch/arm64/include/asm/uaccess.h | 4 ++--
arch/arm64/kernel/armv8_deprecated.c | 4 ++--
arch/arm64/kernel/probes/kprobes.c | 2 +-
arch/arm64/kvm/hyp/switch.c | 4 ++--
11 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/arch_gicv3.h b/arch/arm64/include/asm/arch_gicv3.h
index f37e3a21f6e7..ba54e5bee885 100644
--- a/arch/arm64/include/asm/arch_gicv3.h
+++ b/arch/arm64/include/asm/arch_gicv3.h
@@ -166,7 +166,7 @@ static inline void gic_write_sre(u32 val)
static inline void gic_write_bpr1(u32 val)
{
- asm volatile("msr_s " __stringify(ICC_BPR1_EL1) ", %0" : : "r" (val));
+ asm volatile("msr_s " __stringify(ICC_BPR1_EL1) ", %x0" : : "r" (val));
}
#define gic_read_typer(c) readq_relaxed(c)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 4e0497f581a0..bc167eeda9e4 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -59,7 +59,7 @@ do { \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
case 8: \
- asm volatile ("stlr %1, %0" \
+ asm volatile ("stlr %x1, %0" \
: "=Q" (*p) : "r" (v) : "memory"); \
break; \
} \
@@ -86,7 +86,7 @@ do { \
: "Q" (*p) : "memory"); \
break; \
case 8: \
- asm volatile ("ldar %0, %1" \
+ asm volatile ("ldar %x0, %1" \
: "=r" (*(__u64 *)__u.__c) \
: "Q" (*p) : "memory"); \
break; \
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 0c00c87bb9dd..021e1733da0c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -39,33 +39,33 @@
#define __raw_writeb __raw_writeb
static inline void __raw_writeb(u8 val, volatile void __iomem *addr)
{
- asm volatile("strb %w0, [%1]" : : "rZ" (val), "r" (addr));
+ asm volatile("strb %w0, [%x1]" : : "rZ" (val), "r" (addr));
}
#define __raw_writew __raw_writew
static inline void __raw_writew(u16 val, volatile void __iomem *addr)
{
- asm volatile("strh %w0, [%1]" : : "rZ" (val), "r" (addr));
+ asm volatile("strh %w0, [%x1]" : : "rZ" (val), "r" (addr));
}
#define __raw_writel __raw_writel
static inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
- asm volatile("str %w0, [%1]" : : "rZ" (val), "r" (addr));
+ asm volatile("str %w0, [%x1]" : : "rZ" (val), "r" (addr));
}
#define __raw_writeq __raw_writeq
static inline void __raw_writeq(u64 val, volatile void __iomem *addr)
{
- asm volatile("str %x0, [%1]" : : "rZ" (val), "r" (addr));
+ asm volatile("str %x0, [%x1]" : : "rZ" (val), "r" (addr));
}
#define __raw_readb __raw_readb
static inline u8 __raw_readb(const volatile void __iomem *addr)
{
u8 val;
- asm volatile(ALTERNATIVE("ldrb %w0, [%1]",
- "ldarb %w0, [%1]",
+ asm volatile(ALTERNATIVE("ldrb %w0, [%x1]",
+ "ldarb %w0, [%x1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (addr));
return val;
@@ -76,8 +76,8 @@ static inline u16 __raw_readw(const volatile void __iomem *addr)
{
u16 val;
- asm volatile(ALTERNATIVE("ldrh %w0, [%1]",
- "ldarh %w0, [%1]",
+ asm volatile(ALTERNATIVE("ldrh %w0, [%x1]",
+ "ldarh %w0, [%x1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (addr));
return val;
@@ -87,8 +87,8 @@ static inline u16 __raw_readw(const volatile void __iomem *addr)
static inline u32 __raw_readl(const volatile void __iomem *addr)
{
u32 val;
- asm volatile(ALTERNATIVE("ldr %w0, [%1]",
- "ldar %w0, [%1]",
+ asm volatile(ALTERNATIVE("ldr %w0, [%x1]",
+ "ldar %w0, [%x1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (addr));
return val;
@@ -98,8 +98,8 @@ static inline u32 __raw_readl(const volatile void __iomem *addr)
static inline u64 __raw_readq(const volatile void __iomem *addr)
{
u64 val;
- asm volatile(ALTERNATIVE("ldr %0, [%1]",
- "ldar %0, [%1]",
+ asm volatile(ALTERNATIVE("ldr %x0, [%x1]",
+ "ldar %x0, [%x1]",
ARM64_WORKAROUND_DEVICE_LOAD_ACQUIRE)
: "=r" (val) : "r" (addr));
return val;
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index b18e852d27e8..ee872d9aded5 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64/include/asm/kvm_hyp.h
@@ -28,8 +28,8 @@
#define read_sysreg_elx(r,nvh,vh) \
({ \
u64 reg; \
- asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##nvh),\
- "mrs_s %0, " __stringify(r##vh),\
+ asm volatile(ALTERNATIVE("mrs %x0, " __stringify(r##nvh),\
+ "mrs_s %x0, " __stringify(r##vh),\
ARM64_HAS_VIRT_HOST_EXTN) \
: "=r" (reg)); \
reg; \
@@ -52,8 +52,8 @@
#define read_sysreg_el2(r) \
({ \
u64 reg; \
- asm volatile(ALTERNATIVE("mrs %0, " __stringify(r##_EL2),\
- "mrs %0, " __stringify(r##_EL1),\
+ asm volatile(ALTERNATIVE("mrs %x0, " __stringify(r##_EL2),\
+ "mrs %x0, " __stringify(r##_EL1),\
ARM64_HAS_VIRT_HOST_EXTN) \
: "=r" (reg)); \
reg; \
@@ -115,7 +115,7 @@ typeof(orig) * __hyp_text fname(void) \
{ \
typeof(alt) *val = orig; \
asm volatile(ALTERNATIVE("nop \n", \
- "mov %0, %1 \n", \
+ "mov %x0, %x1\n", \
cond) \
: "+r" (val) : "r" (alt)); \
return val; \
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index ed1246014901..7692a13efe8e 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -115,13 +115,13 @@ alternative_else_nop_endif
static inline unsigned long __kern_hyp_va(unsigned long v)
{
- asm volatile(ALTERNATIVE("and %0, %0, %1",
+ asm volatile(ALTERNATIVE("and %x0, %x0, %1",
"nop",
ARM64_HAS_VIRT_HOST_EXTN)
: "+r" (v)
: "i" (HYP_PAGE_OFFSET_HIGH_MASK));
asm volatile(ALTERNATIVE("nop",
- "and %0, %0, %1",
+ "and %x0, %x0, %1",
ARM64_HYP_OFFSET_LOW)
: "+r" (v)
: "i" (HYP_PAGE_OFFSET_LOW_MASK));
@@ -181,10 +181,10 @@ static inline void kvm_set_s2pte_readonly(pte_t *pte)
asm volatile("// kvm_set_s2pte_readonly\n"
" prfm pstl1strm, %2\n"
- "1: ldxr %0, %2\n"
- " and %0, %0, %3 // clear PTE_S2_RDWR\n"
- " orr %0, %0, %4 // set PTE_S2_RDONLY\n"
- " stxr %w1, %0, %2\n"
+ "1: ldxr %x0, %2\n"
+ " and %x0, %x0, %3 // clear PTE_S2_RDWR\n"
+ " orr %x0, %x0, %4 // set PTE_S2_RDONLY\n"
+ " stxr %w1, %x0, %2\n"
" cbnz %w1, 1b\n"
: "=&r" (pteval), "=&r" (tmp), "+Q" (pte_val(*pte))
: "L" (~PTE_S2_RDWR), "L" (PTE_S2_RDONLY));
diff --git a/arch/arm64/include/asm/percpu.h b/arch/arm64/include/asm/percpu.h
index 3bd498e4de4c..52be13171fec 100644
--- a/arch/arm64/include/asm/percpu.h
+++ b/arch/arm64/include/asm/percpu.h
@@ -20,7 +20,7 @@
static inline void set_my_cpu_offset(unsigned long off)
{
- asm volatile("msr tpidr_el1, %0" :: "r" (off) : "memory");
+ asm volatile("msr tpidr_el1, %x0" :: "r" (off) : "memory");
}
static inline unsigned long __my_cpu_offset(void)
@@ -31,7 +31,7 @@ static inline unsigned long __my_cpu_offset(void)
* We want to allow caching the value, so avoid using volatile and
* instead use a fake stack read to hazard against barrier().
*/
- asm("mrs %0, tpidr_el1" : "=r" (off) :
+ asm("mrs %x0, tpidr_el1" : "=r" (off) :
"Q" (*(const unsigned long *)current_stack_pointer));
return off;
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index ac24b6e798b1..dd7768e114e3 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -309,7 +309,7 @@ asm(
*/
#define read_sysreg(r) ({ \
u64 __val; \
- asm volatile("mrs %0, " __stringify(r) : "=r" (__val)); \
+ asm volatile("mrs %x0, " __stringify(r) : "=r" (__val)); \
__val; \
})
@@ -329,7 +329,7 @@ asm(
*/
#define read_sysreg_s(r) ({ \
u64 __val; \
- asm volatile("mrs_s %0, " __stringify(r) : "=r" (__val)); \
+ asm volatile("mrs_s %x0, " __stringify(r) : "=r" (__val)); \
__val; \
})
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 5308d696311b..e806471e0934 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -256,7 +256,7 @@ do { \
(err), ARM64_HAS_UAO); \
break; \
case 8: \
- __get_user_asm("ldr", "ldtr", "%", __gu_val, (ptr), \
+ __get_user_asm("ldr", "ldtr", "%x", __gu_val, (ptr), \
(err), ARM64_HAS_UAO); \
break; \
default: \
@@ -323,7 +323,7 @@ do { \
(err), ARM64_HAS_UAO); \
break; \
case 8: \
- __put_user_asm("str", "sttr", "%", __pu_val, (ptr), \
+ __put_user_asm("str", "sttr", "%x", __pu_val, (ptr), \
(err), ARM64_HAS_UAO); \
break; \
default: \
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index 657977e77ec8..a82d5259aab1 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -288,8 +288,8 @@ do { \
uaccess_enable(); \
__asm__ __volatile__( \
" mov %w3, %w7\n" \
- "0: ldxr"B" %w2, [%4]\n" \
- "1: stxr"B" %w0, %w1, [%4]\n" \
+ "0: ldxr"B" %w2, [%x4]\n" \
+ "1: stxr"B" %w0, %w1, [%x4]\n" \
" cbz %w0, 2f\n" \
" sub %w3, %w3, #1\n" \
" cbnz %w3, 0b\n" \
diff --git a/arch/arm64/kernel/probes/kprobes.c b/arch/arm64/kernel/probes/kprobes.c
index c5c45942fb6e..237b0e2e3364 100644
--- a/arch/arm64/kernel/probes/kprobes.c
+++ b/arch/arm64/kernel/probes/kprobes.c
@@ -495,7 +495,7 @@ void __kprobes jprobe_return(void)
* -a special PC to identify it from the other kprobes.
* -restore stack addr to original saved pt_regs
*/
- asm volatile(" mov sp, %0 \n"
+ asm volatile(" mov sp, %x0 \n"
"jprobe_return_break: brk %1 \n"
:
: "r" (kcb->jprobe_saved_regs.sp),
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index aede1658aeda..cf22fbe3cf06 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -212,7 +212,7 @@ static bool __hyp_text __translate_far_to_hpfar(u64 far, u64 *hpfar)
* saved the guest context yet, and we may return early...
*/
par = read_sysreg(par_el1);
- asm volatile("at s1e1r, %0" : : "r" (far));
+ asm volatile("at s1e1r, %x0" : : "r" (far));
isb();
tmp = read_sysreg(par_el1);
@@ -388,7 +388,7 @@ static void __hyp_text __hyp_call_panic_nvhe(u64 spsr, u64 elr, u64 par)
* making sure it is a kernel address and not a PC-relative
* reference.
*/
- asm volatile("ldr %0, =__hyp_panic_string" : "=r" (str_va));
+ asm volatile("ldr %x0, =__hyp_panic_string" : "=r" (str_va));
__hyp_do_panic(str_va,
spsr, elr,
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [Bug] VCHIQ functional test broken
From: Eric Anholt @ 2017-04-20 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170414074104.GA8704@laptop>
Rabin Vincent <rabin@rab.in> writes:
> On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
>> > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
>> > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
>> > Author: Rabin Vincent <rabinv@axis.com>
>> > Date: Tue Nov 8 09:21:19 2016 +0100
>> >
>> > ARM: 8627/1: avoid cache flushing in flush_dcache_page()
>> >
>> > When the data cache is PIPT or VIPT non-aliasing, and cache operations
>> > are broadcast by the hardware, we can always postpone the flush in
>> > flush_dcache_page(). A similar change was done for ARM64 in commit
>> > b5b6c9e9149d ("arm64: Avoid cache flushing in flush_dcache_page()").
>> >
>> > Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
>> > Signed-off-by: Rabin Vincent <rabinv@axis.com>
>> > Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
>> >
>> > It seems that staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm
>> > relies on the behavior of flush_dcache_page before this patch get
>> > applied. Any advices to fix this issues are appreciated.
>>
>> Any ideas why this causes a problem for this driver? From what I can see,
>> it doesn't make use of flush_dcache_page().
>
> The driver's create_pagelist() uses get_free_pages(), and
> get_free_pages() calls flush_dcache_page().
>
> The problem is that the driver fails to flush the pages which it
> acquires via get_free_pages(). It's clear that the driver needs to do
> it, since there is a flush in the is_vmalloc_addr() path in the same
> function. The driver probably worked earlier because of the unecessary
> flush in flush_dcache_page() which existed before this patch, but the
> purpose of that flush was not DMA coherency and it was never guaranteed
> that it would flush all the way to the point that devices could see the
> data.
>
> See radeon_ttm_tt_pin_userptr() in drivers/gpu/drm/radeon/radeon_ttm.c
> for an example of how a driver can ensure cache coherency using the DMA
> mapping API if it intends to DMA from/to pages acquired by
> get_free_pages().
>
> The rest of the driver should also be converted to the DMA mapping API
> instead of abusing the API's private functions (dmac_map_area etc.)
I'm confused by what you're saying here. The driver has already been
converted to not use dmac_map_area (commit
cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
matching the radeon driver you give as a model as far as I can see.
That commit is in v4.11-rc6 from Stefan's regression report.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170420/aa19e057/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] arm64/locking: qspinlocks and qrwlocks support
From: Yury Norov @ 2017-04-20 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170413181212.y3ezah76qoztxhnn@hirez.programming.kicks-ass.net>
On Thu, Apr 13, 2017 at 08:12:12PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 11, 2017 at 01:35:04AM +0400, Yury Norov wrote:
>
> > +++ b/arch/arm64/include/asm/qspinlock.h
> > @@ -0,0 +1,20 @@
> > +#ifndef _ASM_ARM64_QSPINLOCK_H
> > +#define _ASM_ARM64_QSPINLOCK_H
> > +
> > +#include <asm-generic/qspinlock_types.h>
> > +
> > +#define queued_spin_unlock queued_spin_unlock
> > +/**
> > + * queued_spin_unlock - release a queued spinlock
> > + * @lock : Pointer to queued spinlock structure
> > + *
> > + * A smp_store_release() on the least-significant byte.
> > + */
> > +static inline void queued_spin_unlock(struct qspinlock *lock)
> > +{
> > + smp_store_release((u8 *)lock, 0);
> > +}
>
> I'm afraid this isn't enough for arm64. I suspect you want your own
> variant of queued_spin_unlock_wait() and queued_spin_is_locked() as
> well.
>
> Much memory ordering fun to be had there.
Hi Peter,
Is there some test to reproduce the locking failure for the case. I
ask because I run loctorture for many hours on my qemu (emulating
cortex-a57), and I see no failures in the test reports. And Jan did it
on ThunderX, and Adam on QDF2400 without any problems. So even if I
rework those functions, how could I check them for correctness?
Anyway, regarding the queued_spin_unlock_wait(), is my understanding
correct that you assume adding smp_mb() before entering the for(;;)
cycle, and using ldaxr/strxr instead of atomic_read()?
Yury
^ permalink raw reply
* [PATCH 4/4] arm64: documentation: document tagged pointer stack constraints
From: Kristina Martsenko @ 2017-04-20 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492712234-4950-1-git-send-email-kristina.martsenko@arm.com>
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Cc: Dave Martin <dave.martin@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
Documentation/arm64/tagged-pointers.txt | 62 +++++++++++++++++++++++++--------
1 file changed, 47 insertions(+), 15 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index d9995f1f51b3..a25a99e82bb1 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -11,24 +11,56 @@ in AArch64 Linux.
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
-this byte for application use, with the following caveats:
+this byte for application use.
- (1) The kernel requires that all user addresses passed to EL1
- are tagged with tag 0x00. This means that any syscall
- parameters containing user virtual addresses *must* have
- their top byte cleared before trapping to the kernel.
- (2) Non-zero tags are not preserved when delivering signals.
- This means that signal handlers in applications making use
- of tags cannot rely on the tag information for user virtual
- addresses being maintained for fields inside siginfo_t.
- One exception to this rule is for signals raised in response
- to watchpoint debug exceptions, where the tag information
- will be preserved.
+Passing tagged addresses to the kernel
+--------------------------------------
- (3) Special care should be taken when using tagged pointers,
- since it is likely that C compilers will not hazard two
- virtual addresses differing only in the upper byte.
+All interpretation of userspace memory addresses by the kernel assumes
+an address tag of 0x00.
+
+This includes, but is not limited to, addresses found in:
+
+ - pointer arguments to system calls, including pointers in structures
+ passed to system calls,
+
+ - the stack pointer (sp), e.g. when interpreting it to deliver a
+ signal,
+
+ - the frame pointer (x29) and frame records, e.g. when interpreting
+ them to generate a backtrace or call graph.
+
+Using non-zero address tags in any of these locations may result in an
+error code being returned, a (fatal) signal being raised, or other modes
+of failure.
+
+For these reasons, passing non-zero address tags to the kernel via
+system calls is forbidden, and using a non-zero address tag for sp is
+strongly discouraged.
+
+Programs maintaining a frame pointer and frame records that use non-zero
+address tags may suffer impaired or inaccurate debug and profiling
+visibility.
+
+
+Preserving tags
+---------------
+
+Non-zero tags are not preserved when delivering signals. This means that
+signal handlers in applications making use of tags cannot rely on the
+tag information for user virtual addresses being maintained for fields
+inside siginfo_t. One exception to this rule is for signals raised in
+response to watchpoint debug exceptions, where the tag information will
+be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
+
+
+Other considerations
+--------------------
+
+Special care should be taken when using tagged pointers, since it is
+likely that C compilers will not hazard two virtual addresses differing
+only in the upper byte.
--
2.1.4
^ permalink raw reply related
* [PATCH 3/4] arm64: entry: improve data abort handling of tagged pointers
From: Kristina Martsenko @ 2017-04-20 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492712234-4950-1-git-send-email-kristina.martsenko@arm.com>
When handling a data abort from EL0, we currently zero the top byte of
the faulting address, as we assume the address is a TTBR0 address, which
may contain a non-zero address tag. However, the address may be a TTBR1
address, in which case we should not zero the top byte. This patch fixes
that. The effect is that the full TTBR1 address is passed to the task's
signal handler (or printed out in the kernel log).
When handling a data abort from EL1, we leave the faulting address
intact, as we assume it's either a TTBR1 address or a TTBR0 address with
tag 0x00. This is true as far as I'm aware, we don't seem to access a
tagged TTBR0 address anywhere in the kernel. Regardless, it's easy to
forget about address tags, and code added in the future may not always
remember to remove tags from addresses before accessing them. So add tag
handling to the EL1 data abort handler as well. This also makes it
consistent with the EL0 data abort handler.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/asm/asm-uaccess.h | 9 +++++++++
arch/arm64/kernel/entry.S | 4 +++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
index df411f3e083c..790ce8e64f8d 100644
--- a/arch/arm64/include/asm/asm-uaccess.h
+++ b/arch/arm64/include/asm/asm-uaccess.h
@@ -62,4 +62,13 @@ alternative_if ARM64_ALT_PAN_NOT_UAO
alternative_else_nop_endif
.endm
+/*
+ * Remove the address tag from a virtual address, if present.
+ */
+ .macro clear_address_tag, addr, tmp
+ bic \tmp, \addr, #(0xff << 56)
+ tst \addr, #(1 << 55)
+ csel \addr, \tmp, \addr, eq
+ .endm
+
#endif
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 43512d4d7df2..2f7ec392ef50 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -434,6 +434,7 @@ el1_da:
tbnz x23, #7, 1f // PSR_I_BIT
enable_irq
1:
+ clear_address_tag x0, x3
mov x2, sp // struct pt_regs
bl do_mem_abort
@@ -594,7 +595,8 @@ el0_da:
// enable interrupts before calling the main handler
enable_dbg_and_irq
ct_user_exit
- bic x0, x26, #(0xff << 56)
+ mov x0, x26
+ clear_address_tag x0, x3
mov x1, x25
mov x2, sp
bl do_mem_abort
--
2.1.4
^ permalink raw reply related
* [PATCH 2/4] arm64: hw_breakpoint: fix watchpoint matching for tagged pointers
From: Kristina Martsenko @ 2017-04-20 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1492712234-4950-1-git-send-email-kristina.martsenko@arm.com>
When we take a watchpoint exception, the address that triggered the
watchpoint is found in FAR_EL1. We compare it to the address of each
configured watchpoint to see which one was hit.
The configured watchpoint addresses are untagged, while the address in
FAR_EL1 will have an address tag if the data access was done using a
tagged address. The tag needs to be removed to compare the address to
the watchpoints.
Currently we don't remove it, and as a result can report the wrong
watchpoint as being hit (specifically, always either the highest TTBR0
watchpoint or lowest TTBR1 watchpoint). This patch removes the tag.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
---
arch/arm64/include/asm/uaccess.h | 6 +++---
arch/arm64/kernel/hw_breakpoint.c | 3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 5308d696311b..0221029e27ff 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -106,9 +106,9 @@ static inline void set_fs(mm_segment_t fs)
})
/*
- * When dealing with data aborts or instruction traps we may end up with
- * a tagged userland pointer. Clear the tag to get a sane pointer to pass
- * on to access_ok(), for instance.
+ * When dealing with data aborts, watchpoints, or instruction traps we may end
+ * up with a tagged userland pointer. Clear the tag to get a sane pointer to
+ * pass on to access_ok(), for instance.
*/
#define untagged_addr(addr) sign_extend64(addr, 55)
diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
index 0296e7924240..749f81779420 100644
--- a/arch/arm64/kernel/hw_breakpoint.c
+++ b/arch/arm64/kernel/hw_breakpoint.c
@@ -36,6 +36,7 @@
#include <asm/traps.h>
#include <asm/cputype.h>
#include <asm/system_misc.h>
+#include <asm/uaccess.h>
/* Breakpoint currently in use for each BRP. */
static DEFINE_PER_CPU(struct perf_event *, bp_on_reg[ARM_MAX_BRP]);
@@ -721,6 +722,8 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,
u64 wp_low, wp_high;
u32 lens, lene;
+ addr = untagged_addr(addr);
+
lens = __ffs(ctrl->len);
lene = __fls(ctrl->len);
--
2.1.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox