summaryrefslogtreecommitdiff
path: root/net/core
diff options
context:
space:
mode:
authorGerd Bayer <gbayer@linux.ibm.com>2024-04-15 15:15:07 +0200
committerDavid S. Miller <davem@davemloft.net>2024-04-17 12:55:49 +0100
commit83781384a96b95e2b6403d3c8a002b2c89031770 (patch)
tree9e7a821721f57290e94c8ad3f86c0957b3e24509 /net/core
parentcb178ccb4a8ea054d39e34ed6bfb821ecc54da39 (diff)
s390/ism: Properly fix receive message buffer allocation
Since [1], dma_alloc_coherent() does not accept requests for GFP_COMP anymore, even on archs that may be able to fulfill this. Functionality that relied on the receive buffer being a compound page broke at that point: The SMC-D protocol, that utilizes the ism device driver, passes receive buffers to the splice processor in a struct splice_pipe_desc with a single entry list of struct pages. As the buffer is no longer a compound page, the splice processor now rejects requests to handle more than a page worth of data. Replace dma_alloc_coherent() and allocate a buffer with folio_alloc and create a DMA map for it with dma_map_page(). Since only receive buffers on ISM devices use DMA, qualify the mapping as FROM_DEVICE. Since ISM devices are available on arch s390, only, and on that arch all DMA is coherent, there is no need to introduce and export some kind of dma_sync_to_cpu() method to be called by the SMC-D protocol layer. Analogously, replace dma_free_coherent by a two step dma_unmap_page, then folio_put to free the receive buffer. [1] https://lore.kernel.org/all/20221113163535.884299-1-hch@lst.de/ Fixes: c08004eede4b ("s390/ism: don't pass bogus GFP_ flags to dma_alloc_coherent") Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/core')
0 files changed, 0 insertions, 0 deletions