| Age | Commit message (Collapse) | Author |
|---|
|
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into linux-linaro-lsk-v3.18
* 'linux-3.18.y' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (172 commits)
Linux 3.18.16
arch/x86/kvm/mmu.c: work around gcc-4.4.4 bug
md/raid0: fix restore to sector variable in raid0_make_request
Linux 3.18.15
ARM: OMAP3: Fix booting with thumb2 kernel
xfrm: release dst_orig in case of error in xfrm_lookup()
ARC: unbork !LLSC build
power/reset: at91: fix return value check in at91_reset_platform_probe()
vfs: read file_handle only once in handle_to_path
drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling"
drm/radeon: don't share plls if monitors differ in audio support
drm/radeon: retry dcpd fetch
drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling
drm/radeon: add new bonaire pci id
iwlwifi: pcie: prevent using unmapped memory in fw monitor
ACPI / init: Fix the ordering of acpi_reserve_resources()
sd: Disable support for 256 byte/sector disks
storvsc: Set the SRB flags correctly when no data transfer is needed
rtlwifi: rtl8192cu: Fix kernel deadlock
md/raid5: don't record new size if resize_stripes fails.
...
|
|
We get a NULL pointer dereference on omap3 for thumb2 compiled kernels:
Internal error: Oops: 80000005 [#1] SMP THUMB2
...
[<c046497b>] (_raw_spin_unlock_irqrestore) from [<c0024375>]
(omap3_enter_idle_bm+0xc5/0x178)
[<c0024375>] (omap3_enter_idle_bm) from [<c0374e63>]
(cpuidle_enter_state+0x77/0x27c)
[<c0374e63>] (cpuidle_enter_state) from [<c00627f1>]
(cpu_startup_entry+0x155/0x23c)
[<c00627f1>] (cpu_startup_entry) from [<c06b9a47>]
(start_kernel+0x32f/0x338)
[<c06b9a47>] (start_kernel) from [<8000807f>] (0x8000807f)
The power management related assembly on omaps needs to interact with
ARM mode bootrom code, so we need to keep most of the related assembly
in ARM mode.
Turns out this error is because of missing ENDPROC for assembly code
as suggested by Stephen Boyd <sboyd@codeaurora.org>. Let's fix the
problem by adding ENDPROC in two places to sleep34xx.S.
Let's also remove the now duplicate custom code for mode switching.
This has been unnecessary since commit 6ebbf2ce437b ("ARM: convert
all "mov.* pc, reg" to "bx reg" for ARMv6+").
And let's also remove the comments about local variables, they are
now just confusing after the ENDPROC.
The reason why ENDPROC makes a difference is it sets .type and then
the compiler knows what to do with the thumb bit as explained at:
https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
Reported-by: Kevin Hilman <khilman@kernel.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
(cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693)
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a ]
Josh Stone reports:
I've discovered a case where both arm and arm64 will miss a ptrace
syscall-exit that they should report. If the syscall is entered
without TIF_SYSCALL_TRACE set, then it goes on the fast path. It's
then possible to have TIF_SYSCALL_TRACE added in the middle of the
syscall, but ret_fast_syscall doesn't check this flag again.
Fix this by always checking for a syscall trace in the fast exit path.
Reported-by: Josh Stone <jistone@redhat.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit a29ef819f3f34f89a1b9b6a939b4c1cdfe1e85ce ]
According to the imx27 documentation, fec has a 4 Kbyte
memory space map. Moreover, the actual 16 Kbyte mapping
overlaps the SCC (Security Controller) memory register
space. So, we reduce the memory register space to 4 Kbyte.
Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Fixes: 9f0749e3eb88 ("ARM i.MX27: Add devicetree support")
Cc: <stable@vger.kernel.org>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 965278dcb8ab0b1f666cc47937933c4be4aea48d ]
At boot time we round the memblock limit down to section size in an
attempt to ensure that we will have mapped this RAM with section
mappings prior to allocating from it. When mapping RAM we iterate over
PMD-sized chunks, creating these section mappings.
Section mappings are only created when the end of a chunk is aligned to
section size. Unfortunately, with classic page tables (where PMD_SIZE is
2 * SECTION_SIZE) this means that if a chunk is between 1M and 2M in
size the first 1M will not be mapped despite having been accounted for
in the memblock limit. This has been observed to result in page tables
being allocated from unmapped memory, causing boot-time hangs.
This patch modifies the memblock limit rounding to always round down to
PMD_SIZE instead of SECTION_SIZE. For classic MMU this means that we
will round the memblock limit down to a 2M boundary, matching the limits
on section mappings, and preventing allocations from unmapped memory.
For LPAE there should be no change as PMD_SIZE == SECTION_SIZE.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Acked-by: Laura Abbott <labbott@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Steve Capper <steve.capper@linaro.org>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
This patch is a partial backport of commit ef01c6c36bb8 ("ARM: mvebu:
remove Armada 375 Z1 workaround for I/O coherency"). This commit was
merged in v3.19, so kernel versions later than v3.19 are not affected
by the problem that this commit fixes.
It does not make a lot of sense to backport this commit entirely,
since it is mainly removing some no longer useful code. However, this
commit is also making sure that the bus_register_notifier that
register the custom DMA operations that should be used for HW I/O
coherency does not get registered when said HW I/O coherency is not
enabled.
This is particularly critical since we have decided to disable HW I/O
coherency completely in all kernels < 4.0, to be on the safe side,
while experimenting a new implementation of the HW I/O coherency in >=
4.0.
Without this commit, kernels earlier than 3.18 have the custom DMA
operations normally used for HW I/O coherency registered (they don't
do cache maintenance operations), while HW I/O coherency is
disabled. It essentially causes every DMA transfer to transfer
garbage.
The issue fixed by this commit was introduced by 5ab5afd8ba83 ("ARM:
mvebu: implement Armada 375 coherency workaround"), but it was not
visible until now since it didn't cause any problem when HW I/O
coherency is enabled.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> v3.16..v3.18
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit c097877319ab61dd045b6497953b4e3df8f2bb44 ]
arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI
calling code to fire, so move the ARM PSCI calls out of line into their
own assembly file for consistency and to safeguard against the same
issue occuring with the 32-bit toolchain.
[will: brought into line with arm64 implementation]
Reported-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 11133db7a836b0cb411faa048f07a38e994d1382 ]
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit f9a8c3914ba85f19c3360b19612d77c47adb8942 ]
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 53d2669844263fd5fdc70f0eb6a2eb8a21086d8e ]
The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but
instead it's specific to the board. Move the definition of it, into the
board DTSs.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 19fc99d0c6ba7d9b65456496b5bb2169d5f74cd0 ]
In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch)
and loading rm first into ARM_R0 will result in jit_udiv() function
being called the same dividend and divisor. Fix that by loading rn
first into ARM_R1 and then rm into ARM_R0.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Cc: <stable@vger.kernel.org> # v3.13+
Fixes: aee636c4809f (bpf: do not use reciprocal divide)
Acked-by: Mircea Gherzan <mgherzan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 102bcb6ed2d1c3ffcc7269afc957c2df11942085 ]
If we use a combination of VMODE and I2C4 for retention modes,
eventually the off idle power consumption will creep up by about
23mW, even during off mode with I2C4 always staying enabled.
Turns out this is because of erratum i531 "Extra Power Consumed
When Repeated Start Operation Mode Is Enabled on I2C Interface
Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth
Menon <nm@ti.com>.
Let's fix the issue by adding i2c_cfg_clear_mask for the bits
to clear when initializing the I2C4 adapter so we can clear
SREN bit that drives the I2C4 lines low otherwise when there
is no traffic.
Fixes: 3b8c4ebb7630 ("ARM: OMAP3: Fix idle mode signaling for
Cc: stable@vger.kernel.org # v3.16+
sys_clkreq and sys_off_mode")
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 750e30d4076ae5e02ad13a376e96c95a2627742c ]
There is no crystal connected to the internal RTC on the Open Block
AX3. So let's disable it in order to prevent the kernel probing the
driver uselessly. Eventually this patches removes the following
warning message from the boot log:
"rtc-mv d0010300.rtc: internal RTC not ticking"
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.8 +
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit cfe8c59762244251fd9a5e281d48808095ff4090 ]
On imx23-olinuxino the LED turns on when level logic high is aplied to
GPIO2_1.
Fix the gpios property accordingly.
Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 0fdebe1a2f4d3a8fc03754022fabf8ba95e131a3 ]
The dr_mode of usb0 on imx233-olinuxino is left to default "otg".
Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the
same pin as USB_OTG_ID it's possible to disable USB host by LED toggling:
echo 0 > /sys/class/leds/green/brightness
[ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1
[ 1068.890000] usb usb1: USB disconnect, device number 1
[ 1068.920000] usb 1-1: USB disconnect, device number 2
[ 1068.920000] usb 1-1.1: USB disconnect, device number 3
[ 1069.070000] usb 1-1.2: USB disconnect, device number 4
[ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11
This patch fixes the issue by setting dr_mode to "host" in the dts file.
Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Peter Chen <peter.chen@freescale.com>
Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 4ada77e37a773168fea484899201e272ab44ba8b ]
Fix a typo in the TX DMA interrupt name for AUART4.
This patch makes AUART4 operational again.
Signed-off-by: Marek Vasut <marex@denx.de>
Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma")
Cc: stable@vger.kernel.org
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 7f8d49dcc66a3dd3a8fc3078330b8fb9e616ad3f ]
The fixed-regulator bindings require a separate property enable-active-high,
the standard gpio phandle property polarity setting is ignored.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Fixes: 4fe69a934b1f ("ARM: dts: Add Phytec pfla02 with i.MX6 DualLite/Solo")
Cc: stable@vger.kernel.org
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit f90d3f0d0a11fa77918fd5497cb616dd2faa8431 ]
The property '#pwm-cells' is currently missing. It is not possible to
use pwm4 without this property.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree")
Cc: <stable@vger.kernel.org>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 1819e3034ee26ffadc71880064ed8b8e7d74f52c ]
N900 audio recording needs that codec provides bias voltage for integrated
digital microphone and headset microphone depending which one is used.
Digital microphone uses 2 V bias and it comes from the codec A part. Codec
B part drives the headset microphone bias and that is set to 2.5 V.
Cc: stable@vger.kernel.org # v3.16+
Signed-off-by: Pavel Machek <pavel@ucw.cz>
[Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit
e2e8bfdf6157 ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")]
Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
* v3.18/topic/for-stable:
ARM: 8221/1: PJ4: allow building in Thumb-2 mode
|
|
Two files that get included when building the multi_v7_defconfig target
fail to build when selecting THUMB2_KERNEL for this configuration.
In both cases, we can just build the file as ARM code, as none of its
symbols are exported to modules, so there are no interworking concerns.
In the iwmmxt.S case, add ENDPROC() declarations so the symbols are
annotated as functions, resulting in the linker to emit the appropriate
mode switches.
Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 13d1b9575ac2c2da143cd2236b6cf0fc314570f8)
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into linux-linaro-lsk-v3.18
* 'linux-3.18.y' of git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (222 commits)
Linux 3.18.14
Drivers: hv: vmbus: Don't wait after requesting offers
hfsplus: don't store special "osx" xattr prefix on-disk
drm/radeon: check new address before removing old one
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
drm/radeon: adjust pll when audio is not enabled
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: move check under lock scope to close a race.
ext4: fix data corruption caused by unwritten and delayed extents
uas: Set max_sectors_240 quirk for ASM1053 devices
uas: Add US_FL_MAX_SECTORS_240 flag
uas: Allow uas_use_uas_driver to return usb-storage flags
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ACPI / SBS: Enable battery manager when present
btrfs: unlock i_mutex after attempting to delete subvolume during send
ASoC: rt5677: fixed wrong DMIC ref clock
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
...
|
|
Conflicts:
arch/arm/boot/dts/Makefile
arch/arm64/boot/dts/Makefile
scripts/Makefile.lib
Conflict:
The android tree added some Kconfig options for building DTB-appended images
by default, including the option of specifying multiple DTBs. This conflicted
with the backport of the upstream commits to move arm64 DTBs to vendor-specific
subdirs.
Resolution:
Gently merge the two approaches, modified the new DTB_OBJS rules in
arch/arm64/boot/Makefile to find the .dtb file in vendor specific subdirs.
|
|
* v3.18/topic/coresight:
ARM: Kconfig.debug: OC_ETM and CORESIGHT are mutually exclusive
|
|
The android tree still has the legacy ETM driver, but it cannot
coexist with the new Coresight driver, so make sure they are mutually
exclusive at compile time.
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
* v3.18/topic/coresight:
Revert "ARM: removing support for etb/etm in "arch/arm/kernel/""
|
|
This reverts commit 912822468977962f8d510b170de61809ccb3d5e5.
Leave the legacy driver in for LSK because Android uses it.
|
|
[ Upstream commit 97534127012f0e396eddea4691f4c9b170aed74b ]
Commit 61f77eda9bbf ("mm/hugetlb: reduce arch dependent code around
follow_huge_*") broke follow_huge_pmd() on s390, where pmd and pte
layout differ and using pte_page() on a huge pmd will return wrong
results. Using pmd_page() instead fixes this.
All architectures that were touched by that commit have pmd_page()
defined, so this should not break anything on other architectures.
Fixes: 61f77eda "mm/hugetlb: reduce arch dependent code around follow_huge_*"
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Acked-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Michal Hocko <mhocko@suse.cz>, Andrea Arcangeli <aarcange@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit a74cd13b807029397f7232449df929bac11fb228 ]
Fix Dove's register addresses of uart2 and uart3 nodes that seem to
be broken since ages due to a copy-and-paste error.
Cc: <stable@vger.kernel.org> # 3.7+
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 4e330ae4ab2915444f1e6dca1358a910aa259362 ]
There are two PMICs on Cragganmore, currently one dynamically assign
its IRQ base and the other uses a fixed base. It is possible for the
statically assigned PMIC to fail if its IRQ is taken by the dynamically
assigned one. Fix this by statically assigning both the IRQ bases.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Kukjin Kim <kgene@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 548ae94c1cc7fc120848757249b9a542b1080ffb ]
On Armada 38x SoCs, under heavy I/O load, the system hangs when CPU
Idle is enabled. Waiting for a solution to this issue, this patch
disables the CPU Idle support for this SoC.
As CPU Hot plug support also uses some of the CPU Idle functions it is
also affected by the same issue. This patch disables it also for the
Armada 38x SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v3.17 +
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 8defb3367fcd19d1af64c07792aade0747b54e0f ]
Usually ELF_ET_DYN_BASE is 2/3 of TASK_SIZE. With 3G/1G user/kernel
split this is not so, because 2*TASK_SIZE overflows 32 bits,
so the actual value of ELF_ET_DYN_BASE is:
(2 * TASK_SIZE / 3) = 0x2a000000
When ASLR is disabled PIE binaries will load at ELF_ET_DYN_BASE address.
On 32bit platforms AddressSanitzer uses addresses [0x20000000 - 0x40000000]
for shadow memory [1]. So ASan doesn't work for PIE binaries when ASLR disabled
as it fails to map shadow memory.
Also after Kees's 'split ET_DYN ASLR from mmap ASLR' patchset PIE binaries
has a high chance of loading somewhere in between [0x2a000000 - 0x40000000]
even if ASLR enabled. This makes ASan with PIE absolutely incompatible.
Fix overflow by dividing TASK_SIZE prior to multiplying.
After this patch ELF_ET_DYN_BASE equals to (for CONFIG_VMSPLIT_3G=y):
(TASK_SIZE / 3 * 2) = 0x7f555554
[1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm#Mapping
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Reported-by: Maria Guseva <m.guseva@samsung.com>
Cc: stable@vger.kernel.org
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit 767bf7e7a1e82a81c59778348d156993d0a6175d ]
Normally, when a CPU wants to clear a cache line to zero in the external
L2 cache, it would generate bus cycles to write each word as it would do
with any other data access.
However, a Cortex A9 connected to a L2C-310 has a specific feature where
the CPU can detect this operation, and signal that it wants to zero an
entire cache line. This feature, known as Full Line of Zeros (FLZ),
involves a non-standard AXI signalling mechanism which only the L2C-310
can properly interpret.
There are separate enable bits in both the L2C-310 and the Cortex A9 -
the L2C-310 needs to be enabled and have the FLZ enable bit set in the
auxiliary control register before the Cortex A9 has this feature
enabled.
Unfortunately, the suspend code was not respecting this - it's not
obvious from the code:
swsusp_arch_suspend()
cpu_suspend() /* saves the Cortex A9 auxiliary control register */
arch_save_image()
soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
At this point, we end up with the L2C disabled, but the Cortex A9 with
FLZ enabled - which means any memset() or zeroing of a full cache line
will fail to take effect.
A similar issue exists in the resume path, but it's slightly more
complex:
swsusp_arch_suspend()
cpu_suspend() /* saves the Cortex A9 auxiliary control register */
arch_save_image() /* image with A9 auxcr saved */
...
swsusp_arch_resume()
call_with_stack()
arch_restore_image() /* restores image with A9 auxcr saved above */
soft_restart() /* turns off FLZ in Cortex A9, and disables L2C */
cpu_resume() /* restores the Cortex A9 registers, inc auxcr */
Again, here we end up with the L2C disabled, but Cortex A9 FLZ enabled.
There's no need to turn off the L2C in either of these two paths; there
are benefits from not doing so - for example, the page copies will be
faster with the L2C enabled.
Hence, fix this by providing a variant of soft_restart() which can be
used without turning the L2 cache controller off, and use it in both
of these paths to keep the L2C enabled across the respective resume
transitions.
Fixes: 8ef418c7178f ("ARM: l2c: trial at enabling some Cortex-A9 optimisations")
Reported-by: Sean Cross <xobs@kosagi.com>
Tested-by: Sean Cross <xobs@kosagi.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
[ Upstream commit fd1d0ddf2ae92fb3df42ed476939861806c5d785 ]
When userland injects a SPI via the KVM_IRQ_LINE ioctl we currently
only check it against a fixed limit, which historically is set
to 127. With the new dynamic IRQ allocation the effective limit may
actually be smaller (64).
So when now a malicious or buggy userland injects a SPI in that
range, we spill over on our VGIC bitmaps and bytemaps memory.
I could trigger a host kernel NULL pointer dereference with current
mainline by injecting some bogus IRQ number from a hacked kvmtool:
-----------------
....
DEBUG: kvm_vgic_inject_irq(kvm, cpu=0, irq=114, level=1)
DEBUG: vgic_update_irq_pending(kvm, cpu=0, irq=114, level=1)
DEBUG: IRQ #114 still in the game, writing to bytemap now...
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = ffffffc07652e000
[00000000] *pgd=00000000f658b003, *pud=00000000f658b003, *pmd=0000000000000000
Internal error: Oops: 96000006 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1053 Comm: lkvm-msi-irqinj Not tainted 4.0.0-rc7+ #3027
Hardware name: FVP Base (DT)
task: ffffffc0774e9680 ti: ffffffc0765a8000 task.ti: ffffffc0765a8000
PC is at kvm_vgic_inject_irq+0x234/0x310
LR is at kvm_vgic_inject_irq+0x30c/0x310
pc : [<ffffffc0000ae0a8>] lr : [<ffffffc0000ae180>] pstate: 80000145
.....
So this patch fixes this by checking the SPI number against the
actual limit. Also we remove the former legacy hard limit of
127 in the ioctl code.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
CC: <stable@vger.kernel.org> # 4.0, 3.19, 3.18
[maz: wrap KVM_ARM_IRQ_GIC_MAX with #ifndef __KERNEL__,
as suggested by Christopher Covington]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
* v3.18/topic/for-stable:
arm64: psci: move psci firmware calls out of line
ARM: 8307/1: psci: move psci firmware calls out of line
Conflicts:
arch/arm64/kernel/Makefile
|
|
arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI
calling code to fire, so move the ARM PSCI calls out of line into their
own assembly file for consistency and to safeguard against the same
issue occuring with the 32-bit toolchain.
[will: brought into line with arm64 implementation]
Reported-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit c097877319ab61dd045b6497953b4e3df8f2bb44)
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
* v3.18/topic/arm64-dt:
arm64: Create link to include/dt-bindings to enable C preprocessor use.
dts, arm64: Move dts files to vendor subdirs
dts, kbuild: Implement support for dtb vendor subdirs
dts, arm/arm64: Remove dtbs build rules in sub-makes
dts, kbuild: Factor out dtbs install rules to Makefile.dtbinst
dts, arm64: Add dtbs_install make target
|
|
Add dtb files to build targets and let kbuild handle them. Thus,
special dtbs rules can be removed. This eases Makefiles and the
implementation of the support of vendor dtb subdirectories.
Signed-off-by: Robert Richter <rrichter@cavium.com>
(cherry picked from commit d38726c485d3fd6e9f2ebd1adaef0c3ead48a5ac)
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
Move dtbs install rules to Makefile.dtbinst. This change is needed to
implement support for dts vendor subdirs. The change makes Makefiles
easier and smaller as no longer the dtbs_install rule needs to be
defined. Another advantage is that install goals are not encoded in
targets anymore (%.dtb_dtbinst_).
Signed-off-by: Robert Richter <rrichter@cavium.com>
(cherry picked from commit 9fb5e5372208973984a23ee6f5f025c05d364633)
Signed-off-by: Kevin Hilman <khilman@linaro.org>
|
|
* v3.18/topic/coresight: (42 commits)
coresight: moving to new "hwtracing" directory
coresight-tmc: Adding a status interface to sysfs
coresight: remove the unnecessary configuration coresight-default-sink
coresight: adding the LINKSINK block as a sink type
coresight: Correcting documentation typographical error
coresight: Adding coresight support for arm64 architecture
coresight: fixing compilation warnings picked up by 64bit compiler
coresight: making cpu index lookup arm64 compliant
coresight: fix function etm_writel_cp14() parameter order
coresight-etm: remove check for unknown Kconfig macro
coresight: fixing CPU hwid lookup in device tree
coresight: remove the unnecessary function coresight_is_bit_set()
coresight: fix the debug AMBA bus name
coresight: remove the extra spaces
coresight: fix the link between orphan connection and newly added device
coresight: remove the unnecessary replicator property
coresight: fix the replicator subtype value
coresight: fixing validity check on remote device
coresight: fix comment in of_coresight.c
coresight: Fixing wrong #ifdef/#endif placement
...
|
|
https://android.googlesource.com/kernel/common into linux-linaro-lsk-v3.18-android
* 'android-3.18' of https://android.googlesource.com/kernel/common: (560 commits)
nf: IDLETIMER: Fix broken uid field in the msg
UPSTREAM: staging: android: Assign bool to true
UPSTREAM: Staging: android: ion: fix typos in comments
UPSTREAM: staging: android: ion: Replace "the the " with "the"
usb: gadget: Do not disconnect unregistered dev
ipv4: Missing sk_nulls_node_init() in ping_unhash().
arm64: fix ftrace due to bad cherry-picks from mainline v3.19
SELinux: ss: Fix policy write for ioctl operations
nf: IDLETIMER: Adds the uid field in the msg
arm64: ptrace: add NT_ARM_SYSTEM_CALL regset
android: configs: Enable SELinux and its dependencies.
arm64: add seccomp support
arm64: add SIGSYS siginfo for compat task
arm64: add seccomp syscall for compat task
asm-generic: add generic seccomp.h for secure computing mode 1
arm64: ptrace: allow tracer to skip a system call
arm64: entry: avoid writing lr explicitly for constructing return paths
Revert "arm64: ptrace: add PTRACE_SET_SYSCALL"
Revert "arm64: ptrace: allow tracer to skip a system call"
Revert "asm-generic: add generic seccomp.h for secure computing mode 1"
...
Conflicts:
arch/arm64/include/asm/cpufeature.h
arch/arm64/kernel/cpuinfo.c
arch/arm64/kernel/setup.c
drivers/clk/clk.c
Conflict Resolution Summary:
Conflict:
Upstream commit 44b82b7700d0 (arm64: Fix up /proc/cpuinfo) exists in
the Android tree as commit 93f223009750 (arm64: Fix up /proc/cpuinfo),
but the android commit has a call to dump_stack_set_arch_desc() in
setup_machine_fdt() that doesn't exist upstream.
Resolution: leave the extra call.
Conflict:
Upstream commit 04597a65c5ef (arm64: Track system support for mixed
endian EL0) picked into Android tree as commit d11d7e575ba2 (arm64:
Track system support for mixed endian EL0) causing some trivial
add-add conflicts between this and the arm64 errata framework which
was pulled in from stable/3.18.y
Resolution: add both sides
Conflict:
Android commit 3a3804ba0a4a (clk: debugfs: Support frequency stats
accounting), which is not upstream, had some trivial add-add conflicts
with upstream commit af33873cc77b (clk: Fix debugfs clk removal before
inited).
Resolution: add both sides
Conflict:
Minor conflict between upstream commit af33873cc77b (clk: Fix debugfs
clk removal before inited) and android commit 3a3804ba0a4a (clk:
debugfs: Support frequency stats accounting) because android commit
applied to upstream before the fix was applied.
Resolution: remove stray comment.
|
|
commit 04b8dc85bf4a64517e3cf20e409eeaa503b15cc1 upstream.
The kernel's pgd_index macro is designed to index a normal, page
sized array. KVM is a bit diffferent, as we can use concatenated
pages to have a bigger address space (for example 40bit IPA with
4kB pages gives us an 8kB PGD.
In the above case, the use of pgd_index will always return an index
inside the first 4kB, which makes a guest that has memory above
0x8000000000 rather unhappy, as it spins forever in a page fault,
whist the host happilly corrupts the lower pgd.
The obvious fix is to get our own kvm_pgd_index that does the right
thing(tm).
Tested on X-Gene with a hacked kvmtool that put memory at a stupidly
high address.
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit a987370f8e7a1677ae385042644326d9cd145a20 upstream.
We're using __get_free_pages with to allocate the guest's stage-2
PGD. The standard behaviour of this function is to return a set of
pages where only the head page has a valid refcount.
This behaviour gets us into trouble when we're trying to increment
the refcount on a non-head page:
page:ffff7c00cfb693c0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x4000000000000000()
page dumped because: VM_BUG_ON_PAGE((*({ __attribute__((unused)) typeof((&page->_count)->counter) __var = ( typeof((&page->_count)->counter)) 0; (volatile typeof((&page->_count)->counter) *)&((&page->_count)->counter); })) <= 0)
BUG: failure at include/linux/mm.h:548/get_page()!
Kernel panic - not syncing: BUG!
CPU: 1 PID: 1695 Comm: kvm-vcpu-0 Not tainted 4.0.0-rc1+ #3825
Hardware name: APM X-Gene Mustang board (DT)
Call trace:
[<ffff80000008a09c>] dump_backtrace+0x0/0x13c
[<ffff80000008a1e8>] show_stack+0x10/0x1c
[<ffff800000691da8>] dump_stack+0x74/0x94
[<ffff800000690d78>] panic+0x100/0x240
[<ffff8000000a0bc4>] stage2_get_pmd+0x17c/0x2bc
[<ffff8000000a1dc4>] kvm_handle_guest_abort+0x4b4/0x6b0
[<ffff8000000a420c>] handle_exit+0x58/0x180
[<ffff80000009e7a4>] kvm_arch_vcpu_ioctl_run+0x114/0x45c
[<ffff800000099df4>] kvm_vcpu_ioctl+0x2e0/0x754
[<ffff8000001c0a18>] do_vfs_ioctl+0x424/0x5c8
[<ffff8000001c0bfc>] SyS_ioctl+0x40/0x78
CPU0: stopping
A possible approach for this is to split the compound page using
split_page() at allocation time, and change the teardown path to
free one page at a time. It turns out that alloc_pages_exact() and
free_pages_exact() does exactly that.
While we're at it, the PGD allocation code is reworked to reduce
duplication.
This has been tested on an X-Gene platform with a 4kB/48bit-VA host
kernel, and kvmtool hacked to place memory in the second page of
the hardware PGD (PUD for the host kernel). Also regression-tested
on a Cubietruck (Cortex-A7).
[ Reworked to use alloc_pages_exact() and free_pages_exact() and to
return pointers directly instead of by reference as arguments
- Christoffer ]
Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit a050dfb21cc22ac0c666d52531040c1bc48184cc upstream.
The check is supposed to catch page-unaligned sizes, not the inverse.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 0d3e4d4fade6b04e933b11e69e80044f35e9cd60 upstream.
When handling a fault in stage-2, we need to resync I$ and D$, just
to be sure we don't leave any old cache line behind.
That's very good, except that we do so using the *user* address.
Under heavy load (swapping like crazy), we may end up in a situation
where the page gets mapped in stage-2 while being unmapped from
userspace by another CPU.
At that point, the DC/IC instructions can generate a fault, which
we handle with kvm->mmu_lock held. The box quickly deadlocks, user
is unhappy.
Instead, perform this invalidation through the kernel mapping,
which is guaranteed to be present. The box is much happier, and so
am I.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 363ef89f8e9bcedc28b976d0fe2d858fe139c122 upstream.
Let's assume a guest has created an uncached mapping, and written
to that page. Let's also assume that the host uses a cache-coherent
IO subsystem. Let's finally assume that the host is under memory
pressure and starts to swap things out.
Before this "uncached" page is evicted, we need to make sure
we invalidate potential speculated, clean cache lines that are
sitting there, or the IO subsystem is going to swap out the
cached view, loosing the data that has been written directly
into memory.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 05971120fca43e0357789a14b3386bb56eef2201 upstream.
It is curently possible to run a VM with architected timers support
without creating an in-kernel VGIC, which will result in interrupts from
the virtual timer going nowhere.
To address this issue, move the architected timers initialization to the
time when we run a VCPU for the first time, and then only initialize
(and enable) the architected timers if we have a properly created and
initialized in-kernel VGIC.
When injecting interrupts from the virtual timer to the vgic, the
current setup should ensure that this never calls an on-demand init of
the VGIC, which is the only call path that could return an error from
kvm_vgic_inject_irq(), so capture the return value and raise a warning
if there's an error there.
We also change the kvm_timer_init() function from returning an int to be
a void function, since the function always succeeds.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 716139df2517fbc3f2306dbe8eba0fa88dca0189 upstream.
When the vgic initializes its internal state it does so based on the
number of VCPUs available at the time. If we allow KVM to create more
VCPUs after the VGIC has been initialized, we are likely to error out in
unfortunate ways later, perform buffer overflows etc.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Eric Auger <eric.auger@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
|
commit 6d3cfbe21bef5b66530b50ad16c88fdc71a04c35 upstream.
VGIC initialization currently happens in three phases:
(1) kvm_vgic_create() (triggered by userspace GIC creation)
(2) vgic_init_maps() (triggered by userspace GIC register read/write
requests, or from kvm_vgic_init() if not already run)
(3) kvm_vgic_init() (triggered by first VM run)
We were doing initialization of some state to correspond with the
state of a freshly-reset GIC in kvm_vgic_init(); this is too late,
since it will overwrite changes made by userspace using the
register access APIs before the VM is run. Move this initialization
earlier, into the vgic_init_maps() phase.
This fixes a bug where QEMU could successfully restore a saved
VM state snapshot into a VM that had already been run, but could
not restore it "from cold" using the -loadvm command line option
(the symptoms being that the restored VM would run but interrupts
were ignored).
Finally rename vgic_init_maps to vgic_init and renamed kvm_vgic_init to
kvm_vgic_map_resources.
[ This patch is originally written by Peter Maydell, but I have
modified it somewhat heavily, renaming various bits and moving code
around. If something is broken, I am to be blamed. - Christoffer ]
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Eric Auger <eric.auger@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
|
