aboutsummaryrefslogtreecommitdiff
path: root/lib/dec_and_lock.c
diff options
context:
space:
mode:
authorLinus Torvalds2019-01-12 10:52:40 -0800
committerLinus Torvalds2019-01-12 10:52:40 -0800
commit66c56cfa64d9dbb9efa8a06c1aece77e8d57ea19 (patch)
treec645a58e97925f7f97dcc5bed2082ead5f2b5d89 /lib/dec_and_lock.c
parent473348891c36ff6de3e224fefa0b3fc86a629178 (diff)
parentdfd32cad146e3624970eee9329e99d2c6ef751b3 (diff)
Merge tag 'remove-dma_zalloc_coherent-5.0' of git://git.infradead.org/users/hch/dma-mapping
Pull dma_zalloc_coherent() removal from Christoph Hellwig: "We've always had a weird situation around dma_zalloc_coherent. To safely support mapping the allocations to userspace major architectures like x86 and arm have always zeroed allocations from dma_alloc_coherent, but a couple other architectures were missing that zeroing either always or in corner cases. Then later we grew anothe dma_zalloc_coherent interface to explicitly request zeroing, but that just added __GFP_ZERO to the allocation flags, which for some allocators that didn't end up using the page allocator ended up being a no-op and still not zeroing the allocations. So for this merge window I fixed up all remaining architectures to zero the memory in dma_alloc_coherent, and made dma_zalloc_coherent a no-op wrapper around dma_alloc_coherent, which fixes all of the above issues. dma_zalloc_coherent is now pointless and can go away, and Luis helped me writing a cocchinelle script and patch series to kill it, which I think we should apply now just after -rc1 to finally settle these issue" * tag 'remove-dma_zalloc_coherent-5.0' of git://git.infradead.org/users/hch/dma-mapping: dma-mapping: remove dma_zalloc_coherent() cross-tree: phase out dma_zalloc_coherent() on headers cross-tree: phase out dma_zalloc_coherent()
Diffstat (limited to 'lib/dec_and_lock.c')
0 files changed, 0 insertions, 0 deletions