diff options
| author | Sebastian Andrzej Siewior <[email protected]> | 2018-03-22 15:22:40 +0000 |
|---|---|---|
| committer | Joerg Roedel <[email protected]> | 2018-03-29 08:38:16 +0000 |
| commit | 993ca6e063a69a0c65ca42ed449b6bc1b3844151 (patch) | |
| tree | 9a503357e65658e3128f643031fa33d3ae360796 /fs/proc/array.c | |
| parent | iommu/amd: Factor out setting the remap table for a devid (diff) | |
| download | kernel-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
