[PATCH 0/3] handle init errors more gracefully in amd_iommu

This series makes error handling more robust in the amd_iommu init code. It was initially motivated by problematic firmware that does not set up the physical address of the iommu. This led to a NULL dereference panic when iommu_disable was called during cleanup. While the first patch is

[PATCH 1/3] iommu/amd: make iommu_disable safer

Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in

[PATCH 1/3] iommu/amd: make iommu_disable safer

Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in

[PATCH 2/3] iommu/amd: move gart fallback to amd_iommu_init

The fallback to the GART driver in the case amd_iommu doesn't work was executed in a function called free_iommu_resources, which didn't really make sense. This was even being called twice if amd_iommu=off was specified on the command line. The only complication is that it needs to be verified

[PATCH 3/3] iommu/amd: only free resources once on init error

When amd_iommu=off was specified on the command line, free_X_resources functions were called immediately after early_amd_iommu_init. They were then called again when amd_iommu_init also failed (as expected). Instead, call them only once: at the end of state_next() whenever there's an error. These

[PATCH 0/3] handle init errors more gracefully in amd_iommu

This series makes error handling more robust in the amd_iommu init code. It was initially motivated by problematic firmware that does not set up the physical address of the iommu. This led to a NULL dereference panic when iommu_disable was called during cleanup. While the first patch is

Re: [PATCH 0/3] handle init errors more gracefully in amd_iommu

Sorry to nag, but did anyone have any comments about these patches? Is no news good news? Thanks, Kevin On Thu, Apr 18, 2019 at 11:14 AM Kevin Mitchell wrote: > This series makes error handling more robust in the amd_iommu init > code. It was initially motivated by problematic firmware that

[PATCH 1/3] iommu/amd: make iommu_disable safer

Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in

[PATCH 2/3] iommu/amd: move gart fallback to amd_iommu_init

The fallback to the GART driver in the case amd_iommu doesn't work was executed in a function called free_iommu_resources, which didn't really make sense. This was even being called twice if amd_iommu=off was specified on the command line. The only complication is that it needs to be verified

[PATCH 3/3] iommu/amd: only free resources once on init error

When amd_iommu=off was specified on the command line, free_X_resources functions were called immediately after early_amd_iommu_init. They were then called again when amd_iommu_init also failed (as expected). Instead, call them only once: at the end of state_next() whenever there's an error. These

[PATCH 0/3] handle init errors more gracefully in amd_iommu

This series makes error handling more robust in the amd_iommu init code. It was initially motivated by problematic firmware that does not set up the physical address of the iommu. This led to a NULL dereference panic when iommu_disable was called during cleanup. While the first patch is