Revision tags: v6.6.30, v6.6.29 |
|
#
03170e65 |
| 18-Apr-2024 |
Guanrui Huang <guanrui.huang@linux.alibaba.com> |
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_in
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ]
Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29 |
|
#
03170e65 |
| 18-Apr-2024 |
Guanrui Huang <guanrui.huang@linux.alibaba.com> |
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_in
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ]
Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.30, v6.6.29 |
|
#
03170e65 |
| 18-Apr-2024 |
Guanrui Huang <guanrui.huang@linux.alibaba.com> |
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_in
irqchip/gic-v3-its: Prevent double free on error
commit c26591afd33adce296c022e3480dea4282b7ef91 upstream.
The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ]
Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang@linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.28, v6.6.27, v6.6.26, v6.6.25, v6.6.24, v6.6.23 |
|
#
4332f541 |
| 19-Feb-2024 |
Oliver Upton <oliver.upton@linux.dev> |
irqchip/gic-v3-its: Do not assume vPE tables are preallocated
commit ec4308ecfc887128a468f03fb66b767559c57c23 upstream.
The GIC/ITS code is designed to ensure to pick up any preallocated LPI tables
irqchip/gic-v3-its: Do not assume vPE tables are preallocated
commit ec4308ecfc887128a468f03fb66b767559c57c23 upstream.
The GIC/ITS code is designed to ensure to pick up any preallocated LPI tables on the redistributors, as enabling LPIs is a one-way switch. There is no such restriction for vLPIs, and for GICv4.1 it is expected to allocate a new vPE table at boot.
This works as intended when initializing an ITS, however when setting up a redistributor in cpu_init_lpis() the early return for preallocated RD tables skips straight past the GICv4 setup. This all comes to a head when trying to kexec() into a new kernel, as the new kernel silently fails to set up GICv4, leading to a complete loss of SGIs and LPIs for KVM VMs.
Slap a band-aid on the problem by ensuring its_cpu_init_lpis() always initializes GICv4 on the way out, even if the other RD tables were preallocated.
Fixes: 6479450f72c1 ("irqchip/gic-v4: Fix occasional VLPI drop") Reported-by: George Cherian <gcherian@marvell.com> Co-developed-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Oliver Upton <oliver.upton@linux.dev> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240219185809.286724-2-oliver.upton@linux.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
65ac3a4f |
| 13-Feb-2024 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update
commit af9acbfc2c4b72c378d0b9a2ee023ed01055d3e2 upstream.
When updating the affinity of a VPE, the VMOVP command is currently skipped if the two
irqchip/gic-v3-its: Fix GICv4.1 VPE affinity update
commit af9acbfc2c4b72c378d0b9a2ee023ed01055d3e2 upstream.
When updating the affinity of a VPE, the VMOVP command is currently skipped if the two CPUs are part of the same VPE affinity.
But this is wrong, as the doorbell corresponding to this VPE is still delivered on the 'old' CPU, which screws up the balancing. Furthermore, offlining that 'old' CPU results in doorbell interrupts generated for this VPE being discarded.
The harsh reality is that VMOVP cannot be elided when a set_affinity() request occurs. It needs to be obeyed, and if an optimisation is to be made, it is at the point where the affinity change request is made (such as in KVM).
Drop the VMOVP elision altogether, and only use the vpe_table_mask to try and stay within the same ITS affinity group if at all possible.
Fixes: dd3f050a216e (irqchip/gic-v4.1: Implement the v4.1 flavour of VMOVP) Reported-by: Kunkun Jiang <jiangkunkun@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240213101206.2137483-4-maz@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
91a80fff |
| 13-Feb-2024 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Restore quirk probing for ACPI-based systems
commit 8b02da04ad978827e5ccd675acf170198f747a7a upstream.
While refactoring the way the ITSs are probed, the handling of quirks appl
irqchip/gic-v3-its: Restore quirk probing for ACPI-based systems
commit 8b02da04ad978827e5ccd675acf170198f747a7a upstream.
While refactoring the way the ITSs are probed, the handling of quirks applicable to ACPI-based platforms was lost. As a result, systems such as HIP07 lose their GICv4 functionnality, and some other may even fail to boot, unless they are configured to boot with DT.
Move the enabling of quirks into its_probe_one(), making it common to all firmware implementations.
Fixes: 9585a495ac93 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node") Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240213101206.2137483-3-maz@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
f7e84c8e |
| 13-Feb-2024 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Handle non-coherent GICv4 redistributors
[ Upstream commit 846297e11e8ae428f8b00156a0cfe2db58100702 ]
Although the GICv3 code base has gained some handling of systems failing to
irqchip/gic-v3-its: Handle non-coherent GICv4 redistributors
[ Upstream commit 846297e11e8ae428f8b00156a0cfe2db58100702 ]
Although the GICv3 code base has gained some handling of systems failing to handle the shareability attributes, the GICv4 side of things has been firmly ignored.
This is unfortunate, as the new recent addition of the "dma-noncoherent" is supposed to apply to all of the GICR tables, and not just the ones that are common to v3 and v4.
Add some checks to handle the VPROPBASE/VPENDBASE shareability and cacheability attributes in the same way we deal with the other GICR_BASE registers, wrapping the flag check in a helper for improved readability.
Note that this has been found by inspection only, as I don't have access to HW that suffers from this particular issue.
Fixes: 3a0fff0fb6a3 ("irqchip/gic-v3: Enable non-coherent redistributors/ITSes DT probing") Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Link: https://lore.kernel.org/r/20240213101206.2137483-2-maz@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10 |
|
#
3fca09b6 |
| 30-Oct-2023 |
Fang Xiang <fangxiang3@xiaomi.com> |
irqchip/gic-v3-its: Flush ITS tables correctly in non-coherent GIC designs
[ Upstream commit d3badb15613c14dd35d3495b1dde5c90fcd616dd ]
In non-coherent GIC designs, the ITS tables must be flushed b
irqchip/gic-v3-its: Flush ITS tables correctly in non-coherent GIC designs
[ Upstream commit d3badb15613c14dd35d3495b1dde5c90fcd616dd ]
In non-coherent GIC designs, the ITS tables must be flushed before writing to the GITS_BASER<n> registers, otherwise the ITS could read dirty tables, which results in unpredictable behavior.
Flush the tables right at the begin of its_setup_baser() to prevent that.
[ tglx: Massage changelog ]
Fixes: a8707f553884 ("irqchip/gic-v3: Add Rockchip 3588001 erratum workaround") Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Fang Xiang <fangxiang3@xiaomi.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20231030083256.4345-1-fangxiang3@xiaomi.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6, v6.5.9 |
|
#
f199bf5b |
| 24-Oct-2023 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Don't override quirk settings with default values
When splitting the allocation of the ITS node from its configuration, some of the default settings were kept in the latter inste
irqchip/gic-v3-its: Don't override quirk settings with default values
When splitting the allocation of the ITS node from its configuration, some of the default settings were kept in the latter instead of being moved to the former.
This has the side effect of negating some of the quirk detections that have happened in between, amongst which the dreaded Synquacer hack (that also affect Dominic's TI platform).
Move the initialisation of these fields early, so that they can again be overriden by the Synquacer quirk.
Fixes: 9585a495ac93 ("irqchip/gic-v3-its: Split allocation from initialisation of its_node") Reported by: Dominic Rath <dominic.rath@ibv-augsburg.net> Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Dominic Rath <dominic.rath@ibv-augsburg.net> Link: https://lore.kernel.org/r/20231024084831.GA3788@JADEVM-DRA Link: https://lore.kernel.org/r/20231024143431.2144579-1-maz@kernel.org
show more ...
|
Revision tags: v6.5.8, v6.5.7 |
|
#
3a0fff0f |
| 06-Oct-2023 |
Lorenzo Pieralisi <lpieralisi@kernel.org> |
irqchip/gic-v3: Enable non-coherent redistributors/ITSes DT probing
The GIC architecture specification defines a set of registers for redistributors and ITSes that control the sharebility and cachea
irqchip/gic-v3: Enable non-coherent redistributors/ITSes DT probing
The GIC architecture specification defines a set of registers for redistributors and ITSes that control the sharebility and cacheability attributes of redistributors/ITSes initiator ports on the interconnect (GICR_[V]PROPBASER, GICR_[V]PENDBASER, GITS_BASER<n>).
Architecturally the GIC provides a means to drive shareability and cacheability attributes signals and related IWB/OWB/ISH barriers but it is not mandatory for designs to wire up the corresponding interconnect signals that control the cacheability/shareability of transactions.
Redistributors and ITSes interconnect ports can be connected to non-coherent interconnects that are not able to manage the shareability/cacheability attributes; this implicitly makes the redistributors and ITSes non-coherent observers.
So far, the GIC driver on probe executes a write to "probe" for the redistributors and ITSes registers shareability bitfields by writing a value (ie InnerShareable - the shareability domain the CPUs are in) and check it back to detect whether the value sticks or not; this hinges on a GIC programming model behaviour that predates the current specifications, that just define shareability bits as writeable but do not guarantee that writing certain shareability values enable the expected behaviour for the redistributors/ITSes memory interconnect ports.
To enable non-coherent GIC designs, introduce the "dma-noncoherent" device tree property to allow firmware to describe redistributors and ITSes as non-coherent observers on the memory interconnect and use the property to force the shareability attributes to be programmed into the redistributors and ITSes registers through the GIC quirks mechanism.
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20231006125929.48591-3-lpieralisi@kernel.org
show more ...
|
#
9585a495 |
| 06-Oct-2023 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Split allocation from initialisation of its_node
In order to pave the way for more fancy quirk handling without making more of a mess of this terrible driver, split the allocatio
irqchip/gic-v3-its: Split allocation from initialisation of its_node
In order to pave the way for more fancy quirk handling without making more of a mess of this terrible driver, split the allocation of the ITS descriptor (its_node) from the actual probing.
This will allow firmware-specific hooks to be added between these two points.
Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20231006125929.48591-4-lpieralisi@kernel.org
show more ...
|
Revision tags: v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38 |
|
#
567f67ac |
| 03-Jul-2023 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
irqchip/gic-v3: Enable Rockchip 3588001 erratum workaround for RK3588S
Commit a8707f553884 ("irqchip/gic-v3: Add Rockchip 3588001 erratum workaround") mentioned RK3588S (the slimmed down variant of
irqchip/gic-v3: Enable Rockchip 3588001 erratum workaround for RK3588S
Commit a8707f553884 ("irqchip/gic-v3: Add Rockchip 3588001 erratum workaround") mentioned RK3588S (the slimmed down variant of RK3588) being affected, but did not check for its compatible value. Thus the quirk is not applied on RK3588S. Since the GIC ITS node got added to the upstream DT, boards using RK3588S are no longer booting without this quirk being applied.
Fixes: 06cdac8e8407 ("arm64: dts: rockchip: add GIC ITS support to rk3588") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230703164129.193991-1-sebastian.reichel@collabora.com
show more ...
|
Revision tags: v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
926846a7 |
| 17-Jun-2023 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation
We normally rely on the irq_to_cpuid_[un]lock() primitives to make sure nothing will change col->idx while performing a LPI i
irqchip/gic-v4.1: Properly lock VPEs when doing a directLPI invalidation
We normally rely on the irq_to_cpuid_[un]lock() primitives to make sure nothing will change col->idx while performing a LPI invalidation.
However, these primitives do not cover VPE doorbells, and we have some open-coded locking for that. Unfortunately, this locking is pretty bogus.
Instead, extend the above primitives to cover VPE doorbells and convert the whole thing to it.
Fixes: f3a059219bc7 ("irqchip/gic-v4.1: Ensure mutual exclusion between vPE affinity change and RD access") Reported-by: Kunkun Jiang <jiangkunkun@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Zenghui Yu <yuzenghui@huawei.com> Cc: wanghaibin.wang@huawei.com Tested-by: Kunkun Jiang <jiangkunkun@huawei.com> Reviewed-by: Zenghui Yu <yuzenghui@huawei.com> Link: https://lore.kernel.org/r/20230617073242.3199746-1-maz@kernel.org
show more ...
|
Revision tags: v6.1.34, v6.1.33 |
|
#
8f4b5895 |
| 08-Jun-2023 |
James Gowans <jgowans@amazon.com> |
irqchip/gic-v3-its: Enable RESEND_WHEN_IN_PROGRESS for LPIs
GICv3 LPIs are impacted by an architectural design issue: they do not have a global active state and as such a given LPI can be delivered
irqchip/gic-v3-its: Enable RESEND_WHEN_IN_PROGRESS for LPIs
GICv3 LPIs are impacted by an architectural design issue: they do not have a global active state and as such a given LPI can be delivered to a new CPU after an affinity change while the previous instance of the same LPI handler has not yet completed on the original CPU.
If LPIs had an active state, this second LPI would not be delivered until the first CPU deactivated the initial LPI, just like SPIs.
To solve this issue, use the newly introduced IRQD_RESEND_WHEN_IN_PROGRESS flag, ensuring that we do not lose an LPI being delivered during that window by getting the GIC to resend it.
This workaround gets enabled for all LPIs, including the VPE doorbells.
Suggested-by: Marc Zyngier <maz@kernel.org> Signed-off-by: James Gowans <jgowans@amazon.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Marc Zyngier <maz@kernel.org> Cc: KarimAllah Raslan <karahmed@amazon.com> Cc: Yipeng Zou <zouyipeng@huawei.com> Cc: Zhang Jianhua <chris.zjh@huawei.com> [maz: massaged commit message] Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230608120021.3273400-4-jgowans@amazon.com
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25 |
|
#
a8707f55 |
| 18-Apr-2023 |
Sebastian Reichel <sebastian.reichel@collabora.com> |
irqchip/gic-v3: Add Rockchip 3588001 erratum workaround
Rockchip RK3588/RK3588s GIC600 integration does not support the sharability feature. Rockchip assigned Erratum ID #3588001 for this issue.
No
irqchip/gic-v3: Add Rockchip 3588001 erratum workaround
Rockchip RK3588/RK3588s GIC600 integration does not support the sharability feature. Rockchip assigned Erratum ID #3588001 for this issue.
Note, that the 0x0201743b ID is not Rockchip specific and thus there is an extra of_machine_is_compatible() check.
The flags are named FORCE_NON_SHAREABLE to be vendor agnostic, since apparently similar integration design errors exist in other platforms and they can reuse the same flag.
Co-developed-by: XiaoDong Huang <derrick.huang@rock-chips.com> Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com> Co-developed-by: Kever Yang <kever.yang@rock-chips.com> Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Co-developed-by: Lucas Tanure <lucas.tanure@collabora.com> Signed-off-by: Lucas Tanure <lucas.tanure@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230418142109.49762-2-sebastian.reichel@collabora.com
show more ...
|
Revision tags: v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20 |
|
#
23baf831 |
| 15-Mar-2023 |
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> |
mm, treewide: redefine MAX_ORDER sanely
MAX_ORDER currently defined as number of orders page allocator supports: user can ask buddy allocator for page order between 0 and MAX_ORDER-1.
This definiti
mm, treewide: redefine MAX_ORDER sanely
MAX_ORDER currently defined as number of orders page allocator supports: user can ask buddy allocator for page order between 0 and MAX_ORDER-1.
This definition is counter-intuitive and lead to number of bugs all over the kernel.
Change the definition of MAX_ORDER to be inclusive: the range of orders user can ask from buddy allocator is 0..MAX_ORDER now.
[kirill@shutemov.name: fix min() warning] Link: https://lkml.kernel.org/r/20230315153800.32wib3n5rickolvh@box [akpm@linux-foundation.org: fix another min_t warning] [kirill@shutemov.name: fixups per Zi Yan] Link: https://lkml.kernel.org/r/20230316232144.b7ic4cif4kjiabws@box.shutemov.name [akpm@linux-foundation.org: fix underlining in docs] Link: https://lore.kernel.org/oe-kbuild-all/202303191025.VRCTk6mP-lkp@intel.com/ Link: https://lkml.kernel.org/r/20230315113133.11326-11-kirill.shutemov@linux.intel.com Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Michael Ellerman <mpe@ellerman.id.au> [powerpc] Cc: "Kirill A. Shutemov" <kirill@shutemov.name> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
show more ...
|
Revision tags: v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12 |
|
#
1e46e040 |
| 13-Feb-2023 |
Johan Hovold <johan+linaro@kernel.org> |
irqchip/gic-v3-its: Use irq_domain_create_hierarchy()
Use the irq_domain_create_hierarchy() helper to create the hierarchical domain, which both serves as documentation and avoids poking at irqdomai
irqchip/gic-v3-its: Use irq_domain_create_hierarchy()
Use the irq_domain_create_hierarchy() helper to create the hierarchical domain, which both serves as documentation and avoids poking at irqdomain internals.
Note that the domain host_data was first set to the struct its_node during allocation only to immediately be overwritten with the struct msi_domain_info.
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org> Tested-by: Mark-PK Tsai <mark-pk.tsai@mediatek.com> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230213104302.17307-17-johan+linaro@kernel.org
show more ...
|
Revision tags: v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11 |
|
#
dcb83f6e |
| 28-Nov-2022 |
Jason Gunthorpe <jgg@nvidia.com> |
genirq/msi: Rename IRQ_DOMAIN_MSI_REMAP to IRQ_DOMAIN_ISOLATED_MSI
What x86 calls "interrupt remapping" is one way to achieve isolated MSI, make it clear this is talking about isolated MSI, no matte
genirq/msi: Rename IRQ_DOMAIN_MSI_REMAP to IRQ_DOMAIN_ISOLATED_MSI
What x86 calls "interrupt remapping" is one way to achieve isolated MSI, make it clear this is talking about isolated MSI, no matter how it is achieved. This matches the new driver facing API name of msi_device_has_isolated_msi()
No functional change.
Link: https://lore.kernel.org/r/6-v3-3313bb5dd3a3+10f11-secure_msi_jgg@nvidia.com Tested-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
show more ...
|
Revision tags: v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
f55a9b59 |
| 12-Sep-2022 |
Pierre Gondois <pierre.gondois@arm.com> |
irqchip/gic-v3-its: Remove cpumask_var_t allocation
Running a PREEMPT_RT kernel based on v5.19-rc3-rt4 on an Ampere Altra triggers:
[ 22.616229] BUG: sleeping function called from invalid context
irqchip/gic-v3-its: Remove cpumask_var_t allocation
Running a PREEMPT_RT kernel based on v5.19-rc3-rt4 on an Ampere Altra triggers:
[ 22.616229] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 [ 22.616239] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1884, name: kworker/80:1 [ 22.616243] preempt_count: 3, expected: 0 [ 22.616244] RCU nest depth: 0, expected: 0 [...] [ 22.616250] hardirqs last enabled at (33): _raw_spin_unlock_irq (/home/piegon01/linux/./arch/arm64/include/asm/irqflags.h:35) [ 22.616273] hardirqs last disabled at (34): __schedule (/home/piegon01/linux/kernel/sched/core.c:6432 (discriminator 1)) [ 22.616283] softirqs last enabled at (0): copy_process (/home/piegon01/linux/./include/linux/lockdep.h:191) [ 22.616297] softirqs last disabled at (0): 0x0 [ 22.616305] Preemption disabled at: [ 22.616307] __setup_irq (/home/piegon01/linux/kernel/irq/manage.c:1612) [ 22.616322] CPU: 80 PID: 1884 Comm: kworker/80:1 Tainted: G W [...] [ 22.616328] Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18 [ 22.616333] Workqueue: events work_for_cpu_fn [ 22.616344] Call trace: [...] [ 22.616403] alloc_cpumask_var_node (/home/piegon01/linux/lib/cpumask.c:115) [ 22.616414] alloc_cpumask_var (/home/piegon01/linux/lib/cpumask.c:147) [ 22.616417] its_select_cpu (/home/piegon01/linux/drivers/irqchip/irq-gic-v3-its.c:1580) [ 22.616428] its_set_affinity (/home/piegon01/linux/drivers/irqchip/irq-gic-v3-its.c:1659) [ 22.616431] msi_domain_set_affinity (/home/piegon01/linux/kernel/irq/msi.c:501) [ 22.616440] irq_do_set_affinity (/home/piegon01/linux/kernel/irq/manage.c:276) [ 22.616443] irq_setup_affinity (/home/piegon01/linux/kernel/irq/manage.c:633) [ 22.616447] irq_startup (/home/piegon01/linux/kernel/irq/chip.c:280) [ 22.616453] __setup_irq (/home/piegon01/linux/kernel/irq/manage.c:1777)
Follow the pattern established in commit cba4235e6031e ("genirq: Remove mask argument from setup_affinity()") and co to overcome this issue by defining a static struct cpumask and protecting it by a raw spinlock.
Since its_select_cpu() can be executed with IRQs enabled or disabled, enforce that the cpumask computation is done with interrupts disabled.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220912141857.1391343-1-pierre.gondois@arm.com
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61 |
|
#
fa49364c |
| 16-Aug-2022 |
Robin Murphy <robin.murphy@arm.com> |
iommu/dma: Move public interfaces to linux/iommu.h
The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with only a couple more public interfaces left pertaining to MSI integration. Sinc
iommu/dma: Move public interfaces to linux/iommu.h
The iommu-dma layer is now mostly encapsulated by iommu_dma_ops, with only a couple more public interfaces left pertaining to MSI integration. Since these depend on the main IOMMU API header anyway, move their declarations there, taking the opportunity to update the half-baked comments to proper kerneldoc along the way.
Signed-off-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/9cd99738f52094e6bed44bfee03fa4f288d20695.1660668998.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de>
show more ...
|
Revision tags: v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
3f893a59 |
| 05-Apr-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3: Always trust the managed affinity provided by the core code
Now that the core code has been fixed to always give us an affinity that only includes online CPUs, directly use this affi
irqchip/gic-v3: Always trust the managed affinity provided by the core code
Now that the core code has been fixed to always give us an affinity that only includes online CPUs, directly use this affinity when computing a target CPU.
Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220405185040.206297-4-maz@kernel.org
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
af27e416 |
| 17-Mar-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling
The way KVM drives GICv4.{0,1} is as follows: - vcpu_load() makes the VPE resident, instructing the RD to start scanning
irqchip/gic-v4: Wait for GICR_VPENDBASER.Dirty to clear before descheduling
The way KVM drives GICv4.{0,1} is as follows: - vcpu_load() makes the VPE resident, instructing the RD to start scanning for interrupts - just before entering the guest, we check that the RD has finished scanning and that we can start running the vcpu - on preemption, we deschedule the VPE by making it invalid on the RD
However, we are preemptible between the first two steps. If it so happens *and* that the RD was still scanning, we nonetheless write to the GICR_VPENDBASER register while Dirty is set, and bad things happen (we're in UNPRED land).
This affects both the 4.0 and 4.1 implementations.
Make sure Dirty is cleared before performing the deschedule, meaning that its_clear_vpend_valid() becomes a sort of full VPE residency barrier.
Reported-by: Jingyi Wang <wangjingyi11@huawei.com> Tested-by: Nianyao Tang <tangnianyao@huawei.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Fixes: 57e3cebd022f ("KVM: arm64: Delay the polling of the GICR_VPENDBASER.Dirty bit") Link: https://lore.kernel.org/r/4aae10ba-b39a-5f84-754b-69c2eb0a2c03@huawei.com
show more ...
|
Revision tags: v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20 |
|
#
eba1e44b |
| 02-Feb-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Skip HP notifier when no ITS is registered
We have some systems out there that have both LPI support and an ITS, but that don't expose the ITS in their firmware tables (either be
irqchip/gic-v3-its: Skip HP notifier when no ITS is registered
We have some systems out there that have both LPI support and an ITS, but that don't expose the ITS in their firmware tables (either because it is broken or because they run under a hypervisor that hides it...).
Is such a configuration, we still register the HP notifier to free the allocated tables if needed, resulting in a warning as there is no memory to free (nothing was allocated the first place).
Fix it by keying the HP notifier on the presence of at least one sucessfully probed ITS.
Fixes: d23bc2bc1d63 ("irqchip/gic-v3-its: Postpone LPI pending table freeing and memreserve") Reported-by: Steev Klimaszewski <steev@kali.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: Valentin Schneider <valentin.schneider@arm.com> Link: https://lore.kernel.org/r/20220202103454.2480465-1-maz@kernel.org
show more ...
|
Revision tags: v5.15.19, v5.15.18, v5.15.17 |
|
#
c733ebb7 |
| 24-Jan-2022 |
Marc Zyngier <maz@kernel.org> |
irqchip/gic-v3-its: Reset each ITS's BASERn register before probe
A recent bug report outlined that the way GICv4.1 is handled across kexec is pretty bad. We can end-up in a situation where ITSs sha
irqchip/gic-v3-its: Reset each ITS's BASERn register before probe
A recent bug report outlined that the way GICv4.1 is handled across kexec is pretty bad. We can end-up in a situation where ITSs share memory (this is the case when SVPET==1) and reprogram the base registers, creating a situation where ITSs that are part of a given affinity group see different pointers. Which is illegal. Boo.
In order to restore some sanity, reset the BASERn registers to 0 *before* probing any ITS. Although this isn't optimised at all, this is only a once-per-boot cost, which shouldn't show up on anyone's radar.
Cc: Jay Chen <jkchen@linux.alibaba.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Link: https://lore.kernel.org/r/20211216190315.GA14220@lpieralisi Link: https://lore.kernel.org/r/20220124133809.1291195-1-maz@kernel.org
show more ...
|
#
16436f70 |
| 22-Jan-2022 |
Ard Biesheuvel <ardb@kernel.org> |
irqchip/gic-v3-its: Fix build for !SMP
Commit 835f442fdbce ("irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime") added a reference to cpus_booted_once_mask, which does not exist on !SMP buil
irqchip/gic-v3-its: Fix build for !SMP
Commit 835f442fdbce ("irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime") added a reference to cpus_booted_once_mask, which does not exist on !SMP builds, breaking the build for such configurations.
Given the intent of the check, short circuit it to always pass.
Cc: Valentin Schneider <valentin.schneider@arm.com> Fixes: 835f442fdbce ("irqchip/gic-v3-its: Limit memreserve cpuhp state lifetime") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20220122151614.133766-1-ardb@kernel.org
show more ...
|