All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ps@pks.im" <ps@pks.im>, "axboe@kernel.dk" <axboe@kernel.dk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>
Subject: Re: [PATCH] block: fix NPE when resuming SCSI devices using blk-mq
Date: Wed, 25 Jul 2018 18:13:02 +0000	[thread overview]
Message-ID: <fda284b59b2401d3d44a1343f809b98a8ae69be7.camel@wdc.com> (raw)
In-Reply-To: <b712b87a509dc64619a3aec7c673935ed09be5de.1531488173.git.ps@pks.im>

On Fri, 2018-07-13 at 15:29 +0200, Patrick Steinhardt wrote:
> When power management for SCSI is enabled and if a device uses blk-mq=
,
> it is possible to trigger a `NULL` pointer exception when res=
uming that
> device. The NPE is triggered when trying to dereference the `requ=
est_fn`
> function pointer of the device's `request_queue`:
>=20
>     __blk_run_queue_uncond:470
>     __blk_run_queue:490
>     blk_post_runtime_resume:3889
>     sdev_runtime_resume:263
>     scsi_runtime_resume:275
>=20
> When the SCSI device is being allocated by `scsi_alloc_sd=
ev`, the
> device's request queue will either be initialized via
> `scsi_mq_alloc_queue` or `scsi_old_al=
loc_queue`. But the `request_fn`
> member of the request queue is in fact only being set in
> `scsi_old_alloc_queue`, which will then later cau=
se the mentioned NPE.
>=20
> Fix the issue by checking whether the `request_fn` is set=
 in
> `__blk_run_queue_uncond`. In case it is unset,=
 we'll silently return and
> not try to invoke the callback, thus fixing the NPE.

Which kernel version are you using? Can you check whether the following two
commits are in your kernel tree?

* 4fd41a8552af ("SCSI: Fix NULL pointer dereference in runtime PM=
CIAOw- December
  2015).
* 765e40b675a9 ("block: disable runtime-pm for blk-mq"; July =
2017).

Thanks,

Bart.

WARNING: multiple messages have this Message-ID (diff)
From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "ps@pks.im" <ps@pks.im>, "axboe@kernel.dk" <axboe@kernel.dk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>
Subject: Re: [PATCH] block: fix NPE when resuming SCSI devices using blk-mq
Date: Wed, 25 Jul 2018 18:13:02 +0000	[thread overview]
Message-ID: <fda284b59b2401d3d44a1343f809b98a8ae69be7.camel@wdc.com> (raw)
In-Reply-To: <b712b87a509dc64619a3aec7c673935ed09be5de.1531488173.git.ps@pks.im>

On Fri, 2018-07-13 at 15:29 +0200, Patrick Steinhardt wrote:
> When power management for SCSI is enabled and if a device uses blk-mq,
> it is possible to trigger a `NULL` pointer exception when resuming that
> device. The NPE is triggered when trying to dereference the `request_fn`
> function pointer of the device's `request_queue`:
> 
>     __blk_run_queue_uncond:470
>     __blk_run_queue:490
>     blk_post_runtime_resume:3889
>     sdev_runtime_resume:263
>     scsi_runtime_resume:275
> 
> When the SCSI device is being allocated by `scsi_alloc_sdev`, the
> device's request queue will either be initialized via
> `scsi_mq_alloc_queue` or `scsi_old_alloc_queue`. But the `request_fn`
> member of the request queue is in fact only being set in
> `scsi_old_alloc_queue`, which will then later cause the mentioned NPE.
> 
> Fix the issue by checking whether the `request_fn` is set in
> `__blk_run_queue_uncond`. In case it is unset, we'll silently return and
> not try to invoke the callback, thus fixing the NPE.

Which kernel version are you using? Can you check whether the following two
commits are in your kernel tree?

* 4fd41a8552af ("SCSI: Fix NULL pointer dereference in runtime PM"; December
  2015).
* 765e40b675a9 ("block: disable runtime-pm for blk-mq"; July 2017).

Thanks,

Bart.

  parent reply	other threads:[~2018-07-25 18:13 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-13 13:29 [PATCH] block: fix NPE when resuming SCSI devices using blk-mq Patrick Steinhardt
2018-07-13 13:41 ` Ming Lei
2018-07-16 15:11   ` Patrick Steinhardt
2018-07-29  9:41   ` Tomas Janousek
2018-07-30  7:59     ` Patrick Steinhardt
2018-07-30 11:50       ` Ming Lei
2018-07-30 15:00         ` Tomas Janousek
2018-07-25 18:13 ` Bart Van Assche [this message]
2018-07-25 18:13   ` Bart Van Assche
2018-07-26  8:38   ` Patrick Steinhardt
2018-07-26 13:51     ` Bart Van Assche
2018-07-27 12:35       ` Patrick Steinhardt
2018-07-27 15:03         ` Bart Van Assche
2018-07-27 15:03           ` Bart Van Assche
2018-07-28 18:50           ` Patrick Steinhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fda284b59b2401d3d44a1343f809b98a8ae69be7.camel@wdc.com \
    --to=bart.vanassche@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=ps@pks.im \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.