Re: [PATCH v7 06/19] s390/dasd: Use GFP_KERNEL in dasd_alloc_device()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-after-free on `cqr` during spinlock release in `dasd_flush_block_queue()`.
--

--- Patch [6]: [PATCH v7 06/19] s390/dasd: Use GFP_KERNEL in dasd_alloc_device() ---
commit a4cb04e072a32106527d386076e01c8c126cd561
Author: Stefan Haberland <[email protected]>

s390/dasd: Use GFP_KERNEL in dasd_alloc_device()

dasd_alloc_device() runs in process context (device set_online), so its
pool allocations do not need GFP_ATOMIC. Use GFP_KERNEL instead, which is
more reliable, especially for the larger DMA allocations that later ESE
full-track work adds here.

> diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
> index f5585c549e09e..d0f72d3d0f541 100644
> --- a/drivers/s390/block/dasd.c
> +++ b/drivers/s390/block/dasd.c

[ ... ]

drivers/s390/block/dasd.c:dasd_flush_block_queue() {
...
		spin_lock_irqsave(&cqr->dq->lock, flags);
		cqr->endclk = get_tod_clock();
		list_del_init(&cqr->blocklist);
		__dasd_cleanup_cqr(cqr);
		spin_unlock_irqrestore(&cqr->dq->lock, flags);
...
}

[Severity: High]
This is a pre-existing issue, but does this code cause a use-after-free on
cqr?

__dasd_cleanup_cqr() calls free_cp(), which frees the cqr request block back
to its memory pool.

When spin_unlock_irqrestore(&cqr->dq->lock, flags) executes immediately after,
the already freed cqr structure must be dereferenced to read the dq pointer.
Could this result in using a poisoned or invalid lock address?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=6