illumos gate

Reading the code, it appears that it is ill equipped to deal with constructor failure here. That's a problem. We can indeed reasonably fail the constructor, and in this case the problem is a failure to alloc a DMA handle.

However, reading bd_xfer_ctor indicates that the DMA allocation should be performed with DDI_DMA_SLEEP. So why is the DMA handle allocation failing? It never should. Perhaps you have corrupted DMA attributes somewhere? Or perhaps all DMA resources on the system are exhausted?

Hmm, I don't think you are right.

bd_xfer_alloc() is called from bd_strategy():

        xi = bd_xfer_alloc(bd, bp, func, KM_NOSLEEP);
        if (xi == NULL) {
                xi = bd_xfer_alloc(bd, bp, func, KM_PUSHPAGE);
        }

And bd_xfer_ctor() says:

        if (kmflag == KM_SLEEP) {
                dcb = DDI_DMA_SLEEP;
        } else {
                dcb = DDI_DMA_DONTWAIT;
        }

So ddi_dma_alloc_handle is called with dcb == DDI_DMA_DONTWAIT. Right?

So, how should we handle this? Is it possible that a KM_SLEEP allocation would cause some pages to be swapped out, thus possibly causing more requests to the same device?

In Linux, they solve the problem using a wider range of GFP flags (analogous to KM flags):
GFP_NOWAIT - Don't sleep.
GFP_NOIO - Can sleep, but don't do any IO on the block layer. Useful in block layer and driver code.
GFP_NOFS - Can sleep and do block IO, but not fs access (can swap, unless the swap is backed by a file). Useful in fs code.
GFP_KERNEL - Can do anything, the default most code should use.
As well as a few others.

We don't have such an abundance in illumos, so I'm not sure how to solve the problem without causing any deadlocks, assuming KM_SLEEP could cause new IO.

I think the problem is that bd_xfer_ctor() needs to consider KM_PUSHPAGE as well as KM_SLEEP. (KM_PUSHPAGE has similar semantics as KM_SLEEP in that it should trigger a sleeping DDI allocation as well.)

The ctor would fail from the first allocation that is using KM_NOSLEEP:

        xi = bd_xfer_alloc(bd, bp, func, KM_NOSLEEP);
        if (xi == NULL) {
                xi = bd_xfer_alloc(bd, bp, func, KM_PUSHPAGE);
        }

We could only leave the KM_PUSHPAGE allocation, and map KM_PUSHPAGE to DDI_DMA_SLEEP, but could this cause more IO to the same device?

No, you misunderstand. KM_NOSLEEP should still be fine. And it is. The problem is that we used KM_PUSHPAGE instead of KM_SLEEP, but the underlying DMA logic doesn't notice that KM_PUSHPAGE was used and fails to apply the correct DDI_DMA_SLEEP setting, I think.

The first call is still made with KM_NOSLEEP, so the ctor would still fail on the first call, and cause the assert in kmem_cache_alloc() to fail, right?

No. KM_NOSLEEP allocations won't be in that code path. Or rather, the rc will be -1, indicating a KM_NOSLEEP failed allocation, not a failure of the constructor. (So the assert won't fire if KM_NOSLEEP fails.)

Got it. kmem_cache_alloc only expects the constructor to always succeed when KM_NOSLEEP is not set. Let me fix blkdev.