aboutsummaryrefslogtreecommitdiffstats
path: root/fs/proc/array.c
diff options
context:
space:
mode:
authorSebastian Andrzej Siewior <[email protected]>2018-03-22 15:22:40 +0000
committerJoerg Roedel <[email protected]>2018-03-29 08:38:16 +0000
commit993ca6e063a69a0c65ca42ed449b6bc1b3844151 (patch)
tree9a503357e65658e3128f643031fa33d3ae360796 /fs/proc/array.c
parentiommu/amd: Factor out setting the remap table for a devid (diff)
downloadkernel-993ca6e063a69a0c65ca42ed449b6bc1b3844151.tar.gz
kernel-993ca6e063a69a0c65ca42ed449b6bc1b3844151.zip
iommu/amd: Drop the lock while allocating new irq remap table
The irq_remap_table is allocated while the iommu_table_lock is held with interrupts disabled. >From looking at the call sites, all callers are in the early device initialisation (apic_bsp_setup(), pci_enable_device(), pci_enable_msi()) so make sense to drop the lock which also enables interrupts and try to allocate that memory with GFP_KERNEL instead GFP_ATOMIC. Since during the allocation the iommu_table_lock is dropped, we need to recheck if table exists after the lock has been reacquired. I *think* that it is impossible that the "devid" entry appears in irq_lookup_table while the lock is dropped since the same device can only be probed once. However I check for both cases, just to be sure. Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
Diffstat (limited to 'fs/proc/array.c')
0 files changed, 0 insertions, 0 deletions