On Tue, 2019-02-12 at 00:06 -0800, Christoph Hellwig wrote:
On Mon, Feb 11, 2019 at 10:05:02AM -0500, Ewan D. Milne wrote:
The change to use dma_set_mask_and_coherent() incorrectly made a second call with the 32 bit DMA mask value when the call with the 64 bit DMA mask value succeeded. This resulted in NVMe/FC connections failing due to corrupted data buffers, and various other SCSI/FCP I/O errors.
Ooops, sorry.
/* Set the device DMA mask size */
- if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) ||
dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)))return error;
- if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)) != 0)
if (dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)) != 0)But this still looks obsfuctating, why not:
error = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); if (error) error = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32))); if (error) return error;
I agree that making the flow of control explicit would be good, but...
It looks like this would introduce a different problem. "error" is set to -ENODEV earlier in the two functions so that the various error paths will return that value. If it is overwritten with a successful result from the call to dma_set_mask_and_coherent() but a later call to e.g. ioremap() fails, the functions will incorrectly return a value indicating that they have succeeded.
It also appears as if the patches to hptiop, hisi_sas and bfa need to be fixed up. I don't have a test environment for these, although I might be able to modify the test environment for bfa. Martin/James, what about the others?
-Ewan