Automated DT boot report for various ARM defconfigs.
Tree/Branch: next-thierry
Git describe: next-20131016
Failed boot tests (console logs at the end)
===========================================
exynos5250-arndale: FAIL: exynos_defconfig
am335x-bone: FAIL: multi_v7_defconfig
Full Report
===========
omap2plus_defconfig
-------------------
am335x-boneblack PASS: 0 min 30.0 sec
omap3-beagle-xm PASS: 0 min 50.5 sec
am335x-bone PASS: 0 min 26.1 sec
omap3-tobi,3530overo PASS: 0 min 21.4 sec
omap4-panda PASS: 1 min 7.4 sec
omap4-panda-es PASS: 1 min 5.1 sec
omap3-tobi,3730storm PASS: 0 min 21.0 sec
omap3-beagle PASS: 0 min 50.9 sec
tegra_defconfig
---------------
tegra30-beaver PASS: 0 min 17.1 sec
imx_v6_v7_defconfig
-------------------
imx6dl-wandboard,wand-dual PASS: 0 min 16.3 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.2 sec
imx6q-wandboard PASS: 0 min 14.9 sec
mvebu_defconfig
---------------
armada-xp-openblocks-ax3-4 PASS: 0 min 22.0 sec
armada-370-mirabox PASS: 0 min 20.0 sec
exynos_defconfig
----------------
exynos5250-arndale FAIL: 0 min 33.4 sec
multi_v7_defconfig
------------------
ste-snowball PASS: 0 min 25.5 sec
tegra30-beaver PASS: 0 min 17.0 sec
am335x-boneblack PASS: 0 min 34.5 sec
omap3-beagle-xm PASS: 0 min 50.1 sec
armada-370-mirabox PASS: 0 min 20.8 sec
omap4-panda PASS: 1 min 6.3 sec
omap4-panda-es PASS: 1 min 8.6 sec
armada-xp-openblocks-ax3-4 PASS: 0 min 22.8 sec
sun4i-a10-cubieboard PASS: 0 min 13.7 sec
imx6dl-wandboard,wand-solo PASS: 0 min 16.5 sec
omap3-tobi,3530overo PASS: 0 min 19.8 sec
am335x-bone FAIL: 0 min 31.4 sec
imx6q-wandboard PASS: 0 min 16.8 sec
omap3-tobi,3730storm PASS: 0 min 22.1 sec
imx6dl-wandboard,wand-dual PASS: 0 min 16.7 sec
omap3-beagle PASS: 0 min 49.9 sec
u8500_defconfig
---------------
ste-snowball PASS: 0 min 33.0 sec
sama5_defconfig
---------------
sama5d35ek PASS: 0 min 17.4 sec
Console logs for failures
=========================
exynos_defconfig
----------------
exynos5250-arndale: FAIL: last 24 lines of boot log:
----------------------------------------------------
tftp 0x407c0000 tmp/arndale-rXxUQ2/exynos5250-arndale.dtb
Waiting for Ethernet connection... done.
Using asx0 device
TFTP from server 192.168.1.2; our IP address is 192.168.1.171
Filename 'tmp/arndale-rXxUQ2/exynos5250-arndale.dtb'.
Load address: 0x407c0000
Loading: *###
done
Bytes transferred = 32949 (80b5 hex)
ARNDALE5250 # printenv bootargs
printenv bootargs
bootargs=console=tty0 console=ttySAC2,115200n8 rw root=/dev/mmcblk1p3 rootwait rootfstype=ext4 ip=192.168.1.171:192.168.1.2:192.168.1.254:255.255.255.0::::192.168.1.254:none
ARNDALE5250 # bootz 0x40800000 - 0x407c0000
bootz 0x40800000 - 0x407c0000
## Flattened Device Tree blob at 407c0000
Booting using the fdt blob at 0x407c0000
Using Device Tree in place at 407c0000, end 407cb0b4
Starting kernel ...
~$off
# PYBOOT: Exception: kernel: ERROR: did not start booting.
# PYBOOT: Time: 33.37 seconds.
# PYBOOT: Result: FAIL
multi_v7_defconfig
------------------
am335x-bone: FAIL: last 24 lines of boot log:
---------------------------------------------
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
cu: /home/khilman/dev/am335xbone: Line in use
Unknown command 'þ`æ~þþþææþ`æ~þþþææþ`æ~þþþææxð~xð~' - try 'help'
U-Boot# ~$off
# PYBOOT: Exception: ERROR: Could not break into autoboot.
# PYBOOT: Time: 31.38 seconds.
# PYBOOT: Result: FAIL
On Wed, Oct 16, 2013 at 12:13:28PM +0100, Ben Dooks wrote:
> On 15/10/13 23:38, Taras Kondratiuk wrote:
> > Hi
> >
> > I was debugging kprobes-test for BE8 and noticed that some data fields
> > are stored in LE instead of BE. It happens because these data fields
> > get interpreted as instructions.
> >
> > Is it a known issue?
>
> I reported the crashes to Tixy along with a different
> method of sovling the problem (changed to using pointers to
> the strings) a while ago. However it seems that nothing has
> happened to fix this.
>
> Since kprobes seems to work with the fixed tests I forgot
> to follow up and prod Jon about looking into this problem.
>
> Jon, if you are not interested in fixing this, then please
> let me know and we can get a patch sorted to fix it.
>
> PS, I am going to leave this out of the current be8 patchset
> as I want to get that merged, and at the moment kprobes-test
> is not essential to getting the system started.
>
> > For example:
> > test_align_fail_data:
> > bx lr
> > .byte 0xaa
> > .align
> > .word 0x12345678
> >
> > I would expect to see something like this:
> > 00000000<test_align_fail_data>:
> > 0: e12fff1e bx lr
> > 4: aa .byte 0xaa
> > 5: 00 .byte 0x00
> > 6: 0000 .short 0x0000
> > 8: 12345678 .word 0x12345678
> >
> > But instead I have:
> > 00000000<test_align_fail_data>:
> > 0: e12fff1e bx lr
> > 4: aa .byte 0xaa
> > 5: 00 .byte 0x00
> > 6: 0000 .short 0x0000
> > 8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000
> >
> > As a result the word 0x12345678 will be stored in LE.
> >
> > I've run several tests and here are my observations:
> > - Double ".align" fixes the issue :)
> > - Behavior is the same for LE/BE, ARM/Thumb, GCC 4.4.1/4.6.x/4.8.2
> > - Size of alignment doesn't matter.
> > - Issue happens only if previous data is not instruction-aligned and
> > 0's are added before NOPs.
> > - Explicit filling with 0's (.align , 0) fixes the issue, but as a side
> > effect data @0x4 is interpreted as a single ".word 0xaa000000"
> > instead of ".byte .byte .short". I'm not sure if there can be any
> > functional difference because of this.
There isn't. This is just objdump's pretty-printing behaviour.
Objdump prints out the data in naturally-aligned units, but this has
nothing to do with whether .byte, .short or .word/.long was used in
the source.
> > - Issue doesn't happen if there is no instructions before data
> > (no "bx lr" in the example).
> > - Issue doesn't happen if data after .align is defined as
> > ".type<symbol>,%object".
>
> Thanks for getting down to a simple test case.
Unfortunately, objdump can and does get confused about data/instruction
boundaries, so the output you see above may be misleading.
Displaying the symbol table with --special-syms will list the magic
symbols that mark the instruction and data boundaries, to help debug
this kind of situation.
However, in this case, I think you've found a bug in the assembler,
as shown below.
Before linking, the final $a symbol (indicating the start of ARM
instructions) is at address 8, so in this case objdump is correct
to show 0x12345678 as an instruction.
After linking, the mapping symbols ($[atd]) remain as before, and
the linker has byteswapped this "instruction" (as it should).
This is likely related to the magic for inserting the extensible
NOP-padding fragment which implements the .align in code sections.
That is code, and requires a $a mapping symbol, but that somehow
goes AWOL or gets displaced after the alignment padding ...
I can't quite get my head around what is going on in
binutils/gas/config/tc-arm.c. We would need to understand that
before we can identify a reliable workaround.
>
> My view is to fix this by not doing complicated things by trying
> to save a bit of space by embedding strings into the code. It is
> not as if we cannot get the compiler to put the strings into the
> relevant data area and give us a pointer we can use.
>
> The code in this case is /not easy/ to follow and it would be nice
> if it could be cleaned up to just take the string as a argument to
> the test code instead of trying to find it via assembly magic.
My conslusion is the same as yours -- we should avoid these clever
tricks in asm for now, if possible. Otherwise, we need to identify
a workaround...
Cheers
---Dave
[terminal spew follows]
$ arm-linux-gnueabi-as --version
GNU assembler (GNU Binutils) 2.23.2
$ arm-linux-gnueabi-as -EB -o test.o test.s
$ arm-linux-gnueabi-ld -EB --be8 -o test test.o
arm-linux-gnueabi-ld: warning: cannot find entry symbol _start; defaulting to 0000000000008054
$ arm-linux-gnueabi-objdump -dst --special-syms test.o
test.o: file format elf32-bigarm
SYMBOL TABLE:
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l .text 00000000 test_align_fail_data
00000000 l .text 00000000 $a
00000004 l .text 00000000 $d
00000005 l .text 00000000 $d
00000008 l .text 00000000 $a
00000000 l d .ARM.attributes 00000000 .ARM.attributes
Contents of section .text:
0000 e12fff1e aa000000 12345678 ./.......4Vx
Contents of section .ARM.attributes:
0000 41000000 15616561 62690001 0000000b A....aeabi......
0010 06020801 0901 ......
Disassembly of section .text:
00000000 <test_align_fail_data>:
0: e12fff1e bx lr
4: aa .byte 0xaa
5: 00 .byte 0x00
6: 0000 .short 0x0000
8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000
$ arm-linux-gnueabi-objdump -dst --special-syms test
test: file format elf32-bigarm
SYMBOL TABLE:
00008054 l d .text 00000000 .text
00000000 l d .ARM.attributes 00000000 .ARM.attributes
00000000 l df *ABS* 00000000 test.o
00008054 l .text 00000000 test_align_fail_data
00008054 l .text 00000000 $a
00008058 l .text 00000000 $d
00008059 l .text 00000000 $d
0000805c l .text 00000000 $a
00000000 l df *ABS* 00000000
00010060 g .text 00000000 _bss_end__
00010060 g .text 00000000 __bss_start__
00010060 g .text 00000000 __bss_end__
00000000 *UND* 00000000 _start
00010060 g .text 00000000 __bss_start
00010060 g .text 00000000 __end__
00010060 g .text 00000000 _edata
00010060 g .text 00000000 _end
Contents of section .text:
8054 1eff2fe1 aa000000 78563412 ../.....xV4.
Contents of section .ARM.attributes:
0000 41000000 15616561 62690001 0000000b A....aeabi......
0010 06020801 0901 ......
Disassembly of section .text:
00008054 <test_align_fail_data>:
8054: e12fff1e bx lr
8058: aa .byte 0xaa
8059: 00 .byte 0x00
805a: 0000 .short 0x0000
805c: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000
Hi
I was debugging kprobes-test for BE8 and noticed that some data fields
are stored in LE instead of BE. It happens because these data fields
get interpreted as instructions.
Is it a known issue?
For example:
test_align_fail_data:
bx lr
.byte 0xaa
.align
.word 0x12345678
I would expect to see something like this:
00000000 <test_align_fail_data>:
0: e12fff1e bx lr
4: aa .byte 0xaa
5: 00 .byte 0x00
6: 0000 .short 0x0000
8: 12345678 .word 0x12345678
But instead I have:
00000000 <test_align_fail_data>:
0: e12fff1e bx lr
4: aa .byte 0xaa
5: 00 .byte 0x00
6: 0000 .short 0x0000
8: 12345678 eorsne r5, r4, #120, 12 ; 0x7800000
As a result the word 0x12345678 will be stored in LE.
I've run several tests and here are my observations:
- Double ".align" fixes the issue :)
- Behavior is the same for LE/BE, ARM/Thumb, GCC 4.4.1/4.6.x/4.8.2
- Size of alignment doesn't matter.
- Issue happens only if previous data is not instruction-aligned and
0's are added before NOPs.
- Explicit filling with 0's (.align , 0) fixes the issue, but as a side
effect data @0x4 is interpreted as a single ".word 0xaa000000"
instead of ".byte .byte .short". I'm not sure if there can be any
functional difference because of this.
- Issue doesn't happen if there is no instructions before data
(no "bx lr" in the example).
- Issue doesn't happen if data after .align is defined as
".type <symbol>,%object".
--
Taras Kondratiuk
From: Mark Brown <broonie(a)linaro.org>
If we have control over the LDO then disable it during suspend; the device
is already being put into reset so will be non-functional over suspend
anyway and this will save a small amount of power.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
sound/soc/codecs/rt5640.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
index 641eeeb..b0cde92 100644
--- a/sound/soc/codecs/rt5640.c
+++ b/sound/soc/codecs/rt5640.c
@@ -1979,12 +1979,20 @@ static int rt5640_suspend(struct snd_soc_codec *codec)
rt5640_reset(codec);
regcache_cache_only(rt5640->regmap, true);
regcache_mark_dirty(rt5640->regmap);
+ if (gpio_is_valid(rt5640->pdata.ldo1_en))
+ gpio_set_value_cansleep(rt5640->pdata.ldo1_en, 0);
return 0;
}
static int rt5640_resume(struct snd_soc_codec *codec)
{
+ struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec);
+
+ if (gpio_is_valid(rt5640->pdata.ldo1_en)) {
+ gpio_set_value_cansleep(rt5640->pdata.ldo1_en, 1);
+ msleep(400);
+ }
rt5640_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
return 0;
--
1.8.4.rc3
This patchset adds support for using Big Endian mode of AArch64 CPUs
All patches have been tested on APM X-Gene Storm SOC.
The Big Endian toolchain used for development can be found at:
http://cbuild.validation.linaro.org/snapshots/big_endian
We have tested both 32bit BE and 64bit BE root filesystems with these
patches.
The 64bit BE root filesystem was build manually using busybox-1.21.1 and
above mentioned toolchain.
The 32bit BE root filesystem was readily available from Linaro releases
located at: http://snapshots.linaro.org/openembedded/images
Ankit Jindal (4):
ARM64: Add Kconfig option to enable Big Endian kernel
ARM64: Include appropriate byteorder for Big Endian
ARM64: Big Endian fixes for kernel booting
ARM64: Support for 32-bit big endian userspace
arch/arm64/Kconfig | 2 ++
arch/arm64/Makefile | 7 +++++++
arch/arm64/include/asm/assembler.h | 7 +++++++
arch/arm64/include/asm/processor.h | 3 +++
arch/arm64/include/uapi/asm/byteorder.h | 4 ++++
arch/arm64/kernel/head.S | 34 +++++++++++++++++++++++++++++++
arch/arm64/kernel/setup.c | 19 +++++++++++++----
arch/arm64/kernel/signal32.c | 4 ++++
arch/arm64/kernel/smp_spin_table.c | 5 +++--
arch/arm64/mm/Kconfig | 7 +++++++
arch/arm64/mm/proc.S | 2 +-
11 files changed, 87 insertions(+), 7 deletions(-)
create mode 100644 arch/arm64/mm/Kconfig
--
1.7.9.5
Hi All,
This is version 2 of cci big endian fix. Idea of this
way of fixing was suggested by Ben Dooks [1]. Compared to
previous solution this one does not use ifdefs and looks
much cleaner.
This was tested on TC2 both LE and BE, CONFIG_ARM_CCI
was enabled.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203248.h…
Thanks,
Victor
Victor Kamensky (1):
ARM: cci driver need big endian fixes in asm code
drivers/bus/arm-cci.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--
1.8.1.4
This patch series enables ECC edac support for Calxeda ECX-2000
(Midway). The ECX-2000 memory controller is similar to Highbank but
has different register bases for error and interrupt registers.
Testing the driver uncovered a bug in the interrupt initialization.
So there is also a fix for this for all the Highbank edac drivers. The
interrupt was enabled too early which caused a crash if there are
interrupts pending (ECC errors) during driver initialization.
Also some improvements and unification of edac log messages I found
useful.
-Robert
Rob Herring (1):
ARM: dts: calxeda: move memory-controller node out of ecx-common.dtsi
Robert Richter (4):
edac, highbank: Fix interrupt setup of mem and l2 controller
edac, highbank: Add Calxeda ECX-2000 support
edac, highbank: Improve and unify naming
edac: Unify reporting of device info for device, mc and pci
.../devicetree/bindings/arm/calxeda/mem-ctrlr.txt | 4 +-
arch/arm/boot/dts/ecx-2000.dts | 6 +
arch/arm/boot/dts/ecx-common.dtsi | 6 -
arch/arm/boot/dts/highbank.dts | 6 +
drivers/edac/edac_device.c | 9 +-
drivers/edac/edac_mc.c | 6 +-
drivers/edac/edac_pci.c | 8 +-
drivers/edac/highbank_l2_edac.c | 33 +++---
drivers/edac/highbank_mc_edac.c | 128 +++++++++++++--------
9 files changed, 127 insertions(+), 79 deletions(-)
--
1.8.4.rc3
From: Mark Brown <broonie(a)linaro.org>
Commit 2353c1f800 (arm: ipi raise/start/end tracing) added tracepoints for
IPIs in the generic GIC driver but only added definitions for them on ARM,
causing build failures on ARM64. Fix this by adding equivalent definitions
for arm64.
Signed-off-by: Mark Brown <broonie(a)linaro.org>
---
arch/arm64/kernel/smp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 5d54e37..a28d285 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -48,6 +48,9 @@
#include <asm/tlbflush.h>
#include <asm/ptrace.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/arm-ipi.h>
+
/*
* as from 2.5, kernels no longer have an init_tasks structure
* so we need some other way of telling a new secondary core
--
1.8.4.rc3
'dev_id' in the comments of clk_register_clkdev should
be 'dev_fmt' here.
Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org>
---
drivers/clk/clkdev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 442a313..825b52b 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -270,9 +270,9 @@ EXPORT_SYMBOL(clkdev_drop);
* clk_register_clkdev - register one clock lookup for a struct clk
* @clk: struct clk to associate with all clk_lookups
* @con_id: connection ID string on device
- * @dev_id: format string describing device name
+ * @dev_fmt: format string describing device name
*
- * con_id or dev_id may be NULL as a wildcard, just as in the rest of
+ * con_id or dev_fmt may be NULL as a wildcard, just as in the rest of
* clkdev.
*
* To make things easier for mass registration, we detect error clks
--
1.7.9.5
The memory pinning code in uaccess_with_memcpy.c does not check
for HugeTLB or THP pmds, and will enter an infinite loop should
a __copy_to_user or __clear_user occur against a huge page.
This patch adds detection code for huge pages to pin_page_for_write.
As this code can be executed in a fast path it refers to the actual
pmds rather than the vma. If a HugeTLB or THP is found (they have
the same pmd representation on ARM), the page table spinlock is
taken to prevent modification whilst the page is pinned.
On ARM, huge pages are only represented as pmds, thus no huge pud
checks are performed. (For huge puds one would lock the page table
in a similar manner as in the pmd case).
Two helper functions are introduced; pmd_thp_or_huge will check
whether or not a page is huge or transparent huge (which have the
same pmd layout on ARM), and pmd_hugewillfault will detect whether
or not a page fault will occur on write to the page.
Running the following test (with the chunking from read_zero
removed):
$ dd if=/dev/zero of=/dev/null bs=10M count=1024
Gave: 2.3 GB/s backed by normal pages,
2.9 GB/s backed by huge pages,
5.1 GB/s backed by huge pages, with page mask=HPAGE_MASK.
After some discussion, it was decided not to adopt the HPAGE_MASK,
as this would have a significant detrimental effect on the overall
system latency due to page_table_lock being held for too long.
This could be revisited if split huge page locks are adopted.
Signed-off-by: Steve Capper <steve.capper(a)linaro.org>
---
Changes in V3:
pmd_hugewillfault and pmd_thp_or_huge were erroneously ommitted from
pgtable-2level.h causing build problems. Empty stubs are added for now
as we don't have huge page support for short descriptors.
Nicolas, can I please re-add your Reviewed-by to this?
---
arch/arm/include/asm/pgtable-2level.h | 7 ++++++
arch/arm/include/asm/pgtable-3level.h | 3 +++
arch/arm/lib/uaccess_with_memcpy.c | 41 ++++++++++++++++++++++++++++++++---
3 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/pgtable-2level.h b/arch/arm/include/asm/pgtable-2level.h
index f97ee02..86a659a 100644
--- a/arch/arm/include/asm/pgtable-2level.h
+++ b/arch/arm/include/asm/pgtable-2level.h
@@ -181,6 +181,13 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
#define set_pte_ext(ptep,pte,ext) cpu_set_pte_ext(ptep,pte,ext)
+/*
+ * We don't have huge page support for short descriptors, for the moment
+ * define empty stubs for use by pin_page_for_write.
+ */
+#define pmd_hugewillfault(pmd) (0)
+#define pmd_thp_or_huge(pmd) (0)
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_PGTABLE_2LEVEL_H */
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index 5689c18..39c54cf 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -206,6 +206,9 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
#define __HAVE_ARCH_PMD_WRITE
#define pmd_write(pmd) (!(pmd_val(pmd) & PMD_SECT_RDONLY))
+#define pmd_hugewillfault(pmd) (!pmd_young(pmd) || !pmd_write(pmd))
+#define pmd_thp_or_huge(pmd) (pmd_huge(pmd) || pmd_trans_huge(pmd))
+
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_trans_huge(pmd) (pmd_val(pmd) && !(pmd_val(pmd) & PMD_TABLE_BIT))
#define pmd_trans_splitting(pmd) (pmd_val(pmd) & PMD_SECT_SPLITTING)
diff --git a/arch/arm/lib/uaccess_with_memcpy.c b/arch/arm/lib/uaccess_with_memcpy.c
index 025f742..3e58d71 100644
--- a/arch/arm/lib/uaccess_with_memcpy.c
+++ b/arch/arm/lib/uaccess_with_memcpy.c
@@ -18,6 +18,7 @@
#include <linux/hardirq.h> /* for in_atomic() */
#include <linux/gfp.h>
#include <linux/highmem.h>
+#include <linux/hugetlb.h>
#include <asm/current.h>
#include <asm/page.h>
@@ -40,7 +41,35 @@ pin_page_for_write(const void __user *_addr, pte_t **ptep, spinlock_t **ptlp)
return 0;
pmd = pmd_offset(pud, addr);
- if (unlikely(pmd_none(*pmd) || pmd_bad(*pmd)))
+ if (unlikely(pmd_none(*pmd)))
+ return 0;
+
+ /*
+ * A pmd can be bad if it refers to a HugeTLB or THP page.
+ *
+ * Both THP and HugeTLB pages have the same pmd layout
+ * and should not be manipulated by the pte functions.
+ *
+ * Lock the page table for the destination and check
+ * to see that it's still huge and whether or not we will
+ * need to fault on write, or if we have a splitting THP.
+ */
+ if (unlikely(pmd_thp_or_huge(*pmd))) {
+ ptl = ¤t->mm->page_table_lock;
+ spin_lock(ptl);
+ if (unlikely(!pmd_thp_or_huge(*pmd)
+ || pmd_hugewillfault(*pmd)
+ || pmd_trans_splitting(*pmd))) {
+ spin_unlock(ptl);
+ return 0;
+ }
+
+ *ptep = NULL;
+ *ptlp = ptl;
+ return 1;
+ }
+
+ if (unlikely(pmd_bad(*pmd)))
return 0;
pte = pte_offset_map_lock(current->mm, pmd, addr, &ptl);
@@ -94,7 +123,10 @@ __copy_to_user_memcpy(void __user *to, const void *from, unsigned long n)
from += tocopy;
n -= tocopy;
- pte_unmap_unlock(pte, ptl);
+ if (pte)
+ pte_unmap_unlock(pte, ptl);
+ else
+ spin_unlock(ptl);
}
if (!atomic)
up_read(¤t->mm->mmap_sem);
@@ -147,7 +179,10 @@ __clear_user_memset(void __user *addr, unsigned long n)
addr += tocopy;
n -= tocopy;
- pte_unmap_unlock(pte, ptl);
+ if (pte)
+ pte_unmap_unlock(pte, ptl);
+ else
+ spin_unlock(ptl);
}
up_read(¤t->mm->mmap_sem);
--
1.8.1.4
Hi Mark, Alex
I have some big.LITTLE MP updates from ARM for LSK can you please pull
these for this month's LSK release? I believe these go into the LSK
topic branch v3.10/topic/big.LITTLE.
Thanks
--
Tixy
The following changes since commit 7ac3860c98608e2f9782902b4439e0ade53c2364:
Merge tag 'big-LITTLE-MP-13.08' into for-lsk (2013-09-05 18:17:48 +0100)
are available in the git repository at:
git://git.linaro.org/arm/big.LITTLE/mp.git for-lsk
for you to fetch changes up to 68f98fec62bada031c89ee61b5bccd61914c23c3:
Merge tag 'big-LITTLE-MP-13.10' into for-lsk (2013-10-11 17:12:02 +0100)
----------------------------------------------------------------
Chris Redpath (7):
sched: HMP: Change default HMP thresholds
sched: HMP: Additional trace points for debugging HMP behaviour
arm: ipi raise/start/end tracing
smp: smp_cross_call function pointer tracing
sched: HMP: fix potential logical errors
hmp: Remove potential for task_struct access race
HMP: Implement task packing for small tasks in HMP systems
Jon Medhurst (1):
Merge tag 'big-LITTLE-MP-13.10' into for-lsk
arch/arm/Kconfig | 12 ++
arch/arm/kernel/smp.c | 5 +
drivers/irqchip/irq-gic.c | 5 +-
include/trace/events/arm-ipi.h | 100 +++++++++++++
include/trace/events/sched.h | 72 ++++++++++
include/trace/events/smp.h | 91 ++++++++++++
kernel/sched/fair.c | 302 +++++++++++++++++++++++++++++-----------
kernel/smp.c | 12 +-
8 files changed, 514 insertions(+), 85 deletions(-)
create mode 100644 include/trace/events/arm-ipi.h
create mode 100644 include/trace/events/smp.h