linux.git/block/blk-integrity.c, branch v5.16.4

blk-crypto: rename blk_keyslot_manager to blk_crypto_profile

2021-10-21T16:49:32+00:00

blk_keyslot_manager is misnamed because it doesn't necessarily manage
keyslots.  It actually does several different things:

  - Contains the crypto capabilities of the device.

  - Provides functions to control the inline encryption hardware.
    Originally these were just for programming/evicting keyslots;
    however, new functionality (hardware-wrapped keys) will require new
    functions here which are unrelated to keyslots.  Moreover,
    device-mapper devices already (ab)use "keyslot_evict" to pass key
    eviction requests to their underlying devices even though
    device-mapper devices don't have any keyslots themselves (so it
    really should be "evict_key", not "keyslot_evict").

  - Sometimes (but not always!) it manages keyslots.  Originally it
    always did, but device-mapper devices don't have keyslots
    themselves, so they use a "passthrough keyslot manager" which
    doesn't actually manage keyslots.  This hack works, but the
    terminology is unnatural.  Also, some hardware doesn't have keyslots
    and thus also uses a "passthrough keyslot manager" (support for such
    hardware is yet to be upstreamed, but it will happen eventually).

Let's stop having keyslot managers which don't actually manage keyslots.
Instead, rename blk_keyslot_manager to blk_crypto_profile.

This is a fairly big change, since for consistency it also has to update
keyslot manager-related function names, variable names, and comments --
not just the actual struct name.  However it's still a fairly
straightforward change, as it doesn't change any actual functionality.

Acked-by: Ulf Hansson  # For MMC
Reviewed-by: Mike Snitzer 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Eric Biggers 
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe

block: move integrity handling out of

2021-10-18T12:17:02+00:00

Split the integrity/metadata handling definitions out into a new header.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Johannes Thumshirn 
Link: https://lore.kernel.org/r/20210920123328.1399408-17-hch@lst.de
Signed-off-by: Jens Axboe

block: flush the integrity workqueue in blk_integrity_unregister

2021-09-15T02:03:30+00:00

When the integrity profile is unregistered there can still be integrity
reads queued up which could see a NULL verify_fn as shown by the race
window below:

CPU0                                    CPU1
  process_one_work                      nvme_validate_ns
    bio_integrity_verify_fn                nvme_update_ns_info
	                                     nvme_update_disk_info
	                                       blk_integrity_unregister
                                               ---set queue->integrity as 0
	bio_integrity_process
	--access bi->profile->verify_fn(bi is a pointer of queue->integity)

Before calling blk_integrity_unregister in nvme_update_disk_info, we must
make sure that there is no work item in the kintegrityd_wq. Just call
blk_flush_integrity to flush the work queue so the bug can be resolved.

Signed-off-by: Lihong Kou 
[hch: split up and shortened the changelog]
Signed-off-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Link: https://lore.kernel.org/r/20210914070657.87677-3-hch@lst.de
Signed-off-by: Jens Axboe

block: check if a profile is actually registered in blk_integrity_unregister

2021-09-15T02:03:30+00:00

While clearing the profile itself is harmless, we really should not clear
the stable writes flag if it wasn't set due to a registered integrity
profile.

Reported-by: Lihong Kou 
Signed-off-by: Christoph Hellwig 
Reviewed-by: Sagi Grimberg 
Link: https://lore.kernel.org/r/20210914070657.87677-2-hch@lst.de
Signed-off-by: Jens Axboe

block: return errors from blk_integrity_add

2021-08-23T18:55:45+00:00

Prepare for proper error handling in add_disk.

Signed-off-by: Luis Chamberlain 
[hch: split from a larger patch]
Signed-off-by: Christoph Hellwig 
Reviewed-by: Hannes Reinecke 
Link: https://lore.kernel.org/r/20210818144542.19305-8-hch@lst.de
Signed-off-by: Jens Axboe

block: remove the unused blk_integrity_merge_bio export

2020-10-06T13:29:53+00:00

Also move the definition from the public blkdev.h to the private
block/blk.h header.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: remove the unused blk_integrity_merge_rq export

2020-10-06T13:29:53+00:00

Also move the definition from the public blkdev.h to the private
block/blk.h header.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

bdi: replace BDI_CAP_STABLE_WRITES with a queue and a sb flag

2020-09-24T19:43:39+00:00

The BDI_CAP_STABLE_WRITES is one of the few bits of information in the
backing_dev_info shared between the block drivers and the writeback code.
To help untangling the dependency replace it with a queue flag and a
superblock flag derived from it.  This also helps with the case of e.g.
a file system requiring stable writes due to its own checksumming, but
not forcing it on other users of the block device like the swap code.

One downside is that we an't support the stable_pages_required bdi
attribute in sysfs anymore.  It is replaced with a queue attribute which
also is writable for easier testing.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Jens Axboe

block: Make blk-integrity preclude hardware inline encryption

2020-05-14T15:48:03+00:00

Whenever a device supports blk-integrity, make the kernel pretend that
the device doesn't support inline encryption (essentially by setting the
keyslot manager in the request queue to NULL).

There's no hardware currently that supports both integrity and inline
encryption. However, it seems possible that there will be such hardware
in the near future (like the NVMe key per I/O support that might support
both inline encryption and PI).

But properly integrating both features is not trivial, and without
real hardware that implements both, it is difficult to tell if it will
be done correctly by the majority of hardware that support both.
So it seems best not to support both features together right now, and
to decide what to do at probe time.

Signed-off-by: Satya Tangirala 
Reviewed-by: Eric Biggers 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Jens Axboe

block: centralize PI remapping logic to the block layer

2019-09-18T02:03:49+00:00

Currently t10_pi_prepare/t10_pi_complete functions are called during the
NVMe and SCSi layers command preparetion/completion, but their actual
place should be the block layer since T10-PI is a general data integrity
feature that is used by block storage protocols. Introduce .prepare_fn
and .complete_fn callbacks within the integrity profile that each type
can implement according to its needs.

Suggested-by: Christoph Hellwig 
Reviewed-by: Christoph Hellwig 
Suggested-by: Martin K. Petersen 
Reviewed-by: Martin K. Petersen 
Signed-off-by: Max Gurtovoy 

Fixed to not call queue integrity functions if BLK_DEV_INTEGRITY
isn't defined in the config.

Signed-off-by: Jens Axboe