Messages in this thread | | | Date | Mon, 19 Mar 2018 13:15:27 +0100 | From | Sebastian Andrzej Siewior <> | Subject | Re: [PATCH 00/10 v2] iommu/amd: lock splitting & GFP_KERNEL allocation |
| |
On 2018-03-17 16:43:39 [-0500], Scott Wood wrote: > If that's worth the lock dropping then fine (though why does only one > of the two allocations use GFP_KERNEL?), but it doesn't need to be a That was a mistake, I planned to keep both as GFP_KERNEL.
> raw lock if the non-allocating users are separated. Keeping them > separate will also preserve the WARNs if we somehow end up in an atomic > context with no table (versus relying on atomic sleep debugging that > may or may not be enabled), and make the code easier to understand by > being explicit about which functions can be used from RT-atomic > context.
That separated part is okay. We could keep it. However, I am not sure if looking at the table irq_lookup_table[devid] without the lock is okay. The pointer is assigned without DTE entry/iommu-flush to be completed. This does not look "okay".
> -Scott > Sebastian
| |