Two more fixes for 4.5:
- One is a fix for OMAP that is urgently needed to avoid DRA7xx chips from
premature aging, by always keeping the Ethernet clock enabled.
- The other solves a I/O memory layout issue on Armada, where SROM and PCI
memory windows were conflicting in some configurations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW4yITAAoJEIwa5zzehBx38BsQAJRjZOeAec3/F+T8+3pnV0Jl
URcyIFBgXQm6AVW9bwrn7bg9GOcWm0hNk4lgQ/E6KgaZpRVJQ+bhqb79Rz45LhCG
7YmxEXtM8zhVY80/AJsEF0vzogfZsPPI3SiGF9OeIwiMEO91hpRMyvFbOqJC2H40
YX17ARv2BTozLJ2PaW9BKoFAJX2uJJqIB6QOi307m3TVFRPQ5qPpVvh43L1+7flF
ntugOzbEhIg1ZENeb0sNMtrhWlsNlQvulJl2xcp3sbXqkj3sPNIHzyvrPXhxOYQI
VFJKHDC1Op6c2PFK8H0iOQMKq+WWuOidjCGwyg5/PNAoQ4cP+AoD0EpEuXXNjh7e
8DlVhCiYNSJl7M88jahHj1pq3X+CxwQraGANHIa0nijKYp4pqOqv+CZA0sgAX5cq
Ro6U5v5XZxgSR6QGwNBtjCxmXC4z9YaYIP/nkCW2zbPQkaeocKYNykOifp1fOI59
VWufA0OTqk1XjVGcYorpgDaLFUAhgc14JEz1VLQGlw1/M+nVVcfr598FtTWrEoNI
C1L2H7ahqKpVRSYCCtUlXg4TipyurjBk3A91mVBVcrSj/A4ztGkqjwMx995KzP+w
HXI7PSulXK/HDupXslUcUCmVwkI5nxhcH7kuk978zwFFyQvDwB+A1mPysR+Naenz
sI0wqCBHKZj70kyFCflm
=/uWT
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Olof Johansson:
"Two more fixes for 4.5:
- One is a fix for OMAP that is urgently needed to avoid DRA7xx chips
from premature aging, by always keeping the Ethernet clock enabled.
- The other solves a I/O memory layout issue on Armada, where SROM
and PCI memory windows were conflicting in some configurations"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window
ARM: dts: dra7: do not gate cpsw clock due to errata i877
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW4xgMAAoJEAhfPr2O5OEVKVAP/1hSigOgCEWrCbXL+mp9xl2P
WXYA87O0ckk6rfIKOi6tv72bkxUlrik9t/F6DIzQejh5SO4IxWeDr8v4iW9Zq+PT
r7ondfq7Sw0VxZfJ/7sulDvtySVBL7V1osJGocrKhtXknmlHdspMX4tuEkB8HYy/
dCpl5yf9ZGYXJrxkRC9rCWFzyEyI8Mg9GE0YORlYYSjaRbl9mYQNQQ6pFjRzlR99
MaPaSfMA7UPQvapyUNplgqHvq8Bo459cLiAL2aR2Z3zdJr8aJvpDYaGBGdzdBIoM
kR55OrDfS/DPX9sou2Xsmty6bMRAynkzI6lGWd5muGfznJ2O5j2s1AY0pkX+wj6O
7S1AfCG8ryi7rvUsfxHkBV6mE2vbKtHU9CnZBIu25B7Dtp2rKNimPh7FqPR6U38h
snWSGNCxayJchAxBBkhXE5BNdCpopLCed6Y9jIQbTelzghNhFKP96APIwHOKvfAq
WmfHT6/diTst7Bu859WS/1UqCf1xIcY6jqofz7El/GIECbAxR6k9eFaPW55tecss
M/60e58U6MLVZxZUqSykKw1bTXq7PeceH5b3dpg1Yv/ST5kNqZZS082rHi1Qpv5o
9llLHIwa/Nu+v4bjeLbiHPOK2VOTcMZp9RAknc4TNRuy3FCX0ntWxGLq24r2FPg+
UzRT+MzaP9slkbb2M80B
=btba
-----END PGP SIGNATURE-----
Merge tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull media fix from Mauro Carvalho Chehab:
"One last time fix: It adds a code that prevents some media tools like
media-ctl to hide some entities that have their IDs out of the range
expected by those apps"
* tag 'media/v4.5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
[media] media-device: map new functions into old types for legacy API
When the Crypto SRAM mappings were added to the Device Tree files
describing the Armada XP boards in commit c466d997bb ("ARM: mvebu:
define crypto SRAM ranges for all armada-xp boards"), the fact that
those mappings were overlaping with the PCIe memory aperture was
overlooked. Due to this, we currently have for all Armada XP platforms
a situation that looks like this:
Memory mapping on Armada XP boards with internal registers at
0xf1000000:
- 0x00000000 -> 0xf0000000 3.75G RAM
- 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
- 0xf1000000 -> 0xf1100000 1M internal registers
- 0xf8000000 -> 0xffe0000 126M PCIe memory aperture
- 0xf8100000 -> 0xf8110000 64KB Crypto SRAM #0 => OVERLAPS WITH PCIE !
- 0xf8110000 -> 0xf8120000 64KB Crypto SRAM #1 => OVERLAPS WITH PCIE !
- 0xffe00000 -> 0xfff00000 1M PCIe I/O aperture
- 0xfff0000 -> 0xffffffff 1M BootROM
The overlap means that when PCIe devices are added, depending on their
memory window needs, they might or might not be mapped into the
physical address space. Indeed, they will not be mapped if the area
allocated in the PCIe memory aperture by the PCI core overlaps with
one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
of PCIe memory will see its PCIe memory window allocated from
0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
to this, the PCIe window is not created, and any attempt to access the
PCIe window makes the kernel explode:
[ 3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
[ 3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
[ 3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
[ 3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018
This problem does not occur on Armada 370 boards, because we use the
following memory mapping (for boards that have internal registers at
0xf1000000):
- 0x00000000 -> 0xf0000000 3.75G RAM
- 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
- 0xf1000000 -> 0xf1100000 1M internal registers
- 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0 => OK !
- 0xf8000000 -> 0xffe0000 126M PCIe memory
- 0xffe00000 -> 0xfff00000 1M PCIe I/O
- 0xfff0000 -> 0xffffffff 1M BootROM
Obviously, the solution is to align the location of the Crypto SRAM
mappings of Armada XP to be similar with the ones on Armada 370, i.e
have them between the "internal registers" area and the beginning of
the PCIe aperture.
However, we have a special case with the OpenBlocks AX3-4 platform,
which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
AX3-4, the internal registers are not at 0xf1000000. And this explains
why the Crypto SRAM mappings were not configured at the same place on
Armada XP.
Hence, the solution is two-fold:
(1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
0xf80000000 space.
(2) Move the Crypto SRAM mappings on Armada XP to be similar to
Armada 370 (except of course that Armada XP has two Crypto SRAM
and not one).
After this patch, the memory mapping on Armada XP boards with
registers at 0xf1 is:
- 0x00000000 -> 0xf0000000 3.75G RAM
- 0xf0000000 -> 0xf1000000 16M NOR flashes (AXP GP / AXP DB)
- 0xf1000000 -> 0xf1100000 1M internal registers
- 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0
- 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1
- 0xf8000000 -> 0xffe0000 126M PCIe memory
- 0xffe00000 -> 0xfff00000 1M PCIe I/O
- 0xfff0000 -> 0xffffffff 1M BootROM
And the memory mapping for the special case of the OpenBlocks AX3-4
(internal registers at 0xd0000000, NOR of 128 MB):
- 0x00000000 -> 0xc0000000 3G RAM
- 0xd0000000 -> 0xd1000000 1M internal registers
- 0xe800000 -> 0xf0000000 128M NOR flash
- 0xf1100000 -> 0xf1110000 64KB Crypto SRAM #0
- 0xf1110000 -> 0xf1120000 64KB Crypto SRAM #1
- 0xf8000000 -> 0xffe0000 126M PCIe memory
- 0xffe00000 -> 0xfff00000 1M PCIe I/O
- 0xfff0000 -> 0xffffffff 1M BootROM
Fixes: c466d997bb ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
Reported-by: Phil Sutter <phil@nwl.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Few more late fixes on drivers nothing major here.
- A memory leak fix in fsdma unmap the dma descriptors on
freeup.
- A fix in xdmac driver for residue calculation of dma
descriptor.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW4vAbAAoJEHwUBw8lI4NHc1kP/14BOZIWPRs7q/Hv/u4nOkz+
feTa0Fv744GO1MaiQAqZo2qTqJ1scp+b29J9xjkN+pLogQ0H6bxCJa0XP843eb91
kurLq24p9OQ4u+RaW84WB8TWEpCC+YjfThm5R2N320R9rqt+waSGw6FEk/tL61Iu
TIAo+nipLxNFr3ctBvzqJjIdclQ7X9b1WL6cc6nnNZtDXb4e+hwzlP2l7e2XFuRu
7UEN1hyvqNKEh8TMi6ix9Wtae+XIY9DDEc3f8lGE0lkzwAEFXYKO1J3zRHyjnNMy
fCWMIb0pXkXy2as3fmJ7RQ+AvWnSpNHSE0e5R3fmWWsM1ztFM3VgdrThNBRu27vL
DJn/eVFfa7rItSJTyBKijykkMHrjgXXyhdkQqnXLwl2+aURZfmsvH6ZAhBfHWody
io3VA5wZJmJqSZ3I/pIDwoEAwvukusic8ArJplry4W6TFn1+tQXcgz+rL6ATp/Wt
gt6+5mSJqH/JkUJMS41MU1FKGlDSKSF5V8pgg7I0yByU8E51c8cqhA04ZlFVG2BO
RE0ZDFg0fHCZkcXn7u7xE1ye9FuhdY/BpRLsvGcfhcByr3HXYbrXkQsX/AOKM3uC
epE/pViMhWXx6bATYTl0Polg5qaIVwXPcYv3gx/4fL963lz1jbC4uVzgtSCJi7an
HjrnmH5UbX0PtNRoU9VQ
=Y4sQ
-----END PGP SIGNATURE-----
Merge tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"Two fixes showed up in last few days, and they should be included in
4.5. Summary:
Two more late fixes to drivers, nothing major here:
- A memory leak fix in fsdma unmap the dma descriptors on freeup
- A fix in xdmac driver for residue calculation of dma descriptor"
* tag 'dmaengine-fix-4.5' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: at_xdmac: fix residue computation
dmaengine: fsldma: fix memory leak
- Revert a recent ACPICA commit that has been reverted
upstream, because it caused problems to happen on user
systems and the problem it attempted to address will not be
relevant any more after upcoming ACPI specification changes
(Bob Moore).
- Fix crash in the generic device properties framework introduced
by a recent change that forgot to check pointers against error
values in addition to checking them against NULL (Heikki Krogerus).
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJW4srMAAoJEILEb/54YlRxlrcP/3sEZHqGWFrRoxSYfcJq3o3b
bhDZNJTMcEqYFpC4j84PON2PN0bqIwUqW4EWrqQz0Rr1ry9iBNKDK6FxhHGkAhFg
oMxkw8s0WtiLnl5IHUCH3lGpw8PdjLDy3hRoPCMVjVZ9bP1kVatlX03iYwEaEK3F
TO3EtKj2aefbr8tPiPV+fCcEyUuVv00fugAtmWjASq37iGo7FpSYYMBSsedBLSGa
D946spbHg/1zcRxE/4zmITQr+4iOkda5eagpbXFCdxaTNxRQcYRaAg1jAX9kz4jW
W9BzSsW7HKJ8iu9eEHz8vKr5M6CtpNSHpBoR4DOPW78H+Zjff4uxtZ1kGBpj2Mc3
vslvHlnsGRh2Limr7e0XFRxAXPIhuw1mviLkayqGD2srQVsFEVvnNSjogp0xIsMk
mivdYNdhgWQ2CPjx4cXJMmpQIOsiqGG3wAz/PSVa73wNfuIJe+pMhHDZaEMEoMuX
WyCiNgVASi8biR8H21GTjR+OFIF8KeQGHMnltsyIuW2ZpEhSl5Zo7FioYUR9rS9c
1ZdJvpPBjT5YWhjbIA7uowp1aAhq2uD5HDU4ywL+beAJ9h/+E33hzXRewb0uB6LT
yTnWRHNhJgdO6FxnHhGIbENlLtMWmb3BSqveMI4vUafy3TdO3xqVBzNRuVAKoOzX
63z4hTL7vnexqV3i0qlY
=Pi1c
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-4.5-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management and ACPI fixes from Rafael Wysocki:
"Two more fixes for issues introduced recently, one in the generic
device properties framework and one in ACPICA.
Specifics:
- Revert a recent ACPICA commit that has been reverted upstream,
because it caused problems to happen on user systems and the
problem it attempted to address will not be relevant any more after
upcoming ACPI specification changes (Bob Moore).
- Fix crash in the generic device properties framework introduced by
a recent change that forgot to check pointers against error values
in addition to checking them against NULL (Heikki Krogerus)"
* tag 'pm+acpi-4.5-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
device property: fwnode->secondary may contain ERR_PTR(-ENODEV)
ACPICA: Revert "Parser: Fix for SuperName method invocation"
A SerDes PHY is optional, so if devm_phy_get() doesn't find one at all,
that's fine. But if devm_phy_get() finds a PHY that doesn't have a driver
yet, it returns -EPROBE_DEFER. In that case, defer probing the Keystone
driver. We may be able to load it later after a PHY driver is loaded.
[bhelgaas: changelog, check for -EPROBE_DEFER first]
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Changes:
o Only perform torn log write detection on dirty logs. This prevents
failures being detected due to a clean filesystem being moved
between machines or kernels of different architectures (e.g. 32
-> 64 bit, BE -> LE, etc). This fixes a regression introduced by
the torn log write detection in 4.5-rc1.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW4fdHAAoJEK3oKUf0dfod/6EP/1Mi2K+z8t9FaevB0yiy+Yfs
CzRe2Sim5EF67IFeh1CBChcJ4dpUtVxwn+vM6/tfOWM8jS0Oo1Chr5woRm2Xc1Ko
O4xmLcoooIBeustVt12/3+lKR0ACY4tSq8V673wBp7tSFi4dj5cnpb2pDuQTio3q
JCTFtHkG7s5d2XnDn0dYVdrm7/eKB1ZdQCaVxikVtqQvdwrnyZpo0Q5iu5/Ync4H
ULOoMW1xrrJQ7bZcMq4uLM9GglUEB2/tPfT2jFtiUFaNo+420B7FzZR9e6P9giBV
JB/t02uiqicN0+WN9xyu+ohYMtjUZ2wrysLaX8P9szy/Rmsn7gOUYs946KUhullD
D5JFzB/IUrLnIhfY4il8bK6NoTLPCj9DlktaA7GikA7QAyZFLrRr3b1r/XbR2lDB
8Sy3ij7yKh2fhThOk4D6fxyVkSgKpr9E2gz6LSl45imbrj69IjXCJwadD1i7yB8j
VJj+Vr54DcjxFR0SnCrpGSG2i7fgkGk+8woIyVkPczPMpVlmQrpnmBbD0+fn4d31
aRX4aDmv7OsT+OKEoy9Hu3wRmfUZSmaRmp+2QdJ0dT98LEFoUCmhsaiJLL+nVgv0
tsApndnvAFxWHZZ9w5VPnJ/99YIvWpb3zzn6mKD3XfN/2Mf4sMcN2JTzxLgEdU9D
2JX+S1/AUMZfL0Ghaww8
=NDeH
-----END PGP SIGNATURE-----
Merge tag 'xfs-for-linus-4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs
Pull xfs fixes from Dave Chinner:
"This is a fix for a regression introduced in 4.5-rc1 by the new torn
log write detection code. The regression only affects people moving a
clean filesystem between machines/kernels of different architecture
(such as changing between 32 bit and 64 bit kernels), but this is the
recommended (and only!) safe way to migrate a filesystem between
architectures so we really need to ensure it works.
The changes are larger than I'd prefer right at the end of the release
cycle, but the majority of the change is just factoring code to enable
the detection of a clean log at the correct time to avoid this issue.
Changes:
- Only perform torn log write detection on dirty logs. This prevents
failures being detected due to a clean filesystem being moved
between machines or kernels of different architectures (e.g. 32 ->
64 bit, BE -> LE, etc). This fixes a regression introduced by the
torn log write detection in 4.5-rc1"
* tag 'xfs-for-linus-4.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs:
xfs: only run torn log write detection on dirty logs
xfs: refactor in-core log state update to helper
xfs: refactor unmount record detection into helper
xfs: separate log head record discovery from verification
Originally altera_pcie_link_is_up() decided the link was up if any of the
low four bits of the LTSSM register were set. But the link is only up if
the LTSSM state is L0, so check for that exact value.
[bhelgaas: changelog]
Signed-off-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Pull vfs fixes from Al Viro:
"A couple of fixes: Fix for my dumb braino in ncpfs and a long-standing
breakage on recovery from failed rename() in jffs2"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
jffs2: reduce the breakage on recovery from halfway failed rename()
ncpfs: fix a braino in OOM handling in ncp_fill_cache()
Make the R-Car drivers depend on ARCH_RENESAS instead of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS. The motivation is that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM-based SoCs.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
The single pinmux controller can be cascaded to the other interrupt
controllers. Hence when propagating wake-up settings to its parent
interrupt controller, there's possiblity of detecting possible recursive
locking and getting lockdep warning.
This patch avoids this false positive by using a separate lockdep class
for this single pinctrl interrupts.
Cc: linux-gpio@vger.kernel.org
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Based on the Allwinner A64 user manual and on the previous sunxi
pinctrl drivers this introduces the pin multiplex assignments for
the ARMv8 Allwinner A64 SoC.
Port A is apparently used for the fixed function DRAM controller, so
the ports start at B here (the manual mentions "n from 1 to 7", so
not starting at 0).
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Xen framebuffer driver selects the xen keyboard driver, so the latter
will be built-in if XEN_FBDEV_FRONTEND=y. However, when CONFIG_INPUT
is a loadable module, this configuration cannot work. On mainline kernels,
the symbol will be enabled but not used, while in combination with
a patch I have to detect such useless configurations, we get the
expected link failure:
drivers/input/built-in.o: In function `xenkbd_remove':
xen-kbdfront.c:(.text+0x2f0): undefined reference to `input_unregister_device'
xen-kbdfront.c:(.text+0x30e): undefined reference to `input_unregister_device'
This removes the extra "select", as it just causes more trouble than
it helps. In theory, some defconfig file might break if it has
XEN_FBDEV_FRONTEND in it but not INPUT_XEN_KBDDEV_FRONTEND. The Kconfig
fragment we ship in the kernel (kernel/configs/xen.config) however
already enables both, and anyone using an old .config file would
keep having both enabled.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Suggested-by: David Vrabel <david.vrabel@citrix.com>
Fixes: 36c1132e34 ("xen kconfig: fix select INPUT_XEN_KBDDEV_FRONTEND")
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The "msi_domain" variable is NULL here so it leads to a NULL dereference. It
looks like we actually intended to free "middle_domain".
Fixes: e6b78f2c3e ('irqchip: Add the Alpine MSIX interrupt controller')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: kernel-janitors@vger.kernel.org
Cc: Tsahee Zidenberg <tsahee@annapurnalabs.com>
Link: http://lkml.kernel.org/r/20160311081442.GE31887@mwanda
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Currently on i386 and on X86_64 when emulating X86_32 in legacy mode, only
the stack and the executable are randomized but not other mmapped files
(libraries, vDSO, etc.). This patch enables randomization for the
libraries, vDSO and mmap requests on i386 and in X86_32 in legacy mode.
By default on i386 there are 8 bits for the randomization of the libraries,
vDSO and mmaps which only uses 1MB of VA.
This patch preserves the original randomness, using 1MB of VA out of 3GB or
4GB. We think that 1MB out of 3GB is not a big cost for having the ASLR.
The first obvious security benefit is that all objects are randomized (not
only the stack and the executable) in legacy mode which highly increases
the ASLR effectiveness, otherwise the attackers may use these
non-randomized areas. But also sensitive setuid/setgid applications are
more secure because currently, attackers can disable the randomization of
these applications by setting the ulimit stack to "unlimited". This is a
very old and widely known trick to disable the ASLR in i386 which has been
allowed for too long.
Another trick used to disable the ASLR was to set the ADDR_NO_RANDOMIZE
personality flag, but fortunately this doesn't work on setuid/setgid
applications because there is security checks which clear Security-relevant
flags.
This patch always randomizes the mmap_legacy_base address, removing the
possibility to disable the ASLR by setting the stack to "unlimited".
Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
Acked-by: Ismael Ripoll Ripoll <iripoll@upv.es>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: akpm@linux-foundation.org
Cc: kees Cook <keescook@chromium.org>
Link: http://lkml.kernel.org/r/1457639460-5242-1-git-send-email-hecmargi@upv.es
Signed-off-by: Ingo Molnar <mingo@kernel.org>
User visible:
- Implement 'perf stat --metric-only' (Andi Kleen)
- Fix perf script python database export crash (Chris Phlipot)
Infrastructure:
- perf top/report --hierarchy assorted fixes for problems introduced in this
perf/core cycle (Namhyung Kim)
- Support '~' operation in libtraceevent (Steven Rosted)
Build fixes:
- Fix bulding of jitdump on opensuse on ubuntu systems when the DWARF
devel files are not installed (Arnaldo Carvalho de Melo)
- Do not try building jitdump on unsupported arches (Jiri Olsa)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJW4d7RAAoJENZQFvNTUqpA//UP/R6gwMFA5+z7bUXTUqDNGjw2
Zc2F7rKCqX46sswow814uvaQsNj/q7JtoHV3AR2L+lQSkB4RTojZ69fT5EKL8di1
Uvo/0hvc5TF+iD3gRQARLha04qtnR84qikToxXfiZRJPCMw5dCtS8Ibxk6NtiezC
gfQagJcOBgx0j9KS4Oj7SPK3vidg9eHOL52ukTjgU0D0xu7S1Gyg5tPUwC0KgkSF
rW+ncQPVsgmt9GNcEQKuwke49eBOcdB2TiYu6KSY88HzKj0oHoCQKJhU/CABbcDj
SSmttVEPAhONk375P3ARkPWVgllgYO8ek6NAsXWXtMnhTqDmrgpmP1Po/sCEG7pr
NvYCAyWW2GBkpRTcrp8C9Zh8dibgcFT+D7uccfeNj0boSsjmZum20DgTbATQyPB+
P4BgyfjrDieGXE4RpWHbahvdGmmfTFuPszur/5JSO1fjeQ/8GE4uuvVYyD8XEtOf
y0jkd4jTSpSyEJt6Sc0t09AWDWH2Tb2kNw3EHeTDtJNAZXxsFzSnRjmqw5R5MdfR
mXBvXxkNqXh4+EwtkYU7Sdxm27zNBCKIr9kaDH+rndpvs6rorNAvRxRIVViNMw9k
Uq+NbI9J/h+Q9y4L60gJi8JQFVU5y5EfyCcp3PxpKH0Lw7e8rgNX3qhvQ8BIWwvH
lcRzdu5GRYR9sjfDbJ1g
=UVtX
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo-20160310' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:
User visible changes:
- Implement 'perf stat --metric-only' (Andi Kleen)
- Fix perf script python database export crash (Chris Phlipot)
Infrastructure changes:
- perf top/report --hierarchy assorted fixes for problems introduced in this
perf/core cycle (Namhyung Kim)
- Support '~' operation in libtraceevent (Steven Rosted)
Build fixes:
- Fix bulding of jitdump on opensuse on ubuntu systems when the DWARF
devel files are not installed (Arnaldo Carvalho de Melo)
- Do not try building jitdump on unsupported arches (Jiri Olsa)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
After the GMBUS transfer times out, we set force_bit=1 and
return -EAGAIN expecting the i2c core to call the .master_xfer
hook again so that we will retry the same transfer via bit-banging.
This is in case the gmbus hardware is somehow faulty.
Unfortunately we left adapter->retries to 0, meaning the i2c core
didn't actually do the retry. Let's tell the core we want one retry
when we return -EAGAIN.
Note that i2c-algo-bit also uses this retry count for some internal
retries, so we'll end up increasing those a bit as well.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Fixes: bffce907d6 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 8b1f165a4a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
A few driver specific fixes for the Rockchip and i.MX SPI controllers,
especially for the i.MX they're annoying bugs if you run into them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJW4POVAAoJECTWi3JdVIfQMRYH/R3bNmMQHZB+qBm6vVL28Pdo
OXNejqStZLJfvdP6+xNXKijomMmvL/Xd+Jf2XMhDcEH8FZDVyemp9WIfQg8LMsy8
uSYxfNIitL7T4xfPkKF8J0z3E81lc6EDGtv9M/7XWYJM1FrfMibQB3lUv1OK6+Gd
z3Q6lpTblh6o6sqN0m2g23uSv3FGhoSdTNMhLeT3Wo5L3SfGFupO35Um5pbX8nHZ
ZKmVNu1wmnWvf879NsaRs8W7btP/l/lcaz+aKB0HlJfzjUjyojsgSZu+EYTBXEDF
ZOe3YZnodXhnFjyHLAcI09aXeDbtLlx4QHGv36OL8ObWHX9M8UYG9pQUuh5/Ujc=
=gJMG
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v4.5-rc7' into spi-linus
spi: Fixes for v4.5
A few driver specific fixes for the Rockchip and i.MX SPI controllers,
especially for the i.MX they're annoying bugs if you run into them.
# gpg: Signature made Thu 10 Mar 2016 11:09:57 ICT using RSA key ID 5D5487D0
# gpg: key CD7BEEBC: no public key for trusted key - skipped
# gpg: key CD7BEEBC marked as ultimately trusted
# gpg: key AF88CD16: no public key for trusted key - skipped
# gpg: key AF88CD16 marked as ultimately trusted
# gpg: key 16005C11: no public key for trusted key - skipped
# gpg: key 16005C11 marked as ultimately trusted
# gpg: key 5621E907: no public key for trusted key - skipped
# gpg: key 5621E907 marked as ultimately trusted
# gpg: key 5C6153AD: no public key for trusted key - skipped
# gpg: key 5C6153AD marked as ultimately trusted
# gpg: Good signature from "Mark Brown <broonie@sirena.org.uk>"
# gpg: aka "Mark Brown <broonie@debian.org>"
# gpg: aka "Mark Brown <broonie@kernel.org>"
# gpg: aka "Mark Brown <broonie@tardis.ed.ac.uk>"
# gpg: aka "Mark Brown <broonie@linaro.org>"
# gpg: aka "Mark Brown <Mark.Brown@linaro.org>"
The spi_split_transfers_maxsize() gfp parameter is missing in the
function kernel-doc so building gives the following warning:
.//drivers/spi/spi.c:2359: warning: No description found for parameter 'gfp'
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The kernel-doc has to be just before the structure definition but the one
for struct spi_replaced_transfers was before a structure declaration and
that confuses kernel-doc which complains with the following build error:
.//include/linux/spi/spi.h:933: error: Cannot parse struct or union!
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
erst_init currently leaks resources allocated from its call to
apei_resources_init(). The data allocated there gets copied
into apei_resources_all and can be freed when we're done with it.
Signed-off-by: Josh Hunt <johunt@akamai.com>
Reviewed-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
We leak the NVS and arch resources (if used), in apei_resources_request.
They are allocated to make sure we exclude them from the APEI resources,
but they are never freed at the end of the function. Free them now.
Signed-off-by: Josh Hunt <johunt@akamai.com>
Reviewed-by: Chen, Gong <gong.chen@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
If the current value of MPERF or the current value of TSC is the
same as the previous one, respectively, intel_pstate_sample() bails
out early and skips the sample.
However, intel_pstate_adjust_busy_pstate() is still called in that
case which is not correct, so modify intel_pstate_sample() to
return a bool value indicating whether or not the sample has been
taken and use it to decide whether or not to call
intel_pstate_adjust_busy_pstate().
While at it, remove redundant parentheses from the MPERF/TSC
check in intel_pstate_sample().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Use a helper function to compute the average pstate and call it only
where it is needed (only when tracing or in intel_pstate_get).
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The cpu_load algorithm doesn't need to invoke intel_pstate_calc_busy(),
so move that call from intel_pstate_sample() to
get_target_pstate_use_performance().
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
mul_fp(int_tofp(A), B) expands to:
((A << FRAC_BITS) * B) >> FRAC_BITS, so the same result can be obtained
via simple multiplication A * B. Apply this observation to
max_perf * limits->max_perf and max_perf * limits->min_perf in
intel_pstate_get_min_max()."
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
pid->setpoint and pid->deadband can be initialized in fixed point, so we
can avoid the int_tofp in pid_calc.
Signed-off-by: Philippe Longepe <philippe.longepe@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Otherwise operations may be attempted that will only ever go on to crash
(since the metadata device is either missing or unreliable if 'fail_io'
is set).
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
clone_bio() now checks if bio_integrity_clone() returned an error rather
than just drop it on the floor.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
If a transaction abort has failed then we can no longer use the metadata
device. Typically this happens if the superblock is unreadable.
This fix addresses a crash seen during metadata device failure testing.
Fixes: 8a01a6af75 ("dm thin: prefetch missing metadata pages")
Cc: stable@vger.kernel.org # 3.19+
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
smq seems to be performing better than the old mq policy in all
situations, as well as using a quarter of the memory.
Make 'mq' an alias for 'smq' when choosing a cache policy. The tunables
that were present for the old mq are faked, and have no effect. mq
should be considered deprecated now.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
md->queue and q are the same thing in dm_old_init_request_queue() and
dm_mq_init_request_queue().
Also drop the temporary 'struct request_queue *q' in
dm_old_init_request_queue().
Signed-off-by: Bob Liu <bob.liu@oracle.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Saves 16 bytes by eliminating 4 4byte holes but more importantly:
numerous members that crossed cachelines were fixed.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Change the map pointer in 'struct mapped_device' from 'struct dm_table
__rcu *' to 'void __rcu *' to avoid the need for the dummy definition.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Allows user to control which NUMA node the memory for DM device
structures (e.g. mapped_device, request_queue, gendisk, blk_mq_tag_set)
is allocated from.
Defaults to NUMA_NO_NODE (-1). Allowable range is from -1 until the
last online NUMA node id.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
fail_path() will print a "Failing path ..." message but reinstate_path()
doesn't print a "Reinstating path ...". Add that message to
reinstate_path() to add symmetry and aid system debugging.
Remove reinstate_path()'s check for the path_selector providing
.reinstate_path hook. All path selectors provide this and any future
ones must too.
activate_path() calls pg_init_done() with SCSI_DH_DEV_OFFLINED but
pg_init_done() doesn't expicitly handle it in its swicth statement. Add
SCSI_DH_DEV_OFFLINED to the default case.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
