6 years agoMerge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into... 20180207_1141 ti-rt-linux-4.14.y-next-20180131 ti-rt-linux-4.14.y-next-20180201 ti-rt-linux-4.14.y-next-20180202 ti-rt-linux-4.14.y-next-20180203 ti-rt-linux-4.14.y-next-20180204 ti-rt-linux-4.14.y-next-20180205 ti-rt-linux-4.14.y-next-20180206 ti-rt-linux-4.14.y-next-20180207 ti-rt-linux-4.14.y-next-20180208 ti-rt-linux-4.14.y-next-20180209
Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
pci: dwc: pci-dra7xx: Improve MSI IRQ handling
Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"
PCI: dra7xx: Iterate over INTx status bits
PCI: dra7xx: Fix legacy INTD IRQ handling
PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
pci: dwc: pci-dra7xx: Make shutdown handler static
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
pci: dwc: pci-dra7xx: Improve MSI IRQ handling
Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"
PCI: dra7xx: Iterate over INTx status bits
PCI: dra7xx: Fix legacy INTD IRQ handling
PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
pci: dwc: pci-dra7xx: Make shutdown handler static
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.14.y
* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
pci: dwc: pci-dra7xx: Improve MSI IRQ handling
Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"
PCI: dra7xx: Iterate over INTx status bits
PCI: dra7xx: Fix legacy INTD IRQ handling
PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
pci: dwc: pci-dra7xx: Make shutdown handler static
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.14.y
* 'connectivity-ti-linux-4.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
pci: dwc: pci-dra7xx: Improve MSI IRQ handling
Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"
PCI: dra7xx: Iterate over INTx status bits
PCI: dra7xx: Fix legacy INTD IRQ handling
PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
pci: dwc: pci-dra7xx: Make shutdown handler static
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
serial: 8250: omap: Enable UART module wakeup based on device_may_wakeup() status
ARM: dts: am437x-gp-evm: Add pinmux for gpio0 wake
Input: matrix-keypad: Enhance pinctrl support
ARM: dts: ti: Allow kernel internal dtc to be found when using OOT builds
ARM: dts: ti: fix cleaning of overlay directory
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
serial: 8250: omap: Enable UART module wakeup based on device_may_wakeup() status
ARM: dts: am437x-gp-evm: Add pinmux for gpio0 wake
Input: matrix-keypad: Enhance pinctrl support
ARM: dts: ti: Allow kernel internal dtc to be found when using OOT builds
ARM: dts: ti: fix cleaning of overlay directory
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.14.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.14.y
* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
serial: 8250: omap: Enable UART module wakeup based on device_may_wakeup() status
ARM: dts: am437x-gp-evm: Add pinmux for gpio0 wake
Input: matrix-keypad: Enhance pinctrl support
ARM: dts: ti: Allow kernel internal dtc to be found when using OOT builds
ARM: dts: ti: fix cleaning of overlay directory
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.14.y
* 'platform-ti-linux-4.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
serial: 8250: omap: Enable UART module wakeup based on device_may_wakeup() status
ARM: dts: am437x-gp-evm: Add pinmux for gpio0 wake
Input: matrix-keypad: Enhance pinctrl support
ARM: dts: ti: Allow kernel internal dtc to be found when using OOT builds
ARM: dts: ti: fix cleaning of overlay directory
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
pci: dwc: pci-dra7xx: Improve MSI IRQ handling
We need to ensure that there are no pending MSI IRQ vector set (i.e
PCIE_MSI_INTR0_STATUS reads 0 at least once) before exiting
dra7xx_pcie_msi_irq_handler(). Else, the dra7xx PCIe wrapper will not
register new MSI IRQs even though PCIE_MSI_INTR0_STATUS shows IRQs are
pending. Therefore, keep calling dra7xx_pcie_msi_irq_handler() until it
returns IRQ_NONE, which suggests that PCIE_MSI_INTR0_STATUS is 0.
This fixes a bug, where PCIe wifi cards with 4 DMA queues like Intel
8260 used to throw following error and stall during ping/iperf3 tests.
[ 97.776310] iwlwifi 0000:01:00.0: Queue 9 stuck for 2500 ms.
Signed-off-by: Vignesh R <vigneshr@ti.com>
[nsekhar@ti.com: optimize 'count' condition check]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
We need to ensure that there are no pending MSI IRQ vector set (i.e
PCIE_MSI_INTR0_STATUS reads 0 at least once) before exiting
dra7xx_pcie_msi_irq_handler(). Else, the dra7xx PCIe wrapper will not
register new MSI IRQs even though PCIE_MSI_INTR0_STATUS shows IRQs are
pending. Therefore, keep calling dra7xx_pcie_msi_irq_handler() until it
returns IRQ_NONE, which suggests that PCIE_MSI_INTR0_STATUS is 0.
This fixes a bug, where PCIe wifi cards with 4 DMA queues like Intel
8260 used to throw following error and stall during ping/iperf3 tests.
[ 97.776310] iwlwifi 0000:01:00.0: Queue 9 stuck for 2500 ms.
Signed-off-by: Vignesh R <vigneshr@ti.com>
[nsekhar@ti.com: optimize 'count' condition check]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Revert "PCI: dwc: Clear MSI interrupt status after it is handled, not before"
Since commit 06e15e6883bed ("PCI: dwc: Clear MSI interrupt status after
it is handled, not before"), MSI IRQ status in PCIE_MSI_INTR0_STATUS
register is cleared after calling EP's IRQ handler.
But, MSI IRQs in case of PCIe are bit like edge interrupts. If a
another MSI IRQ is raised and the end of current EP's IRQ handler call
but before clearing the MSI IRQ status in PCIE_MSI_INTR0_STATUS register
then the new MSI IRQ is lost.
This issue has been observed in case of USB-Ethernet adapter connected
to PCIe USB card running iperf3 test. iperf3 client stalls after
sometime as reported here[1]. This is because XHCI raises MSI IRQ at the
end of its IRQ handler but before PCIe driver has cleared its status
in PCIE_MSI_INTR0_STATUS register. Hence, the new IRQ is never
registered by PCIe designware core. Since, XHCI does not raise any more
IRQs until the previous one is handled, it leads to a stall in
communication.
Therefore driver should always clear the MSI IRQ status in
PCIE_MSI_INTR0_STATUS before calling EP's IRQ handler. This make sure
that DW PCIe core catches new IRQ raised during the call to EP's IRQ
handler
[1] https://lkml.kernel.org/r/BN6PR18MB124994D85EAC4B5B1AD5EC56866E0@BN6PR18MB1249.namprd18.prod.outlook.com
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Since commit 06e15e6883bed ("PCI: dwc: Clear MSI interrupt status after
it is handled, not before"), MSI IRQ status in PCIE_MSI_INTR0_STATUS
register is cleared after calling EP's IRQ handler.
But, MSI IRQs in case of PCIe are bit like edge interrupts. If a
another MSI IRQ is raised and the end of current EP's IRQ handler call
but before clearing the MSI IRQ status in PCIE_MSI_INTR0_STATUS register
then the new MSI IRQ is lost.
This issue has been observed in case of USB-Ethernet adapter connected
to PCIe USB card running iperf3 test. iperf3 client stalls after
sometime as reported here[1]. This is because XHCI raises MSI IRQ at the
end of its IRQ handler but before PCIe driver has cleared its status
in PCIE_MSI_INTR0_STATUS register. Hence, the new IRQ is never
registered by PCIe designware core. Since, XHCI does not raise any more
IRQs until the previous one is handled, it leads to a stall in
communication.
Therefore driver should always clear the MSI IRQ status in
PCIE_MSI_INTR0_STATUS before calling EP's IRQ handler. This make sure
that DW PCIe core catches new IRQ raised during the call to EP's IRQ
handler
[1] https://lkml.kernel.org/r/BN6PR18MB124994D85EAC4B5B1AD5EC56866E0@BN6PR18MB1249.namprd18.prod.outlook.com
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: dra7xx: Iterate over INTx status bits
commit 09b2d20349e37a03a0951ab69524b516c8f1cc5b upstream.
It is possible that more than one legacy IRQ may be set at the same
time, therefore iterate and handle all the pending INTx interrupts
before clearing the status and exiting the IRQ handler. Otherwise, some
interrupts would be lost.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 09b2d20349e37a03a0951ab69524b516c8f1cc5b upstream.
It is possible that more than one legacy IRQ may be set at the same
time, therefore iterate and handle all the pending INTx interrupts
before clearing the status and exiting the IRQ handler. Otherwise, some
interrupts would be lost.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: dra7xx: Fix legacy INTD IRQ handling
commit 524d59f6e30aab5b618da55e604c802ccd83e708 upstream.
Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
4 which is numbered 0-3. Therefore when INTD IRQ line is used with
pci-dra7xx driver following warning is seen:
WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:342 irq_domain_associate+0x12c/0x1c4
error: hwirq 0x4 is too large for dummy
Fix this by using pci_irqd_intx_xlate() helper to translate the INTx 1-4
range into the 0-3 as done in other PCIe drivers.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Reported-by: Chris Welch <Chris.Welch@viavisolutions.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 524d59f6e30aab5b618da55e604c802ccd83e708 upstream.
Legacy INTD IRQ handling is broken on dra7xx due to fact that driver
uses hwirq in range of 1-4 for INTA, INTD whereas IRQ domain is of size
4 which is numbered 0-3. Therefore when INTD IRQ line is used with
pci-dra7xx driver following warning is seen:
WARNING: CPU: 0 PID: 1 at kernel/irq/irqdomain.c:342 irq_domain_associate+0x12c/0x1c4
error: hwirq 0x4 is too large for dummy
Fix this by using pci_irqd_intx_xlate() helper to translate the INTx 1-4
range into the 0-3 as done in other PCIe drivers.
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Reported-by: Chris Welch <Chris.Welch@viavisolutions.com>
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
PCI: Add dummy pci_irqd_intx_xlate() for CONFIG_PCI=n build
commit 80db6f08b7af93eddc9487535e6150b220262637 upstream.
Some hardware can operate in either "host" or "endpoint" mode, which means
there can be both a host bridge driver and an endpoint driver for the same
device. Those drivers share a lot of code, so sometimes they live in the
same source file.
The host bridge driver requires CONFIG_PCI=y because it enumerates PCI
devices below the bridge using the PCI core. The endpoint driver does not
require CONFIG_PCI=y because it runs in an embedded kernel on the other
side of the device, e.g., on an adapter card.
pci-dra7xx.c contains both host and endpoint drivers. If we select only
the endpoint driver (CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y), the unneeded
host driver is still compiled. It references pci_irqd_intx_xlate(), which
is not present when CONFIG_PCI=n, which causes this error:
drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared here (not in a function)
Add a dummy pci_irqd_intx_xlate() for the CONFIG_PCI=n case.
[bhelgaas: changelog]
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 80db6f08b7af93eddc9487535e6150b220262637 upstream.
Some hardware can operate in either "host" or "endpoint" mode, which means
there can be both a host bridge driver and an endpoint driver for the same
device. Those drivers share a lot of code, so sometimes they live in the
same source file.
The host bridge driver requires CONFIG_PCI=y because it enumerates PCI
devices below the bridge using the PCI core. The endpoint driver does not
require CONFIG_PCI=y because it runs in an embedded kernel on the other
side of the device, e.g., on an adapter card.
pci-dra7xx.c contains both host and endpoint drivers. If we select only
the endpoint driver (CONFIG_PCI=n and CONFIG_PCI_DRA7XX_EP=y), the unneeded
host driver is still compiled. It references pci_irqd_intx_xlate(), which
is not present when CONFIG_PCI=n, which causes this error:
drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared here (not in a function)
Add a dummy pci_irqd_intx_xlate() for the CONFIG_PCI=n case.
[bhelgaas: changelog]
Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
pci: dwc: pci-dra7xx: Make shutdown handler static
commit 4751fac776f37e75670c7bdb7a86f81553f538e0 upstream.
Define dra7xx_pcie_shutdown() as a static function as it is not used
in other compilation units.
Signed-off-by: Vignesh R <vigneshr@ti.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
commit 4751fac776f37e75670c7bdb7a86f81553f538e0 upstream.
Define dra7xx_pcie_shutdown() as a static function as it is not used
in other compilation units.
Signed-off-by: Vignesh R <vigneshr@ti.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
serial: 8250: omap: Enable UART module wakeup based on device_may_wakeup() status
Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
return value of device_may_wakeup() in .suspend(). This is allows
userspace to use sysfs to control the ability of UART to wakeup the
system from low power state. Register is restored back in .startup()
call that happens as part of resume sequence.
With this patch, userspace can control UART wakeup capability via sysfs:
To enable wakeup capability:
echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
For disabling wakeup capability:
echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
Signed-off-by: Vignesh R <vigneshr@ti.com>
Enable/Clear module level UART wakeup in UART_OMAP_WER register based on
return value of device_may_wakeup() in .suspend(). This is allows
userspace to use sysfs to control the ability of UART to wakeup the
system from low power state. Register is restored back in .startup()
call that happens as part of resume sequence.
With this patch, userspace can control UART wakeup capability via sysfs:
To enable wakeup capability:
echo enabled > /sys/class/tty/ttyXX/device/power/wakeup
For disabling wakeup capability:
echo disabled > /sys/class/tty/ttyXX/device/power/wakeup
Signed-off-by: Vignesh R <vigneshr@ti.com>
ARM: dts: am437x-gp-evm: Add pinmux for gpio0 wake
Add pinctrl settings so that gpio0 wake from suspend will be supported
using buttons SW4 and SW7. Also, add pinctrl configuration for 0x954,
spi0_d0, which is an unused pin brought out to a header on the board
that in it's default state also connects to the gpio used for wakeup,
gpio0_3, which affects the state of the pin and prevents a working
wakeup unless we set the mux to a different state.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Add pinctrl settings so that gpio0 wake from suspend will be supported
using buttons SW4 and SW7. Also, add pinctrl configuration for 0x954,
spi0_d0, which is an unused pin brought out to a header on the board
that in it's default state also connects to the gpio used for wakeup,
gpio0_3, which affects the state of the pin and prevents a working
wakeup unless we set the mux to a different state.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Input: matrix-keypad: Enhance pinctrl support
Update matrix-keypad driver to set the state of the pins to:
- "sleep" on suspend
- "default" on resume
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- minimize current leakage from pins and thus save power,
- prevent the IP from driving pins output in an uncontrolled manner,
which may happen if the power domain drops the domain regulator.
When using any of the GPIOs in a matrix-keypad for wakeup the pins must
be set to the appropriate state to allow this dependent on the board.
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Update matrix-keypad driver to set the state of the pins to:
- "sleep" on suspend
- "default" on resume
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- minimize current leakage from pins and thus save power,
- prevent the IP from driving pins output in an uncontrolled manner,
which may happen if the power domain drops the domain regulator.
When using any of the GPIOs in a matrix-keypad for wakeup the pins must
be set to the appropriate state to allow this dependent on the board.
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: dts: ti: Allow kernel internal dtc to be found when using OOT builds
When building out-of-tree, 'srctree' does not contain the DTC binary, and
so we still fall-back to the system installed DTC. The correct path for
both build types is 'objtree', use this instead.
Fixes: 8567a04835e2 ("ARM: dts: ti: force mkimage tool to use kernel internal dtc")
Signed-off-by: Andrew F. Davis <afd@ti.com>
When building out-of-tree, 'srctree' does not contain the DTC binary, and
so we still fall-back to the system installed DTC. The correct path for
both build types is 'objtree', use this instead.
Fixes: 8567a04835e2 ("ARM: dts: ti: force mkimage tool to use kernel internal dtc")
Signed-off-by: Andrew F. Davis <afd@ti.com>
ARM: dts: ti: fix cleaning of overlay directory
make clean does not propagate properly to the ti/ subdir, because the
config is empty at this point. Fix the problem by explicitly adding
ti/ to the subdirs.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
make clean does not propagate properly to the ti/ subdir, because the
config is empty at this point. Fix the problem by explicitly adding
ti/ to the subdirs.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
6 years agoMerge branch 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git... ti-rt-linux-4.14.y-next-20180130
Merge branch 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel into ti-rt-linux-4.14.y
TI-Feature: linux_rt-4-14
TI-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
TI-Branch: linux-4.14.y-rt
* 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel:
v4.14.15-rt13
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: linux_rt-4-14
TI-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
TI-Branch: linux-4.14.y-rt
* 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel:
v4.14.15-rt13
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
v4.14.15-rt13
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'rpmsg-ti-linux-4.14.y-intg' of git://git.ti.com/rpmsg/rpmsg into ti-linux-4.14.y
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.14.y-intg
* 'rpmsg-ti-linux-4.14.y-intg' of git://git.ti.com/rpmsg/rpmsg:
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.14.y-intg
* 'rpmsg-ti-linux-4.14.y-intg' of git://git.ti.com/rpmsg/rpmsg:
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'rpmsg-ti-linux-4.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-4.14.y-intg
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ti_config_fragments: rpmsg: Add keystone-dsp-mem and UIO modules
Add the keystone-dsp-mem module and UIO core modules to the rpmsg
defconfig fragment to enable the user-land Multi Proc Manager (MPM)
based remoteproc usecases on Keystone platforms.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the keystone-dsp-mem module and UIO core modules to the rpmsg
defconfig fragment to enable the user-land Multi Proc Manager (MPM)
based remoteproc usecases on Keystone platforms.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-4.14.y
Pull in the updated remoteproc feature branch that enhances the
Keystone remoteproc driver to provide an userspace interface
for supporting a userland driven Multi Proc Manager (MPM) loader.
An additional temporary keystone_dsp_mem driver is also added
that provides an mmap interface for MultiCore Shared Memory (MSM)
and portions of DDR for exclusive usage for the DSPs.
Both the keystone remoteproc driver and keystone_dsp_mem driver
provide sysfs interfaces for presenting the DSP internal memory
regions and the DDR & SRAM regions respectively to userspace.
The keystone_dsp_mem driver uses the SRAM driver infrastructure,
and uses specific child nodes to reserve portions of the MSM
RAM for exposing them to userspace for the MPM stack on all
Keystone 2 SoCs.
This support has been added to all the currently supported TI
platforms - K2H EVM, K2L EVM, K2E EVM, K2G GP EVM and K2G-ICE
boards. Note that the file-system options for the last two boards
is limited without few additional patches. The K2G GP EVM board
is limited to the filesystem being in MMC sdcard and the K2G-ICE
board is limited to a ramdisk/initramfs at the moment.
* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: Suman Anna <s-anna@ti.com>
Pull in the updated remoteproc feature branch that enhances the
Keystone remoteproc driver to provide an userspace interface
for supporting a userland driven Multi Proc Manager (MPM) loader.
An additional temporary keystone_dsp_mem driver is also added
that provides an mmap interface for MultiCore Shared Memory (MSM)
and portions of DDR for exclusive usage for the DSPs.
Both the keystone remoteproc driver and keystone_dsp_mem driver
provide sysfs interfaces for presenting the DSP internal memory
regions and the DDR & SRAM regions respectively to userspace.
The keystone_dsp_mem driver uses the SRAM driver infrastructure,
and uses specific child nodes to reserve portions of the MSM
RAM for exposing them to userspace for the MPM stack on all
Keystone 2 SoCs.
This support has been added to all the currently supported TI
platforms - K2H EVM, K2L EVM, K2E EVM, K2G GP EVM and K2G-ICE
boards. Note that the file-system options for the last two boards
is limited without few additional patches. The K2G GP EVM board
is limited to the filesystem being in MMC sdcard and the K2G-ICE
board is limited to a ramdisk/initramfs at the moment.
* 'rproc-linux-4.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc: deny sysfs operations with MPM userspace loader
remoteproc/keystone: add support for MPM userspace loader
remoteproc: add infrastructure to support user-space loading/booting
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
ARM: dts: keystone-k2g: Reserve SRAM for MPM
ARM: dts: keystone-k2e: Reserve SRAM for MPM
ARM: dts: keystone-k2l: Reserve SRAM for MPM
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
TEMP: soc: ti: add the keystone_dsp_mem driver
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'integration-ti-rt-linux-4.14.y' of git://git.ti.com/ti-linux-kernel/kernel-integration-tree into ti-rt-linux-4.14.y
TI-Feature: integration
TI-Tree: git://git.ti.com/ti-linux-kernel/kernel-integration-tree.git
TI-Branch: integration-ti-rt-linux-4.14.y
* 'integration-ti-rt-linux-4.14.y' of git://git.ti.com/ti-linux-kernel/kernel-integration-tree:
ti_config_fragments: RT: add real_time.cfg fragment
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: integration
TI-Tree: git://git.ti.com/ti-linux-kernel/kernel-integration-tree.git
TI-Branch: integration-ti-rt-linux-4.14.y
* 'integration-ti-rt-linux-4.14.y' of git://git.ti.com/ti-linux-kernel/kernel-integration-tree:
ti_config_fragments: RT: add real_time.cfg fragment
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel into ti-rt-linux-4.14.y
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: ti_linux_base_rt
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.14.y
* 'ti-linux-4.14.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
Signed-off-by: Dan Murphy <dmurphy@ti.com>
ti_config_fragments: RT: add real_time.cfg fragment
Add the real time config fragment to enable a real time
kernel.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Add the real time config fragment to enable a real time
kernel.
Signed-off-by: Dan Murphy <dmurphy@ti.com>
remoteproc: deny sysfs operations with MPM userspace loader
The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. The Keystone
remoteproc driver also supports a custom userspace-driven load
and boot mechanism called Multi Proc Manager (MPM) through a
char device and custom ioctls supporting a userspace daemon.
The sysfs interface does conflict with the MPM state-machine and
the corresponding state variables within the keystone remoteproc
driver. So, add a check to the sysfs interface operations to fix
this by obstructing any changes to the remoteproc state-machine
when a remote processor is configured for supporting the userspace
loader/boot mechanism.
Signed-off-by: Suman Anna <s-anna@ti.com>
The remoteproc framework provides sysfs interfaces for changing
the firmware name and for starting/stopping a remote processor
through the sysfs files 'state' and 'firmware'. The Keystone
remoteproc driver also supports a custom userspace-driven load
and boot mechanism called Multi Proc Manager (MPM) through a
char device and custom ioctls supporting a userspace daemon.
The sysfs interface does conflict with the MPM state-machine and
the corresponding state variables within the keystone remoteproc
driver. So, add a check to the sysfs interface operations to fix
this by obstructing any changes to the remoteproc state-machine
when a remote processor is configured for supporting the userspace
loader/boot mechanism.
Signed-off-by: Suman Anna <s-anna@ti.com>
remoteproc/keystone: add support for MPM userspace loader
The Keystone remoteproc driver performs the device management of
different DSP processor subsystems present on various Keystone 2
family of SoCs. The driver currently supports loading/booting using
the remoteproc core's 'auto-boot' feature and supports advanced
features like error recovery.
This patch enhances the Keystone remoteproc driver to add support
for a TI specific userspace based loading/booting mechanism called
the Multi Proc Manager (MPM) by exposing a character device interface
to userspace per device. A new module parameter 'use_rproc_core_loader'
is introduced to configure the driver for in-kernel auto-boot mode
or the MPM non auto-boot mode, with the default configured for MPM.
The standard platform driver's bind and unbind sysfs attributes are
suppressed for MPM-based stack so that the regular sysfs approach of
booting and shutting down a Keystone DSP remote processor does not
mess up the MPM-based state-machine by unbinding the device from the
driver even when it has open usage reference counts. An exception
notification is also provided through an UIO device exposed by the
keystone remoteproc driver for now.
The MPM loading/booting mechanism uses the file operations exported
by the character device. The mmap interface is used for mapping device
memory into userspace for loading and the ioctl interfaces are used
for reset and remoteproc resource table configuration and triggering
the boot and shutdown of the DSPs.
The address and size of the various DSP internal RAM memories to
be used with the mmap interface are provided through two sysfs
files 'addr' and 'size' for each region, and are created under the
respective dspX misc device for each DSP remoteproc processor. These
files are created in their own directory for each region accessible
under the /sys/class/misc/dspX/ path, where X is the DSP number
(indexed from 0). The MPM also relies on another memory mapping
character device (/dev/dspmem) to support loading images into
external DDR memory and the Multicore Shared Memory (MSM). This
sysfs logic allows the userspace-based Multi Proc Manager (MPM)
stack to not rely on procfs-based DT parsing for looking up the
memories.
The MPM supports various kinds of firmware images - images with and
without resource tables, images that have a resource table but with
or without the virtio device resource entries. The loadable regions
include images just using internal DSP memories, or images using
portions of the MSM RAM and/or external DDR. The load/boot of images
with and without resource tables are supported using separate ioctl
operations. The KEYSTONE_RPROC_IOC_SET_STATE ioctl is used to boot
and shutdown remote processors for images with resource tables, and
the KEYSTONE_RPROC_IOC_DSP_RESET/BOOT ioctls for images without a
resource table. The boot address/entry point is published during the
corresponding ioctls that trigger a boot, and is stored in a local
variable in driver instance and later picked up by remoteproc core
driver through fw_ops.
This logic is created anew using an older code from Cyril Chemparathy
as a baseline.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>
The Keystone remoteproc driver performs the device management of
different DSP processor subsystems present on various Keystone 2
family of SoCs. The driver currently supports loading/booting using
the remoteproc core's 'auto-boot' feature and supports advanced
features like error recovery.
This patch enhances the Keystone remoteproc driver to add support
for a TI specific userspace based loading/booting mechanism called
the Multi Proc Manager (MPM) by exposing a character device interface
to userspace per device. A new module parameter 'use_rproc_core_loader'
is introduced to configure the driver for in-kernel auto-boot mode
or the MPM non auto-boot mode, with the default configured for MPM.
The standard platform driver's bind and unbind sysfs attributes are
suppressed for MPM-based stack so that the regular sysfs approach of
booting and shutting down a Keystone DSP remote processor does not
mess up the MPM-based state-machine by unbinding the device from the
driver even when it has open usage reference counts. An exception
notification is also provided through an UIO device exposed by the
keystone remoteproc driver for now.
The MPM loading/booting mechanism uses the file operations exported
by the character device. The mmap interface is used for mapping device
memory into userspace for loading and the ioctl interfaces are used
for reset and remoteproc resource table configuration and triggering
the boot and shutdown of the DSPs.
The address and size of the various DSP internal RAM memories to
be used with the mmap interface are provided through two sysfs
files 'addr' and 'size' for each region, and are created under the
respective dspX misc device for each DSP remoteproc processor. These
files are created in their own directory for each region accessible
under the /sys/class/misc/dspX/ path, where X is the DSP number
(indexed from 0). The MPM also relies on another memory mapping
character device (/dev/dspmem) to support loading images into
external DDR memory and the Multicore Shared Memory (MSM). This
sysfs logic allows the userspace-based Multi Proc Manager (MPM)
stack to not rely on procfs-based DT parsing for looking up the
memories.
The MPM supports various kinds of firmware images - images with and
without resource tables, images that have a resource table but with
or without the virtio device resource entries. The loadable regions
include images just using internal DSP memories, or images using
portions of the MSM RAM and/or external DDR. The load/boot of images
with and without resource tables are supported using separate ioctl
operations. The KEYSTONE_RPROC_IOC_SET_STATE ioctl is used to boot
and shutdown remote processors for images with resource tables, and
the KEYSTONE_RPROC_IOC_DSP_RESET/BOOT ioctls for images without a
resource table. The boot address/entry point is published during the
corresponding ioctls that trigger a boot, and is stored in a local
variable in driver instance and later picked up by remoteproc core
driver through fw_ops.
This logic is created anew using an older code from Cyril Chemparathy
as a baseline.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <samnelson@ti.com>
remoteproc: add infrastructure to support user-space loading/booting
The remoteproc infrastructure is enhanced to allow remoteproc drivers
to support userspace driven loading and booting mechanism. This is
done in preparation to allow the TI Keystone remoteproc driver to
support a userspace based loader.
A new field 'use_userspace_loader' is added to the rproc structure,
and this field is expected to be set alongside configuring the
'auto_boot' flag to false by remoteproc drivers wishing to bypass
the in-kernel loading and boot mechanism. The remoteproc core skips
looking for firmware or loading any firmware segments using these
two state flags.
The remoteproc drivers are expected to invoke rproc_boot() and
rproc_shutdown() for triggering the boot and shutdown of the remote
processor after the loading is completed and the resource table
information is published to the remoteproc driver. The resource
table is processed in-line during the rproc_boot() invocation.
The interface and implementation details to userspace is left to
the individual remoteproc drivers.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
The remoteproc infrastructure is enhanced to allow remoteproc drivers
to support userspace driven loading and booting mechanism. This is
done in preparation to allow the TI Keystone remoteproc driver to
support a userspace based loader.
A new field 'use_userspace_loader' is added to the rproc structure,
and this field is expected to be set alongside configuring the
'auto_boot' flag to false by remoteproc drivers wishing to bypass
the in-kernel loading and boot mechanism. The remoteproc core skips
looking for firmware or loading any firmware segments using these
two state flags.
The remoteproc drivers are expected to invoke rproc_boot() and
rproc_shutdown() for triggering the boot and shutdown of the remote
processor after the loading is completed and the resource table
information is published to the remoteproc driver. The resource
table is processed in-line during the rproc_boot() invocation.
The interface and implementation details to userspace is left to
the individual remoteproc drivers.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
TEMP: ARM: dts: keystone-k2g-ice: Add a memory carveout for MPM usecases
A reserved memory carveout node with the appropriate compatible property
is added on the K2G ICE board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
This address and size are aligned with the values used on the
K2G EVM board so that same firmwares can be run on both the K2G
boards. Note that these values are different from those used on
the other K2HK/K2L/K2E EVM boards.
Signed-off-by: Suman Anna <s-anna@ti.com>
A reserved memory carveout node with the appropriate compatible property
is added on the K2G ICE board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
This address and size are aligned with the values used on the
K2G EVM board so that same firmwares can be run on both the K2G
boards. Note that these values are different from those used on
the other K2HK/K2L/K2E EVM boards.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: ARM: dts: keystone-k2g-evm: Add a memory carveout for MPM usecases
A reserved memory carveout node with the appropriate compatible property
is added on the K2G EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Note that this carveout is smaller and at a different address in
comparision to those used on K2HK/K2L/K2E EVMs. This is done to
align with the usage on K2G ICE board which has a smaller DDR memory
footprint, and thereby allow same firmwares to be run on both the
K2G boards.
Signed-off-by: Suman Anna <s-anna@ti.com>
A reserved memory carveout node with the appropriate compatible property
is added on the K2G EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 40 MB is currently reserved at address
0x81d000000 (aliased at 0x9d000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Note that this carveout is smaller and at a different address in
comparision to those used on K2HK/K2L/K2E EVMs. This is done to
align with the usage on K2G ICE board which has a smaller DDR memory
footprint, and thereby allow same firmwares to be run on both the
K2G boards.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: ARM: dts: keystone-k2e-evm: Add a memory carveout for MPM usecases
A reserved memory carveout node with the appropriate compatible property
is added on the K2E EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
A reserved memory carveout node with the appropriate compatible property
is added on the K2E EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: ARM: dts: keystone-k2l-evm: Add a memory carveout for MPM usecases
A reserved memory carveout node with the appropriate compatible property
is added on the K2L EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
A reserved memory carveout node with the appropriate compatible property
is added on the K2L EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: ARM: dts: keystone-k2hk-evm: Add a memory carveout for MPM usecases
A reserved memory carveout node with the appropriate compatible property
is added on the K2HK EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
A reserved memory carveout node with the appropriate compatible property
is added on the K2HK EVM board so that it can be reserved specifically to
be used by the Keystone Multi Proc Manager (MPM) stack for loading various
firmware images onto the DSPs directly from userspace.
A memory region of size 256 MB is currently reserved at address
0x820000000 (aliased at 0xa0000000). The memory is chosen to be
adjacent to the DSP CMA memory pool so that the DSP Memory Protection
and Address Extension (MPAX) module can be configured efficiently.
This memory will not be mapped into the kernel space.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: keystone-k2g: Reserve SRAM for MPM
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2G
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2G
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: keystone-k2e: Reserve SRAM for MPM
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2E
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2E
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: keystone-k2l: Reserve SRAM for MPM
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2L
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2L
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: keystone-k2hk: Reserve SRAM for MPM
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2H
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a child SRAM node to reserve a portion of the Multicore Shared
Memory (MSM) RAM for use by the keystone-dsp-mem driver on 66AK2H
SoCs. This memory will be exposed to the userspace for meeting the
needs of the Multi Proc Manager (MPM) stack.
A preliminary size of 512 KB is reserved to begin with and can be
adjusted as per need.
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: soc: ti: add the keystone_dsp_mem driver
A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.
The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.
The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.
The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
A very simple keystone_dsp_mem driver has been added for TI's Keystone 2
family of SoCs. This driver provides a user-space mapping interface for
some On-chip Multicore Shared Memory (MSM) SRAM Memory regions and/or
some portions of the platform board's DDR memory. This is done to enable
the Multi Proc Manager (MPM) based loader for loading different firmware
images into both DDR and On-chip SRAM in userspace for the various C66
DSP co-processors on the SoC.
The different MSM RAM regions to be exposed to userspace through this
driver need to be defined as 'reserved' child nodes under the parent
MSM RAM mmio-sram node with a specific compatible "ti,keystone-dsp-msm-ram"
property. Each of the DDR regions to be exposed should also be defined
using reserved-memory child nodes with the "no-map" property set and
using a specific compatible "ti,keystone-dsp-mpm-pool" property. Multiple
discrete regions of either SRAM and/or DDR can be exposed to userspace
by defining similar DTS nodes.
The keystone-dsp-mem driver provides sysfs entries to allow userspace
to read the address and size of supported DDR and Multicore Shared Memory
(MSM) RAM memories that are exposed to userspace. This sysfs logic provides
an agnostic way of presenting the supported memories irrespective of how
the driver acquires the memories. The 32-bit DDR alias addresses are used
while presenting the DDR regions through sysfs as per current MPM usage.
Each supported memory region is represented by its own directory, and are
created under the dspmem misc device. The directories can be accessed
under the /sys/class/misc/dspmem/ path.
The mapping interfaces are provided through a miscdevice and exposed
using the character device /dev/dspmem (matching the usage within MPM).
The mmap logic itself is based on a mechanism used within the UIO
framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel into ti-rt-linux-4.14.y
TI-Feature: linux_rt-4-14
TI-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
TI-Branch: linux-4.14.y-rt
* 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel: (95 commits)
v4.14.15-rt12
tracing: Update the "tracing: Inter-event (e.g. latency) support" patch
Revert "net: sysrq via icmp"
v4.14.15-rt11
Linux 4.14.15
MIPS: AR7: ensure the port type's FCR value is used
net: mvpp2: do not disable GMAC padding
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()
x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
x86/pti: Document fix wrong index
kprobes/x86: Disable optimizing on the function jumps to indirect thunk
kprobes/x86: Blacklist indirect thunk functions for kprobes
retpoline: Introduce start/end markers of indirect thunk
x86/mce: Make machine check speculation protected
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
MIPS: CM: Drop WARN_ON(vp != 0)
alpha/PCI: Fix noname IRQ level detection
x86: Use __nostackprotect for sme_encrypt_kernel
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: linux_rt-4-14
TI-Tree: https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
TI-Branch: linux-4.14.y-rt
* 'linux-4.14.y-rt' of https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel: (95 commits)
v4.14.15-rt12
tracing: Update the "tracing: Inter-event (e.g. latency) support" patch
Revert "net: sysrq via icmp"
v4.14.15-rt11
Linux 4.14.15
MIPS: AR7: ensure the port type's FCR value is used
net: mvpp2: do not disable GMAC padding
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()
x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
x86/pti: Document fix wrong index
kprobes/x86: Disable optimizing on the function jumps to indirect thunk
kprobes/x86: Blacklist indirect thunk functions for kprobes
retpoline: Introduce start/end markers of indirect thunk
x86/mce: Make machine check speculation protected
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
MIPS: CM: Drop WARN_ON(vp != 0)
alpha/PCI: Fix noname IRQ level detection
x86: Use __nostackprotect for sme_encrypt_kernel
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
v4.14.15-rt12
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
tracing: Update the "tracing: Inter-event (e.g. latency) support" patch
This commit is an all-in-one update of Tom Zanussi's "tracing: Inter-event
(e.g. latency) support" series from v8 to v9 as posted on 2018-01-16. It
includes the following patches:
tracing: Move hist trigger Documentation to histogram.txt
tracing: Add Documentation for log2 modifier
tracing: Add support to detect and avoid duplicates
tracing: Remove code which merges duplicates
ring-buffer: Add interface for setting absolute time stamps
ring-buffer: Redefine the unimplemented RINGBUF_TYPE_TIME_STAMP
tracing: Add timestamp_mode trace file
tracing: Give event triggers access to ring_buffer_event
tracing: Add ring buffer event param to hist field functions
tracing: Break out hist trigger assignment parsing
tracing: Add hist trigger timestamp support
tracing: Add per-element variable support to tracing_map
tracing: Add hist_data member to hist_field
tracing: Add usecs modifier for hist trigger timestamps
tracing: Add variable support to hist triggers
tracing: Account for variables in named trigger compatibility
tracing: Move get_hist_field_flags()
tracing: Add simple expression support to hist triggers
tracing: Generalize per-element hist trigger data
tracing: Pass tracing_map_elt to hist_field accessor functions
tracing: Add hist_field 'type' field
tracing: Add variable reference handling to hist triggers
tracing: Add hist trigger action hook
tracing: Add support for 'synthetic' events
tracing: Add support for 'field variables'
tracing: Add 'onmatch' hist trigger action support
tracing: Add 'onmax' hist trigger action support
tracing: Allow whitespace to surround hist trigger filter
tracing: Add cpu field for hist triggers
tracing: Add hist trigger support for variable reference aliases
tracing: Add 'last error' error facility for hist triggers
tracing: Add inter-event hist trigger Documentation
tracing: Make tracing_set_clock() non-static
tracing: Add a clock attribute for hist triggers
tracing: Increase trace_recursive_lock() limit for synthetic events
tracing: Add inter-event blurb to HIST_TRIGGERS config option
selftests: ftrace: Add inter-event hist triggers testcases
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This commit is an all-in-one update of Tom Zanussi's "tracing: Inter-event
(e.g. latency) support" series from v8 to v9 as posted on 2018-01-16. It
includes the following patches:
tracing: Move hist trigger Documentation to histogram.txt
tracing: Add Documentation for log2 modifier
tracing: Add support to detect and avoid duplicates
tracing: Remove code which merges duplicates
ring-buffer: Add interface for setting absolute time stamps
ring-buffer: Redefine the unimplemented RINGBUF_TYPE_TIME_STAMP
tracing: Add timestamp_mode trace file
tracing: Give event triggers access to ring_buffer_event
tracing: Add ring buffer event param to hist field functions
tracing: Break out hist trigger assignment parsing
tracing: Add hist trigger timestamp support
tracing: Add per-element variable support to tracing_map
tracing: Add hist_data member to hist_field
tracing: Add usecs modifier for hist trigger timestamps
tracing: Add variable support to hist triggers
tracing: Account for variables in named trigger compatibility
tracing: Move get_hist_field_flags()
tracing: Add simple expression support to hist triggers
tracing: Generalize per-element hist trigger data
tracing: Pass tracing_map_elt to hist_field accessor functions
tracing: Add hist_field 'type' field
tracing: Add variable reference handling to hist triggers
tracing: Add hist trigger action hook
tracing: Add support for 'synthetic' events
tracing: Add support for 'field variables'
tracing: Add 'onmatch' hist trigger action support
tracing: Add 'onmax' hist trigger action support
tracing: Allow whitespace to surround hist trigger filter
tracing: Add cpu field for hist triggers
tracing: Add hist trigger support for variable reference aliases
tracing: Add 'last error' error facility for hist triggers
tracing: Add inter-event hist trigger Documentation
tracing: Make tracing_set_clock() non-static
tracing: Add a clock attribute for hist triggers
tracing: Increase trace_recursive_lock() limit for synthetic events
tracing: Add inter-event blurb to HIST_TRIGGERS config option
selftests: ftrace: Add inter-event hist triggers testcases
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
TEMP: dt-bindings: soc: ti: Add Keystone DSP Memory mapping binding
Add the device tree binding document for the userspace memory mapping
driver on TI Keystone SoCs. This driver is used to expose either some
portions of the DDR and/or some portions of the On-chip RAM controlled
by the Multicore Shared Memory Controller (MSMC) to userspace for the
Multi Proc Manager (MPM) stack.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add the device tree binding document for the userspace memory mapping
driver on TI Keystone SoCs. This driver is used to expose either some
portions of the DDR and/or some portions of the On-chip RAM controlled
by the Multicore Shared Memory Controller (MSMC) to userspace for the
Multi Proc Manager (MPM) stack.
Signed-off-by: Suman Anna <s-anna@ti.com>
Revert "net: sysrq via icmp"
This reverts commit c3be7bd61d19 ("net: sysrq via icmp").
Carsten suggested to remove it from the queue since probably won't reach
mainline.
Cc: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This reverts commit c3be7bd61d19 ("net: sysrq via icmp").
Carsten suggested to remove it from the queue since probably won't reach
mainline.
Cc: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
v4.14.15-rt11
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Merge tag 'v4.14.15' into linux-4.14.y-rt
This is the 4.14.15 stable release
This is the 4.14.15 stable release
Merge tag 'v4.14.15' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.14.y
This is the 4.14.15 stable release
* tag 'v4.14.15' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (91 commits)
Linux 4.14.15
MIPS: AR7: ensure the port type's FCR value is used
net: mvpp2: do not disable GMAC padding
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()
x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
x86/pti: Document fix wrong index
kprobes/x86: Disable optimizing on the function jumps to indirect thunk
kprobes/x86: Blacklist indirect thunk functions for kprobes
retpoline: Introduce start/end markers of indirect thunk
x86/mce: Make machine check speculation protected
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
MIPS: CM: Drop WARN_ON(vp != 0)
alpha/PCI: Fix noname IRQ level detection
x86: Use __nostackprotect for sme_encrypt_kernel
dm crypt: fix error return code in crypt_ctr()
dm crypt: wipe kernel key copy after IV initialization
dm crypt: fix crash by adding missing check for auth key size
dm integrity: don't store cipher request on the stack
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
This is the 4.14.15 stable release
* tag 'v4.14.15' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (91 commits)
Linux 4.14.15
MIPS: AR7: ensure the port type's FCR value is used
net: mvpp2: do not disable GMAC padding
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()
x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
x86/pti: Document fix wrong index
kprobes/x86: Disable optimizing on the function jumps to indirect thunk
kprobes/x86: Blacklist indirect thunk functions for kprobes
retpoline: Introduce start/end markers of indirect thunk
x86/mce: Make machine check speculation protected
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
MIPS: CM: Drop WARN_ON(vp != 0)
alpha/PCI: Fix noname IRQ level detection
x86: Use __nostackprotect for sme_encrypt_kernel
dm crypt: fix error return code in crypt_ctr()
dm crypt: wipe kernel key copy after IV initialization
dm crypt: fix crash by adding missing check for auth key size
dm integrity: don't store cipher request on the stack
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Linux 4.14.15
MIPS: AR7: ensure the port type's FCR value is used
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0a5191efe06b5103909206e4fbcff81d30283f8e upstream.
Since commit aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt
trigger I/F of FIFO buffers"), the port's default FCR value isn't used
in serial8250_do_set_termios anymore, but copied over once in
serial8250_config_port and then modified as needed.
Unfortunately, serial8250_config_port will never be called if the port
is shared between kernel and userspace, and the port's flag doesn't have
UPF_BOOT_AUTOCONF, which would trigger a serial8250_config_port as well.
This causes garbled output from userspace:
[ 5.220000] random: procd urandom read with 49 bits of entropy available
ers
[kee
Fix this by forcing it to be configured on boot, resulting in the
expected output:
[ 5.250000] random: procd urandom read with 50 bits of entropy available
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
Fixes: aef9a7bd9b67 ("serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17544/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: mvpp2: do not disable GMAC padding
commit e749aca84b10f3987b2ee1f76e0c7d8aacc5653c upstream.
Short fragmented packets may never be sent by the hardware when padding
is disabled. This patch stop modifying the GMAC padding bits, to leave
them to their reset value (disabled).
Fixes: 3919357fb0bb ("net: mvpp2: initialize the GMAC when using a port")
Signed-off-by: Yan Markman <ymarkman@marvell.com>
[Antoine: commit message]
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e749aca84b10f3987b2ee1f76e0c7d8aacc5653c upstream.
Short fragmented packets may never be sent by the hardware when padding
is disabled. This patch stop modifying the GMAC padding bits, to leave
them to their reset value (disabled).
Fixes: 3919357fb0bb ("net: mvpp2: initialize the GMAC when using a port")
Signed-off-by: Yan Markman <ymarkman@marvell.com>
[Antoine: commit message]
Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm, page_vma_mapped: Drop faulty pointer arithmetics in check_pte()
commit 0d665e7b109d512b7cae3ccef6e8654714887844 upstream.
Tetsuo reported random crashes under memory pressure on 32-bit x86
system and tracked down to change that introduced
page_vma_mapped_walk().
The root cause of the issue is the faulty pointer math in check_pte().
As ->pte may point to an arbitrary page we have to check that they are
belong to the section before doing math. Otherwise it may lead to weird
results.
It wasn't noticed until now as mem_map[] is virtually contiguous on
flatmem or vmemmap sparsemem. Pointer arithmetic just works against all
'struct page' pointers. But with classic sparsemem, it doesn't because
each section memap is allocated separately and so consecutive pfns
crossing two sections might have struct pages at completely unrelated
addresses.
Let's restructure code a bit and replace pointer arithmetic with
operations on pfns.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-and-tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0d665e7b109d512b7cae3ccef6e8654714887844 upstream.
Tetsuo reported random crashes under memory pressure on 32-bit x86
system and tracked down to change that introduced
page_vma_mapped_walk().
The root cause of the issue is the faulty pointer math in check_pte().
As ->pte may point to an arbitrary page we have to check that they are
belong to the section before doing math. Otherwise it may lead to weird
results.
It wasn't noticed until now as mem_map[] is virtually contiguous on
flatmem or vmemmap sparsemem. Pointer arithmetic just works against all
'struct page' pointers. But with classic sparsemem, it doesn't because
each section memap is allocated separately and so consecutive pfns
crossing two sections might have struct pages at completely unrelated
addresses.
Let's restructure code a bit and replace pointer arithmetic with
operations on pfns.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-and-tested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Acked-by: Michal Hocko <mhocko@suse.com>
Fixes: ace71a19cec5 ("mm: introduce page_vma_mapped_walk()")
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Rework wbinvd, hlt operation in stop_this_cpu()
commit f23d74f6c66c3697e032550eeef3f640391a3a7d upstream.
Some issues have been reported with the for loop in stop_this_cpu() that
issues the 'wbinvd; hlt' sequence. Reverting this sequence to halt()
has been shown to resolve the issue.
However, the wbinvd is needed when running with SME. The reason for the
wbinvd is to prevent cache flush races between encrypted and non-encrypted
entries that have the same physical address. This can occur when
kexec'ing from memory encryption active to inactive or vice-versa. The
important thing is to not have outside of kernel text memory references
(such as stack usage), so the usage of the native_*() functions is needed
since these expand as inline asm sequences. So instead of reverting the
change, rework the sequence.
Move the wbinvd instruction outside of the for loop as native_wbinvd()
and make its execution conditional on X86_FEATURE_SME. In the for loop,
change the asm 'wbinvd; hlt' sequence back to a halt sequence but use
the native_halt() call.
Fixes: bba4ed011a52 ("x86/mm, kexec: Allow kexec to be used with SME")
Reported-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Yu Chen <yu.c.chen@intel.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kexec@lists.infradead.org
Cc: ebiederm@redhat.com
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rui Zhang <rui.zhang@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Link: https://lkml.kernel.org/r/20180117234141.21184.44067.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f23d74f6c66c3697e032550eeef3f640391a3a7d upstream.
Some issues have been reported with the for loop in stop_this_cpu() that
issues the 'wbinvd; hlt' sequence. Reverting this sequence to halt()
has been shown to resolve the issue.
However, the wbinvd is needed when running with SME. The reason for the
wbinvd is to prevent cache flush races between encrypted and non-encrypted
entries that have the same physical address. This can occur when
kexec'ing from memory encryption active to inactive or vice-versa. The
important thing is to not have outside of kernel text memory references
(such as stack usage), so the usage of the native_*() functions is needed
since these expand as inline asm sequences. So instead of reverting the
change, rework the sequence.
Move the wbinvd instruction outside of the for loop as native_wbinvd()
and make its execution conditional on X86_FEATURE_SME. In the for loop,
change the asm 'wbinvd; hlt' sequence back to a halt sequence but use
the native_halt() call.
Fixes: bba4ed011a52 ("x86/mm, kexec: Allow kexec to be used with SME")
Reported-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Dave Young <dyoung@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Yu Chen <yu.c.chen@intel.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: kexec@lists.infradead.org
Cc: ebiederm@redhat.com
Cc: Borislav Petkov <bp@alien8.de>
Cc: Rui Zhang <rui.zhang@intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Link: https://lkml.kernel.org/r/20180117234141.21184.44067.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/retpoline: Optimize inline assembler for vmexit_fill_RSB
commit 3f7d875566d8e79c5e0b2c9a413e91b2c29e0854 upstream.
The generated assembler for the C fill RSB inline asm operations has
several issues:
- The C code sets up the loop register, which is then immediately
overwritten in __FILL_RETURN_BUFFER with the same value again.
- The C code also passes in the iteration count in another register, which
is not used at all.
Remove these two unnecessary operations. Just rely on the single constant
passed to the macro for the iterations.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: dave.hansen@intel.com
Cc: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org
Cc: arjan@linux.intel.com
Link: https://lkml.kernel.org/r/20180117225328.15414-1-andi@firstfloor.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f7d875566d8e79c5e0b2c9a413e91b2c29e0854 upstream.
The generated assembler for the C fill RSB inline asm operations has
several issues:
- The C code sets up the loop register, which is then immediately
overwritten in __FILL_RETURN_BUFFER with the same value again.
- The C code also passes in the iteration count in another register, which
is not used at all.
Remove these two unnecessary operations. Just rely on the single constant
passed to the macro for the iterations.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: dave.hansen@intel.com
Cc: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org
Cc: arjan@linux.intel.com
Link: https://lkml.kernel.org/r/20180117225328.15414-1-andi@firstfloor.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/pti: Document fix wrong index
commit 98f0fceec7f84d80bc053e49e596088573086421 upstream.
In section <2. Runtime Cost>, fix wrong index.
Signed-off-by: zhenwei.pi <zhenwei.pi@youruncloud.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: dave.hansen@linux.intel.com
Link: https://lkml.kernel.org/r/1516237492-27739-1-git-send-email-zhenwei.pi@youruncloud.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98f0fceec7f84d80bc053e49e596088573086421 upstream.
In section <2. Runtime Cost>, fix wrong index.
Signed-off-by: zhenwei.pi <zhenwei.pi@youruncloud.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: dave.hansen@linux.intel.com
Link: https://lkml.kernel.org/r/1516237492-27739-1-git-send-email-zhenwei.pi@youruncloud.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kprobes/x86: Disable optimizing on the function jumps to indirect thunk
commit c86a32c09f8ced67971a2310e3b0dda4d1749007 upstream.
Since indirect jump instructions will be replaced by jump
to __x86_indirect_thunk_*, those jmp instruction must be
treated as an indirect jump. Since optprobe prohibits to
optimize probes in the function which uses an indirect jump,
it also needs to find out the function which jump to
__x86_indirect_thunk_* and disable optimization.
Add a check that the jump target address is between the
__indirect_thunk_start/end when optimizing kprobe.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629212062.10241.6991266100233002273.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c86a32c09f8ced67971a2310e3b0dda4d1749007 upstream.
Since indirect jump instructions will be replaced by jump
to __x86_indirect_thunk_*, those jmp instruction must be
treated as an indirect jump. Since optprobe prohibits to
optimize probes in the function which uses an indirect jump,
it also needs to find out the function which jump to
__x86_indirect_thunk_* and disable optimization.
Add a check that the jump target address is between the
__indirect_thunk_start/end when optimizing kprobe.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629212062.10241.6991266100233002273.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kprobes/x86: Blacklist indirect thunk functions for kprobes
commit c1804a236894ecc942da7dc6c5abe209e56cba93 upstream.
Mark __x86_indirect_thunk_* functions as blacklist for kprobes
because those functions can be called from anywhere in the kernel
including blacklist functions of kprobes.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629209111.10241.5444852823378068683.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1804a236894ecc942da7dc6c5abe209e56cba93 upstream.
Mark __x86_indirect_thunk_* functions as blacklist for kprobes
because those functions can be called from anywhere in the kernel
including blacklist functions of kprobes.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629209111.10241.5444852823378068683.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
retpoline: Introduce start/end markers of indirect thunk
commit 736e80a4213e9bbce40a7c050337047128b472ac upstream.
Introduce start/end markers of __x86_indirect_thunk_* functions.
To make it easy, consolidate .text.__x86.indirect_thunk.* sections
to one .text.__x86.indirect_thunk section and put it in the
end of kernel text section and adds __indirect_thunk_start/end
so that other subsystem (e.g. kprobes) can identify it.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629206178.10241.6828804696410044771.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 736e80a4213e9bbce40a7c050337047128b472ac upstream.
Introduce start/end markers of __x86_indirect_thunk_* functions.
To make it easy, consolidate .text.__x86.indirect_thunk.* sections
to one .text.__x86.indirect_thunk section and put it in the
end of kernel text section and adds __indirect_thunk_start/end
so that other subsystem (e.g. kprobes) can identify it.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org>
Link: https://lkml.kernel.org/r/151629206178.10241.6828804696410044771.stgit@devbox
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mce: Make machine check speculation protected
commit 6f41c34d69eb005e7848716bbcafc979b35037d5 upstream.
The machine check idtentry uses an indirect branch directly from the low
level code. This evades the speculation protection.
Replace it by a direct call into C code and issue the indirect call there
so the compiler can apply the proper speculation protection.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by:Borislav Petkov <bp@alien8.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Niced-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801181626290.1847@nanos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f41c34d69eb005e7848716bbcafc979b35037d5 upstream.
The machine check idtentry uses an indirect branch directly from the low
level code. This evades the speculation protection.
Replace it by a direct call into C code and issue the indirect call there
so the compiler can apply the proper speculation protection.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by:Borislav Petkov <bp@alien8.de>
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Niced-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801181626290.1847@nanos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arm64: KVM: Fix SMCCC handling of unimplemented SMC/HVC calls
commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit acfb3b883f6d6a4b5d27ad7fdded11f6a09ae6dd upstream.
KVM doesn't follow the SMCCC when it comes to unimplemented calls,
and inject an UNDEF instead of returning an error. Since firmware
calls are now used for security mitigation, they are becoming more
common, and the undef is counter productive.
Instead, let's follow the SMCCC which states that -1 must be returned
to the caller when getting an unknown function number.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KVM: arm/arm64: Check pagesize when allocating a hugepage at Stage 2
commit c507babf10ead4d5c8cca704539b170752a8ac84 upstream.
KVM only supports PMD hugepages at stage 2 but doesn't actually check
that the provided hugepage memory pagesize is PMD_SIZE before populating
stage 2 entries.
In cases where the backing hugepage size is smaller than PMD_SIZE (such
as when using contiguous hugepages), KVM can end up creating stage 2
mappings that extend beyond the supplied memory.
Fix this by checking for the pagesize of userspace vma before creating
PMD hugepage at stage 2.
Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c507babf10ead4d5c8cca704539b170752a8ac84 upstream.
KVM only supports PMD hugepages at stage 2 but doesn't actually check
that the provided hugepage memory pagesize is PMD_SIZE before populating
stage 2 entries.
In cases where the backing hugepage size is smaller than PMD_SIZE (such
as when using contiguous hugepages), KVM can end up creating stage 2
mappings that extend beyond the supplied memory.
Fix this by checking for the pagesize of userspace vma before creating
PMD hugepage at stage 2.
Fixes: 66b3923a1a0f77a ("arm64: hugetlb: add support for PTE contiguous bit")
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
MIPS: CM: Drop WARN_ON(vp != 0)
commit c04de7b1ad645b61c141df8ca903ba0cc03a57f7 upstream.
Since commit 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to
mips_cm_lock_other()"), mips_smp_send_ipi_mask() has used
mips_cm_lock_other_cpu() with each CPU number, rather than
mips_cm_lock_other() with the first VPE in each core. Prior to r6,
multicore multithreaded systems such as dual-core dual-thread
interAptivs with CPU Idle enabled (e.g. MIPS Creator Ci40) results in
mips_cm_lock_other() repeatedly hitting WARN_ON(vp != 0).
There doesn't appear to be anything fundamentally wrong about passing a
non-zero VP/VPE number, even if it is a core's region that is locked
into the other region before r6, so remove that particular WARN_ON().
Fixes: 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to mips_cm_lock_other()")
Signed-off-by: James Hogan <jhogan@kernel.org>
Reviewed-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17883/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c04de7b1ad645b61c141df8ca903ba0cc03a57f7 upstream.
Since commit 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to
mips_cm_lock_other()"), mips_smp_send_ipi_mask() has used
mips_cm_lock_other_cpu() with each CPU number, rather than
mips_cm_lock_other() with the first VPE in each core. Prior to r6,
multicore multithreaded systems such as dual-core dual-thread
interAptivs with CPU Idle enabled (e.g. MIPS Creator Ci40) results in
mips_cm_lock_other() repeatedly hitting WARN_ON(vp != 0).
There doesn't appear to be anything fundamentally wrong about passing a
non-zero VP/VPE number, even if it is a core's region that is locked
into the other region before r6, so remove that particular WARN_ON().
Fixes: 68923cdc2eb3 ("MIPS: CM: Add cluster & block args to mips_cm_lock_other()")
Signed-off-by: James Hogan <jhogan@kernel.org>
Reviewed-by: Paul Burton <paul.burton@mips.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17883/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
alpha/PCI: Fix noname IRQ level detection
commit 86be89939d11a84800f66e2a283b915b704bf33d upstream.
The conversion of the alpha architecture PCI host bridge legacy IRQ
mapping/swizzling to the new PCI host bridge map/swizzle hooks carried
out through:
commit 0e4c2eeb758a ("alpha/PCI: Replace pci_fixup_irqs() call with
host bridge IRQ mapping hooks")
implies that IRQ for devices are now allocated through pci_assign_irq()
function in pci_device_probe() that is called when a driver matching a
device is found in order to probe the device through the device driver.
Alpha noname platforms required IRQ level programming to be executed
in sio_fixup_irq_levels(), that is called in noname_init_pci(), a
platform hook called within a subsys_initcall.
In noname_init_pci(), present IRQs are detected through
sio_collect_irq_levels() that check the struct pci_dev->irq number
to detect if an IRQ has been allocated for the device.
By the time sio_collect_irq_levels() is called, some devices may still
have not a matching driver loaded to match them (eg loadable module)
therefore their IRQ allocation is still pending - which means that
sio_collect_irq_levels() does not programme the correct IRQ level for
those devices, causing their IRQ handling to be broken when the device
driver is actually loaded and the device is probed.
Fix the issue by adding code in the noname map_irq() function
(noname_map_irq()) that, whilst mapping/swizzling the IRQ line, it also
ensures that the correct IRQ level programming is executed at platform
level, fixing the issue.
Fixes: 0e4c2eeb758a ("alpha/PCI: Replace pci_fixup_irqs() call with
host bridge IRQ mapping hooks")
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Meelis Roos <mroos@linux.ee>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86be89939d11a84800f66e2a283b915b704bf33d upstream.
The conversion of the alpha architecture PCI host bridge legacy IRQ
mapping/swizzling to the new PCI host bridge map/swizzle hooks carried
out through:
commit 0e4c2eeb758a ("alpha/PCI: Replace pci_fixup_irqs() call with
host bridge IRQ mapping hooks")
implies that IRQ for devices are now allocated through pci_assign_irq()
function in pci_device_probe() that is called when a driver matching a
device is found in order to probe the device through the device driver.
Alpha noname platforms required IRQ level programming to be executed
in sio_fixup_irq_levels(), that is called in noname_init_pci(), a
platform hook called within a subsys_initcall.
In noname_init_pci(), present IRQs are detected through
sio_collect_irq_levels() that check the struct pci_dev->irq number
to detect if an IRQ has been allocated for the device.
By the time sio_collect_irq_levels() is called, some devices may still
have not a matching driver loaded to match them (eg loadable module)
therefore their IRQ allocation is still pending - which means that
sio_collect_irq_levels() does not programme the correct IRQ level for
those devices, causing their IRQ handling to be broken when the device
driver is actually loaded and the device is probed.
Fix the issue by adding code in the noname map_irq() function
(noname_map_irq()) that, whilst mapping/swizzling the IRQ line, it also
ensures that the correct IRQ level programming is executed at platform
level, fixing the issue.
Fixes: 0e4c2eeb758a ("alpha/PCI: Replace pci_fixup_irqs() call with
host bridge IRQ mapping hooks")
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: Meelis Roos <mroos@linux.ee>
Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86: Use __nostackprotect for sme_encrypt_kernel
commit 91cfc88c66bf8ab95937606569670cf67fa73e09 upstream.
Commit bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME
PGD mapping") moved some parameters into a structure.
The structure was large enough to trigger the stack protection canary in
sme_encrypt_kernel which doesn't work this early, causing reboots.
Mark sme_encrypt_kernel appropriately to not use the canary.
Fixes: bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping")
Signed-off-by: Laura Abbott <labbott@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 91cfc88c66bf8ab95937606569670cf67fa73e09 upstream.
Commit bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME
PGD mapping") moved some parameters into a structure.
The structure was large enough to trigger the stack protection canary in
sme_encrypt_kernel which doesn't work this early, causing reboots.
Mark sme_encrypt_kernel appropriately to not use the canary.
Fixes: bacf6b499e11 ("x86/mm: Use a struct to reduce parameters for SME PGD mapping")
Signed-off-by: Laura Abbott <labbott@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm crypt: fix error return code in crypt_ctr()
commit 3cc2e57c4beabcbbaa46e1ac6d77ca8276a4a42d upstream.
Fix to return error code -ENOMEM from the mempool_create_kmalloc_pool()
error handling case instead of 0, as done elsewhere in this function.
Fixes: ef43aa38063a6 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3cc2e57c4beabcbbaa46e1ac6d77ca8276a4a42d upstream.
Fix to return error code -ENOMEM from the mempool_create_kmalloc_pool()
error handling case instead of 0, as done elsewhere in this function.
Fixes: ef43aa38063a6 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm crypt: wipe kernel key copy after IV initialization
commit dc94902bde1e158cd19c4deab208e5d6eb382a44 upstream.
Loading key via kernel keyring service erases the internal
key copy immediately after we pass it in crypto layer. This is
wrong because IV is initialized later and we use wrong key
for the initialization (instead of real key there's just zeroed
block).
The bug may cause data corruption if key is loaded via kernel keyring
service first and later same crypt device is reactivated using exactly
same key in hexbyte representation, or vice versa. The bug (and fix)
affects only ciphers using following IVs: essiv, lmk and tcw.
Fixes: c538f6ec9f56 ("dm crypt: add ability to use keys from the kernel key retention service")
Signed-off-by: Ondrej Kozina <okozina@redhat.com>
Reviewed-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dc94902bde1e158cd19c4deab208e5d6eb382a44 upstream.
Loading key via kernel keyring service erases the internal
key copy immediately after we pass it in crypto layer. This is
wrong because IV is initialized later and we use wrong key
for the initialization (instead of real key there's just zeroed
block).
The bug may cause data corruption if key is loaded via kernel keyring
service first and later same crypt device is reactivated using exactly
same key in hexbyte representation, or vice versa. The bug (and fix)
affects only ciphers using following IVs: essiv, lmk and tcw.
Fixes: c538f6ec9f56 ("dm crypt: add ability to use keys from the kernel key retention service")
Signed-off-by: Ondrej Kozina <okozina@redhat.com>
Reviewed-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm crypt: fix crash by adding missing check for auth key size
commit 27c7003697fc2c78f965984aa224ef26cd6b2949 upstream.
If dm-crypt uses authenticated mode with separate MAC, there are two
concatenated part of the key structure - key(s) for encryption and
authentication key.
Add a missing check for authenticated key length. If this key length is
smaller than actually provided key, dm-crypt now properly fails instead
of crashing.
Fixes: ef43aa3806 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
Reported-by: Salah Coronya <salahx@yahoo.com>
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27c7003697fc2c78f965984aa224ef26cd6b2949 upstream.
If dm-crypt uses authenticated mode with separate MAC, there are two
concatenated part of the key structure - key(s) for encryption and
authentication key.
Add a missing check for authenticated key length. If this key length is
smaller than actually provided key, dm-crypt now properly fails instead
of crashing.
Fixes: ef43aa3806 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
Reported-by: Salah Coronya <salahx@yahoo.com>
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm integrity: don't store cipher request on the stack
commit 717f4b1c52135f279112df82583e0c77e80f90de upstream.
Some asynchronous cipher implementations may use DMA. The stack may
be mapped in the vmalloc area that doesn't support DMA. Therefore,
the cipher request and initialization vector shouldn't be on the
stack.
Fix this by allocating the request and iv with kmalloc.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 717f4b1c52135f279112df82583e0c77e80f90de upstream.
Some asynchronous cipher implementations may use DMA. The stack may
be mapped in the vmalloc area that doesn't support DMA. Therefore,
the cipher request and initialization vector shouldn't be on the
stack.
Fix this by allocating the request and iv with kmalloc.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6
commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf upstream.
For btree removal, there is a corner case that a single thread
could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5)
and leads to deadlock.
A btree removal might eventually call
rebalance_children()->rebalance3() to rebalance entries of three
neighbor child nodes when shadow_spine has already acquired two
write locks. In rebalance3(), it tries to shadow and acquire the
write locks of all three child nodes. However, shadowing a child
node requires acquiring a read lock of the original child node and
a write lock of the new block. Although the read lock will be
released after block shadowing, shadowing the third child node
in rebalance3() could still take the sixth lock.
(2 write locks for shadow_spine +
2 write locks for the first two child nodes's shadow +
1 write lock for the last child node's shadow +
1 read lock for the last child node)
Signed-off-by: Dennis Yang <dennisyang@qnap.com>
Acked-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf upstream.
For btree removal, there is a corner case that a single thread
could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5)
and leads to deadlock.
A btree removal might eventually call
rebalance_children()->rebalance3() to rebalance entries of three
neighbor child nodes when shadow_spine has already acquired two
write locks. In rebalance3(), it tries to shadow and acquire the
write locks of all three child nodes. However, shadowing a child
node requires acquiring a read lock of the original child node and
a write lock of the new block. Although the read lock will be
released after block shadowing, shadowing the third child node
in rebalance3() could still take the sixth lock.
(2 write locks for shadow_spine +
2 write locks for the first two child nodes's shadow +
1 write lock for the last child node's shadow +
1 read lock for the last child node)
Signed-off-by: Dennis Yang <dennisyang@qnap.com>
Acked-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dm btree: fix serious bug in btree_split_beneath()
commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 upstream.
When inserting a new key/value pair into a btree we walk down the spine of
btree nodes performing the following 2 operations:
i) space for a new entry
ii) adjusting the first key entry if the new key is lower than any in the node.
If the _root_ node is full, the function btree_split_beneath() allocates 2 new
nodes, and redistibutes the root nodes entries between them. The root node is
left with 2 entries corresponding to the 2 new nodes.
btree_split_beneath() then adjusts the spine to point to one of the two new
children. This means the first key is never adjusted if the new key was lower,
ie. operation (ii) gets missed out. This can result in the new key being
'lost' for a period; until another low valued key is inserted that will uncover
it.
This is a serious bug, and quite hard to make trigger in normal use. A
reproducing test case ("thin create devices-in-reverse-order") is
available as part of the thin-provision-tools project:
https://github.com/jthornber/thin-provisioning-tools/blob/master/functional-tests/device-mapper/dm-tests.scm#L593
Fix the issue by changing btree_split_beneath() so it no longer adjusts
the spine. Instead it unlocks both the new nodes, and lets the main
loop in btree_insert_raw() relock the appropriate one and make any
neccessary adjustments.
Reported-by: Monty Pavel <monty_pavel@sina.com>
Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 upstream.
When inserting a new key/value pair into a btree we walk down the spine of
btree nodes performing the following 2 operations:
i) space for a new entry
ii) adjusting the first key entry if the new key is lower than any in the node.
If the _root_ node is full, the function btree_split_beneath() allocates 2 new
nodes, and redistibutes the root nodes entries between them. The root node is
left with 2 entries corresponding to the 2 new nodes.
btree_split_beneath() then adjusts the spine to point to one of the two new
children. This means the first key is never adjusted if the new key was lower,
ie. operation (ii) gets missed out. This can result in the new key being
'lost' for a period; until another low valued key is inserted that will uncover
it.
This is a serious bug, and quite hard to make trigger in normal use. A
reproducing test case ("thin create devices-in-reverse-order") is
available as part of the thin-provision-tools project:
https://github.com/jthornber/thin-provisioning-tools/blob/master/functional-tests/device-mapper/dm-tests.scm#L593
Fix the issue by changing btree_split_beneath() so it no longer adjusts
the spine. Instead it unlocks both the new nodes, and lets the main
loop in btree_insert_raw() relock the appropriate one and make any
neccessary adjustments.
Reported-by: Monty Pavel <monty_pavel@sina.com>
Signed-off-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/vmwgfx: fix memory corruption with legacy/sou connectors
commit 8a510a5c75261ba0ec39155326982aa786541e29 upstream.
It looks like in all cases 'struct vmw_connector_state' is used. But
only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
subclassed. Leading to writes beyond the end of the allocated connector
state block and all sorts of fun memory corruption related crashes.
Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Signed-off-by: Rob Clark <rclark@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a510a5c75261ba0ec39155326982aa786541e29 upstream.
It looks like in all cases 'struct vmw_connector_state' is used. But
only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
subclassed. Leading to writes beyond the end of the allocated connector
state block and all sorts of fun memory corruption related crashes.
Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
Signed-off-by: Rob Clark <rclark@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
workqueue: avoid hard lockups in show_workqueue_state()
commit 62635ea8c18f0f62df4cc58379e4f1d33afd5801 upstream.
show_workqueue_state() can print out a lot of messages while being in
atomic context, e.g. sysrq-t -> show_workqueue_state(). If the console
device is slow it may end up triggering NMI hard lockup watchdog.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 62635ea8c18f0f62df4cc58379e4f1d33afd5801 upstream.
show_workqueue_state() can print out a lot of messages while being in
atomic context, e.g. sysrq-t -> show_workqueue_state(). If the console
device is slow it may end up triggering NMI hard lockup watchdog.
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scsi: libsas: Disable asynchronous aborts for SATA devices
commit c9f926000fe3b84135a81602a9f7e63a6a7898e2 upstream.
Handling CD-ROM devices from libsas is decidedly odd, as libata relies
on SCSI EH to be started to figure out that no medium is present. So we
cannot do asynchronous aborts for SATA devices.
Fixes: 909657615d9 ("scsi: libsas: allow async aborts")
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9f926000fe3b84135a81602a9f7e63a6a7898e2 upstream.
Handling CD-ROM devices from libsas is decidedly odd, as libata relies
on SCSI EH to be started to figure out that no medium is present. So we
cannot do asynchronous aborts for SATA devices.
Fixes: 909657615d9 ("scsi: libsas: allow async aborts")
Signed-off-by: Hannes Reinecke <hare@suse.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Tested-by: Yves-Alexis Perez <corsac@debian.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
libata: apply MAX_SEC_1024 to all LITEON EP1 series devices
commit db5ff909798ef0099004ad50a0ff5fde92426fd1 upstream.
LITEON EP1 has the same timeout issues as CX1 series devices.
Revert max_sectors to the value of 1024.
Fixes: e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")
Signed-off-by: Xinyu Lin <xinyu0123@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db5ff909798ef0099004ad50a0ff5fde92426fd1 upstream.
LITEON EP1 has the same timeout issues as CX1 series devices.
Revert max_sectors to the value of 1024.
Fixes: e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")
Signed-off-by: Xinyu Lin <xinyu0123@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
proc: fix coredump vs read /proc/*/stat race
commit 8bb2ee192e482c5d500df9f2b1b26a560bd3026f upstream.
do_task_stat() accesses IP and SP of a task without bumping reference
count of a stack (which became an entity with independent lifetime at
some point).
Steps to reproduce:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <sys/wait.h>
int main(void)
{
setrlimit(RLIMIT_CORE, &(struct rlimit){});
while (1) {
char buf[64];
char buf2[4096];
pid_t pid;
int fd;
pid = fork();
if (pid == 0) {
*(volatile int *)0 = 0;
}
snprintf(buf, sizeof(buf), "/proc/%u/stat", pid);
fd = open(buf, O_RDONLY);
read(fd, buf2, sizeof(buf2));
close(fd);
waitpid(pid, NULL, 0);
}
return 0;
}
BUG: unable to handle kernel paging request at 0000000000003fd8
IP: do_task_stat+0x8b4/0xaf0
PGD 800000003d73e067 P4D 800000003d73e067 PUD 3d558067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 1417 Comm: a.out Not tainted 4.15.0-rc8-dirty #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
RIP: 0010:do_task_stat+0x8b4/0xaf0
Call Trace:
proc_single_show+0x43/0x70
seq_read+0xe6/0x3b0
__vfs_read+0x1e/0x120
vfs_read+0x84/0x110
SyS_read+0x3d/0xa0
entry_SYSCALL_64_fastpath+0x13/0x6c
RIP: 0033:0x7f4d7928cba0
RSP: 002b:00007ffddb245158 EFLAGS: 00000246
Code: 03 b7 a0 01 00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9 ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24
RIP: do_task_stat+0x8b4/0xaf0 RSP: ffffc90000607cc8
CR2: 0000000000003fd8
John Ogness said: for my tests I added an else case to verify that the
race is hit and correctly mitigated.
Link: http://lkml.kernel.org/r/20180116175054.GA11513@avx2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Reported-by: "Kohli, Gaurav" <gkohli@codeaurora.org>
Tested-by: John Ogness <john.ogness@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8bb2ee192e482c5d500df9f2b1b26a560bd3026f upstream.
do_task_stat() accesses IP and SP of a task without bumping reference
count of a stack (which became an entity with independent lifetime at
some point).
Steps to reproduce:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/time.h>
#include <sys/resource.h>
#include <unistd.h>
#include <sys/wait.h>
int main(void)
{
setrlimit(RLIMIT_CORE, &(struct rlimit){});
while (1) {
char buf[64];
char buf2[4096];
pid_t pid;
int fd;
pid = fork();
if (pid == 0) {
*(volatile int *)0 = 0;
}
snprintf(buf, sizeof(buf), "/proc/%u/stat", pid);
fd = open(buf, O_RDONLY);
read(fd, buf2, sizeof(buf2));
close(fd);
waitpid(pid, NULL, 0);
}
return 0;
}
BUG: unable to handle kernel paging request at 0000000000003fd8
IP: do_task_stat+0x8b4/0xaf0
PGD 800000003d73e067 P4D 800000003d73e067 PUD 3d558067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 1417 Comm: a.out Not tainted 4.15.0-rc8-dirty #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
RIP: 0010:do_task_stat+0x8b4/0xaf0
Call Trace:
proc_single_show+0x43/0x70
seq_read+0xe6/0x3b0
__vfs_read+0x1e/0x120
vfs_read+0x84/0x110
SyS_read+0x3d/0xa0
entry_SYSCALL_64_fastpath+0x13/0x6c
RIP: 0033:0x7f4d7928cba0
RSP: 002b:00007ffddb245158 EFLAGS: 00000246
Code: 03 b7 a0 01 00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9 ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24
RIP: do_task_stat+0x8b4/0xaf0 RSP: ffffc90000607cc8
CR2: 0000000000003fd8
John Ogness said: for my tests I added an else case to verify that the
race is hit and correctly mitigated.
Link: http://lkml.kernel.org/r/20180116175054.GA11513@avx2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Reported-by: "Kohli, Gaurav" <gkohli@codeaurora.org>
Tested-by: John Ogness <john.ogness@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
scripts/gdb/linux/tasks.py: fix get_thread_info
commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream.
Since kernel 4.9, the thread_info has been moved into task_struct, no
longer locates at the bottom of kernel stack.
See commits c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") and 15f4eae70d36 ("x86: Move thread_info into
task_struct").
Before fix:
(gdb) set $current = $lx_current()
(gdb) p $lx_thread_info($current)
$1 = {flags = 1470918301}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
After fix:
(gdb) p $lx_thread_info($current)
$1 = {flags = 2147483648}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
Signed-off-by: Xi Kangjie <imxikangjie@gmail.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Kieran Bingham <kbingham@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream.
Since kernel 4.9, the thread_info has been moved into task_struct, no
longer locates at the bottom of kernel stack.
See commits c65eacbe290b ("sched/core: Allow putting thread_info into
task_struct") and 15f4eae70d36 ("x86: Move thread_info into
task_struct").
Before fix:
(gdb) set $current = $lx_current()
(gdb) p $lx_thread_info($current)
$1 = {flags = 1470918301}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
After fix:
(gdb) p $lx_thread_info($current)
$1 = {flags = 2147483648}
(gdb) p $current.thread_info
$2 = {flags = 2147483648}
Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
Signed-off-by: Xi Kangjie <imxikangjie@gmail.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Acked-by: Kieran Bingham <kbingham@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.
It is possible from a user application to run into that issue by
calling the I2C_SMBUS ioctl with data.block[0] greater than
I2C_SMBUS_BLOCK_MAX + 1.
This patch makes the code compliant with
Documentation/i2c/dev-interface by raising an error when the requested
size is larger than 32 bytes.
Call Trace:
[<ffffffff8139f695>] dump_stack+0x67/0x92
[<ffffffff811802a4>] panic+0xc5/0x1eb
[<ffffffff810ecb5f>] ? vprintk_default+0x1f/0x30
[<ffffffff817456d3>] ? i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff8109a68b>] __stack_chk_fail+0x1b/0x20
[<ffffffff817456d3>] i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff81745aed>] i2cdev_ioctl+0x4d/0x1e0
[<ffffffff811f761a>] do_vfs_ioctl+0x2ba/0x490
[<ffffffff81336e43>] ? security_file_ioctl+0x43/0x60
[<ffffffff811f7869>] SyS_ioctl+0x79/0x90
[<ffffffff81a22e97>] entry_SYSCALL_64_fastpath+0x12/0x6a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.
It is possible from a user application to run into that issue by
calling the I2C_SMBUS ioctl with data.block[0] greater than
I2C_SMBUS_BLOCK_MAX + 1.
This patch makes the code compliant with
Documentation/i2c/dev-interface by raising an error when the requested
size is larger than 32 bytes.
Call Trace:
[<ffffffff8139f695>] dump_stack+0x67/0x92
[<ffffffff811802a4>] panic+0xc5/0x1eb
[<ffffffff810ecb5f>] ? vprintk_default+0x1f/0x30
[<ffffffff817456d3>] ? i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff8109a68b>] __stack_chk_fail+0x1b/0x20
[<ffffffff817456d3>] i2cdev_ioctl_smbus+0x303/0x320
[<ffffffff81745aed>] i2cdev_ioctl+0x4d/0x1e0
[<ffffffff811f761a>] do_vfs_ioctl+0x2ba/0x490
[<ffffffff81336e43>] ? security_file_ioctl+0x43/0x60
[<ffffffff811f7869>] SyS_ioctl+0x79/0x90
[<ffffffff81a22e97>] entry_SYSCALL_64_fastpath+0x12/0x6a
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
If an invalid CANFD frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
If an invalid CAN frame is received, from a driver or from a tun
interface, a Kernel warning is generated.
This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
kernel, bootet with panic_on_warn, does not panic. A printk seems to be
more appropriate here.
Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: peak: fix potential bug in packet fragmentation
commit d8a243af1a68395e07ac85384a2740d4134c67f4 upstream.
In some rare conditions when running one PEAK USB-FD interface over
a non high-speed USB controller, one useless USB fragment might be sent.
This patch fixes the way a USB command is fragmented when its length is
greater than 64 bytes and when the underlying USB controller is not a
high-speed one.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d8a243af1a68395e07ac85384a2740d4134c67f4 upstream.
In some rare conditions when running one PEAK USB-FD interface over
a non high-speed USB controller, one useless USB fragment might be sent.
This patch fixes the way a USB command is fragmented when its length is
greater than 64 bytes and when the underlying USB controller is not a
high-speed one.
Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
commit 56aeb07c914a616ab84357d34f8414a69b140cdf upstream.
MPP7 is currently muxed as "gpio", but this function doesn't exist for
MPP7, only "gpo" is available. This causes the following error:
kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
pinctrl core: failed to register map default (6): invalid type given
kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
So the pinctrl driver is not probed, all device drivers (including the
UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
really boot (well, it boots, but with no UART, and no devices that
require pin-muxing).
Back when the Device Tree file for this board was introduced, the
definition was already wrong. The pinctrl driver also always described
as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
a hog pin failing to be muxed was turned from a simple warning to a
hard error that caused the entire pinctrl driver probe to bail
out. This is probably the result of commit 6118714275f0a ("pinctrl:
core: Fix pinctrl_register_and_init() with pinctrl_enable()").
This commit fixes the Device Tree to use the proper "gpo" function for
MPP7, which fixes the boot of OpenBlocks A7, which was broken since
Linux 4.11.
Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 56aeb07c914a616ab84357d34f8414a69b140cdf upstream.
MPP7 is currently muxed as "gpio", but this function doesn't exist for
MPP7, only "gpo" is available. This causes the following error:
kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
pinctrl core: failed to register map default (6): invalid type given
kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
So the pinctrl driver is not probed, all device drivers (including the
UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
really boot (well, it boots, but with no UART, and no devices that
require pin-muxing).
Back when the Device Tree file for this board was introduced, the
definition was already wrong. The pinctrl driver also always described
as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
a hog pin failing to be muxed was turned from a simple warning to a
hard error that caused the entire pinctrl driver probe to bail
out. This is probably the result of commit 6118714275f0a ("pinctrl:
core: Fix pinctrl_register_and_init() with pinctrl_enable()").
This commit fixes the Device Tree to use the proper "gpo" function for
MPP7, which fixes the boot of OpenBlocks A7, which was broken since
Linux 4.11.
Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: sunxi_defconfig: Enable CMA
commit c13e7f313da33d1488355440f1a10feb1897480a upstream.
The DRM driver most notably, but also out of tree drivers (for now) like
the VPU or GPU drivers, are quite big consumers of large, contiguous memory
buffers. However, the sunxi_defconfig doesn't enable CMA in order to
mitigate that, which makes them almost unusable.
Enable it to make sure it somewhat works.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c13e7f313da33d1488355440f1a10feb1897480a upstream.
The DRM driver most notably, but also out of tree drivers (for now) like
the VPU or GPU drivers, are quite big consumers of large, contiguous memory
buffers. However, the sunxi_defconfig doesn't enable CMA in order to
mitigate that, which makes them almost unusable.
Enable it to make sure it somewhat works.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
commit e3af9f7c6ece29fdb7fe0aeb83ac5d3077a06edb upstream.
On the CP modules we found on Armada 7K/8K, many IP block actually also
need a "functional" clock (from the bus). This patch add them which allows
to fix some issues hanging the kernel:
If Ethernet and sdhci driver are built as modules and sdhci was loaded
first then the kernel hang.
Fixes: bb16ea1742c8 ("mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock")
Reported-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3af9f7c6ece29fdb7fe0aeb83ac5d3077a06edb upstream.
On the CP modules we found on Armada 7K/8K, many IP block actually also
need a "functional" clock (from the bus). This patch add them which allows
to fix some issues hanging the kernel:
If Ethernet and sdhci driver are built as modules and sdhci was loaded
first then the kernel hang.
Fixes: bb16ea1742c8 ("mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock")
Reported-by: Riku Voipio <riku.voipio@linaro.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
phy: work around 'phys' references to usb-nop-xceiv devices
commit b7563e2796f8b23c98afcfea7363194227fa089d upstream.
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.
I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).
To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.
Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.
Fixes: 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7563e2796f8b23c98afcfea7363194227fa089d upstream.
Stefan Wahren reports a problem with a warning fix that was merged
for v4.15: we had lots of device nodes with a 'phys' property pointing
to a device node that is not compliant with the binding documented in
Documentation/devicetree/bindings/phy/phy-bindings.txt
This generally works because USB HCD drivers that support both the generic
phy subsystem and the older usb-phy subsystem ignore most errors from
phy_get() and related calls and then use the usb-phy driver instead.
However, it turns out that making the usb-nop-xceiv device compatible with
the generic-phy binding changes the phy_get() return code from -EINVAL to
-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
-EPROBE_DEFER from its probe function rather than ignoring the failure,
breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
function, so a reasonable assumption would be that many other platforms
are affected as well.
I have reviewed all the related patches and concluded that "usb-nop-xceiv"
is the only USB phy that is affected by the change, and since it is by far
the most commonly referenced phy, all the other USB phy drivers appear
to be used in ways that are are either safe in DT (they don't use the
'phys' property), or in the driver (they already ignore -EPROBE_DEFER
from generic-phy when usb-phy is available).
To work around the problem, this adds a special case to _of_phy_get()
so we ignore any PHY node that is compatible with "usb-nop-xceiv",
as we know that this can never load no matter how much we defer. In the
future, we might implement a generic-phy driver for "usb-nop-xceiv"
and then remove this workaround.
Since we generally want older kernels to also want to work with the
fixed devicetree files, it would be good to backport the patch into
stable kernels as well (3.13+ are possibly affected), even though they
don't contain any of the patches that may have caused regressions.
Fixes: 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
Fixes: c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
Fixes: 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
Fixes: f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
Fixes: d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
Fixes: 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
Link: https://patchwork.kernel.org/patch/10158145/
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Eric Anholt <eric@anholt.net>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tracing: Fix converting enum's from the map in trace_event_eval_update()
commit 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 upstream.
Since enums do not get converted by the TRACE_EVENT macro into their values,
the event format displaces the enum name and not the value. This breaks
tools like perf and trace-cmd that need to interpret the raw binary data. To
solve this, an enum map was created to convert these enums into their actual
numbers on boot up. This is done by TRACE_EVENTS() adding a
TRACE_DEFINE_ENUM() macro.
Some enums were not being converted. This was caused by an optization that
had a bug in it.
All calls get checked against this enum map to see if it should be converted
or not, and it compares the call's system to the system that the enum map
was created under. If they match, then they call is processed.
To cut down on the number of iterations needed to find the maps with a
matching system, since calls and maps are grouped by system, when a match is
made, the index into the map array is saved, so that the next call, if it
belongs to the same system as the previous call, could start right at that
array index and not have to scan all the previous arrays.
The problem was, the saved index was used as the variable to know if this is
a call in a new system or not. If the index was zero, it was assumed that
the call is in a new system and would keep incrementing the saved index
until it found a matching system. The issue arises when the first matching
system was at index zero. The next map, if it belonged to the same system,
would then think it was the first match and increment the index to one. If
the next call belong to the same system, it would begin its search of the
maps off by one, and miss the first enum that should be converted. This left
a single enum not converted properly.
Also add a comment to describe exactly what that index was for. It took me a
bit too long to figure out what I was thinking when debugging this issue.
Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com
Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values")
Reported-by: Chuck Lever <chuck.lever@oracle.com>
Teste-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 upstream.
Since enums do not get converted by the TRACE_EVENT macro into their values,
the event format displaces the enum name and not the value. This breaks
tools like perf and trace-cmd that need to interpret the raw binary data. To
solve this, an enum map was created to convert these enums into their actual
numbers on boot up. This is done by TRACE_EVENTS() adding a
TRACE_DEFINE_ENUM() macro.
Some enums were not being converted. This was caused by an optization that
had a bug in it.
All calls get checked against this enum map to see if it should be converted
or not, and it compares the call's system to the system that the enum map
was created under. If they match, then they call is processed.
To cut down on the number of iterations needed to find the maps with a
matching system, since calls and maps are grouped by system, when a match is
made, the index into the map array is saved, so that the next call, if it
belongs to the same system as the previous call, could start right at that
array index and not have to scan all the previous arrays.
The problem was, the saved index was used as the variable to know if this is
a call in a new system or not. If the index was zero, it was assumed that
the call is in a new system and would keep incrementing the saved index
until it found a matching system. The issue arises when the first matching
system was at index zero. The next map, if it belonged to the same system,
would then think it was the first match and increment the index to one. If
the next call belong to the same system, it would begin its search of the
maps off by one, and miss the first enum that should be converted. This left
a single enum not converted properly.
Also add a comment to describe exactly what that index was for. It took me a
bit too long to figure out what I was thinking when debugging this issue.
Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com
Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values")
Reported-by: Chuck Lever <chuck.lever@oracle.com>
Teste-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: twl4030-vibra - fix sibling-node lookup
commit 5b189201993ab03001a398de731045bfea90c689 upstream.
A helper purported to look up a child node based on its name was using
the wrong of-helper and ended up prematurely freeing the parent of-node
while searching the whole device tree depth-first starting at the parent
node.
Fixes: 64b9e4d803b1 ("input: twl4030-vibra: Support for DT booted kernel")
Fixes: e661d0a04462 ("Input: twl4030-vibra - fix ERROR: Bad of_node_put() warning")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5b189201993ab03001a398de731045bfea90c689 upstream.
A helper purported to look up a child node based on its name was using
the wrong of-helper and ended up prematurely freeing the parent of-node
while searching the whole device tree depth-first starting at the parent
node.
Fixes: 64b9e4d803b1 ("input: twl4030-vibra: Support for DT booted kernel")
Fixes: e661d0a04462 ("Input: twl4030-vibra - fix ERROR: Bad of_node_put() warning")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: twl6040-vibra - fix child-node lookup
commit dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad upstream.
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at parent rather than just matching on
its children.
Later sanity checks on node properties (which would likely be missing)
should prevent this from causing much trouble however, especially as the
original premature free of the parent node has already been fixed
separately (but that "fix" was apparently never backported to stable).
Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support")
Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com> (on Pyra OMAP5 hardware)
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad upstream.
Fix child-node lookup during probe, which ended up searching the whole
device tree depth-first starting at parent rather than just matching on
its children.
Later sanity checks on node properties (which would likely be missing)
should prevent this from causing much trouble however, especially as the
original premature free of the parent node has already been fixed
separately (but that "fix" was apparently never backported to stable).
Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support")
Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management")
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: H. Nikolaus Schaller <hns@goldelico.com> (on Pyra OMAP5 hardware)
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: 88pm860x-ts - fix child-node lookup
commit 906bf7daa0618d0ef39f4872ca42218c29a3631f upstream.
Fix child node-lookup during probe, which ended up searching the whole
device tree depth-first starting at parent rather than just matching on
its children.
To make things worse, the parent node was prematurely freed, while the
child node was leaked.
Fixes: 2e57d56747e6 ("mfd: 88pm860x: Device tree support")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 906bf7daa0618d0ef39f4872ca42218c29a3631f upstream.
Fix child node-lookup during probe, which ended up searching the whole
device tree depth-first starting at parent rather than just matching on
its children.
To make things worse, the parent node was prematurely freed, while the
child node was leaked.
Fixes: 2e57d56747e6 ("mfd: 88pm860x: Device tree support")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: synaptics-rmi4 - prevent UAF reported by KASAN
commit 55edde9fff1ae4114c893c572e641620c76c9c21 upstream.
KASAN found a UAF due to dangling pointer. As the report below says,
rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in
rmi_irq_fn.
[ 311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162
[ 311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2
[ 311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017
[ 311.424078] Call Trace:
[ 311.424086] dump_stack+0xae/0x12d
[ 311.424090] ? _atomic_dec_and_lock+0x103/0x103
[ 311.424094] ? show_regs_print_info+0xa/0xa
[ 311.424099] ? input_handle_event+0x10b/0x810
[ 311.424104] print_address_description+0x65/0x229
[ 311.424108] kasan_report.cold.5+0xa7/0x281
[ 311.424117] rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424123] ? memcpy+0x1f/0x50
[ 311.424132] ? rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424143] ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core]
[ 311.424153] ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core]
[ 311.424163] ? rmi_irq_fn+0x22c/0x270 [rmi_core]
[ 311.424173] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[ 311.424177] ? free_irq+0xa0/0xa0
[ 311.424180] ? irq_finalize_oneshot.part.39+0xeb/0x180
[ 311.424190] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[ 311.424193] ? irq_thread_fn+0x3d/0x80
[ 311.424197] ? irq_finalize_oneshot.part.39+0x180/0x180
[ 311.424200] ? irq_thread+0x21d/0x290
[ 311.424203] ? irq_thread_check_affinity+0x170/0x170
[ 311.424207] ? remove_wait_queue+0x150/0x150
[ 311.424212] ? kasan_unpoison_shadow+0x30/0x40
[ 311.424214] ? __init_waitqueue_head+0xa0/0xd0
[ 311.424218] ? task_non_contending.cold.55+0x18/0x18
[ 311.424221] ? irq_forced_thread_fn+0xa0/0xa0
[ 311.424226] ? irq_thread_check_affinity+0x170/0x170
[ 311.424230] ? kthread+0x19e/0x1c0
[ 311.424233] ? kthread_create_worker_on_cpu+0xc0/0xc0
[ 311.424237] ? ret_from_fork+0x32/0x40
[ 311.424244] Allocated by task 899:
[ 311.424249] kasan_kmalloc+0xbf/0xe0
[ 311.424252] __kmalloc_track_caller+0xd9/0x1f0
[ 311.424255] kmemdup+0x17/0x40
[ 311.424264] rmi_set_attn_data+0xa4/0x1b0 [rmi_core]
[ 311.424269] rmi_raw_event+0x10b/0x1f0 [hid_rmi]
[ 311.424278] hid_input_report+0x1a8/0x2c0 [hid]
[ 311.424283] i2c_hid_irq+0x146/0x1d0 [i2c_hid]
[ 311.424286] irq_thread_fn+0x3d/0x80
[ 311.424288] irq_thread+0x21d/0x290
[ 311.424291] kthread+0x19e/0x1c0
[ 311.424293] ret_from_fork+0x32/0x40
[ 311.424296] Freed by task 1162:
[ 311.424300] kasan_slab_free+0x71/0xc0
[ 311.424303] kfree+0x90/0x190
[ 311.424311] rmi_irq_fn+0x1b2/0x270 [rmi_core]
[ 311.424319] rmi_irq_fn+0x257/0x270 [rmi_core]
[ 311.424322] irq_thread_fn+0x3d/0x80
[ 311.424324] irq_thread+0x21d/0x290
[ 311.424327] kthread+0x19e/0x1c0
[ 311.424330] ret_from_fork+0x32/0x40
[ 311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64
[ 311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100)
[ 311.424344] The buggy address belongs to the page:
[ 311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0
[ 311.424353] flags: 0x17ffffc0000100(slab)
[ 311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a
[ 311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000
[ 311.424366] page dumped because: kasan: bad access detected
[ 311.424369] Memory state around the buggy address:
[ 311.424373] ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 311.424377] ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
[ 311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
[ 311.424384] ^
[ 311.424387] ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[ 311.424391] ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 55edde9fff1ae4114c893c572e641620c76c9c21 upstream.
KASAN found a UAF due to dangling pointer. As the report below says,
rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in
rmi_irq_fn.
[ 311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162
[ 311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2
[ 311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017
[ 311.424078] Call Trace:
[ 311.424086] dump_stack+0xae/0x12d
[ 311.424090] ? _atomic_dec_and_lock+0x103/0x103
[ 311.424094] ? show_regs_print_info+0xa/0xa
[ 311.424099] ? input_handle_event+0x10b/0x810
[ 311.424104] print_address_description+0x65/0x229
[ 311.424108] kasan_report.cold.5+0xa7/0x281
[ 311.424117] rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424123] ? memcpy+0x1f/0x50
[ 311.424132] ? rmi_f11_attention+0x526/0x5e0 [rmi_core]
[ 311.424143] ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core]
[ 311.424153] ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core]
[ 311.424163] ? rmi_irq_fn+0x22c/0x270 [rmi_core]
[ 311.424173] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[ 311.424177] ? free_irq+0xa0/0xa0
[ 311.424180] ? irq_finalize_oneshot.part.39+0xeb/0x180
[ 311.424190] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
[ 311.424193] ? irq_thread_fn+0x3d/0x80
[ 311.424197] ? irq_finalize_oneshot.part.39+0x180/0x180
[ 311.424200] ? irq_thread+0x21d/0x290
[ 311.424203] ? irq_thread_check_affinity+0x170/0x170
[ 311.424207] ? remove_wait_queue+0x150/0x150
[ 311.424212] ? kasan_unpoison_shadow+0x30/0x40
[ 311.424214] ? __init_waitqueue_head+0xa0/0xd0
[ 311.424218] ? task_non_contending.cold.55+0x18/0x18
[ 311.424221] ? irq_forced_thread_fn+0xa0/0xa0
[ 311.424226] ? irq_thread_check_affinity+0x170/0x170
[ 311.424230] ? kthread+0x19e/0x1c0
[ 311.424233] ? kthread_create_worker_on_cpu+0xc0/0xc0
[ 311.424237] ? ret_from_fork+0x32/0x40
[ 311.424244] Allocated by task 899:
[ 311.424249] kasan_kmalloc+0xbf/0xe0
[ 311.424252] __kmalloc_track_caller+0xd9/0x1f0
[ 311.424255] kmemdup+0x17/0x40
[ 311.424264] rmi_set_attn_data+0xa4/0x1b0 [rmi_core]
[ 311.424269] rmi_raw_event+0x10b/0x1f0 [hid_rmi]
[ 311.424278] hid_input_report+0x1a8/0x2c0 [hid]
[ 311.424283] i2c_hid_irq+0x146/0x1d0 [i2c_hid]
[ 311.424286] irq_thread_fn+0x3d/0x80
[ 311.424288] irq_thread+0x21d/0x290
[ 311.424291] kthread+0x19e/0x1c0
[ 311.424293] ret_from_fork+0x32/0x40
[ 311.424296] Freed by task 1162:
[ 311.424300] kasan_slab_free+0x71/0xc0
[ 311.424303] kfree+0x90/0x190
[ 311.424311] rmi_irq_fn+0x1b2/0x270 [rmi_core]
[ 311.424319] rmi_irq_fn+0x257/0x270 [rmi_core]
[ 311.424322] irq_thread_fn+0x3d/0x80
[ 311.424324] irq_thread+0x21d/0x290
[ 311.424327] kthread+0x19e/0x1c0
[ 311.424330] ret_from_fork+0x32/0x40
[ 311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64
[ 311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100)
[ 311.424344] The buggy address belongs to the page:
[ 311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0
[ 311.424353] flags: 0x17ffffc0000100(slab)
[ 311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a
[ 311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000
[ 311.424366] page dumped because: kasan: bad access detected
[ 311.424369] Memory state around the buggy address:
[ 311.424373] ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 311.424377] ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
[ 311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
[ 311.424384] ^
[ 311.424387] ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
[ 311.424391] ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Input: ALPS - fix multi-touch decoding on SS4 plus touchpads
commit 4d94e776bd29670f01befa27e12df784fa05fa2e upstream.
The fix for handling two-finger scroll (i4a646580f793 - "Input: ALPS -
fix two-finger scroll breakage in right side on ALPS touchpad")
introduced a minor "typo" that broke decoding of multi-touch events are
decoded on some ALPS touchpads. For example, tapping with three-fingers
can no longer be used to emulate middle-mouse-button (the kernel doesn't
recognize this as the proper event, and doesn't report it correctly to
userspace). This affects touchpads that use SS4 "plus" protocol
variant, like those found on Dell E7270 & E7470 laptops (tested on
E7270).
First, probably the code in alps_decode_ss4_v2() for case
SS4_PACKET_ID_MULTI used inconsistent indices to "f->mt[]". You can see
0 & 1 are used for the "if" part but 2 & 3 are used for the "else" part.
Second, in the previous patch, new macros were introduced to decode X
coordinates specific to the SS4 "plus" variant, but the macro to
define the maximum X value wasn't changed accordingly. The macros to
decode X values for "plus" variant are effectively shifted right by 1
bit, but the max wasn't shifted too. This causes the driver to
incorrectly handle "no data" cases, which also interfered with how
multi-touch was handled.
Fixes: 4a646580f793 ("Input: ALPS - fix two-finger scroll breakage...")
Signed-off-by: Nir Perry <nirperry@gmail.com>
Reviewed-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4d94e776bd29670f01befa27e12df784fa05fa2e upstream.
The fix for handling two-finger scroll (i4a646580f793 - "Input: ALPS -
fix two-finger scroll breakage in right side on ALPS touchpad")
introduced a minor "typo" that broke decoding of multi-touch events are
decoded on some ALPS touchpads. For example, tapping with three-fingers
can no longer be used to emulate middle-mouse-button (the kernel doesn't
recognize this as the proper event, and doesn't report it correctly to
userspace). This affects touchpads that use SS4 "plus" protocol
variant, like those found on Dell E7270 & E7470 laptops (tested on
E7270).
First, probably the code in alps_decode_ss4_v2() for case
SS4_PACKET_ID_MULTI used inconsistent indices to "f->mt[]". You can see
0 & 1 are used for the "if" part but 2 & 3 are used for the "else" part.
Second, in the previous patch, new macros were introduced to decode X
coordinates specific to the SS4 "plus" variant, but the macro to
define the maximum X value wasn't changed accordingly. The macros to
decode X values for "plus" variant are effectively shifted right by 1
bit, but the max wasn't shifted too. This causes the driver to
incorrectly handle "no data" cases, which also interfered with how
multi-touch was handled.
Fixes: 4a646580f793 ("Input: ALPS - fix two-finger scroll breakage...")
Signed-off-by: Nir Perry <nirperry@gmail.com>
Reviewed-by: Masaki Ota <masaki.ota@jp.alps.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Encrypt the initrd earlier for BSP microcode update
commit 107cd2532181b96c549e8f224cdcca8631c3076b upstream.
Currently the BSP microcode update code examines the initrd very early
in the boot process. If SME is active, the initrd is treated as being
encrypted but it has not been encrypted (in place) yet. Update the
early boot code that encrypts the kernel to also encrypt the initrd so
that early BSP microcode updates work.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192634.6026.10452.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 107cd2532181b96c549e8f224cdcca8631c3076b upstream.
Currently the BSP microcode update code examines the initrd very early
in the boot process. If SME is active, the initrd is treated as being
encrypted but it has not been encrypted (in place) yet. Update the
early boot code that encrypts the kernel to also encrypt the initrd so
that early BSP microcode updates work.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192634.6026.10452.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: OMAP3: hwmod_data: add missing module_offs for MMC3
commit 3c4d296e58a23687f2076d8ad531e6ae2b725846 upstream.
MMC3 hwmod data is missing the module_offs definition. MMC3 belongs under
core, so add CORE_MOD for it.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Adam Ford <aford173@gmail.com>
Fixes: 6c0afb503937 ("clk: ti: convert to use proper register definition for all accesses")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c4d296e58a23687f2076d8ad531e6ae2b725846 upstream.
MMC3 hwmod data is missing the module_offs definition. MMC3 belongs under
core, so add CORE_MOD for it.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Adam Ford <aford173@gmail.com>
Fixes: 6c0afb503937 ("clk: ti: convert to use proper register definition for all accesses")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Prepare sme_encrypt_kernel() for PAGE aligned encryption
commit cc5f01e28d6c60f274fd1e33b245f679f79f543c upstream.
In preparation for encrypting more than just the kernel, the encryption
support in sme_encrypt_kernel() needs to support 4KB page aligned
encryption instead of just 2MB large page aligned encryption.
Update the routines that populate the PGD to support non-2MB aligned
addresses. This is done by creating PTE page tables for the start
and end portion of the address range that fall outside of the 2MB
alignment. This results in, at most, two extra pages to hold the
PTE entries for each mapping of a range.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192626.6026.75387.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cc5f01e28d6c60f274fd1e33b245f679f79f543c upstream.
In preparation for encrypting more than just the kernel, the encryption
support in sme_encrypt_kernel() needs to support 4KB page aligned
encryption instead of just 2MB large page aligned encryption.
Update the routines that populate the PGD to support non-2MB aligned
addresses. This is done by creating PTE page tables for the start
and end portion of the address range that fall outside of the 2MB
alignment. This results in, at most, two extra pages to hold the
PTE entries for each mapping of a range.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192626.6026.75387.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Centralize PMD flags in sme_encrypt_kernel()
commit 2b5d00b6c2cdd94f6d6a494a6f6c0c0fc7b8e711 upstream.
In preparation for encrypting more than just the kernel during early
boot processing, centralize the use of the PMD flag settings based
on the type of mapping desired. When 4KB aligned encryption is added,
this will allow either PTE flags or large page PMD flags to be used
without requiring the caller to adjust.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192615.6026.14767.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b5d00b6c2cdd94f6d6a494a6f6c0c0fc7b8e711 upstream.
In preparation for encrypting more than just the kernel during early
boot processing, centralize the use of the PMD flag settings based
on the type of mapping desired. When 4KB aligned encryption is added,
this will allow either PTE flags or large page PMD flags to be used
without requiring the caller to adjust.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192615.6026.14767.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Use a struct to reduce parameters for SME PGD mapping
commit bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4 upstream.
In preparation for follow-on patches, combine the PGD mapping parameters
into a struct to reduce the number of function arguments and allow for
direct updating of the next pagetable mapping area pointer.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192605.6026.96206.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4 upstream.
In preparation for follow-on patches, combine the PGD mapping parameters
into a struct to reduce the number of function arguments and allow for
direct updating of the next pagetable mapping area pointer.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192605.6026.96206.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm: Clean up register saving in the __enc_copy() assembly code
commit 1303880179e67c59e801429b7e5d0f6b21137d99 upstream.
Clean up the use of PUSH and POP and when registers are saved in the
__enc_copy() assembly function in order to improve the readability of the code.
Move parameter register saving into general purpose registers earlier
in the code and move all the pushes to the beginning of the function
with corresponding pops at the end.
We do this to prepare fixes.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192556.6026.74187.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1303880179e67c59e801429b7e5d0f6b21137d99 upstream.
Clean up the use of PUSH and POP and when registers are saved in the
__enc_copy() assembly function in order to improve the readability of the code.
Move parameter register saving into general purpose registers earlier
in the code and move all the pushes to the beginning of the function
with corresponding pops at the end.
We do this to prepare fixes.
Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20180110192556.6026.74187.stgit@tlendack-t1.amdoffice.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/apic/vector: Fix off by one in error path
commit 45d55e7bac4028af93f5fa324e69958a0b868e96 upstream.
Keith reported the following warning:
WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120
x86_vector_free_irqs+0xa1/0x180
x86_vector_alloc_irqs+0x1e4/0x3a0
msi_domain_alloc+0x62/0x130
The reason for this is that if the vector allocation fails the error
handling code tries to free the failed vector as well, which causes the
above imbalance warning to trigger.
Adjust the error path to handle this correctly.
Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors")
Reported-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Keith Busch <keith.busch@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 45d55e7bac4028af93f5fa324e69958a0b868e96 upstream.
Keith reported the following warning:
WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120
x86_vector_free_irqs+0xa1/0x180
x86_vector_alloc_irqs+0x1e4/0x3a0
msi_domain_alloc+0x62/0x130
The reason for this is that if the vector allocation fails the error
handling code tries to free the failed vector as well, which causes the
above imbalance warning to trigger.
Adjust the error path to handle this correctly.
Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors")
Reported-by: Keith Busch <keith.busch@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Keith Busch <keith.busch@intel.com>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pipe: avoid round_pipe_size() nr_pages overflow on 32-bit
commit d3f14c485867cfb2e0c48aa88c41d0ef4bf5209c upstream.
round_pipe_size() contains a right-bit-shift expression which may
overflow, which would cause undefined results in a subsequent
roundup_pow_of_two() call.
static inline unsigned int round_pipe_size(unsigned int size)
{
unsigned long nr_pages;
nr_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
return roundup_pow_of_two(nr_pages) << PAGE_SHIFT;
}
PAGE_SIZE is defined as (1UL << PAGE_SHIFT), so:
- 4 bytes wide on 32-bit (0 to 0xffffffff)
- 8 bytes wide on 64-bit (0 to 0xffffffffffffffff)
That means that 32-bit round_pipe_size(), nr_pages may overflow to 0:
size=0x00000000 nr_pages=0x0
size=0x00000001 nr_pages=0x1
size=0xfffff000 nr_pages=0xfffff
size=0xfffff001 nr_pages=0x0 << !
size=0xffffffff nr_pages=0x0 << !
This is bad because roundup_pow_of_two(n) is undefined when n == 0!
64-bit is not a problem as the unsigned int size is 4 bytes wide
(similar to 32-bit) and the larger, 8 byte wide unsigned long, is
sufficient to handle the largest value of the bit shift expression:
size=0xffffffff nr_pages=100000
Modify round_pipe_size() to return 0 if n == 0 and updates its callers to
handle accordingly.
Link: http://lkml.kernel.org/r/1507658689-11669-3-git-send-email-joe.lawrence@redhat.com
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dong Jinguang <dongjinguang@huawei.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d3f14c485867cfb2e0c48aa88c41d0ef4bf5209c upstream.
round_pipe_size() contains a right-bit-shift expression which may
overflow, which would cause undefined results in a subsequent
roundup_pow_of_two() call.
static inline unsigned int round_pipe_size(unsigned int size)
{
unsigned long nr_pages;
nr_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
return roundup_pow_of_two(nr_pages) << PAGE_SHIFT;
}
PAGE_SIZE is defined as (1UL << PAGE_SHIFT), so:
- 4 bytes wide on 32-bit (0 to 0xffffffff)
- 8 bytes wide on 64-bit (0 to 0xffffffffffffffff)
That means that 32-bit round_pipe_size(), nr_pages may overflow to 0:
size=0x00000000 nr_pages=0x0
size=0x00000001 nr_pages=0x1
size=0xfffff000 nr_pages=0xfffff
size=0xfffff001 nr_pages=0x0 << !
size=0xffffffff nr_pages=0x0 << !
This is bad because roundup_pow_of_two(n) is undefined when n == 0!
64-bit is not a problem as the unsigned int size is 4 bytes wide
(similar to 32-bit) and the larger, 8 byte wide unsigned long, is
sufficient to handle the largest value of the bit shift expression:
size=0xffffffff nr_pages=100000
Modify round_pipe_size() to return 0 if n == 0 and updates its callers to
handle accordingly.
Link: http://lkml.kernel.org/r/1507658689-11669-3-git-send-email-joe.lawrence@redhat.com
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dong Jinguang <dongjinguang@huawei.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/tsc: Fix erroneous TSC rate on Skylake Xeon
commit b511203093489eb1829cb4de86e8214752205ac6 upstream.
The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is
problematic:
- SKX workstations (with same model # as server variants) use a 24 MHz
crystal. This results in a -4.0% time drift rate on SKX workstations.
- SKX servers subject the crystal to an EMI reduction circuit that reduces its
actual frequency by (approximately) -0.25%. This results in -1 second per
10 minute time drift as compared to network time.
This issue can also trigger a timer and power problem, on configurations
that use the LAPIC timer (versus the TSC deadline timer). Clock ticks
scheduled with the LAPIC timer arrive a few usec before the time they are
expected (according to the slow TSC). This causes Linux to poll-idle, when
it should be in an idle power saving state. The idle and clock code do not
graciously recover from this error, sometimes resulting in significant
polling and measurable power impact.
Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
native_calibrate_tsc() will return 0, boot will run with tsc_khz = cpu_khz,
and the TSC refined calibration will update tsc_khz to correct for the
difference.
[ tglx: Sanitized change log ]
Fixes: 6baf3d61821f ("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: Prarit Bhargava <prarit@redhat.com>
Link: https://lkml.kernel.org/r/ff6dcea166e8ff8f2f6a03c17beab2cb436aa779.1513920414.git.len.brown@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b511203093489eb1829cb4de86e8214752205ac6 upstream.
The INTEL_FAM6_SKYLAKE_X hardcoded crystal_khz value of 25MHZ is
problematic:
- SKX workstations (with same model # as server variants) use a 24 MHz
crystal. This results in a -4.0% time drift rate on SKX workstations.
- SKX servers subject the crystal to an EMI reduction circuit that reduces its
actual frequency by (approximately) -0.25%. This results in -1 second per
10 minute time drift as compared to network time.
This issue can also trigger a timer and power problem, on configurations
that use the LAPIC timer (versus the TSC deadline timer). Clock ticks
scheduled with the LAPIC timer arrive a few usec before the time they are
expected (according to the slow TSC). This causes Linux to poll-idle, when
it should be in an idle power saving state. The idle and clock code do not
graciously recover from this error, sometimes resulting in significant
polling and measurable power impact.
Stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
native_calibrate_tsc() will return 0, boot will run with tsc_khz = cpu_khz,
and the TSC refined calibration will update tsc_khz to correct for the
difference.
[ tglx: Sanitized change log ]
Fixes: 6baf3d61821f ("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: Prarit Bhargava <prarit@redhat.com>
Link: https://lkml.kernel.org/r/ff6dcea166e8ff8f2f6a03c17beab2cb436aa779.1513920414.git.len.brown@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/tsc: Future-proof native_calibrate_tsc()
commit da4ae6c4a0b8dee5a5377a385545d2250fa8cddb upstream.
If the crystal frequency cannot be determined via CPUID(15).crystal_khz or
the built-in table then native_calibrate_tsc() will still set the
X86_FEATURE_TSC_KNOWN_FREQ flag which prevents the refined TSC calibration.
As a consequence such systems use cpu_khz for the TSC frequency which is
incorrect when cpu_khz != tsc_khz resulting in time drift.
Return early when the crystal frequency cannot be retrieved without setting
the X86_FEATURE_TSC_KNOWN_FREQ flag. This ensures that the refined TSC
calibration is invoked.
[ tglx: Steam-blastered changelog. Sigh ]
Fixes: 4ca4df0b7eb0 ("x86/tsc: Mark TSC frequency determined by CPUID as known")
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: Bin Gao <bin.gao@intel.com>
Link: https://lkml.kernel.org/r/0fe2503aa7d7fc69137141fc705541a78101d2b9.1513920414.git.len.brown@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da4ae6c4a0b8dee5a5377a385545d2250fa8cddb upstream.
If the crystal frequency cannot be determined via CPUID(15).crystal_khz or
the built-in table then native_calibrate_tsc() will still set the
X86_FEATURE_TSC_KNOWN_FREQ flag which prevents the refined TSC calibration.
As a consequence such systems use cpu_khz for the TSC frequency which is
incorrect when cpu_khz != tsc_khz resulting in time drift.
Return early when the crystal frequency cannot be retrieved without setting
the X86_FEATURE_TSC_KNOWN_FREQ flag. This ensures that the refined TSC
calibration is invoked.
[ tglx: Steam-blastered changelog. Sigh ]
Fixes: 4ca4df0b7eb0 ("x86/tsc: Mark TSC frequency determined by CPUID as known")
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: peterz@infradead.org
Cc: Bin Gao <bin.gao@intel.com>
Link: https://lkml.kernel.org/r/0fe2503aa7d7fc69137141fc705541a78101d2b9.1513920414.git.len.brown@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/idt: Mark IDT tables __initconst
commit 327867faa4d66628fcd92a843adb3345736a5313 upstream.
const variables must use __initconst, not __initdata.
Fix this up for the IDT tables, which got it consistently wrong.
Fixes: 16bc18d895ce ("x86/idt: Move 32-bit idt_descr to C code")
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20171222001821.2157-7-andi@firstfloor.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 327867faa4d66628fcd92a843adb3345736a5313 upstream.
const variables must use __initconst, not __initdata.
Fix this up for the IDT tables, which got it consistently wrong.
Fixes: 16bc18d895ce ("x86/idt: Move 32-bit idt_descr to C code")
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20171222001821.2157-7-andi@firstfloor.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/mm/pkeys: Fix fill_sig_info_pkey
commit beacd6f7ed5e2915959442245b3b2480c2e37490 upstream.
SEGV_PKUERR is a signal specific si_code which happens to have the same
numeric value as several others: BUS_MCEERR_AR, ILL_ILLTRP, FPE_FLTOVF,
TRAP_HWBKPT, CLD_TRAPPED, POLL_ERR, SEGV_THREAD_ID, as such it is not safe
to just test the si_code the signal number must also be tested to prevent a
false positive in fill_sig_info_pkey.
This error was by inspection, and BUS_MCEERR_AR appears to be a real
candidate for confusion. So pass in si_signo and check for SIG_SEGV to
verify that it is actually a SEGV_PKUERR
Fixes: 019132ff3daf ("x86/mm/pkeys: Fill in pkey field in siginfo")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lkml.kernel.org/r/20180112203135.4669-2-ebiederm@xmission.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit beacd6f7ed5e2915959442245b3b2480c2e37490 upstream.
SEGV_PKUERR is a signal specific si_code which happens to have the same
numeric value as several others: BUS_MCEERR_AR, ILL_ILLTRP, FPE_FLTOVF,
TRAP_HWBKPT, CLD_TRAPPED, POLL_ERR, SEGV_THREAD_ID, as such it is not safe
to just test the si_code the signal number must also be tested to prevent a
false positive in fill_sig_info_pkey.
This error was by inspection, and BUS_MCEERR_AR appears to be a real
candidate for confusion. So pass in si_signo and check for SIG_SEGV to
verify that it is actually a SEGV_PKUERR
Fixes: 019132ff3daf ("x86/mm/pkeys: Fill in pkey field in siginfo")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Link: https://lkml.kernel.org/r/20180112203135.4669-2-ebiederm@xmission.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>