On Wed, 12 Jun 2019 15:33:24 +0200 Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > On Wed, 12 Jun 2019 08:21:27 +0200 > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > > On Wed, 12 Jun 2019 02:32:31 +0200 > > Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > > > > > On Tue, 11 Jun 2019 18:19:44 +0200 > > > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > > > > > > > On Tue, 11 Jun 2019 16:27:21 +0200 > > > > Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > > > > > > > IMHO the cleanest thing to do at this stage is to check if the > > > > > airq_iv_cache is NULL and fail the allocation if it is (to preserve > > > > > previous behavior). > > > > > > > > That's probably the least invasive fix for now. Did you check whether > > > > any of the other dma pools this series introduces have a similar > > > > problem due to init not failing? > > > > > > > > > > Good question! > > > > > > I did a quick check. virtio_ccw_init() should be OK, because we don't > > > register the driver if allocation fails, so the thing is going to end > > > up dysfunctional as expected. > > > > > > If however cio_dma_pool_init() fails, then we end up with the same > > > problem with airqs, just on the !AIRQ_IV_CACHELINE code path. It can be > > > fixed analogously: make cio_dma_zalloc() fail all allocation if > > > cio_dma_pool_init() failed before. > > > > Ok, makes sense. > > v5 is out with the fixes. I have no ack/r-b from you for patch 4. Would > you like to give some, or should I proceed without? Please give this some more time, I will look at this later.
