On Mon, Aug 21, 2023 at 12:06:40PM +0100, Robin Murphy wrote:
> The solution is to drop those locking patches entirely and rethink the whole
> thing.
Agreed, that was exactly what I thought when looking at this patch.
I dropped the original 10 patches and the 4 fixes on-top from the IOMMU
tree.
On Mon, Aug 21, 2023 at 09:51:13AM -0300, Jason Gunthorpe wrote:
> So now that Joerg has dropped it - what is your big idea to make the
> locking actually work right?
I am not opposed to the general idea. When putting it into the tree I
wasn't aware how many users still need to be adapted to
On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> I think it is just better to follow kernel convention and have
> allocation functions include the GFP because it is a clear signal to
> the user that there is an allocation hidden inside the API. The whole
> point of gfp is not to
On Fri, Jan 20, 2023 at 01:53:40PM -0400, Jason Gunthorpe wrote:
> > Well, having GFP parameters is not a strict kernel convention. There are
> > places doing it differently and have sleeping and atomic variants of
> > APIs. I have to say I like the latter more. But given that this leads to
> > an
On Mon, Jan 23, 2023 at 04:35:53PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (10):
> iommu: Add a gfp parameter to iommu_map()
> iommu: Remove iommu_map_atomic()
> iommu: Add a gfp parameter to iommu_map_sg()
> iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
>
