mbox series

[SRU,F/Unstable,0/1] Handle I/O on a blk device without request function

Message ID 20200123083303.11611-1-stefan.bader@canonical.com
Headers show
Series Handle I/O on a blk device without request function | expand

Message

Stefan Bader Jan. 23, 2020, 8:33 a.m. UTC 
This is to handle a situation which only recently started to be
exercised but the underlying breakage has been around since 4.1
(Xenial onwards).

The plan is to try getting this upstream and backported via
stable as it is nothing that will happen accidental in a normal
workflow.

Just for the background, this was observed when uc20 started to
support encrypted devices. During the initial setup, when the
encrypted device is created, there is a short period of time
(cryptsetup luksOpen does under the hood have first the device-
mapper target without a mapping table and then supply the mapping)
where the logical block device is around but has no function set up
to do the I/O mapping. This stage already fires a uvent about the
block device being added and this is acted on by a udev rule which
only takes action when inside a snap, and this action attempts a
mount which sends I/O to detect which (or wheteher) filesystem is
on the block device/partition. And that causes a kernel crash.

-Stefan

Stefan Bader (1):
  UBUNTU: SAUCE: blk/core: Gracefully handle unset make_request_fn

 block/blk-core.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Seth Forshee Jan. 29, 2020, 4:33 a.m. UTC | #1 
On Thu, Jan 23, 2020 at 10:33:02AM +0200, Stefan Bader wrote:
> This is to handle a situation which only recently started to be
> exercised but the underlying breakage has been around since 4.1
> (Xenial onwards).
> 
> The plan is to try getting this upstream and backported via
> stable as it is nothing that will happen accidental in a normal
> workflow.
> 
> Just for the background, this was observed when uc20 started to
> support encrypted devices. During the initial setup, when the
> encrypted device is created, there is a short period of time
> (cryptsetup luksOpen does under the hood have first the device-
> mapper target without a mapping table and then supply the mapping)
> where the logical block device is around but has no function set up
> to do the I/O mapping. This stage already fires a uvent about the
> block device being added and this is acted on by a udev rule which
> only takes action when inside a snap, and this action attempts a
> mount which sends I/O to detect which (or wheteher) filesystem is
> on the block device/partition. And that causes a kernel crash.

Applied to focal/master-next and unstable/master, thanks!