Merged TI feature vigneshr_next into ti-linux-4.19.y-next
TI-Feature: vigneshr_next
TI-Tree: git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel:
serial: 8250: 8250_omap: Remove redundant call to omap_8250_rx_dma_flush
serial: 8250: 8250_omap: Fix DMA teardown sequence during RX timeout
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: vigneshr_next
TI-Tree: git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/~vigneshr/ti-linux-kernel/vigneshr-ti-linux-kernel:
serial: 8250: 8250_omap: Remove redundant call to omap_8250_rx_dma_flush
serial: 8250: 8250_omap: Fix DMA teardown sequence during RX timeout
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature kishon_next into ti-linux-4.19.y-next
TI-Feature: kishon_next
TI-Tree: git://git.ti.com/linux-phy/kishons-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti-linux-kernel: (24 commits)
ti_config_fragments/connectivity.cfg: Enable NTB configs
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
PCI: Add TI J721E device to pci ids
PCI: endpoint: Add EP function driver to provide NTB functionality
PCI: endpoint: *_free_bar() to return error codes on failure
PCI: endpoint: Fix missing mutex_unlock in error case
PCI: endpoint: Remove unused pci_epf_match_device()
PCI: cadence: Implement ->msi_map_irq() ops
PCI: endpoint: Add pci_epc_ops to map MSI irq
PCI: endpoint: Add support to associate secondary EPC with EPF
PCI: endpoint: Add helper API to populate header with values from DT
PCI: endpoint: Make pci_epf_driver ops optional
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
PCI: endpoint: Add "pci-epf-bus" driver
PCI: endpoint: Add API to create EPF device from device tree
PCI: endpoint: Add API to get reference to EPC from device-tree
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: kishon_next
TI-Tree: git://git.ti.com/linux-phy/kishons-ti-linux-kernel.git
TI-Branch: ti-linux-4.19.y-for-next
* 'ti-linux-4.19.y-for-next' of git://git.ti.com/linux-phy/kishons-ti-linux-kernel: (24 commits)
ti_config_fragments/connectivity.cfg: Enable NTB configs
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
PCI: Add TI J721E device to pci ids
PCI: endpoint: Add EP function driver to provide NTB functionality
PCI: endpoint: *_free_bar() to return error codes on failure
PCI: endpoint: Fix missing mutex_unlock in error case
PCI: endpoint: Remove unused pci_epf_match_device()
PCI: cadence: Implement ->msi_map_irq() ops
PCI: endpoint: Add pci_epc_ops to map MSI irq
PCI: endpoint: Add support to associate secondary EPC with EPF
PCI: endpoint: Add helper API to populate header with values from DT
PCI: endpoint: Make pci_epf_driver ops optional
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
PCI: endpoint: Add "pci-epf-bus" driver
PCI: endpoint: Add API to create EPF device from device tree
PCI: endpoint: Add API to get reference to EPC from device-tree
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature rpmsg_next into ti-linux-4.19.y-next
TI-Feature: rpmsg_next
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-next
* 'rpmsg-ti-linux-4.19.y-next' of git://git.ti.com/rpmsg/rpmsg: (21 commits)
soc: ti: pruss: update pruss_get() to retrieve a PRUSS id
soc: ti: pruss: store the pruss instance id
ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: rpmsg_next
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-4.19.y-next
* 'rpmsg-ti-linux-4.19.y-next' of git://git.ti.com/rpmsg/rpmsg: (21 commits)
soc: ti: pruss: update pruss_get() to retrieve a PRUSS id
soc: ti: pruss: store the pruss instance id
ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
ARM: dts: dra76-evm: Fix rproc reserved-memory labels and node names
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature connectivity_next into ti-linux-4.19.y-next
TI-Feature: connectivity_next
TI-Tree: ssh://git@bitbucket.itg.ti.com/~a0875516/ti-linux-kernel.git
TI-Branch: connectivity-next
* 'connectivity-next' of ssh://bitbucket.itg.ti.com/~a0875516/ti-linux-kernel:
net: ethernet: ti: am65-cpsw: fix sw timestamping for non PTP packets
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity_next
TI-Tree: ssh://git@bitbucket.itg.ti.com/~a0875516/ti-linux-kernel.git
TI-Branch: connectivity-next
* 'connectivity-next' of ssh://bitbucket.itg.ti.com/~a0875516/ti-linux-kernel:
net: ethernet: ti: am65-cpsw: fix sw timestamping for non PTP packets
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Merged TI feature linux-stable-4.19-rc into ti-linux-4.19.y-next
TI-Feature: linux-stable-4.19-rc
TI-Tree: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
TI-Branch: linux-4.19.y
* 'linux-4.19.y' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc: (131 commits)
Linux 4.19.75
media: technisat-usb2: break out of loop at end of buffer
arm64: kpti: Whitelist Cortex-A CPUs that don't implement the CSV3 field
binfmt_elf: move brk out of mmap when doing direct loader exec
floppy: fix usercopy direction
ovl: fix regression caused by overlapping layers detection
PCI: kirin: Fix section mismatch warning
iommu/amd: Fix race in increase_address_space()
iommu/amd: Flush old domains in kdump kernel
keys: Fix missing null pointer check in request_key_auth_describe()
x86/hyper-v: Fix overflow bug in fill_gva_list()
x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
dmaengine: ti: dma-crossbar: Fix a memory leak bug
net: seeq: Fix the function used to release some memory in an error handling path
net: aquantia: fix out of memory condition on rx side
tools/power turbostat: fix buffer overrun
tools/power x86_energy_perf_policy: Fix argument parsing
tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at -O2
amd-xgbe: Fix error path in xgbe_mod_init()
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: linux-stable-4.19-rc
TI-Tree: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
TI-Branch: linux-4.19.y
* 'linux-4.19.y' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc: (131 commits)
Linux 4.19.75
media: technisat-usb2: break out of loop at end of buffer
arm64: kpti: Whitelist Cortex-A CPUs that don't implement the CSV3 field
binfmt_elf: move brk out of mmap when doing direct loader exec
floppy: fix usercopy direction
ovl: fix regression caused by overlapping layers detection
PCI: kirin: Fix section mismatch warning
iommu/amd: Fix race in increase_address_space()
iommu/amd: Flush old domains in kdump kernel
keys: Fix missing null pointer check in request_key_auth_describe()
x86/hyper-v: Fix overflow bug in fill_gva_list()
x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
dmaengine: ti: dma-crossbar: Fix a memory leak bug
net: seeq: Fix the function used to release some memory in an error handling path
net: aquantia: fix out of memory condition on rx side
tools/power turbostat: fix buffer overrun
tools/power x86_energy_perf_policy: Fix argument parsing
tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at -O2
amd-xgbe: Fix error path in xgbe_mod_init()
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
ti_config_fragments/connectivity.cfg: Enable NTB configs
Enable NTB related configs to enable NTB both on the host and device
systems.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Enable NTB related configs to enable NTB both on the host and device
systems.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
arm64: dts: ti: k3-j721e: Add DT overlay for PCIe Backplane
Add DT overlay for PCIe Backplane to configure the PCIe instances
in EP mode and includes a NTB DT node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add DT overlay for PCIe Backplane to configure the PCIe instances
in EP mode and includes a NTB DT node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
arm64: dts: ti: k3-j721e: Add reference to *phy* in PCIe EP DT node
Add *phys* and *phy-names* property to PCIe EP DT nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add *phys* and *phy-names* property to PCIe EP DT nodes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge
Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
NTB: Add support for EPF PCI-Express Non-Transparent Bridge
Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: Add TI J721E device to pci ids
Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add EP function driver to provide NTB functionality
Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: *_free_bar() to return error codes on failure
Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Fix missing mutex_unlock in error case
There is a missing mutex_unlock() in pci_epc_add_epf() in one of the
error scenarios. Fix it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
There is a missing mutex_unlock() in pci_epc_add_epf() in one of the
error scenarios. Fix it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Remove unused pci_epf_match_device()
Remove unused pci_epf_match_device() function added in pci-epf-core.c
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Remove unused pci_epf_match_device() function added in pci-epf-core.c
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: cadence: Implement ->msi_map_irq() ops
Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add pci_epc_ops to map MSI irq
Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add support to associate secondary EPC with EPF
In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add helper API to populate header with values from DT
Add helper API pci_epc_of_parse_header() to populate header with
values from device tree. These values will be written to the
configuration space header in the endpoint controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add helper API pci_epc_of_parse_header() to populate header with
values from device tree. These values will be written to the
configuration space header in the endpoint controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Make pci_epf_driver ops optional
pci_epf_driver had two ops for bind and unbind which will be invoked
when an endpoint controller is bound to an endpoint function (using
configfs). Now that endpoint core has support to define an endpoint
function using device tree alone, the bind and unbind ops can be
optional. Make pci_epf_driver ops optional here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
pci_epf_driver had two ops for bind and unbind which will be invoked
when an endpoint controller is bound to an endpoint function (using
configfs). Now that endpoint core has support to define an endpoint
function using device tree alone, the bind and unbind ops can be
optional. Make pci_epf_driver ops optional here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add helper API to get the 'next' unreserved BAR
Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR
pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).
Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).
Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add "pci-epf-bus" driver
Add "pci-epf-bus" driver that helps to create EPF device from
device tree. This is added in order to define an endpoint function
completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add "pci-epf-bus" driver that helps to create EPF device from
device tree. This is added in order to define an endpoint function
completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add API to create EPF device from device tree
Add API to create EPF device from device tree and the device managed
interface corresponding to it. This is added in order to define
an endpoint function completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add API to create EPF device from device tree and the device managed
interface corresponding to it. This is added in order to define
an endpoint function completely from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
PCI: endpoint: Add API to get reference to EPC from device-tree
Add of_pci_epc_get() and of_pci_epc_get_by_name() to get reference
to EPC from device-tree. This is added in preparation to define
an endpoint function from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add of_pci_epc_get() and of_pci_epc_get_by_name() to get reference
to EPC from device-tree. This is added in preparation to define
an endpoint function from device tree.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Documentation: PCI: Add specification for the *PCI NTB* function device
Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF NTB Device
Add device tree bindings for PCI endpoint NTB function device.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add device tree bindings for PCI endpoint NTB function device.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Device
Add device tree bindings for PCI endpoint function device. The
nodes for PCI endpoint function device should be attached to
PCI endpoint function bus.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add device tree bindings for PCI endpoint function device. The
nodes for PCI endpoint function device should be attached to
PCI endpoint function bus.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
dt-bindings: PCI: Endpoint: Add DT bindings for PCI EPF Bus
Add device tree bindings for PCI endpoint function bus to which
endpoint function devices should be attached.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Add device tree bindings for PCI endpoint function bus to which
endpoint function devices should be attached.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
soc: ti: pruss: update pruss_get() to retrieve a PRUSS id
Update the pruss_get() function to take in an additional integer
pointer argument in which the PRUSS instance id is filled in and
provided back to the callers. This allows the drivers to add some
instance-specific logic/customization in their code, as the PRUSS
handle is not useful to build this logic.
The already existing usage within both the regular PRU Ethernet
and the ICSSG PRU Ethernet drivers have also been updated accordingly,
and this will cater to its need for supporting switching between
different Ethernet protocols dynamically per instance. The invocation
within the PRU Soft UART driver has also been updated, with this
driver not needing the PRUSS instance id at present.
Signed-off-by: Suman Anna <s-anna@ti.com>
Update the pruss_get() function to take in an additional integer
pointer argument in which the PRUSS instance id is filled in and
provided back to the callers. This allows the drivers to add some
instance-specific logic/customization in their code, as the PRUSS
handle is not useful to build this logic.
The already existing usage within both the regular PRU Ethernet
and the ICSSG PRU Ethernet drivers have also been updated accordingly,
and this will cater to its need for supporting switching between
different Ethernet protocols dynamically per instance. The invocation
within the PRU Soft UART driver has also been updated, with this
driver not needing the PRUSS instance id at present.
Signed-off-by: Suman Anna <s-anna@ti.com>
soc: ti: pruss: store the pruss instance id
Add logic to the PRUSS platform driver to store the instance id
of a PRUSS instance. This is being added to enable support for
the PRU Ethernet driver to be able to switch between different
Ethernet protocols dynamically per instance.
The values for instance ids are not always zero-indexed on all
SoCs, they were chosen to match the numbering used in the TRMs.
The instance ids are computed assigned using the PRUSS memory
region base address lookup table. The base address matching
logic is not robust for long-term for newer SoCs, but is okay
for currently supported SoCs as all the addresses are unique.
This is done this way to retain the current usage of minimal
static data and to avoid having to introduce the instance
specific static data just for the instance id data.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add logic to the PRUSS platform driver to store the instance id
of a PRUSS instance. This is being added to enable support for
the PRU Ethernet driver to be able to switch between different
Ethernet protocols dynamically per instance.
The values for instance ids are not always zero-indexed on all
SoCs, they were chosen to match the numbering used in the TRMs.
The instance ids are computed assigned using the PRUSS memory
region base address lookup table. The base address matching
logic is not robust for long-term for newer SoCs, but is okay
for currently supported SoCs as all the addresses are unique.
This is done this way to retain the current usage of minimal
static data and to avoid having to introduce the instance
specific static data just for the instance id data.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'topic/4.19/dra7-late-attach' into rpmsg-ti-linux-4.19.y-next
* topic/4.19/dra7-late-attach:
ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
Signed-off-by: Suman Anna <s-anna@ti.com>
* topic/4.19/dra7-late-attach:
ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
TEMP: remoteproc/omap: add "late attach" support
TEMP: iommu/omap: add support for performing a "late attach"
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
TEMP: remoteproc: call the non-zeroing allocation function
TEMP: remoteproc: add "late attach" support
HACK: dma-mapping: add non-zeroing coherent alloc function
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am571x-idk: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the AM571x IDK board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the AM571x IDK board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am572x-idk-common: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors in the am572x-idk-common.dtsi file that applies
to both the AM572x and AM574x IDK boards. These processors should have been
booted earlier by either the U-Boot or SPL. All the necessary node changes
are applied by including the common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors in the am572x-idk-common.dtsi file that applies
to both the AM572x and AM574x IDK boards. These processors should have been
booted earlier by either the U-Boot or SPL. All the necessary node changes
are applied by including the common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: beagle-x15-common: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors on all the AM57xx BeagleBoard-X15 boards. These
processors should have been booted earlier by either the U-Boot or SPL.
All the necessary node changes are applied by including the common
dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of the IPU1
and IPU2 remote processors on all the AM57xx BeagleBoard-X15 boards. These
processors should have been booted earlier by either the U-Boot or SPL.
All the necessary node changes are applied by including the common
dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra71-evm: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA71 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA71 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra72-evms: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on both the DRA72 EVM and DRA72
rev.C EVM boards. These processors should have been booted earlier
by either the U-Boot or SPL. All the necessary node changes are
applied by including the common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on both the DRA72 EVM and DRA72
rev.C EVM boards. These processors should have been booted earlier
by either the U-Boot or SPL. All the necessary node changes are
applied by including the common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra76-evm: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA76 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA76 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra7-evm: Provide support for early-booted IPU1 & IPU2
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA7 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Add support to enable the remoteproc late attach functionality of
the IPU1 and IPU2 remote processors on the DRA7 EVM board. These
processors should have been booted earlier by either the U-Boot or
SPL. All the necessary node changes are applied by including the
common dra7-ipu-common-early-boot.dtsi file.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
HACK: ARM: dts: dra7-ipu-common: Revert to CMA pools for IPU early boots
The patch d1a42fca5944 ("TEMP: ARM: dts: dra7-ipu-common: Add a common
file for IPU early boots") converts the default CMA pools used in regular
remoteproc mode to carveouts/DMA pools for early-boot usage scenarios
using the "no-map" property to avoid the kernel from corrupting the
remoteproc firmware image sections.
The allocation scheme with DMA pools though is different than with CMA
pools, and this may cause some of the existing firmwares used in the
regular remoteproc mode with CMA to fail. The DMA pools may require a
number of changes in general:
- Split the firmware RSC_CARVEOUT sections into better aligned memory
regions conducive to the DMA pool allocation scheme.
- Increase the vmalloc size, as the DMA pools are no longer mapped by
default in kernel linear memory (for DDR < 2 GB) and needs to be
mapped into vmalloc space to be accessed. This may depend on system
configuration, number of remote cores using a DMA pool, and the sizes
of the DMA pools.
- Increase the size of the carveouts (last resort)
Revert back to CMA pools temporarily to make the current firmware images
be functional. A short-term fix would be to update the firmwares and the
long-term fix would be to eliminate the allocation logic altogether and
rely on fixed memory carveout support.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The patch d1a42fca5944 ("TEMP: ARM: dts: dra7-ipu-common: Add a common
file for IPU early boots") converts the default CMA pools used in regular
remoteproc mode to carveouts/DMA pools for early-boot usage scenarios
using the "no-map" property to avoid the kernel from corrupting the
remoteproc firmware image sections.
The allocation scheme with DMA pools though is different than with CMA
pools, and this may cause some of the existing firmwares used in the
regular remoteproc mode with CMA to fail. The DMA pools may require a
number of changes in general:
- Split the firmware RSC_CARVEOUT sections into better aligned memory
regions conducive to the DMA pool allocation scheme.
- Increase the vmalloc size, as the DMA pools are no longer mapped by
default in kernel linear memory (for DDR < 2 GB) and needs to be
mapped into vmalloc space to be accessed. This may depend on system
configuration, number of remote cores using a DMA pool, and the sizes
of the DMA pools.
- Increase the size of the carveouts (last resort)
Revert back to CMA pools temporarily to make the current firmware images
be functional. A short-term fix would be to update the firmwares and the
long-term fix would be to eliminate the allocation logic altogether and
rely on fixed memory carveout support.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
TEMP: ARM: dts: dra7-ipu-common: Add a common file for IPU early boots
The remoteproc 'late attach' functionality has the remote processors
configured, programmed and booted early even before the kernel is booted.
This includes loading the necessary firmware into memory, programming the
IOMMU, configuring the required timers, and programming the corresponding
device's clocks and resets.
The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU1 & IPU2 processor subsystems to support the
'late attach' feature on these devices, and change the omap hwmod init
behavior. The corresponding memory regions are also removed from the
default kernel memory map (DMA pools instead of CMA pools) so that the
kernel doesn't access anything in these regions until the remoteprocs
are booted.
The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-idle-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).
These attributes are added in a new common dtsi file that should be
included into the corresponding TI DRA7xx and AM57xx boards that have
actually early-booted the IPU processors. This file _must_ be included
_only_ when both the IPU1 and IPU2 processors have been booted by
SPL/U-boot.
TODO:
Evaluate the approach where U-Boot can directly add/modify these required
properties using code. Such an approach would eliminate the need for
maintaining one or more dtsi files/overlays and make the support
self-contained within the bootloader.
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The remoteproc 'late attach' functionality has the remote processors
configured, programmed and booted early even before the kernel is booted.
This includes loading the necessary firmware into memory, programming the
IOMMU, configuring the required timers, and programming the corresponding
device's clocks and resets.
The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU1 & IPU2 processor subsystems to support the
'late attach' feature on these devices, and change the omap hwmod init
behavior. The corresponding memory regions are also removed from the
default kernel memory map (DMA pools instead of CMA pools) so that the
kernel doesn't access anything in these regions until the remoteprocs
are booted.
The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-idle-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).
These attributes are added in a new common dtsi file that should be
included into the corresponding TI DRA7xx and AM57xx boards that have
actually early-booted the IPU processors. This file _must_ be included
_only_ when both the IPU1 and IPU2 processors have been booted by
SPL/U-boot.
TODO:
Evaluate the approach where U-Boot can directly add/modify these required
properties using code. Such an approach would eliminate the need for
maintaining one or more dtsi files/overlays and make the support
self-contained within the bootloader.
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
TEMP: remoteproc/omap: add "late attach" support
Add the necessary support in the OMAP remoteproc driver to enable the
"late attach" functionality. The 'late attach' functionality has the
processors already loaded and running by the time the kernel has booted.
The 'late attach' support in OMAP remoteproc driver is added through
minimal changes like skipping the releasing of the processor reset.
The processor reset is skipped as this relies on the omap_hwmod /
omap_device API which perform a module disable/enable sequence in
addition to the reset programming. Other required functionality is
achieved through the late attach support in the remoteproc driver core.
During late attach, we use non-zeroing dma ops to prevent the kernel
from overwriting already loaded code and data segments. When shutting
down the processor, we restore the normal zeroing dma ops. This allows
the kernel to clear memory when loading a new remoteproc binary or
during error recovery with the current remoteproc binary.
The 'late attach' capability is determined through a .device_is_enabled
pdata ops. The rproc nodes along with the corresponding IOMMU and timer
nodes should all have the "ti,no-idle-on-init" and "ti,no-reset-on-init"
properties set to prevent omap_hwmod from resetting and idling these
devices on boot.
The .late_attach field in the rproc data structure is used to denote
the mode and differentiate a normal boot from a late-attach boot. The
late_attach functionality is relevant only for the first time boot of
the kernel, and will be reset for subsequent probes of the remoteproc
node. The flag is also reset during the stopping of the remoteproc,
so that any error recovery results in a regular boot.
TODO:
Move away from modifying the dma_ops for the device completely.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Add the necessary support in the OMAP remoteproc driver to enable the
"late attach" functionality. The 'late attach' functionality has the
processors already loaded and running by the time the kernel has booted.
The 'late attach' support in OMAP remoteproc driver is added through
minimal changes like skipping the releasing of the processor reset.
The processor reset is skipped as this relies on the omap_hwmod /
omap_device API which perform a module disable/enable sequence in
addition to the reset programming. Other required functionality is
achieved through the late attach support in the remoteproc driver core.
During late attach, we use non-zeroing dma ops to prevent the kernel
from overwriting already loaded code and data segments. When shutting
down the processor, we restore the normal zeroing dma ops. This allows
the kernel to clear memory when loading a new remoteproc binary or
during error recovery with the current remoteproc binary.
The 'late attach' capability is determined through a .device_is_enabled
pdata ops. The rproc nodes along with the corresponding IOMMU and timer
nodes should all have the "ti,no-idle-on-init" and "ti,no-reset-on-init"
properties set to prevent omap_hwmod from resetting and idling these
devices on boot.
The .late_attach field in the rproc data structure is used to denote
the mode and differentiate a normal boot from a late-attach boot. The
late_attach functionality is relevant only for the first time boot of
the kernel, and will be reset for subsequent probes of the remoteproc
node. The flag is also reset during the stopping of the remoteproc,
so that any error recovery results in a regular boot.
TODO:
Move away from modifying the dma_ops for the device completely.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
TEMP: iommu/omap: add support for performing a "late attach"
The remoteproc module has a concept of "late attach" whereby a remote
core is loaded externally to remoteproc, for which remoteproc must
attach to the core without disrupting its existing state. Introduce an
iommu-based "late attach" model for the same use case.
In the "late attach" model, the iommu subsystem is mostly unused since
the external loader will have programmed the remote core's mmu, but
certain "attach" functionality must be performed so that subsequent
"detach" functionality can complete.
This logic is detected in the driver through a "ti,late-attach" property
set on the IOMMU node in the device tree. The IOMMU node should also have
the "ti,no-init-on-reset" and "ti,no-init-on-idle" so that the omap_hwmod
and omap_device layers do not reset and idle/disable the device during
the initial kernel boot. This "ti,late-attach" is therefore removed from
the device tree on the first probe so that further probes or remoteproc
recovery boots treat the IOMMU device normally.
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Subash Lakkimsetti <x0091084@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
The remoteproc module has a concept of "late attach" whereby a remote
core is loaded externally to remoteproc, for which remoteproc must
attach to the core without disrupting its existing state. Introduce an
iommu-based "late attach" model for the same use case.
In the "late attach" model, the iommu subsystem is mostly unused since
the external loader will have programmed the remote core's mmu, but
certain "attach" functionality must be performed so that subsequent
"detach" functionality can complete.
This logic is detected in the driver through a "ti,late-attach" property
set on the IOMMU node in the device tree. The IOMMU node should also have
the "ti,no-init-on-reset" and "ti,no-init-on-idle" so that the omap_hwmod
and omap_device layers do not reset and idle/disable the device during
the initial kernel boot. This "ti,late-attach" is therefore removed from
the device tree on the first probe so that further probes or remoteproc
recovery boots treat the IOMMU device normally.
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Subash Lakkimsetti <x0091084@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
ARM: OMAP2+: pdata-quirks: Add device_is_enabled ops for IOMMUs and rprocs
Add a new .device_is_enabled() platform data callback ops to both
the OMAP IOMMU and remoteproc devices to check if the corresponding
omap_device/hwmod is already enabled. This helps the OMAP IOMMU and
remoteproc drivers to figure out if the corresponding processors
have already been loaded and booted by bootloaders.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[s-anna@ti.com: minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a new .device_is_enabled() platform data callback ops to both
the OMAP IOMMU and remoteproc devices to check if the corresponding
omap_device/hwmod is already enabled. This helps the OMAP IOMMU and
remoteproc drivers to figure out if the corresponding processors
have already been loaded and booted by bootloaders.
Signed-off-by: Keerthy <j-keerthy@ti.com>
[s-anna@ti.com: minor cleanups]
Signed-off-by: Suman Anna <s-anna@ti.com>
clocksource: timer-ti-dm: Add support to handle late attach of rproc timers
During late attach, the dmtimers used by remote processors would already
have been configured and running. To prevent the kernel from resetting or
reconfiguring the timers,
- Set the late attach parameter if the timer is already running.
- If late attach flag is set, increment the dmtimer's usage counter
immediately on probe and maintain this state until remoteproc starts
the timer. This prevents kernel power management functionality from
idling and disabling the dmtimers.
- If late attach flag is set, also prevent the dmtimer configuration
code from modifying the dmtimer registers.
The late attach flag in the omap_dm_timer structure is cleared on timer
start to allow normal operation to resume.
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
During late attach, the dmtimers used by remote processors would already
have been configured and running. To prevent the kernel from resetting or
reconfiguring the timers,
- Set the late attach parameter if the timer is already running.
- If late attach flag is set, increment the dmtimer's usage counter
immediately on probe and maintain this state until remoteproc starts
the timer. This prevents kernel power management functionality from
idling and disabling the dmtimers.
- If late attach flag is set, also prevent the dmtimer configuration
code from modifying the dmtimer registers.
The late attach flag in the omap_dm_timer structure is cleared on timer
start to allow normal operation to resume.
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
TEMP: remoteproc: call the non-zeroing allocation function
For DMA pool scenario the plugged in allocation ops are not
used for carveout allocation. It is necessary to call a differnt
function that does not zero the DMA pool memory gotten from
the call to dma_alloc_coherent.
Call the dma_malloc_coherent (non-zeroing) api in the case
of late attach to guarantee that the memory is not zero-ed for
either a CMA or DMA pool. The memory for virtio rings is not
used in U-Boot, so need not use the non-zeroing function.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
For DMA pool scenario the plugged in allocation ops are not
used for carveout allocation. It is necessary to call a differnt
function that does not zero the DMA pool memory gotten from
the call to dma_alloc_coherent.
Call the dma_malloc_coherent (non-zeroing) api in the case
of late attach to guarantee that the memory is not zero-ed for
either a CMA or DMA pool. The memory for virtio rings is not
used in U-Boot, so need not use the non-zeroing function.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Shravan Karthik <shravan.karthik@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
TEMP: remoteproc: add "late attach" support
The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.
The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.
The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.
The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.
The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
HACK: dma-mapping: add non-zeroing coherent alloc function
Add a new function, dma_malloc_from_coherent(), which
takes a parameter that specifies if the allocated memory
should be zero-ed or not. Modify dma_alloc_from_coherent
to call dma_malloc_from_coherent with the flag set to
true in order to zero the memory. In this way
dma_alloc_from_coherent behaves the same as before.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Add a new function, dma_malloc_from_coherent(), which
takes a parameter that specifies if the allocated memory
should be zero-ed or not. Modify dma_alloc_from_coherent
to call dma_malloc_from_coherent with the flag set to
true in order to zero the memory. In this way
dma_alloc_from_coherent behaves the same as before.
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
HACK: ARM: dma-mapping: create non-zeroing dma_map_ops
A new dma_ops, 'arm_dma_m_ops', is created from a copy of the
standard 'arm_dma_ops' but with a new non-zeroing .alloc method.
These ops are added mainly to support a 'late attach' feature in
the OMAP remoteproc driver. When remoteproc does a 'late attach'
to a remote processor, it does not load any firmware contents into
memory, but it still needs to allocate the processor's CMA memory
to mark the memory as reserved/used from the kernel. The standard
'arm_dma_ops' contains an .alloc method that zeroes out the memory,
thereby overwriting the firmware code/data in the memory that was
pre-loaded before the Linux kernel has booted.
This scenario is handled by adding a new non-zeroing allocation
function and using it as the .alloc method in a copy of the
'arm_dma_ops'. The so created 'arm_dma_m_ops' will be assigned
as the rproc device's dma_ops when supporting the 'late attach'
functionality.
Signed-off-by: Martin Ambrose <martin@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
A new dma_ops, 'arm_dma_m_ops', is created from a copy of the
standard 'arm_dma_ops' but with a new non-zeroing .alloc method.
These ops are added mainly to support a 'late attach' feature in
the OMAP remoteproc driver. When remoteproc does a 'late attach'
to a remote processor, it does not load any firmware contents into
memory, but it still needs to allocate the processor's CMA memory
to mark the memory as reserved/used from the kernel. The standard
'arm_dma_ops' contains an .alloc method that zeroes out the memory,
thereby overwriting the firmware code/data in the memory that was
pre-loaded before the Linux kernel has booted.
This scenario is handled by adding a new non-zeroing allocation
function and using it as the .alloc method in a copy of the
'arm_dma_ops'. The so created 'arm_dma_m_ops' will be assigned
as the rproc device's dma_ops when supporting the 'late attach'
functionality.
Signed-off-by: Martin Ambrose <martin@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Linux 4.19.75
media: technisat-usb2: break out of loop at end of buffer
commit 0c4df39e504bf925ab666132ac3c98d6cbbe380b upstream.
Ensure we do not access the buffer beyond the end if no 0xff byte
is encountered.
Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0c4df39e504bf925ab666132ac3c98d6cbbe380b upstream.
Ensure we do not access the buffer beyond the end if no 0xff byte
is encountered.
Reported-by: syzbot+eaaaf38a95427be88f4b@syzkaller.appspotmail.com
Signed-off-by: Sean Young <sean@mess.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arm64: kpti: Whitelist Cortex-A CPUs that don't implement the CSV3 field
commit 2a355ec25729053bb9a1a89b6c1d1cdd6c3b3fb1 upstream.
While the CSV3 field of the ID_AA64_PFR0 CPU ID register can be checked
to see if a CPU is susceptible to Meltdown and therefore requires kpti
to be enabled, existing CPUs do not implement this field.
We therefore whitelist all unaffected Cortex-A CPUs that do not implement
the CSV3 field.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a355ec25729053bb9a1a89b6c1d1cdd6c3b3fb1 upstream.
While the CSV3 field of the ID_AA64_PFR0 CPU ID register can be checked
to see if a CPU is susceptible to Meltdown and therefore requires kpti
to be enabled, existing CPUs do not implement this field.
We therefore whitelist all unaffected Cortex-A CPUs that do not implement
the CSV3 field.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Cc: Niklas Cassel <niklas.cassel@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
binfmt_elf: move brk out of mmap when doing direct loader exec
commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream.
Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
made changes in the rare case when the ELF loader was directly invoked
(e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
the loader), by moving into the mmap region to avoid both ET_EXEC and
PIE binaries. This had the effect of also moving the brk region into
mmap, which could lead to the stack and brk being arbitrarily close to
each other. An unlucky process wouldn't get its requested stack size
and stack allocations could end up scribbling on the heap.
This is illustrated here. In the case of using the loader directly, brk
(so helpfully identified as "[heap]") is allocated with the _loader_ not
the binary. For example, with ASLR entirely disabled, you can see this
more clearly:
$ /bin/cat /proc/self/maps
555555554000-55555555c000 r-xp 00000000 ... /bin/cat
55555575b000-55555575c000 r--p 00007000 ... /bin/cat
55555575c000-55555575d000 rw-p 00008000 ... /bin/cat
55555575d000-55555577e000 rw-p 00000000 ... [heap]
...
7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 ...
7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
$ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps
...
7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat
7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat
7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat
7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat
7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ...
7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap]
7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since
nothing is there in the direct loader case (and ET_EXEC is still far
away at 0x400000). Anything that ran before should still work (i.e.
the ultimately-launched binary already had the brk very far from its
text, so this should be no different from a COMPAT_BRK standpoint). The
only risk I see here is that if someone started to suddenly depend on
the entire memory space lower than the mmap region being available when
launching binaries via a direct loader execs which seems highly
unlikely, I'd hope: this would mean a binary would _not_ work when
exec()ed normally.
(Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION
when randomization is turned on.)
Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast
Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com
Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Ali Saidi <alisaidi@amazon.com>
Cc: Ali Saidi <alisaidi@amazon.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bbdc6076d2e5d07db44e74c11b01a3e27ab90b32 upstream.
Commmit eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE"),
made changes in the rare case when the ELF loader was directly invoked
(e.g to set a non-inheritable LD_LIBRARY_PATH, testing new versions of
the loader), by moving into the mmap region to avoid both ET_EXEC and
PIE binaries. This had the effect of also moving the brk region into
mmap, which could lead to the stack and brk being arbitrarily close to
each other. An unlucky process wouldn't get its requested stack size
and stack allocations could end up scribbling on the heap.
This is illustrated here. In the case of using the loader directly, brk
(so helpfully identified as "[heap]") is allocated with the _loader_ not
the binary. For example, with ASLR entirely disabled, you can see this
more clearly:
$ /bin/cat /proc/self/maps
555555554000-55555555c000 r-xp 00000000 ... /bin/cat
55555575b000-55555575c000 r--p 00007000 ... /bin/cat
55555575c000-55555575d000 rw-p 00008000 ... /bin/cat
55555575d000-55555577e000 rw-p 00000000 ... [heap]
...
7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 ...
7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
$ /lib/x86_64-linux-gnu/ld-2.27.so /bin/cat /proc/self/maps
...
7ffff7bcc000-7ffff7bd4000 r-xp 00000000 ... /bin/cat
7ffff7bd4000-7ffff7dd3000 ---p 00008000 ... /bin/cat
7ffff7dd3000-7ffff7dd4000 r--p 00007000 ... /bin/cat
7ffff7dd4000-7ffff7dd5000 rw-p 00008000 ... /bin/cat
7ffff7dd5000-7ffff7dfc000 r-xp 00000000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7fb2000-7ffff7fd6000 rw-p 00000000 ...
7ffff7ff7000-7ffff7ffa000 r--p 00000000 ... [vvar]
7ffff7ffa000-7ffff7ffc000 r-xp 00000000 ... [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00027000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffd000-7ffff7ffe000 rw-p 00028000 ... /lib/x86_64-linux-gnu/ld-2.27.so
7ffff7ffe000-7ffff8020000 rw-p 00000000 ... [heap]
7ffffffde000-7ffffffff000 rw-p 00000000 ... [stack]
The solution is to move brk out of mmap and into ELF_ET_DYN_BASE since
nothing is there in the direct loader case (and ET_EXEC is still far
away at 0x400000). Anything that ran before should still work (i.e.
the ultimately-launched binary already had the brk very far from its
text, so this should be no different from a COMPAT_BRK standpoint). The
only risk I see here is that if someone started to suddenly depend on
the entire memory space lower than the mmap region being available when
launching binaries via a direct loader execs which seems highly
unlikely, I'd hope: this would mean a binary would _not_ work when
exec()ed normally.
(Note that this is only done under CONFIG_ARCH_HAS_ELF_RANDOMIZATION
when randomization is turned on.)
Link: http://lkml.kernel.org/r/20190422225727.GA21011@beast
Link: https://lkml.kernel.org/r/CAGXu5jJ5sj3emOT2QPxQkNQk0qbU6zEfu9=Omfhx_p0nCKPSjA@mail.gmail.com
Fixes: eab09532d400 ("binfmt_elf: use ELF_ET_DYN_BASE only for PIE")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Ali Saidi <alisaidi@amazon.com>
Cc: Ali Saidi <alisaidi@amazon.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
floppy: fix usercopy direction
commit 52f6f9d74f31078964ca1574f7bb612da7877ac8 upstream.
As sparse points out, these two copy_from_user() should actually be
copy_to_user().
Fixes: 229b53c9bf4e ("take floppy compat ioctls to sodding floppy.c")
Cc: stable@vger.kernel.org
Acked-by: Alexander Popov <alex.popov@linux.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 52f6f9d74f31078964ca1574f7bb612da7877ac8 upstream.
As sparse points out, these two copy_from_user() should actually be
copy_to_user().
Fixes: 229b53c9bf4e ("take floppy compat ioctls to sodding floppy.c")
Cc: stable@vger.kernel.org
Acked-by: Alexander Popov <alex.popov@linux.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ovl: fix regression caused by overlapping layers detection
commit 0be0bfd2de9dfdd2098a9c5b14bdd8f739c9165d upstream.
Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
This change caused a docker regression. The root cause was mount leaks
by docker, which as far as I know, still exist.
To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
caused by exclusive upper/work dir protection") in v4.14 turned the
mount errors into warnings for the default index=off configuration.
Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
v5.2, re-introduced exclusive upper/work dir checks regardless of
index=off configuration.
This changes the status quo and mount leak related bug reports have
started to re-surface. Restore the status quo to fix the regressions.
To clarify, index=off does NOT relax overlapping layers check for this
ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
with another overlayfs mount.
To cover the part of overlapping layers detection that used the
exclusive upper/work dir checks to detect overlap with self upper/work
dir, add a trap also on the work base dir.
Link: https://github.com/moby/moby/issues/34672
Link: https://lore.kernel.org/linux-fsdevel/20171006121405.GA32700@veci.piliscsaba.szeredi.hu/
Link: https://github.com/containers/libpod/issues/3540
Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Tested-by: Colin Walters <walters@verbum.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0be0bfd2de9dfdd2098a9c5b14bdd8f739c9165d upstream.
Once upon a time, commit 2cac0c00a6cd ("ovl: get exclusive ownership on
upper/work dirs") in v4.13 added some sanity checks on overlayfs layers.
This change caused a docker regression. The root cause was mount leaks
by docker, which as far as I know, still exist.
To mitigate the regression, commit 85fdee1eef1a ("ovl: fix regression
caused by exclusive upper/work dir protection") in v4.14 turned the
mount errors into warnings for the default index=off configuration.
Recently, commit 146d62e5a586 ("ovl: detect overlapping layers") in
v5.2, re-introduced exclusive upper/work dir checks regardless of
index=off configuration.
This changes the status quo and mount leak related bug reports have
started to re-surface. Restore the status quo to fix the regressions.
To clarify, index=off does NOT relax overlapping layers check for this
ovelayfs mount. index=off only relaxes exclusive upper/work dir checks
with another overlayfs mount.
To cover the part of overlapping layers detection that used the
exclusive upper/work dir checks to detect overlap with self upper/work
dir, add a trap also on the work base dir.
Link: https://github.com/moby/moby/issues/34672
Link: https://lore.kernel.org/linux-fsdevel/20171006121405.GA32700@veci.piliscsaba.szeredi.hu/
Link: https://github.com/containers/libpod/issues/3540
Fixes: 146d62e5a586 ("ovl: detect overlapping layers")
Cc: <stable@vger.kernel.org> # v4.19+
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Tested-by: Colin Walters <walters@verbum.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PCI: kirin: Fix section mismatch warning
commit 6870b673509779195cab300aedc844b352d9cfbc upstream.
The PCI kirin driver compilation produces the following section mismatch
warning:
WARNING: vmlinux.o(.text+0x4758cc): Section mismatch in reference from
the function kirin_pcie_probe() to the function
.init.text:kirin_add_pcie_port()
The function kirin_pcie_probe() references
the function __init kirin_add_pcie_port().
This is often because kirin_pcie_probe lacks a __init
annotation or the annotation of kirin_add_pcie_port is wrong.
Remove '__init' from kirin_add_pcie_port() to fix it.
Fixes: fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller driver")
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6870b673509779195cab300aedc844b352d9cfbc upstream.
The PCI kirin driver compilation produces the following section mismatch
warning:
WARNING: vmlinux.o(.text+0x4758cc): Section mismatch in reference from
the function kirin_pcie_probe() to the function
.init.text:kirin_add_pcie_port()
The function kirin_pcie_probe() references
the function __init kirin_add_pcie_port().
This is often because kirin_pcie_probe lacks a __init
annotation or the annotation of kirin_add_pcie_port is wrong.
Remove '__init' from kirin_add_pcie_port() to fix it.
Fixes: fc5165db245a ("PCI: kirin: Add HiSilicon Kirin SoC PCIe controller driver")
Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
[lorenzo.pieralisi@arm.com: updated commit log]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iommu/amd: Fix race in increase_address_space()
[ Upstream commit 754265bcab78a9014f0f99cd35e0d610fcd7dfa7 ]
After the conversion to lock-less dma-api call the
increase_address_space() function can be called without any
locking. Multiple CPUs could potentially race for increasing
the address space, leading to invalid domain->mode settings
and invalid page-tables. This has been happening in the wild
under high IO load and memory pressure.
Fix the race by locking this operation. The function is
called infrequently so that this does not introduce
a performance regression in the dma-api path again.
Reported-by: Qian Cai <cai@lca.pw>
Fixes: 256e4621c21a ('iommu/amd: Make use of the generic IOVA allocator')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 754265bcab78a9014f0f99cd35e0d610fcd7dfa7 ]
After the conversion to lock-less dma-api call the
increase_address_space() function can be called without any
locking. Multiple CPUs could potentially race for increasing
the address space, leading to invalid domain->mode settings
and invalid page-tables. This has been happening in the wild
under high IO load and memory pressure.
Fix the race by locking this operation. The function is
called infrequently so that this does not introduce
a performance regression in the dma-api path again.
Reported-by: Qian Cai <cai@lca.pw>
Fixes: 256e4621c21a ('iommu/amd: Make use of the generic IOVA allocator')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
iommu/amd: Flush old domains in kdump kernel
[ Upstream commit 36b7200f67dfe75b416b5281ed4ace9927b513bc ]
When devices are attached to the amd_iommu in a kdump kernel, the old device
table entries (DTEs), which were copied from the crashed kernel, will be
overwritten with a new domain number. When the new DTE is written, the IOMMU
is told to flush the DTE from its internal cache--but it is not told to flush
the translation cache entries for the old domain number.
Without this patch, AMD systems using the tg3 network driver fail when kdump
tries to save the vmcore to a network system, showing network timeouts and
(sometimes) IOMMU errors in the kernel log.
This patch will flush IOMMU translation cache entries for the old domain when
a DTE gets overwritten with a new domain number.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Fixes: 3ac3e5ee5ed5 ('iommu/amd: Copy old trans table from old kernel')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 36b7200f67dfe75b416b5281ed4ace9927b513bc ]
When devices are attached to the amd_iommu in a kdump kernel, the old device
table entries (DTEs), which were copied from the crashed kernel, will be
overwritten with a new domain number. When the new DTE is written, the IOMMU
is told to flush the DTE from its internal cache--but it is not told to flush
the translation cache entries for the old domain number.
Without this patch, AMD systems using the tg3 network driver fail when kdump
tries to save the vmcore to a network system, showing network timeouts and
(sometimes) IOMMU errors in the kernel log.
This patch will flush IOMMU translation cache entries for the old domain when
a DTE gets overwritten with a new domain number.
Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com>
Fixes: 3ac3e5ee5ed5 ('iommu/amd: Copy old trans table from old kernel')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
keys: Fix missing null pointer check in request_key_auth_describe()
[ Upstream commit d41a3effbb53b1bcea41e328d16a4d046a508381 ]
If a request_key authentication token key gets revoked, there's a window in
which request_key_auth_describe() can see it with a NULL payload - but it
makes no check for this and something like the following oops may occur:
BUG: Kernel NULL pointer dereference at 0x00000038
Faulting instruction address: 0xc0000000004ddf30
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [...] request_key_auth_describe+0x90/0xd0
LR [...] request_key_auth_describe+0x54/0xd0
Call Trace:
[...] request_key_auth_describe+0x54/0xd0 (unreliable)
[...] proc_keys_show+0x308/0x4c0
[...] seq_read+0x3d0/0x540
[...] proc_reg_read+0x90/0x110
[...] __vfs_read+0x3c/0x70
[...] vfs_read+0xb4/0x1b0
[...] ksys_read+0x7c/0x130
[...] system_call+0x5c/0x70
Fix this by checking for a NULL pointer when describing such a key.
Also make the read routine check for a NULL pointer to be on the safe side.
[DH: Modified to not take already-held rcu lock and modified to also check
in the read routine]
Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Hillf Danton <hdanton@sina.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d41a3effbb53b1bcea41e328d16a4d046a508381 ]
If a request_key authentication token key gets revoked, there's a window in
which request_key_auth_describe() can see it with a NULL payload - but it
makes no check for this and something like the following oops may occur:
BUG: Kernel NULL pointer dereference at 0x00000038
Faulting instruction address: 0xc0000000004ddf30
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [...] request_key_auth_describe+0x90/0xd0
LR [...] request_key_auth_describe+0x54/0xd0
Call Trace:
[...] request_key_auth_describe+0x54/0xd0 (unreliable)
[...] proc_keys_show+0x308/0x4c0
[...] seq_read+0x3d0/0x540
[...] proc_reg_read+0x90/0x110
[...] __vfs_read+0x3c/0x70
[...] vfs_read+0xb4/0x1b0
[...] ksys_read+0x7c/0x130
[...] system_call+0x5c/0x70
Fix this by checking for a NULL pointer when describing such a key.
Also make the read routine check for a NULL pointer to be on the safe side.
[DH: Modified to not take already-held rcu lock and modified to also check
in the read routine]
Fixes: 04c567d9313e ("[PATCH] Keys: Fix race between two instantiators of a key")
Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Hillf Danton <hdanton@sina.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
x86/hyper-v: Fix overflow bug in fill_gva_list()
[ Upstream commit 4030b4c585c41eeefec7bd20ce3d0e100a0f2e4d ]
When the 'start' parameter is >= 0xFF000000 on 32-bit
systems, or >= 0xFFFFFFFF'FF000000 on 64-bit systems,
fill_gva_list() gets into an infinite loop.
With such inputs, 'cur' overflows after adding HV_TLB_FLUSH_UNIT
and always compares as less than end. Memory is filled with
guest virtual addresses until the system crashes.
Fix this by never incrementing 'cur' to be larger than 'end'.
Reported-by: Jong Hyun Park <park.jonghyun@yonsei.ac.kr>
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 2ffd9e33ce4a ("x86/hyper-v: Use hypercall for remote TLB flush")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4030b4c585c41eeefec7bd20ce3d0e100a0f2e4d ]
When the 'start' parameter is >= 0xFF000000 on 32-bit
systems, or >= 0xFFFFFFFF'FF000000 on 64-bit systems,
fill_gva_list() gets into an infinite loop.
With such inputs, 'cur' overflows after adding HV_TLB_FLUSH_UNIT
and always compares as less than end. Memory is filled with
guest virtual addresses until the system crashes.
Fix this by never incrementing 'cur' to be larger than 'end'.
Reported-by: Jong Hyun Park <park.jonghyun@yonsei.ac.kr>
Signed-off-by: Tianyu Lan <Tianyu.Lan@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 2ffd9e33ce4a ("x86/hyper-v: Use hypercall for remote TLB flush")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
x86/uaccess: Don't leak the AC flags into __get_user() argument evaluation
[ Upstream commit 9b8bd476e78e89c9ea26c3b435ad0201c3d7dbf5 ]
Identical to __put_user(); the __get_user() argument evalution will too
leak UBSAN crud into the __uaccess_begin() / __uaccess_end() region.
While uncommon this was observed to happen for:
drivers/xen/gntdev.c: if (__get_user(old_status, batch->status[i]))
where UBSAN added array bound checking.
This complements commit:
6ae865615fc4 ("x86/uaccess: Dont leak the AC flag into __put_user() argument evaluation")
Tested-by Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: broonie@kernel.org
Cc: sfr@canb.auug.org.au
Cc: akpm@linux-foundation.org
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: mhocko@suse.cz
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20190829082445.GM2369@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9b8bd476e78e89c9ea26c3b435ad0201c3d7dbf5 ]
Identical to __put_user(); the __get_user() argument evalution will too
leak UBSAN crud into the __uaccess_begin() / __uaccess_end() region.
While uncommon this was observed to happen for:
drivers/xen/gntdev.c: if (__get_user(old_status, batch->status[i]))
where UBSAN added array bound checking.
This complements commit:
6ae865615fc4 ("x86/uaccess: Dont leak the AC flag into __put_user() argument evaluation")
Tested-by Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: broonie@kernel.org
Cc: sfr@canb.auug.org.au
Cc: akpm@linux-foundation.org
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: mhocko@suse.cz
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20190829082445.GM2369@hirez.programming.kicks-ass.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
dmaengine: ti: omap-dma: Add cleanup in omap_dma_probe()
[ Upstream commit 962411b05a6d3342aa649e39cda1704c1fc042c6 ]
If devm_request_irq() fails to disable all interrupts, no cleanup is
performed before retuning the error. To fix this issue, invoke
omap_dma_free() to do the cleanup.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/1565938570-7528-1-git-send-email-wenwen@cs.uga.edu
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 962411b05a6d3342aa649e39cda1704c1fc042c6 ]
If devm_request_irq() fails to disable all interrupts, no cleanup is
performed before retuning the error. To fix this issue, invoke
omap_dma_free() to do the cleanup.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/1565938570-7528-1-git-send-email-wenwen@cs.uga.edu
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
dmaengine: ti: dma-crossbar: Fix a memory leak bug
[ Upstream commit 2c231c0c1dec42192aca0f87f2dc68b8f0cbc7d2 ]
In ti_dra7_xbar_probe(), 'rsv_events' is allocated through kcalloc(). Then
of_property_read_u32_array() is invoked to search for the property.
However, if this process fails, 'rsv_events' is not deallocated, leading to
a memory leak bug. To fix this issue, free 'rsv_events' before returning
the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/1565938136-7249-1-git-send-email-wenwen@cs.uga.edu
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2c231c0c1dec42192aca0f87f2dc68b8f0cbc7d2 ]
In ti_dra7_xbar_probe(), 'rsv_events' is allocated through kcalloc(). Then
of_property_read_u32_array() is invoked to search for the property.
However, if this process fails, 'rsv_events' is not deallocated, leading to
a memory leak bug. To fix this issue, free 'rsv_events' before returning
the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/1565938136-7249-1-git-send-email-wenwen@cs.uga.edu
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: seeq: Fix the function used to release some memory in an error handling path
[ Upstream commit e1e54ec7fb55501c33b117c111cb0a045b8eded2 ]
In commit 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv"),
a call to 'get_zeroed_page()' has been turned into a call to
'dma_alloc_coherent()'. Only the remove function has been updated to turn
the corresponding 'free_page()' into 'dma_free_attrs()'.
The error hndling path of the probe function has not been updated.
Fix it now.
Rename the corresponding label to something more in line.
Fixes: 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e1e54ec7fb55501c33b117c111cb0a045b8eded2 ]
In commit 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv"),
a call to 'get_zeroed_page()' has been turned into a call to
'dma_alloc_coherent()'. Only the remove function has been updated to turn
the corresponding 'free_page()' into 'dma_free_attrs()'.
The error hndling path of the probe function has not been updated.
Fix it now.
Rename the corresponding label to something more in line.
Fixes: 99cd149efe82 ("sgiseeq: replace use of dma_cache_wback_inv")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
net: aquantia: fix out of memory condition on rx side
[ Upstream commit be6cef69ba570ebb327eba1ef6438f7af49aaf86 ]
On embedded environments with hard memory limits it is a normal although
rare case when skb can't be allocated on rx part under high traffic.
In such OOM cases napi_complete_done() was not called.
So the napi object became in an invalid state like it is "scheduled".
Kernel do not re-schedules the poll of that napi object.
Consequently, kernel can not remove that object the system hangs on
`ifconfig down` waiting for a poll.
We are fixing this by gracefully closing napi poll routine with correct
invocation of napi_complete_done.
This was reproduced with artificially failing the allocation of skb to
simulate an "out of memory" error case and check that traffic does
not get stuck.
Fixes: 970a2e9864b0 ("net: ethernet: aquantia: Vector operations")
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit be6cef69ba570ebb327eba1ef6438f7af49aaf86 ]
On embedded environments with hard memory limits it is a normal although
rare case when skb can't be allocated on rx part under high traffic.
In such OOM cases napi_complete_done() was not called.
So the napi object became in an invalid state like it is "scheduled".
Kernel do not re-schedules the poll of that napi object.
Consequently, kernel can not remove that object the system hangs on
`ifconfig down` waiting for a poll.
We are fixing this by gracefully closing napi poll routine with correct
invocation of napi_complete_done.
This was reproduced with artificially failing the allocation of skb to
simulate an "out of memory" error case and check that traffic does
not get stuck.
Fixes: 970a2e9864b0 ("net: ethernet: aquantia: Vector operations")
Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: Dmitry Bogdanov <dmitry.bogdanov@aquantia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/power turbostat: fix buffer overrun
[ Upstream commit eeb71c950bc6eee460f2070643ce137e067b234c ]
turbostat could be terminated by general protection fault on some latest
hardwares which (for example) support 9 levels of C-states and show 18
"tADDED" lines. That bloats the total output and finally causes buffer
overrun. So let's extend the buffer to avoid this.
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit eeb71c950bc6eee460f2070643ce137e067b234c ]
turbostat could be terminated by general protection fault on some latest
hardwares which (for example) support 9 levels of C-states and show 18
"tADDED" lines. That bloats the total output and finally causes buffer
overrun. So let's extend the buffer to avoid this.
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/power x86_energy_perf_policy: Fix argument parsing
[ Upstream commit 03531482402a2bc4ab93cf6dde46833775e035e9 ]
The -w argument in x86_energy_perf_policy currently triggers an
unconditional segfault.
This is because the argument string reads: "+a:c:dD:E:e:f:m:M:rt:u:vw" and
yet the argument handler expects an argument.
When parse_optarg_string is called with a null argument, we then proceed to
crash in strncmp, not horribly friendly.
The man page describes -w as taking an argument, the long form
(--hwp-window) is correctly marked as taking a required argument, and the
code expects it.
As such, this patch simply marks the short form (-w) as requiring an
argument.
Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 03531482402a2bc4ab93cf6dde46833775e035e9 ]
The -w argument in x86_energy_perf_policy currently triggers an
unconditional segfault.
This is because the argument string reads: "+a:c:dD:E:e:f:m:M:rt:u:vw" and
yet the argument handler expects an argument.
When parse_optarg_string is called with a null argument, we then proceed to
crash in strncmp, not horribly friendly.
The man page describes -w as taking an argument, the long form
(--hwp-window) is correctly marked as taking a required argument, and the
code expects it.
As such, this patch simply marks the short form (-w) as requiring an
argument.
Signed-off-by: Zephaniah E. Loss-Cutler-Hull <zephaniah@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools/power x86_energy_perf_policy: Fix "uninitialized variable" warnings at -O2
[ Upstream commit adb8049097a9ec4acd09fbd3aa8636199a78df8a ]
x86_energy_perf_policy first uses __get_cpuid() to check the maximum
CPUID level and exits if it is too low. It then assumes that later
calls will succeed (which I think is architecturally guaranteed). It
also assumes that CPUID works at all (which is not guaranteed on
x86_32).
If optimisations are enabled, gcc warns about potentially
uninitialized variables. Fix this by adding an exit-on-error after
every call to __get_cpuid() instead of just checking the maximum
level.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit adb8049097a9ec4acd09fbd3aa8636199a78df8a ]
x86_energy_perf_policy first uses __get_cpuid() to check the maximum
CPUID level and exits if it is too low. It then assumes that later
calls will succeed (which I think is architecturally guaranteed). It
also assumes that CPUID works at all (which is not guaranteed on
x86_32).
If optimisations are enabled, gcc warns about potentially
uninitialized variables. Fix this by adding an exit-on-error after
every call to __get_cpuid() instead of just checking the maximum
level.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
amd-xgbe: Fix error path in xgbe_mod_init()
[ Upstream commit b6b4dc4c1fa7f1c99398e7dc85758049645e9588 ]
In xgbe_mod_init(), we should do cleanup if some error occurs
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: efbaa828330a ("amd-xgbe: Add support to handle device renaming")
Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b6b4dc4c1fa7f1c99398e7dc85758049645e9588 ]
In xgbe_mod_init(), we should do cleanup if some error occurs
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: efbaa828330a ("amd-xgbe: Add support to handle device renaming")
Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
perf/x86/amd/ibs: Fix sample bias for dispatched micro-ops
[ Upstream commit 0f4cd769c410e2285a4e9873a684d90423f03090 ]
When counting dispatched micro-ops with cnt_ctl=1, in order to prevent
sample bias, IBS hardware preloads the least significant 7 bits of
current count (IbsOpCurCnt) with random values, such that, after the
interrupt is handled and counting resumes, the next sample taken
will be slightly perturbed.
The current count bitfield is in the IBS execution control h/w register,
alongside the maximum count field.
Currently, the IBS driver writes that register with the maximum count,
leaving zeroes to fill the current count field, thereby overwriting
the random bits the hardware preloaded for itself.
Fix the driver to actually retain and carry those random bits from the
read of the IBS control register, through to its write, instead of
overwriting the lower current count bits with zeroes.
Tested with:
perf record -c 100001 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0 <workload>
'perf annotate' output before:
15.70 65: addsd %xmm0,%xmm1
17.30 add $0x1,%rax
15.88 cmp %rdx,%rax
je 82
17.32 72: test $0x1,%al
jne 7c
7.52 movapd %xmm1,%xmm0
5.90 jmp 65
8.23 7c: sqrtsd %xmm1,%xmm0
12.15 jmp 65
'perf annotate' output after:
16.63 65: addsd %xmm0,%xmm1
16.82 add $0x1,%rax
16.81 cmp %rdx,%rax
je 82
16.69 72: test $0x1,%al
jne 7c
8.30 movapd %xmm1,%xmm0
8.13 jmp 65
8.24 7c: sqrtsd %xmm1,%xmm0
8.39 jmp 65
Tested on Family 15h and 17h machines.
Machines prior to family 10h Rev. C don't have the RDWROPCNT capability,
and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't
affect their operation.
It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit
counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt
field; the number of preloaded random bits has always been 7, AFAICT.
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: <x86@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Borislav Petkov" <bp@alien8.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: "Namhyung Kim" <namhyung@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lkml.kernel.org/r/20190826195730.30614-1-kim.phillips@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0f4cd769c410e2285a4e9873a684d90423f03090 ]
When counting dispatched micro-ops with cnt_ctl=1, in order to prevent
sample bias, IBS hardware preloads the least significant 7 bits of
current count (IbsOpCurCnt) with random values, such that, after the
interrupt is handled and counting resumes, the next sample taken
will be slightly perturbed.
The current count bitfield is in the IBS execution control h/w register,
alongside the maximum count field.
Currently, the IBS driver writes that register with the maximum count,
leaving zeroes to fill the current count field, thereby overwriting
the random bits the hardware preloaded for itself.
Fix the driver to actually retain and carry those random bits from the
read of the IBS control register, through to its write, instead of
overwriting the lower current count bits with zeroes.
Tested with:
perf record -c 100001 -e ibs_op/cnt_ctl=1/pp -a -C 0 taskset -c 0 <workload>
'perf annotate' output before:
15.70 65: addsd %xmm0,%xmm1
17.30 add $0x1,%rax
15.88 cmp %rdx,%rax
je 82
17.32 72: test $0x1,%al
jne 7c
7.52 movapd %xmm1,%xmm0
5.90 jmp 65
8.23 7c: sqrtsd %xmm1,%xmm0
12.15 jmp 65
'perf annotate' output after:
16.63 65: addsd %xmm0,%xmm1
16.82 add $0x1,%rax
16.81 cmp %rdx,%rax
je 82
16.69 72: test $0x1,%al
jne 7c
8.30 movapd %xmm1,%xmm0
8.13 jmp 65
8.24 7c: sqrtsd %xmm1,%xmm0
8.39 jmp 65
Tested on Family 15h and 17h machines.
Machines prior to family 10h Rev. C don't have the RDWROPCNT capability,
and have the IbsOpCurCnt bitfield reserved, so this patch shouldn't
affect their operation.
It is unknown why commit db98c5faf8cb ("perf/x86: Implement 64-bit
counter support for IBS") ignored the lower 4 bits of the IbsOpCurCnt
field; the number of preloaded random bits has always been 7, AFAICT.
Signed-off-by: Kim Phillips <kim.phillips@amd.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: "Arnaldo Carvalho de Melo" <acme@kernel.org>
Cc: <x86@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Borislav Petkov" <bp@alien8.de>
Cc: Stephane Eranian <eranian@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: "Namhyung Kim" <namhyung@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Link: https://lkml.kernel.org/r/20190826195730.30614-1-kim.phillips@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
perf/x86/intel: Restrict period on Nehalem
[ Upstream commit 44d3bbb6f5e501b873218142fe08cdf62a4ac1f3 ]
We see our Nehalem machines reporting 'perfevents: irq loop stuck!' in
some cases when using perf:
perfevents: irq loop stuck!
WARNING: CPU: 0 PID: 3485 at arch/x86/events/intel/core.c:2282 intel_pmu_handle_irq+0x37b/0x530
...
RIP: 0010:intel_pmu_handle_irq+0x37b/0x530
...
Call Trace:
<NMI>
? perf_event_nmi_handler+0x2e/0x50
? intel_pmu_save_and_restart+0x50/0x50
perf_event_nmi_handler+0x2e/0x50
nmi_handle+0x6e/0x120
default_do_nmi+0x3e/0x100
do_nmi+0x102/0x160
end_repeat_nmi+0x16/0x50
...
? native_write_msr+0x6/0x20
? native_write_msr+0x6/0x20
</NMI>
intel_pmu_enable_event+0x1ce/0x1f0
x86_pmu_start+0x78/0xa0
x86_pmu_enable+0x252/0x310
__perf_event_task_sched_in+0x181/0x190
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x35/0x70
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x35/0x70
finish_task_switch+0x158/0x260
__schedule+0x2f6/0x840
? hrtimer_start_range_ns+0x153/0x210
schedule+0x32/0x80
schedule_hrtimeout_range_clock+0x8a/0x100
? hrtimer_init+0x120/0x120
ep_poll+0x2f7/0x3a0
? wake_up_q+0x60/0x60
do_epoll_wait+0xa9/0xc0
__x64_sys_epoll_wait+0x1a/0x20
do_syscall_64+0x4e/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fdeb1e96c03
...
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: acme@kernel.org
Cc: Josh Hunt <johunt@akamai.com>
Cc: bpuranda@akamai.com
Cc: mingo@redhat.com
Cc: jolsa@redhat.com
Cc: tglx@linutronix.de
Cc: namhyung@kernel.org
Cc: alexander.shishkin@linux.intel.com
Link: https://lkml.kernel.org/r/1566256411-18820-1-git-send-email-johunt@akamai.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 44d3bbb6f5e501b873218142fe08cdf62a4ac1f3 ]
We see our Nehalem machines reporting 'perfevents: irq loop stuck!' in
some cases when using perf:
perfevents: irq loop stuck!
WARNING: CPU: 0 PID: 3485 at arch/x86/events/intel/core.c:2282 intel_pmu_handle_irq+0x37b/0x530
...
RIP: 0010:intel_pmu_handle_irq+0x37b/0x530
...
Call Trace:
<NMI>
? perf_event_nmi_handler+0x2e/0x50
? intel_pmu_save_and_restart+0x50/0x50
perf_event_nmi_handler+0x2e/0x50
nmi_handle+0x6e/0x120
default_do_nmi+0x3e/0x100
do_nmi+0x102/0x160
end_repeat_nmi+0x16/0x50
...
? native_write_msr+0x6/0x20
? native_write_msr+0x6/0x20
</NMI>
intel_pmu_enable_event+0x1ce/0x1f0
x86_pmu_start+0x78/0xa0
x86_pmu_enable+0x252/0x310
__perf_event_task_sched_in+0x181/0x190
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x35/0x70
? __switch_to_asm+0x41/0x70
? __switch_to_asm+0x35/0x70
finish_task_switch+0x158/0x260
__schedule+0x2f6/0x840
? hrtimer_start_range_ns+0x153/0x210
schedule+0x32/0x80
schedule_hrtimeout_range_clock+0x8a/0x100
? hrtimer_init+0x120/0x120
ep_poll+0x2f7/0x3a0
? wake_up_q+0x60/0x60
do_epoll_wait+0xa9/0xc0
__x64_sys_epoll_wait+0x1a/0x20
do_syscall_64+0x4e/0x110
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fdeb1e96c03
...
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: acme@kernel.org
Cc: Josh Hunt <johunt@akamai.com>
Cc: bpuranda@akamai.com
Cc: mingo@redhat.com
Cc: jolsa@redhat.com
Cc: tglx@linutronix.de
Cc: namhyung@kernel.org
Cc: alexander.shishkin@linux.intel.com
Link: https://lkml.kernel.org/r/1566256411-18820-1-git-send-email-johunt@akamai.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
i2c: designware: Synchronize IRQs when unregistering slave client
[ Upstream commit c486dcd2f1bbdd524a1e0149734b79e4ae329650 ]
Make sure interrupt handler i2c_dw_irq_handler_slave() has finished
before clearing the the dev->slave pointer in i2c_dw_unreg_slave().
There is possibility for a race if i2c_dw_irq_handler_slave() is running
on another CPU while clearing the dev->slave pointer.
Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Reported-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c486dcd2f1bbdd524a1e0149734b79e4ae329650 ]
Make sure interrupt handler i2c_dw_irq_handler_slave() has finished
before clearing the the dev->slave pointer in i2c_dw_unreg_slave().
There is possibility for a race if i2c_dw_irq_handler_slave() is running
on another CPU while clearing the dev->slave pointer.
Reported-by: Krzysztof Adamski <krzysztof.adamski@nokia.com>
Reported-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
sky2: Disable MSI on yet another ASUS boards (P6Xxxx)
[ Upstream commit 189308d5823a089b56e2299cd96589507dac7319 ]
A similar workaround for the suspend/resume problem is needed for yet
another ASUS machines, P6X models. Like the previous fix, the BIOS
doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_*
entries are used instead.
Reported-and-tested-by: SteveM <swm@swm1.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 189308d5823a089b56e2299cd96589507dac7319 ]
A similar workaround for the suspend/resume problem is needed for yet
another ASUS machines, P6X models. Like the previous fix, the BIOS
doesn't provide the standard DMI_SYS_* entry, so again DMI_BOARD_*
entries are used instead.
Reported-and-tested-by: SteveM <swm@swm1.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ibmvnic: Do not process reset during or after device removal
[ Upstream commit 36f1031c51a2538e5558fb44c6d6b88f98d3c0f2 ]
Currently, the ibmvnic driver will not schedule device resets
if the device is being removed, but does not check the device
state before the reset is actually processed. This leads to a race
where a reset is scheduled with a valid device state but is
processed after the driver has been removed, resulting in an oops.
Fix this by checking the device state before processing a queued
reset event.
Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Tested-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 36f1031c51a2538e5558fb44c6d6b88f98d3c0f2 ]
Currently, the ibmvnic driver will not schedule device resets
if the device is being removed, but does not check the device
state before the reset is actually processed. This leads to a race
where a reset is scheduled with a valid device state but is
processed after the driver has been removed, resulting in an oops.
Fix this by checking the device state before processing a queued
reset event.
Reported-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Tested-by: Abdul Haleem <abdhalee@linux.vnet.ibm.com>
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: 8901/1: add a criteria for pfn_valid of arm
[ Upstream commit 5b3efa4f1479c91cb8361acef55f9c6662feba57 ]
pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
The issue originally arise from bellowing call stack, which corresponding to
an access of the /proc/kpageflags from userspace with a invalid pfn parameter
and leads to kernel panic.
[46886.723249] c7 [<c031ff98>] (stable_page_flags) from [<c03203f8>]
[46886.723264] c7 [<c0320368>] (kpageflags_read) from [<c0312030>]
[46886.723280] c7 [<c0311fb0>] (proc_reg_read) from [<c02a6e6c>]
[46886.723290] c7 [<c02a6e24>] (__vfs_read) from [<c02a7018>]
[46886.723301] c7 [<c02a6f74>] (vfs_read) from [<c02a778c>]
[46886.723315] c7 [<c02a770c>] (SyS_pread64) from [<c0108620>]
(ret_fast_syscall+0x0/0x28)
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5b3efa4f1479c91cb8361acef55f9c6662feba57 ]
pfn_valid can be wrong when parsing a invalid pfn whose phys address
exceeds BITS_PER_LONG as the MSB will be trimed when shifted.
The issue originally arise from bellowing call stack, which corresponding to
an access of the /proc/kpageflags from userspace with a invalid pfn parameter
and leads to kernel panic.
[46886.723249] c7 [<c031ff98>] (stable_page_flags) from [<c03203f8>]
[46886.723264] c7 [<c0320368>] (kpageflags_read) from [<c0312030>]
[46886.723280] c7 [<c0311fb0>] (proc_reg_read) from [<c02a6e6c>]
[46886.723290] c7 [<c02a6e24>] (__vfs_read) from [<c02a7018>]
[46886.723301] c7 [<c02a6f74>] (vfs_read) from [<c02a778c>]
[46886.723315] c7 [<c02a770c>] (SyS_pread64) from [<c0108620>]
(ret_fast_syscall+0x0/0x28)
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@unisoc.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
usb: host: xhci-tegra: Set DMA mask correctly
[ Upstream commit 993cc8753453fccfe060a535bbe21fcf1001b626 ]
The Falcon microcontroller that runs the XUSB firmware and which is
responsible for exposing the XHCI interface can address only 40 bits of
memory. Typically that's not a problem because Tegra devices don't have
enough system memory to exceed those 40 bits.
However, if the ARM SMMU is enable on Tegra186 and later, the addresses
passed to the XUSB controller can be anywhere in the 48-bit IOV address
space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from
the top of the IOVA space, the Falcon microcontroller is not able to
load the firmware successfully.
Fix this by setting the DMA mask to 40 bits, which will force the DMA
API to map the buffer for the firmware to an IOVA that is addressable by
the Falcon.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/1566989697-13049-1-git-send-email-nkristam@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 993cc8753453fccfe060a535bbe21fcf1001b626 ]
The Falcon microcontroller that runs the XUSB firmware and which is
responsible for exposing the XHCI interface can address only 40 bits of
memory. Typically that's not a problem because Tegra devices don't have
enough system memory to exceed those 40 bits.
However, if the ARM SMMU is enable on Tegra186 and later, the addresses
passed to the XUSB controller can be anywhere in the 48-bit IOV address
space of the ARM SMMU. Since the DMA/IOMMU API starts allocating from
the top of the IOVA space, the Falcon microcontroller is not able to
load the firmware successfully.
Fix this by setting the DMA mask to 40 bits, which will force the DMA
API to map the buffer for the firmware to an IOVA that is addressable by
the Falcon.
Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://lore.kernel.org/r/1566989697-13049-1-git-send-email-nkristam@nvidia.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cifs: Use kzfree() to zero out the password
[ Upstream commit 478228e57f81f6cb60798d54fc02a74ea7dd267e ]
It's safer to zero out the password so that it can never be disclosed.
Fixes: 0c219f5799c7 ("cifs: set domainName when a domain-key is used in multiuser")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 478228e57f81f6cb60798d54fc02a74ea7dd267e ]
It's safer to zero out the password so that it can never be disclosed.
Fixes: 0c219f5799c7 ("cifs: set domainName when a domain-key is used in multiuser")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cifs: set domainName when a domain-key is used in multiuser
[ Upstream commit f2aee329a68f5a907bcff11a109dfe17c0b41aeb ]
RHBZ: 1710429
When we use a domain-key to authenticate using multiuser we must also set
the domainnmame for the new volume as it will be used and passed to the server
in the NTLMSSP Domain-name.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f2aee329a68f5a907bcff11a109dfe17c0b41aeb ]
RHBZ: 1710429
When we use a domain-key to authenticate using multiuser we must also set
the domainnmame for the new volume as it will be used and passed to the server
in the NTLMSSP Domain-name.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
kallsyms: Don't let kallsyms_lookup_size_offset() fail on retrieving the first symbol
[ Upstream commit 2a1a3fa0f29270583f0e6e3100d609e09697add1 ]
An arm64 kernel configured with
CONFIG_KPROBES=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
reports the following kprobe failure:
[ 0.032677] kprobes: failed to populate blacklist: -22
[ 0.033376] Please take care of using kprobes.
It appears that kprobe fails to retrieve the symbol at address
0xffff000010081000, despite this symbol being in System.map:
ffff000010081000 T __exception_text_start
This symbol is part of the first group of aliases in the
kallsyms_offsets array (symbol names generated using ugly hacks in
scripts/kallsyms.c):
kallsyms_offsets:
.long 0x1000 // do_undefinstr
.long 0x1000 // efi_header_end
.long 0x1000 // _stext
.long 0x1000 // __exception_text_start
.long 0x12b0 // do_cp15instr
Looking at the implementation of get_symbol_pos(), it returns the
lowest index for aliasing symbols. In this case, it return 0.
But kallsyms_lookup_size_offset() considers 0 as a failure, which
is obviously wrong (there is definitely a valid symbol living there).
In turn, the kprobe blacklisting stops abruptly, hence the original
error.
A CONFIG_KALLSYMS_ALL kernel wouldn't fail as there is always
some random symbols at the beginning of this array, which are never
looked up via kallsyms_lookup_size_offset.
Fix it by considering that get_symbol_pos() is always successful
(which is consistent with the other uses of this function).
Fixes: ffc5089196446 ("[PATCH] Create kallsyms_lookup_size_offset()")
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2a1a3fa0f29270583f0e6e3100d609e09697add1 ]
An arm64 kernel configured with
CONFIG_KPROBES=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
CONFIG_KALLSYMS_BASE_RELATIVE=y
reports the following kprobe failure:
[ 0.032677] kprobes: failed to populate blacklist: -22
[ 0.033376] Please take care of using kprobes.
It appears that kprobe fails to retrieve the symbol at address
0xffff000010081000, despite this symbol being in System.map:
ffff000010081000 T __exception_text_start
This symbol is part of the first group of aliases in the
kallsyms_offsets array (symbol names generated using ugly hacks in
scripts/kallsyms.c):
kallsyms_offsets:
.long 0x1000 // do_undefinstr
.long 0x1000 // efi_header_end
.long 0x1000 // _stext
.long 0x1000 // __exception_text_start
.long 0x12b0 // do_cp15instr
Looking at the implementation of get_symbol_pos(), it returns the
lowest index for aliasing symbols. In this case, it return 0.
But kallsyms_lookup_size_offset() considers 0 as a failure, which
is obviously wrong (there is definitely a valid symbol living there).
In turn, the kprobe blacklisting stops abruptly, hence the original
error.
A CONFIG_KALLSYMS_ALL kernel wouldn't fail as there is always
some random symbols at the beginning of this array, which are never
looked up via kallsyms_lookup_size_offset.
Fix it by considering that get_symbol_pos() is always successful
(which is consistent with the other uses of this function).
Fixes: ffc5089196446 ("[PATCH] Create kallsyms_lookup_size_offset()")
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFSv2: Fix write regression
[ Upstream commit d33d4beb522987d1c305c12500796f9be3687dee ]
Ensure we update the write result count on success, since the
RPC call itself does not do so.
Reported-by: Jan Stancek <jstancek@redhat.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d33d4beb522987d1c305c12500796f9be3687dee ]
Ensure we update the write result count on success, since the
RPC call itself does not do so.
Reported-by: Jan Stancek <jstancek@redhat.com>
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFSv2: Fix eof handling
[ Upstream commit 71affe9be45a5c60b9772e1b2701710712637274 ]
If we received a reply from the server with a zero length read and
no error, then that implies we are at eof.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 71affe9be45a5c60b9772e1b2701710712637274 ]
If we received a reply from the server with a zero length read and
no error, then that implies we are at eof.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
netfilter: nf_conntrack_ftp: Fix debug output
[ Upstream commit 3a069024d371125227de3ac8fa74223fcf473520 ]
The find_pattern() debug output was printing the 'skip' character.
This can be a NULL-byte and messes up further pr_debug() output.
Output without the fix:
kernel: nf_conntrack_ftp: Pattern matches!
kernel: nf_conntrack_ftp: Skipped up to `<7>nf_conntrack_ftp: find_pattern `PORT': dlen = 8
kernel: nf_conntrack_ftp: find_pattern `EPRT': dlen = 8
Output with the fix:
kernel: nf_conntrack_ftp: Pattern matches!
kernel: nf_conntrack_ftp: Skipped up to 0x0 delimiter!
kernel: nf_conntrack_ftp: Match succeeded!
kernel: nf_conntrack_ftp: conntrack_ftp: match `172,17,0,100,200,207' (20 bytes at 4150681645)
kernel: nf_conntrack_ftp: find_pattern `PORT': dlen = 8
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3a069024d371125227de3ac8fa74223fcf473520 ]
The find_pattern() debug output was printing the 'skip' character.
This can be a NULL-byte and messes up further pr_debug() output.
Output without the fix:
kernel: nf_conntrack_ftp: Pattern matches!
kernel: nf_conntrack_ftp: Skipped up to `<7>nf_conntrack_ftp: find_pattern `PORT': dlen = 8
kernel: nf_conntrack_ftp: find_pattern `EPRT': dlen = 8
Output with the fix:
kernel: nf_conntrack_ftp: Pattern matches!
kernel: nf_conntrack_ftp: Skipped up to 0x0 delimiter!
kernel: nf_conntrack_ftp: Match succeeded!
kernel: nf_conntrack_ftp: conntrack_ftp: match `172,17,0,100,200,207' (20 bytes at 4150681645)
kernel: nf_conntrack_ftp: find_pattern `PORT': dlen = 8
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
netfilter: xt_physdev: Fix spurious error message in physdev_mt_check
[ Upstream commit 3cf2f450fff304be9cf4868bf0df17f253bc5b1c ]
Simplify the check in physdev_mt_check() to emit an error message
only when passed an invalid chain (ie, NF_INET_LOCAL_OUT).
This avoids cluttering up the log with errors against valid rules.
For large/heavily modified rulesets, current behavior can quickly
overwhelm the ring buffer, because this function gets called on
every change, regardless of the rule that was changed.
Signed-off-by: Todd Seidelmann <tseidelmann@linode.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3cf2f450fff304be9cf4868bf0df17f253bc5b1c ]
Simplify the check in physdev_mt_check() to emit an error message
only when passed an invalid chain (ie, NF_INET_LOCAL_OUT).
This avoids cluttering up the log with errors against valid rules.
For large/heavily modified rulesets, current behavior can quickly
overwhelm the ring buffer, because this function gets called on
every change, regardless of the rule that was changed.
Signed-off-by: Todd Seidelmann <tseidelmann@linode.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
x86/apic: Fix arch_dynirq_lower_bound() bug for DT enabled machines
[ Upstream commit 3e5bedc2c258341702ddffbd7688c5e6eb01eafa ]
Rahul Tanwar reported the following bug on DT systems:
> 'ioapic_dynirq_base' contains the virtual IRQ base number. Presently, it is
> updated to the end of hardware IRQ numbers but this is done only when IOAPIC
> configuration type is IOAPIC_DOMAIN_LEGACY or IOAPIC_DOMAIN_STRICT. There is
> a third type IOAPIC_DOMAIN_DYNAMIC which applies when IOAPIC configuration
> comes from devicetree.
>
> See dtb_add_ioapic() in arch/x86/kernel/devicetree.c
>
> In case of IOAPIC_DOMAIN_DYNAMIC (DT/OF based system), 'ioapic_dynirq_base'
> remains to zero initialized value. This means that for OF based systems,
> virtual IRQ base will get set to zero.
Such systems will very likely not even boot.
For DT enabled machines ioapic_dynirq_base is irrelevant and not
updated, so simply map the IRQ base 1:1 instead.
Reported-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Tested-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: alan@linux.intel.com
Cc: bp@alien8.de
Cc: cheol.yong.kim@intel.com
Cc: qi-ming.wu@intel.com
Cc: rahul.tanwar@intel.com
Cc: rppt@linux.ibm.com
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/20190821081330.1187-1-rahul.tanwar@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3e5bedc2c258341702ddffbd7688c5e6eb01eafa ]
Rahul Tanwar reported the following bug on DT systems:
> 'ioapic_dynirq_base' contains the virtual IRQ base number. Presently, it is
> updated to the end of hardware IRQ numbers but this is done only when IOAPIC
> configuration type is IOAPIC_DOMAIN_LEGACY or IOAPIC_DOMAIN_STRICT. There is
> a third type IOAPIC_DOMAIN_DYNAMIC which applies when IOAPIC configuration
> comes from devicetree.
>
> See dtb_add_ioapic() in arch/x86/kernel/devicetree.c
>
> In case of IOAPIC_DOMAIN_DYNAMIC (DT/OF based system), 'ioapic_dynirq_base'
> remains to zero initialized value. This means that for OF based systems,
> virtual IRQ base will get set to zero.
Such systems will very likely not even boot.
For DT enabled machines ioapic_dynirq_base is irrelevant and not
updated, so simply map the IRQ base 1:1 instead.
Reported-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Tested-by: Rahul Tanwar <rahul.tanwar@linux.intel.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: alan@linux.intel.com
Cc: bp@alien8.de
Cc: cheol.yong.kim@intel.com
Cc: qi-ming.wu@intel.com
Cc: rahul.tanwar@intel.com
Cc: rppt@linux.ibm.com
Cc: tony.luck@intel.com
Link: http://lkml.kernel.org/r/20190821081330.1187-1-rahul.tanwar@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
r8152: Set memory to all 0xFFs on failed reg reads
[ Upstream commit f53a7ad189594a112167efaf17ea8d0242b5ac00 ]
get_registers() blindly copies the memory written to by the
usb_control_msg() call even if the underlying urb failed.
This could lead to junk register values being read by the driver, since
some indirect callers of get_registers() ignore the return values. One
example is:
ocp_read_dword() ignores the return value of generic_ocp_read(), which
calls get_registers().
So, emulate PCI "Master Abort" behavior by setting the buffer to all
0xFFs when usb_control_msg() fails.
This patch is copied from the r8152 driver (v2.12.0) published by
Realtek (www.realtek.com).
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f53a7ad189594a112167efaf17ea8d0242b5ac00 ]
get_registers() blindly copies the memory written to by the
usb_control_msg() call even if the underlying urb failed.
This could lead to junk register values being read by the driver, since
some indirect callers of get_registers() ignore the return values. One
example is:
ocp_read_dword() ignores the return value of generic_ocp_read(), which
calls get_registers().
So, emulate PCI "Master Abort" behavior by setting the buffer to all
0xFFs when usb_control_msg() fails.
This patch is copied from the r8152 driver (v2.12.0) published by
Realtek (www.realtek.com).
Signed-off-by: Prashant Malani <pmalani@chromium.org>
Acked-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
bpf: allow narrow loads of some sk_reuseport_md fields with offset > 0
[ Upstream commit 2c238177bd7f4b14bdf7447cc1cd9bb791f147e6 ]
test_select_reuseport fails on s390 due to verifier rejecting
test_select_reuseport_kern.o with the following message:
; data_check.eth_protocol = reuse_md->eth_protocol;
18: (69) r1 = *(u16 *)(r6 +22)
invalid bpf_context access off=22 size=2
This is because on big-endian machines casts from __u32 to __u16 are
generated by referencing the respective variable as __u16 with an offset
of 2 (as opposed to 0 on little-endian machines).
The verifier already has all the infrastructure in place to allow such
accesses, it's just that they are not explicitly enabled for
eth_protocol field. Enable them for eth_protocol field by using
bpf_ctx_range instead of offsetof.
Ditto for ip_protocol, bind_inany and len, since they already allow
narrowing, and the same problem can arise when working with them.
Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2c238177bd7f4b14bdf7447cc1cd9bb791f147e6 ]
test_select_reuseport fails on s390 due to verifier rejecting
test_select_reuseport_kern.o with the following message:
; data_check.eth_protocol = reuse_md->eth_protocol;
18: (69) r1 = *(u16 *)(r6 +22)
invalid bpf_context access off=22 size=2
This is because on big-endian machines casts from __u32 to __u16 are
generated by referencing the respective variable as __u16 with an offset
of 2 (as opposed to 0 on little-endian machines).
The verifier already has all the infrastructure in place to allow such
accesses, it's just that they are not explicitly enabled for
eth_protocol field. Enable them for eth_protocol field by using
bpf_ctx_range instead of offsetof.
Ditto for ip_protocol, bind_inany and len, since they already allow
narrowing, and the same problem can arise when working with them.
Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
batman-adv: Only read OGM2 tvlv_len after buffer len check
[ Upstream commit 0ff0f15a32c093381ad1abc06abe85afb561ab28 ]
Multiple batadv_ogm2_packet can be stored in an skbuff. The functions
batadv_v_ogm_send_to_if() uses batadv_v_ogm_aggr_packet() to check if there
is another additional batadv_ogm2_packet in the skb or not before they
continue processing the packet.
The length for such an OGM2 is BATADV_OGM2_HLEN +
batadv_ogm2_packet->tvlv_len. The check must first check that at least
BATADV_OGM2_HLEN bytes are available before it accesses tvlv_len (which is
part of the header. Otherwise it might try read outside of the currently
available skbuff to get the content of tvlv_len.
Fixes: 9323158ef9f4 ("batman-adv: OGMv2 - implement originators logic")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0ff0f15a32c093381ad1abc06abe85afb561ab28 ]
Multiple batadv_ogm2_packet can be stored in an skbuff. The functions
batadv_v_ogm_send_to_if() uses batadv_v_ogm_aggr_packet() to check if there
is another additional batadv_ogm2_packet in the skb or not before they
continue processing the packet.
The length for such an OGM2 is BATADV_OGM2_HLEN +
batadv_ogm2_packet->tvlv_len. The check must first check that at least
BATADV_OGM2_HLEN bytes are available before it accesses tvlv_len (which is
part of the header. Otherwise it might try read outside of the currently
available skbuff to get the content of tvlv_len.
Fixes: 9323158ef9f4 ("batman-adv: OGMv2 - implement originators logic")
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ARM: 8874/1: mm: only adjust sections of valid mm structures
[ Upstream commit c51bc12d06b3a5494fbfcbd788a8e307932a06e9 ]
A timing hazard exists when an early fork/exec thread begins
exiting and sets its mm pointer to NULL while a separate core
tries to update the section information.
This commit ensures that the mm pointer is not NULL before
setting its section parameters. The arguments provided by
commit 11ce4b33aedc ("ARM: 8672/1: mm: remove tasklist locking
from update_sections_early()") are equally valid for not
requiring grabbing the task_lock around this check.
Fixes: 08925c2f124f ("ARM: 8464/1: Update all mm structures with section adjustments")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c51bc12d06b3a5494fbfcbd788a8e307932a06e9 ]
A timing hazard exists when an early fork/exec thread begins
exiting and sets its mm pointer to NULL while a separate core
tries to update the section information.
This commit ensures that the mm pointer is not NULL before
setting its section parameters. The arguments provided by
commit 11ce4b33aedc ("ARM: 8672/1: mm: remove tasklist locking
from update_sections_early()") are equally valid for not
requiring grabbing the task_lock around this check.
Fixes: 08925c2f124f ("ARM: 8464/1: Update all mm structures with section adjustments")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
qed: Add cleanup in qed_slowpath_start()
[ Upstream commit de0e4fd2f07ce3bbdb69dfb8d9426b7227451b69 ]
If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
memory leaks. To fix this issue, introduce the label 'err4' to perform the
cleanup work before returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de0e4fd2f07ce3bbdb69dfb8d9426b7227451b69 ]
If qed_mcp_send_drv_version() fails, no cleanup is executed, leading to
memory leaks. To fix this issue, introduce the label 'err4' to perform the
cleanup work before returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
Acked-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
xdp: unpin xdp umem pages in error path
[ Upstream commit fb89c39455e4b49881c5a42761bd71f03d3ef888 ]
Fix mem leak caused by missed unpin routine for umem pages.
Fixes: 8aef7340ae9695 ("xsk: introduce xdp_umem_page")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit fb89c39455e4b49881c5a42761bd71f03d3ef888 ]
Fix mem leak caused by missed unpin routine for umem pages.
Fixes: 8aef7340ae9695 ("xsk: introduce xdp_umem_page")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kconfig: Fix the reference to the IDT77105 Phy driver in the description of ATM_NICSTAR_USE_IDT77105
[ Upstream commit cd9d4ff9b78fcd0fc4708900ba3e52e71e1a7690 ]
This should be IDT77105, not IDT77015.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cd9d4ff9b78fcd0fc4708900ba3e52e71e1a7690 ]
This should be IDT77105, not IDT77015.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFS: Fix initialisation of I/O result struct in nfs_pgio_rpcsetup
[ Upstream commit 17d8c5d145000070c581f2a8aa01edc7998582ab ]
Initialise the result count to 0 rather than initialising it to the
argument count. The reason is that we want to ensure we record the
I/O stats correctly in the case where an error is returned (for
instance in the layoutstats).
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 17d8c5d145000070c581f2a8aa01edc7998582ab ]
Initialise the result count to 0 rather than initialising it to the
argument count. The reason is that we want to ensure we record the
I/O stats correctly in the case where an error is returned (for
instance in the layoutstats).
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFSv4: Fix return value in nfs_finish_open()
[ Upstream commit 9821421a291b548ef4369c6998745baa36ddecd5 ]
If the file turns out to be of the wrong type after opening, we want
to revalidate the path and retry, so return EOPENSTALE rather than
ESTALE.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9821421a291b548ef4369c6998745baa36ddecd5 ]
If the file turns out to be of the wrong type after opening, we want
to revalidate the path and retry, so return EOPENSTALE rather than
ESTALE.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
NFSv4: Fix return values for nfs4_file_open()
[ Upstream commit 90cf500e338ab3f3c0f126ba37e36fb6a9058441 ]
Currently, we are translating RPC level errors such as timeouts,
as well as interrupts etc into EOPENSTALE, which forces a single
replay of the open attempt. What we actually want to do is
force the replay only in the cases where the returned error
indicates that the file may have changed on the server.
So the fix is to spell out the exact set of errors where we want
to return EOPENSTALE.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 90cf500e338ab3f3c0f126ba37e36fb6a9058441 ]
Currently, we are translating RPC level errors such as timeouts,
as well as interrupts etc into EOPENSTALE, which forces a single
replay of the open attempt. What we actually want to do is
force the replay only in the cases where the returned error
indicates that the file may have changed on the server.
So the fix is to spell out the exact set of errors where we want
to return EOPENSTALE.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
netfilter: xt_nfacct: Fix alignment mismatch in xt_nfacct_match_info
[ Upstream commit 89a26cd4b501e9511d3cd3d22327fc76a75a38b3 ]
When running a 64-bit kernel with a 32-bit iptables binary, the size of
the xt_nfacct_match_info struct diverges.
kernel: sizeof(struct xt_nfacct_match_info) : 40
iptables: sizeof(struct xt_nfacct_match_info)) : 36
Trying to append nfacct related rules results in an unhelpful message.
Although it is suggested to look for more information in dmesg, nothing
can be found there.
# iptables -A <chain> -m nfacct --nfacct-name <acct-object>
iptables: Invalid argument. Run `dmesg' for more information.
This patch fixes the memory misalignment by enforcing 8-byte alignment
within the struct's first revision. This solution is often used in many
other uapi netfilter headers.
Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 89a26cd4b501e9511d3cd3d22327fc76a75a38b3 ]
When running a 64-bit kernel with a 32-bit iptables binary, the size of
the xt_nfacct_match_info struct diverges.
kernel: sizeof(struct xt_nfacct_match_info) : 40
iptables: sizeof(struct xt_nfacct_match_info)) : 36
Trying to append nfacct related rules results in an unhelpful message.
Although it is suggested to look for more information in dmesg, nothing
can be found there.
# iptables -A <chain> -m nfacct --nfacct-name <acct-object>
iptables: Invalid argument. Run `dmesg' for more information.
This patch fixes the memory misalignment by enforcing 8-byte alignment
within the struct's first revision. This solution is often used in many
other uapi netfilter headers.
Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
netfilter: nft_flow_offload: missing netlink attribute policy
[ Upstream commit 14c415862c0630e01712a4eeaf6159a2b1b6d2a4 ]
The netlink attribute policy for NFTA_FLOW_TABLE_NAME is missing.
Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 14c415862c0630e01712a4eeaf6159a2b1b6d2a4 ]
The netlink attribute policy for NFTA_FLOW_TABLE_NAME is missing.
Fixes: a3c90f7a2323 ("netfilter: nf_tables: flow offload expression")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
netfilter: ebtables: Fix argument order to ADD_COUNTER
[ Upstream commit f20faa06d83de440bec8e200870784c3458793c4 ]
The ordering of arguments to the x_tables ADD_COUNTER macro
appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
and arp_tables.c).
This causes data corruption in the ebtables userspace tools
because they get incorrect packet & byte counts from the kernel.
Fixes: d72133e628803 ("netfilter: ebtables: use ADD_COUNTER macro")
Signed-off-by: Todd Seidelmann <tseidelmann@linode.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f20faa06d83de440bec8e200870784c3458793c4 ]
The ordering of arguments to the x_tables ADD_COUNTER macro
appears to be wrong in ebtables (cf. ip_tables.c, ip6_tables.c,
and arp_tables.c).
This causes data corruption in the ebtables userspace tools
because they get incorrect packet & byte counts from the kernel.
Fixes: d72133e628803 ("netfilter: ebtables: use ADD_COUNTER macro")
Signed-off-by: Todd Seidelmann <tseidelmann@linode.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fpga: altera-ps-spi: Fix getting of optional confd gpio
[ Upstream commit dec43da46f63eb71f519d963ba6832838e4262a3 ]
Currently the driver does not handle EPROBE_DEFER for the confd gpio.
Use devm_gpiod_get_optional() instead of devm_gpiod_get() and return
error codes from altera_ps_probe().
Fixes: 5692fae0742d ("fpga manager: Add altera-ps-spi driver for Altera FPGAs")
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit dec43da46f63eb71f519d963ba6832838e4262a3 ]
Currently the driver does not handle EPROBE_DEFER for the confd gpio.
Use devm_gpiod_get_optional() instead of devm_gpiod_get() and return
error codes from altera_ps_probe().
Fixes: 5692fae0742d ("fpga manager: Add altera-ps-spi driver for Altera FPGAs")
Signed-off-by: Phil Reid <preid@electromag.com.au>
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
tools: bpftool: close prog FD before exit on showing a single program
[ Upstream commit d34b044038bfb0e19caa8b019910efc465f41d5f ]
When showing metadata about a single program by invoking
"bpftool prog show PROG", the file descriptor referring to the program
is not closed before returning from the function. Let's close it.
Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d34b044038bfb0e19caa8b019910efc465f41d5f ]
When showing metadata about a single program by invoking
"bpftool prog show PROG", the file descriptor referring to the program
is not closed before returning from the function. Let's close it.
Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Andrii Nakryiko <andriin@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
selftests/bpf: fix "bind{4, 6} deny specific IP & port" on s390
[ Upstream commit 27df5c7068bf23cab282dc64b1c9894429b3b8a0 ]
"bind4 allow specific IP & port" and "bind6 deny specific IP & port"
fail on s390 because of endianness issue: the 4 IP address bytes are
loaded as a word and compared with a constant, but the value of this
constant should be different on big- and little- endian machines, which
is not the case right now.
Use __bpf_constant_ntohl to generate proper value based on machine
endianness.
Fixes: 1d436885b23b ("selftests/bpf: Selftest for sys_bind post-hooks.")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 27df5c7068bf23cab282dc64b1c9894429b3b8a0 ]
"bind4 allow specific IP & port" and "bind6 deny specific IP & port"
fail on s390 because of endianness issue: the 4 IP address bytes are
loaded as a word and compared with a constant, but the value of this
constant should be different on big- and little- endian machines, which
is not the case right now.
Use __bpf_constant_ntohl to generate proper value based on machine
endianness.
Fixes: 1d436885b23b ("selftests/bpf: Selftest for sys_bind post-hooks.")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>