From: "huteng.ht" <[email protected]>
Since poll method in blk_mq_ops may not be implemented by driver,
add a judgement to avoid NULL pointer access.
Signed-off-by: huteng.ht <[email protected]>
---
block/blk-mq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index c5cf0dbca1db..f58f166d1c75 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -4897,6 +4897,8 @@ static int blk_mq_poll_classic(struct request_queue *q, blk_qc_t cookie,
int ret;
do {
+ if (!q->mq_ops->poll)
+ break;
ret = q->mq_ops->poll(hctx, iob);
if (ret > 0) {
__set_current_state(TASK_RUNNING);
--
2.20.1
On Fri, Dec 16, 2022 at 11:06:36PM +0800, [email protected] wrote:
> From: "huteng.ht" <[email protected]>
>
> Since poll method in blk_mq_ops may not be implemented by driver,
> add a judgement to avoid NULL pointer access.
Have you actually observed this NULL pointer access occur? Because the
poll attempt should have been abandoned much earlier due to the queue
not having QUEUE_FLAG_POLL set. If a driver has that flag set without
actually implementing ->poll(), though, that'd be a different bug.
On 12/16/22 8:06 AM, [email protected] wrote:
> From: "huteng.ht" <[email protected]>
>
> Since poll method in blk_mq_ops may not be implemented by driver,
> add a judgement to avoid NULL pointer access.
So the queue has QUEUE_FLAG_POLL set, but no -mq_ops->poll() set?
That seems like the real bug.
Where did you see this oops?
--
Jens Axboe