2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2001 Sistina Software (UK) Limited.
|
dm table: rework reference counting
Rework table reference counting.
The existing code uses a reference counter. When the last reference is
dropped and the counter reaches zero, the table destructor is called.
Table reference counters are acquired/released from upcalls from other
kernel code (dm_any_congested, dm_merge_bvec, dm_unplug_all).
If the reference counter reaches zero in one of the upcalls, the table
destructor is called from almost random kernel code.
This leads to various problems:
* dm_any_congested being called under a spinlock, which calls the
destructor, which calls some sleeping function.
* the destructor attempting to take a lock that is already taken by the
same process.
* stale reference from some other kernel code keeps the table
constructed, which keeps some devices open, even after successful
return from "dmsetup remove". This can confuse lvm and prevent closing
of underlying devices or reusing device minor numbers.
The patch changes reference counting so that the table destructor can be
called only at predetermined places.
The table has always exactly one reference from either mapped_device->map
or hash_cell->new_map. After this patch, this reference is not counted
in table->holders. A pair of dm_create_table/dm_destroy_table functions
is used for table creation/destruction.
Temporary references from the other code increase table->holders. A pair
of dm_table_get/dm_table_put functions is used to manipulate it.
When the table is about to be destroyed, we wait for table->holders to
reach 0. Then, we call the table destructor. We use active waiting with
msleep(1), because the situation happens rarely (to one user in 5 years)
and removing the device isn't performance-critical task: the user doesn't
care if it takes one tick more or not.
This way, the destructor is called only at specific points
(dm_table_destroy function) and the above problems associated with lazy
destruction can't happen.
Finally remove the temporary protection added to dm_any_congested().
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-01-06 11:05:10 +08:00
|
|
|
* Copyright (C) 2004-2008 Red Hat, Inc. All rights reserved.
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* This file is released under the GPL.
|
|
|
|
*/
|
|
|
|
|
2016-05-13 04:28:10 +08:00
|
|
|
#include "dm-core.h"
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
#include <linux/blkdev.h>
|
2021-09-20 20:33:27 +08:00
|
|
|
#include <linux/blk-integrity.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/namei.h>
|
|
|
|
#include <linux/ctype.h>
|
2009-12-15 10:01:06 +08:00
|
|
|
#include <linux/string.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/interrupt.h>
|
2006-03-27 17:18:20 +08:00
|
|
|
#include <linux/mutex.h>
|
dm table: rework reference counting
Rework table reference counting.
The existing code uses a reference counter. When the last reference is
dropped and the counter reaches zero, the table destructor is called.
Table reference counters are acquired/released from upcalls from other
kernel code (dm_any_congested, dm_merge_bvec, dm_unplug_all).
If the reference counter reaches zero in one of the upcalls, the table
destructor is called from almost random kernel code.
This leads to various problems:
* dm_any_congested being called under a spinlock, which calls the
destructor, which calls some sleeping function.
* the destructor attempting to take a lock that is already taken by the
same process.
* stale reference from some other kernel code keeps the table
constructed, which keeps some devices open, even after successful
return from "dmsetup remove". This can confuse lvm and prevent closing
of underlying devices or reusing device minor numbers.
The patch changes reference counting so that the table destructor can be
called only at predetermined places.
The table has always exactly one reference from either mapped_device->map
or hash_cell->new_map. After this patch, this reference is not counted
in table->holders. A pair of dm_create_table/dm_destroy_table functions
is used for table creation/destruction.
Temporary references from the other code increase table->holders. A pair
of dm_table_get/dm_table_put functions is used to manipulate it.
When the table is about to be destroyed, we wait for table->holders to
reach 0. Then, we call the table destructor. We use active waiting with
msleep(1), because the situation happens rarely (to one user in 5 years)
and removing the device isn't performance-critical task: the user doesn't
care if it takes one tick more or not.
This way, the destructor is called only at specific points
(dm_table_destroy function) and the above problems associated with lazy
destruction can't happen.
Finally remove the temporary protection added to dm_any_congested().
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-01-06 11:05:10 +08:00
|
|
|
#include <linux/delay.h>
|
2011-07-27 07:09:06 +08:00
|
|
|
#include <linux/atomic.h>
|
2015-03-08 13:51:47 +08:00
|
|
|
#include <linux/blk-mq.h>
|
dm table: fall back to getting device using name_to_dev_t()
If a device is used as the root filesystem, it can't be built
off of devices which are within the root filesystem (just like
command line arguments to root=). For this reason, Linux has a
pseudo-filesystem for root= and MD initialization (based on the
function name_to_dev_t) which handles different ways of specifying
devices including PARTUUID and major:minor.
Switch to using name_to_dev_t() in dm_get_device(). Rather than
having DM assume that all things which are not major:minor are paths in
an already-mounted filesystem, change dm_get_device() to first attempt
to look up the device in the filesystem, and if not found it will fall
back to using name_to_dev_t().
In terms of backwards compatibility, there are some cases where
behavior will be different:
- If you have a file in the current working directory named 1:2 and
you initialze DM there, then it will try to use that file rather
than the disk with that major:minor pair as a backing device.
- Similarly for other bdev types which name_to_dev_t() knows how to
interpret, the previous behavior was to repeatedly check for the
existence of the file (e.g., while waiting for rootfs to come up)
but the new behavior is to use the name_to_dev_t() interpretation.
For example, if you have a file named /dev/ubiblock0_0 which is
a symlink to /dev/sda3, but it is not yet present when DM starts
to initialize, then the name_to_dev_t() interpretation will take
precedence.
These incompatibilities would only show up in really strange setups
with bad practices so we shouldn't have to worry about them.
Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2015-02-11 07:20:51 +08:00
|
|
|
#include <linux/mount.h>
|
2017-07-26 21:35:09 +08:00
|
|
|
#include <linux/dax.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-06-26 15:27:35 +08:00
|
|
|
#define DM_MSG_PREFIX "table"
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#define NODE_SIZE L1_CACHE_BYTES
|
|
|
|
#define KEYS_PER_NODE (NODE_SIZE / sizeof(sector_t))
|
|
|
|
#define CHILDREN_PER_NODE (KEYS_PER_NODE + 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Similar to ceiling(log_size(n))
|
|
|
|
*/
|
|
|
|
static unsigned int int_log(unsigned int n, unsigned int base)
|
|
|
|
{
|
|
|
|
int result = 0;
|
|
|
|
|
|
|
|
while (n > 1) {
|
|
|
|
n = dm_div_up(n, base);
|
|
|
|
result++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Calculate the index of the child node of the n'th node k'th key.
|
|
|
|
*/
|
|
|
|
static inline unsigned int get_child(unsigned int n, unsigned int k)
|
|
|
|
{
|
|
|
|
return (n * CHILDREN_PER_NODE) + k;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the n'th node of level l from table t.
|
|
|
|
*/
|
|
|
|
static inline sector_t *get_node(struct dm_table *t,
|
|
|
|
unsigned int l, unsigned int n)
|
|
|
|
{
|
|
|
|
return t->index[l] + (n * KEYS_PER_NODE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return the highest key that you could lookup from the n'th
|
|
|
|
* node on level l of the btree.
|
|
|
|
*/
|
|
|
|
static sector_t high(struct dm_table *t, unsigned int l, unsigned int n)
|
|
|
|
{
|
|
|
|
for (; l < t->depth - 1; l++)
|
|
|
|
n = get_child(n, CHILDREN_PER_NODE - 1);
|
|
|
|
|
|
|
|
if (n >= t->counts[l])
|
|
|
|
return (sector_t) - 1;
|
|
|
|
|
|
|
|
return get_node(t, l, n)[KEYS_PER_NODE - 1];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Fills in a level of the btree based on the highs of the level
|
|
|
|
* below it.
|
|
|
|
*/
|
|
|
|
static int setup_btree_index(unsigned int l, struct dm_table *t)
|
|
|
|
{
|
|
|
|
unsigned int n, k;
|
|
|
|
sector_t *node;
|
|
|
|
|
|
|
|
for (n = 0U; n < t->counts[l]; n++) {
|
|
|
|
node = get_node(t, l, n);
|
|
|
|
|
|
|
|
for (k = 0U; k < KEYS_PER_NODE; k++)
|
|
|
|
node[k] = high(t, l + 1, get_child(n, k));
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* highs, and targets are managed as dynamic arrays during a
|
|
|
|
* table load.
|
|
|
|
*/
|
|
|
|
static int alloc_targets(struct dm_table *t, unsigned int num)
|
|
|
|
{
|
|
|
|
sector_t *n_highs;
|
|
|
|
struct dm_target *n_targets;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate both the target array and offset array at once.
|
|
|
|
*/
|
2021-04-07 21:25:22 +08:00
|
|
|
n_highs = kvcalloc(num, sizeof(struct dm_target) + sizeof(sector_t),
|
|
|
|
GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!n_highs)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
n_targets = (struct dm_target *) (n_highs + num);
|
|
|
|
|
dm table: remove unused buggy code that extends the targets array
A device mapper table is allocated in the following way:
* The function dm_table_create is called, it gets the number of targets
as an argument -- it allocates a targets array accordingly.
* For each target, we call dm_table_add_target.
If we add more targets than were specified in dm_table_create, the
function dm_table_add_target reallocates the targets array. However,
this reallocation code is wrong - it moves the targets array to a new
location, while some target constructors hold pointers to the array in
the old location.
The following DM target drivers save the pointer to the target
structure, so they corrupt memory if the target array is moved:
multipath, raid, mirror, snapshot, stripe, switch, thin, verity.
Under normal circumstances, the reallocation function is not called
(because dm_table_create is called with the correct number of targets),
so the buggy reallocation code is not used.
Prior to the fix "dm table: fail dm_table_create on dm_round_up
overflow", the reallocation code could only be used in case the user
specifies too large a value in param->target_count, such as 0xffffffff.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2013-11-23 08:51:39 +08:00
|
|
|
memset(n_highs, -1, sizeof(*n_highs) * num);
|
2021-04-07 21:25:22 +08:00
|
|
|
kvfree(t->highs);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
t->num_allocated = num;
|
|
|
|
t->highs = n_highs;
|
|
|
|
t->targets = n_targets;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-09-03 03:28:45 +08:00
|
|
|
int dm_table_create(struct dm_table **result, fmode_t mode,
|
2006-03-27 17:17:54 +08:00
|
|
|
unsigned num_targets, struct mapped_device *md)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2007-10-20 05:38:51 +08:00
|
|
|
struct dm_table *t = kzalloc(sizeof(*t), GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (!t)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&t->devices);
|
|
|
|
|
|
|
|
if (!num_targets)
|
|
|
|
num_targets = KEYS_PER_NODE;
|
|
|
|
|
|
|
|
num_targets = dm_round_up(num_targets, KEYS_PER_NODE);
|
|
|
|
|
2013-11-23 08:52:06 +08:00
|
|
|
if (!num_targets) {
|
|
|
|
kfree(t);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
if (alloc_targets(t, num_targets)) {
|
|
|
|
kfree(t);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2016-05-25 09:16:51 +08:00
|
|
|
t->type = DM_TYPE_NONE;
|
2005-04-17 06:20:36 +08:00
|
|
|
t->mode = mode;
|
2006-03-27 17:17:54 +08:00
|
|
|
t->md = md;
|
2005-04-17 06:20:36 +08:00
|
|
|
*result = t;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
static void free_devices(struct list_head *devices, struct mapped_device *md)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
struct list_head *tmp, *next;
|
|
|
|
|
2008-02-08 10:09:59 +08:00
|
|
|
list_for_each_safe(tmp, next, devices) {
|
2008-10-10 20:37:09 +08:00
|
|
|
struct dm_dev_internal *dd =
|
|
|
|
list_entry(tmp, struct dm_dev_internal, list);
|
2014-08-14 02:53:43 +08:00
|
|
|
DMWARN("%s: dm_table_destroy: dm_put_device call missing for %s",
|
|
|
|
dm_device_name(md), dd->dm_dev->name);
|
|
|
|
dm_put_table_device(md, dd->dm_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(dd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static void dm_table_destroy_crypto_profile(struct dm_table *t);
|
2021-02-01 13:10:17 +08:00
|
|
|
|
dm table: rework reference counting
Rework table reference counting.
The existing code uses a reference counter. When the last reference is
dropped and the counter reaches zero, the table destructor is called.
Table reference counters are acquired/released from upcalls from other
kernel code (dm_any_congested, dm_merge_bvec, dm_unplug_all).
If the reference counter reaches zero in one of the upcalls, the table
destructor is called from almost random kernel code.
This leads to various problems:
* dm_any_congested being called under a spinlock, which calls the
destructor, which calls some sleeping function.
* the destructor attempting to take a lock that is already taken by the
same process.
* stale reference from some other kernel code keeps the table
constructed, which keeps some devices open, even after successful
return from "dmsetup remove". This can confuse lvm and prevent closing
of underlying devices or reusing device minor numbers.
The patch changes reference counting so that the table destructor can be
called only at predetermined places.
The table has always exactly one reference from either mapped_device->map
or hash_cell->new_map. After this patch, this reference is not counted
in table->holders. A pair of dm_create_table/dm_destroy_table functions
is used for table creation/destruction.
Temporary references from the other code increase table->holders. A pair
of dm_table_get/dm_table_put functions is used to manipulate it.
When the table is about to be destroyed, we wait for table->holders to
reach 0. Then, we call the table destructor. We use active waiting with
msleep(1), because the situation happens rarely (to one user in 5 years)
and removing the device isn't performance-critical task: the user doesn't
care if it takes one tick more or not.
This way, the destructor is called only at specific points
(dm_table_destroy function) and the above problems associated with lazy
destruction can't happen.
Finally remove the temporary protection added to dm_any_congested().
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-01-06 11:05:10 +08:00
|
|
|
void dm_table_destroy(struct dm_table *t)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
2009-12-11 07:52:23 +08:00
|
|
|
if (!t)
|
|
|
|
return;
|
|
|
|
|
2010-08-12 11:14:03 +08:00
|
|
|
/* free the indexes */
|
2005-04-17 06:20:36 +08:00
|
|
|
if (t->depth >= 2)
|
2021-04-07 21:25:22 +08:00
|
|
|
kvfree(t->index[t->depth - 2]);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* free the targets */
|
|
|
|
for (i = 0; i < t->num_targets; i++) {
|
|
|
|
struct dm_target *tgt = t->targets + i;
|
|
|
|
|
|
|
|
if (tgt->type->dtr)
|
|
|
|
tgt->type->dtr(tgt);
|
|
|
|
|
|
|
|
dm_put_target_type(tgt->type);
|
|
|
|
}
|
|
|
|
|
2021-04-07 21:25:22 +08:00
|
|
|
kvfree(t->highs);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/* free the device list */
|
2014-08-14 02:53:43 +08:00
|
|
|
free_devices(&t->devices, t->md);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
dm_free_md_mempools(t->mempools);
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dm_table_destroy_crypto_profile(t);
|
2021-02-01 13:10:17 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* See if we've already got a device in the list.
|
|
|
|
*/
|
2008-10-10 20:37:09 +08:00
|
|
|
static struct dm_dev_internal *find_device(struct list_head *l, dev_t dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2008-10-10 20:37:09 +08:00
|
|
|
struct dm_dev_internal *dd;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
list_for_each_entry (dd, l, list)
|
2014-08-14 02:53:43 +08:00
|
|
|
if (dd->dm_dev->bdev->bd_dev == dev)
|
2005-04-17 06:20:36 +08:00
|
|
|
return dd;
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2009-09-05 03:40:22 +08:00
|
|
|
* If possible, this checks an area of a destination device is invalid.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-09-05 03:40:22 +08:00
|
|
|
static int device_area_is_invalid(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-06-22 17:12:34 +08:00
|
|
|
struct queue_limits *limits = data;
|
|
|
|
struct block_device *bdev = dev->bdev;
|
2021-10-18 18:11:05 +08:00
|
|
|
sector_t dev_size = bdev_nr_sectors(bdev);
|
2009-06-22 17:12:30 +08:00
|
|
|
unsigned short logical_block_size_sectors =
|
2009-06-22 17:12:34 +08:00
|
|
|
limits->logical_block_size >> SECTOR_SHIFT;
|
2007-05-09 17:32:57 +08:00
|
|
|
|
|
|
|
if (!dev_size)
|
2009-09-05 03:40:22 +08:00
|
|
|
return 0;
|
2007-05-09 17:32:57 +08:00
|
|
|
|
2009-07-24 03:30:42 +08:00
|
|
|
if ((start >= dev_size) || (start + len > dev_size)) {
|
2022-03-01 16:38:15 +08:00
|
|
|
DMWARN("%s: %pg too small for target: "
|
2009-09-05 03:40:24 +08:00
|
|
|
"start=%llu, len=%llu, dev_size=%llu",
|
2022-03-01 16:38:15 +08:00
|
|
|
dm_device_name(ti->table->md), bdev,
|
2009-09-05 03:40:24 +08:00
|
|
|
(unsigned long long)start,
|
|
|
|
(unsigned long long)len,
|
|
|
|
(unsigned long long)dev_size);
|
2009-09-05 03:40:22 +08:00
|
|
|
return 1;
|
2009-06-22 17:12:30 +08:00
|
|
|
}
|
|
|
|
|
2017-05-09 07:40:43 +08:00
|
|
|
/*
|
|
|
|
* If the target is mapped to zoned block device(s), check
|
|
|
|
* that the zones are not partially mapped.
|
|
|
|
*/
|
2021-05-26 05:24:55 +08:00
|
|
|
if (bdev_is_zoned(bdev)) {
|
2017-05-09 07:40:43 +08:00
|
|
|
unsigned int zone_sectors = bdev_zone_sectors(bdev);
|
|
|
|
|
|
|
|
if (start & (zone_sectors - 1)) {
|
2022-03-01 16:38:15 +08:00
|
|
|
DMWARN("%s: start=%llu not aligned to h/w zone size %u of %pg",
|
2017-05-09 07:40:43 +08:00
|
|
|
dm_device_name(ti->table->md),
|
|
|
|
(unsigned long long)start,
|
2022-03-01 16:38:15 +08:00
|
|
|
zone_sectors, bdev);
|
2017-05-09 07:40:43 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: The last zone of a zoned block device may be smaller
|
|
|
|
* than other zones. So for a target mapping the end of a
|
|
|
|
* zoned block device with such a zone, len would not be zone
|
|
|
|
* aligned. We do not allow such last smaller zone to be part
|
|
|
|
* of the mapping here to ensure that mappings with multiple
|
|
|
|
* devices do not end up with a smaller zone in the middle of
|
|
|
|
* the sector range.
|
|
|
|
*/
|
|
|
|
if (len & (zone_sectors - 1)) {
|
2022-03-01 16:38:15 +08:00
|
|
|
DMWARN("%s: len=%llu not aligned to h/w zone size %u of %pg",
|
2017-05-09 07:40:43 +08:00
|
|
|
dm_device_name(ti->table->md),
|
|
|
|
(unsigned long long)len,
|
2022-03-01 16:38:15 +08:00
|
|
|
zone_sectors, bdev);
|
2017-05-09 07:40:43 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-06-22 17:12:30 +08:00
|
|
|
if (logical_block_size_sectors <= 1)
|
2009-09-05 03:40:22 +08:00
|
|
|
return 0;
|
2009-06-22 17:12:30 +08:00
|
|
|
|
|
|
|
if (start & (logical_block_size_sectors - 1)) {
|
|
|
|
DMWARN("%s: start=%llu not aligned to h/w "
|
2022-03-01 16:38:15 +08:00
|
|
|
"logical block size %u of %pg",
|
2009-06-22 17:12:30 +08:00
|
|
|
dm_device_name(ti->table->md),
|
|
|
|
(unsigned long long)start,
|
2022-03-01 16:38:15 +08:00
|
|
|
limits->logical_block_size, bdev);
|
2009-09-05 03:40:22 +08:00
|
|
|
return 1;
|
2009-06-22 17:12:30 +08:00
|
|
|
}
|
|
|
|
|
2009-07-24 03:30:42 +08:00
|
|
|
if (len & (logical_block_size_sectors - 1)) {
|
2009-06-22 17:12:30 +08:00
|
|
|
DMWARN("%s: len=%llu not aligned to h/w "
|
2022-03-01 16:38:15 +08:00
|
|
|
"logical block size %u of %pg",
|
2009-06-22 17:12:30 +08:00
|
|
|
dm_device_name(ti->table->md),
|
2009-07-24 03:30:42 +08:00
|
|
|
(unsigned long long)len,
|
2022-03-01 16:38:15 +08:00
|
|
|
limits->logical_block_size, bdev);
|
2009-09-05 03:40:22 +08:00
|
|
|
return 1;
|
2009-06-22 17:12:30 +08:00
|
|
|
}
|
|
|
|
|
2009-09-05 03:40:22 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2009-04-03 02:55:28 +08:00
|
|
|
* This upgrades the mode on an already open dm_dev, being
|
2005-04-17 06:20:36 +08:00
|
|
|
* careful to leave things as they were if we fail to reopen the
|
2009-04-03 02:55:28 +08:00
|
|
|
* device and not to touch the existing bdev field in case
|
2020-07-01 17:06:22 +08:00
|
|
|
* it is accessed concurrently.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-09-03 03:28:45 +08:00
|
|
|
static int upgrade_mode(struct dm_dev_internal *dd, fmode_t new_mode,
|
2008-10-10 20:37:09 +08:00
|
|
|
struct mapped_device *md)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int r;
|
2014-08-14 02:53:43 +08:00
|
|
|
struct dm_dev *old_dev, *new_dev;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
old_dev = dd->dm_dev;
|
2009-04-03 02:55:28 +08:00
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
r = dm_get_table_device(md, dd->dm_dev->bdev->bd_dev,
|
|
|
|
dd->dm_dev->mode | new_mode, &new_dev);
|
2009-04-03 02:55:28 +08:00
|
|
|
if (r)
|
|
|
|
return r;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
dd->dm_dev = new_dev;
|
|
|
|
dm_put_table_device(md, old_dev);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2009-04-03 02:55:28 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2016-02-02 12:29:18 +08:00
|
|
|
/*
|
|
|
|
* Convert the path to a device
|
|
|
|
*/
|
|
|
|
dev_t dm_get_dev_t(const char *path)
|
|
|
|
{
|
2017-04-19 04:51:46 +08:00
|
|
|
dev_t dev;
|
2016-02-02 12:29:18 +08:00
|
|
|
|
2020-11-23 20:38:40 +08:00
|
|
|
if (lookup_bdev(path, &dev))
|
2016-02-02 12:29:18 +08:00
|
|
|
dev = name_to_dev_t(path);
|
|
|
|
return dev;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dm_get_dev_t);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Add a device to the list, or just increment the usage count if
|
|
|
|
* it's already present.
|
|
|
|
*/
|
2011-08-02 19:32:04 +08:00
|
|
|
int dm_get_device(struct dm_target *ti, const char *path, fmode_t mode,
|
|
|
|
struct dm_dev **result)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int r;
|
2016-02-02 12:29:18 +08:00
|
|
|
dev_t dev;
|
2021-01-22 01:50:56 +08:00
|
|
|
unsigned int major, minor;
|
|
|
|
char dummy;
|
2008-10-10 20:37:09 +08:00
|
|
|
struct dm_dev_internal *dd;
|
2011-08-02 19:32:04 +08:00
|
|
|
struct dm_table *t = ti->table;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2006-03-27 00:22:50 +08:00
|
|
|
BUG_ON(!t);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2021-01-22 01:50:56 +08:00
|
|
|
if (sscanf(path, "%u:%u%c", &major, &minor, &dummy) == 2) {
|
|
|
|
/* Extract the major/minor numbers */
|
|
|
|
dev = MKDEV(major, minor);
|
|
|
|
if (MAJOR(dev) != major || MINOR(dev) != minor)
|
|
|
|
return -EOVERFLOW;
|
|
|
|
} else {
|
|
|
|
dev = dm_get_dev_t(path);
|
|
|
|
if (!dev)
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
dd = find_device(&t->devices, dev);
|
|
|
|
if (!dd) {
|
|
|
|
dd = kmalloc(sizeof(*dd), GFP_KERNEL);
|
|
|
|
if (!dd)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
if ((r = dm_get_table_device(t->md, dev, mode, &dd->dm_dev))) {
|
2005-04-17 06:20:36 +08:00
|
|
|
kfree(dd);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2017-10-20 15:37:38 +08:00
|
|
|
refcount_set(&dd->count, 1);
|
2005-04-17 06:20:36 +08:00
|
|
|
list_add(&dd->list, &t->devices);
|
2017-11-25 13:27:26 +08:00
|
|
|
goto out;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
} else if (dd->dm_dev->mode != (mode | dd->dm_dev->mode)) {
|
2006-03-27 17:17:59 +08:00
|
|
|
r = upgrade_mode(dd, mode, t->md);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (r)
|
|
|
|
return r;
|
|
|
|
}
|
2017-11-25 13:27:26 +08:00
|
|
|
refcount_inc(&dd->count);
|
|
|
|
out:
|
2014-08-14 02:53:43 +08:00
|
|
|
*result = dd->dm_dev;
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_get_device);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-06-03 22:30:28 +08:00
|
|
|
static int dm_set_device_limits(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2009-06-22 17:12:34 +08:00
|
|
|
struct queue_limits *limits = data;
|
|
|
|
struct block_device *bdev = dev->bdev;
|
2007-07-24 15:28:11 +08:00
|
|
|
struct request_queue *q = bdev_get_queue(bdev);
|
2008-10-10 20:37:13 +08:00
|
|
|
|
|
|
|
if (unlikely(!q)) {
|
2022-03-01 16:38:15 +08:00
|
|
|
DMWARN("%s: Cannot set limits for nonexistent device %pg",
|
|
|
|
dm_device_name(ti->table->md), bdev);
|
2009-06-22 17:12:34 +08:00
|
|
|
return 0;
|
2008-10-10 20:37:13 +08:00
|
|
|
}
|
2006-10-03 16:15:42 +08:00
|
|
|
|
2020-07-20 14:12:50 +08:00
|
|
|
if (blk_stack_limits(limits, &q->limits,
|
|
|
|
get_start_sect(bdev) + start) < 0)
|
2022-03-01 16:38:15 +08:00
|
|
|
DMWARN("%s: adding target device %pg caused an alignment inconsistency: "
|
2009-09-05 03:40:24 +08:00
|
|
|
"physical_block_size=%u, logical_block_size=%u, "
|
|
|
|
"alignment_offset=%u, start=%llu",
|
2022-03-01 16:38:15 +08:00
|
|
|
dm_device_name(ti->table->md), bdev,
|
2009-09-05 03:40:24 +08:00
|
|
|
q->limits.physical_block_size,
|
|
|
|
q->limits.logical_block_size,
|
|
|
|
q->limits.alignment_offset,
|
2010-01-11 16:21:50 +08:00
|
|
|
(unsigned long long) start << SECTOR_SHIFT);
|
2009-06-22 17:12:34 +08:00
|
|
|
return 0;
|
2006-10-03 16:15:42 +08:00
|
|
|
}
|
2006-03-27 17:17:49 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2011-08-02 19:32:04 +08:00
|
|
|
* Decrement a device's use count and remove it if necessary.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2008-10-10 20:37:09 +08:00
|
|
|
void dm_put_device(struct dm_target *ti, struct dm_dev *d)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2014-08-14 02:53:43 +08:00
|
|
|
int found = 0;
|
|
|
|
struct list_head *devices = &ti->table->devices;
|
|
|
|
struct dm_dev_internal *dd;
|
2008-10-10 20:37:09 +08:00
|
|
|
|
2014-08-14 02:53:43 +08:00
|
|
|
list_for_each_entry(dd, devices, list) {
|
|
|
|
if (dd->dm_dev == d) {
|
|
|
|
found = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!found) {
|
|
|
|
DMWARN("%s: device %s not in table devices list",
|
|
|
|
dm_device_name(ti->table->md), d->name);
|
|
|
|
return;
|
|
|
|
}
|
2017-10-20 15:37:38 +08:00
|
|
|
if (refcount_dec_and_test(&dd->count)) {
|
2014-08-14 02:53:43 +08:00
|
|
|
dm_put_table_device(ti->table->md, d);
|
2005-04-17 06:20:36 +08:00
|
|
|
list_del(&dd->list);
|
|
|
|
kfree(dd);
|
|
|
|
}
|
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_put_device);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Checks to see if the target joins onto the end of the table.
|
|
|
|
*/
|
|
|
|
static int adjoin(struct dm_table *table, struct dm_target *ti)
|
|
|
|
{
|
|
|
|
struct dm_target *prev;
|
|
|
|
|
|
|
|
if (!table->num_targets)
|
|
|
|
return !ti->begin;
|
|
|
|
|
|
|
|
prev = &table->targets[table->num_targets - 1];
|
|
|
|
return (ti->begin == (prev->begin + prev->len));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Used to dynamically allocate the arg array.
|
2013-11-01 01:55:45 +08:00
|
|
|
*
|
|
|
|
* We do first allocation with GFP_NOIO because dm-mpath and dm-thin must
|
|
|
|
* process messages even if some device is suspended. These messages have a
|
|
|
|
* small fixed number of arguments.
|
|
|
|
*
|
|
|
|
* On the other hand, dm-switch needs to process bulk data using messages and
|
|
|
|
* excessive use of GFP_NOIO could cause trouble.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2018-05-08 07:47:02 +08:00
|
|
|
static char **realloc_argv(unsigned *size, char **old_argv)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
char **argv;
|
|
|
|
unsigned new_size;
|
2013-11-01 01:55:45 +08:00
|
|
|
gfp_t gfp;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2018-05-08 07:47:02 +08:00
|
|
|
if (*size) {
|
|
|
|
new_size = *size * 2;
|
2013-11-01 01:55:45 +08:00
|
|
|
gfp = GFP_KERNEL;
|
|
|
|
} else {
|
|
|
|
new_size = 8;
|
|
|
|
gfp = GFP_NOIO;
|
|
|
|
}
|
treewide: kmalloc() -> kmalloc_array()
The kmalloc() function has a 2-factor argument form, kmalloc_array(). This
patch replaces cases of:
kmalloc(a * b, gfp)
with:
kmalloc_array(a * b, gfp)
as well as handling cases of:
kmalloc(a * b * c, gfp)
with:
kmalloc(array3_size(a, b, c), gfp)
as it's slightly less ugly than:
kmalloc_array(array_size(a, b), c, gfp)
This does, however, attempt to ignore constant size factors like:
kmalloc(4 * 1024, gfp)
though any constants defined via macros get caught up in the conversion.
Any factors with a sizeof() of "unsigned char", "char", and "u8" were
dropped, since they're redundant.
The tools/ directory was manually excluded, since it has its own
implementation of kmalloc().
The Coccinelle script used for this was:
// Fix redundant parens around sizeof().
@@
type TYPE;
expression THING, E;
@@
(
kmalloc(
- (sizeof(TYPE)) * E
+ sizeof(TYPE) * E
, ...)
|
kmalloc(
- (sizeof(THING)) * E
+ sizeof(THING) * E
, ...)
)
// Drop single-byte sizes and redundant parens.
@@
expression COUNT;
typedef u8;
typedef __u8;
@@
(
kmalloc(
- sizeof(u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * (COUNT)
+ COUNT
, ...)
|
kmalloc(
- sizeof(u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(__u8) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(char) * COUNT
+ COUNT
, ...)
|
kmalloc(
- sizeof(unsigned char) * COUNT
+ COUNT
, ...)
)
// 2-factor product with sizeof(type/expression) and identifier or constant.
@@
type TYPE;
expression THING;
identifier COUNT_ID;
constant COUNT_CONST;
@@
(
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_ID)
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_ID
+ COUNT_ID, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (COUNT_CONST)
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * COUNT_CONST
+ COUNT_CONST, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_ID)
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_ID
+ COUNT_ID, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (COUNT_CONST)
+ COUNT_CONST, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * COUNT_CONST
+ COUNT_CONST, sizeof(THING)
, ...)
)
// 2-factor product, only identifiers.
@@
identifier SIZE, COUNT;
@@
- kmalloc
+ kmalloc_array
(
- SIZE * COUNT
+ COUNT, SIZE
, ...)
// 3-factor product with 1 sizeof(type) or sizeof(expression), with
// redundant parens removed.
@@
expression THING;
identifier STRIDE, COUNT;
type TYPE;
@@
(
kmalloc(
- sizeof(TYPE) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(TYPE) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(TYPE))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * (COUNT) * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * (STRIDE)
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
|
kmalloc(
- sizeof(THING) * COUNT * STRIDE
+ array3_size(COUNT, STRIDE, sizeof(THING))
, ...)
)
// 3-factor product with 2 sizeof(variable), with redundant parens removed.
@@
expression THING1, THING2;
identifier COUNT;
type TYPE1, TYPE2;
@@
(
kmalloc(
- sizeof(TYPE1) * sizeof(TYPE2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(TYPE2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(THING1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(THING1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * COUNT
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
|
kmalloc(
- sizeof(TYPE1) * sizeof(THING2) * (COUNT)
+ array3_size(COUNT, sizeof(TYPE1), sizeof(THING2))
, ...)
)
// 3-factor product, only identifiers, with redundant parens removed.
@@
identifier STRIDE, SIZE, COUNT;
@@
(
kmalloc(
- (COUNT) * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * STRIDE * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- (COUNT) * (STRIDE) * (SIZE)
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
|
kmalloc(
- COUNT * STRIDE * SIZE
+ array3_size(COUNT, STRIDE, SIZE)
, ...)
)
// Any remaining multi-factor products, first at least 3-factor products,
// when they're not all constants...
@@
expression E1, E2, E3;
constant C1, C2, C3;
@@
(
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(
- (E1) * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * E3
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- (E1) * (E2) * (E3)
+ array3_size(E1, E2, E3)
, ...)
|
kmalloc(
- E1 * E2 * E3
+ array3_size(E1, E2, E3)
, ...)
)
// And then all remaining 2 factors products when they're not all constants,
// keeping sizeof() as the second factor argument.
@@
expression THING, E1, E2;
type TYPE;
constant C1, C2, C3;
@@
(
kmalloc(sizeof(THING) * C2, ...)
|
kmalloc(sizeof(TYPE) * C2, ...)
|
kmalloc(C1 * C2 * C3, ...)
|
kmalloc(C1 * C2, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * (E2)
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(TYPE) * E2
+ E2, sizeof(TYPE)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * (E2)
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- sizeof(THING) * E2
+ E2, sizeof(THING)
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * E2
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- (E1) * (E2)
+ E1, E2
, ...)
|
- kmalloc
+ kmalloc_array
(
- E1 * E2
+ E1, E2
, ...)
)
Signed-off-by: Kees Cook <keescook@chromium.org>
2018-06-13 04:55:00 +08:00
|
|
|
argv = kmalloc_array(new_size, sizeof(*argv), gfp);
|
dm table: don't copy from a NULL pointer in realloc_argv()
For the first call to realloc_argv() in dm_split_args(), old_argv is
NULL and size is zero. Then memcpy is called, with the NULL old_argv
as the source argument and a zero size argument. AFAIK, this is
undefined behavior and generates the following warning when compiled
with UBSAN on ppc64le:
In file included from ./arch/powerpc/include/asm/paca.h:19,
from ./arch/powerpc/include/asm/current.h:16,
from ./include/linux/sched.h:12,
from ./include/linux/kthread.h:6,
from drivers/md/dm-core.h:12,
from drivers/md/dm-table.c:8:
In function 'memcpy',
inlined from 'realloc_argv' at drivers/md/dm-table.c:565:3,
inlined from 'dm_split_args' at drivers/md/dm-table.c:588:9:
./include/linux/string.h:345:9: error: argument 2 null where non-null expected [-Werror=nonnull]
return __builtin_memcpy(p, q, size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/md/dm-table.c: In function 'dm_split_args':
./include/linux/string.h:345:9: note: in a call to built-in function '__builtin_memcpy'
Signed-off-by: Jerome Marchand <jmarchan@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2019-06-13 00:22:26 +08:00
|
|
|
if (argv && old_argv) {
|
2018-05-08 07:47:02 +08:00
|
|
|
memcpy(argv, old_argv, *size * sizeof(*argv));
|
|
|
|
*size = new_size;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
kfree(old_argv);
|
|
|
|
return argv;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Destructively splits up the argument list to pass to ctr.
|
|
|
|
*/
|
|
|
|
int dm_split_args(int *argc, char ***argvp, char *input)
|
|
|
|
{
|
|
|
|
char *start, *end = input, *out, **argv = NULL;
|
|
|
|
unsigned array_size = 0;
|
|
|
|
|
|
|
|
*argc = 0;
|
2006-06-26 15:27:31 +08:00
|
|
|
|
|
|
|
if (!input) {
|
|
|
|
*argvp = NULL;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
argv = realloc_argv(&array_size, argv);
|
|
|
|
if (!argv)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
/* Skip whitespace */
|
2009-12-15 10:01:06 +08:00
|
|
|
start = skip_spaces(end);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
if (!*start)
|
|
|
|
break; /* success, we hit the end */
|
|
|
|
|
|
|
|
/* 'out' is used to remove any back-quotes */
|
|
|
|
end = out = start;
|
|
|
|
while (*end) {
|
|
|
|
/* Everything apart from '\0' can be quoted */
|
|
|
|
if (*end == '\\' && *(end + 1)) {
|
|
|
|
*out++ = *(end + 1);
|
|
|
|
end += 2;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (isspace(*end))
|
|
|
|
break; /* end of token */
|
|
|
|
|
|
|
|
*out++ = *end++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* have we already filled the array ? */
|
|
|
|
if ((*argc + 1) > array_size) {
|
|
|
|
argv = realloc_argv(&array_size, argv);
|
|
|
|
if (!argv)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we know this is whitespace */
|
|
|
|
if (*end)
|
|
|
|
end++;
|
|
|
|
|
|
|
|
/* terminate the string and put it in the array */
|
|
|
|
*out = '\0';
|
|
|
|
argv[*argc] = start;
|
|
|
|
(*argc)++;
|
|
|
|
}
|
|
|
|
|
|
|
|
*argvp = argv;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-22 17:12:31 +08:00
|
|
|
/*
|
|
|
|
* Impose necessary and sufficient conditions on a devices's table such
|
|
|
|
* that any incoming bio which respects its logical_block_size can be
|
|
|
|
* processed successfully. If it falls across the boundary between
|
|
|
|
* two or more targets, the size of each piece it gets split into must
|
|
|
|
* be compatible with the logical_block_size of the target processing it.
|
|
|
|
*/
|
2009-06-22 17:12:34 +08:00
|
|
|
static int validate_hardware_logical_block_alignment(struct dm_table *table,
|
|
|
|
struct queue_limits *limits)
|
2009-06-22 17:12:31 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* This function uses arithmetic modulo the logical_block_size
|
|
|
|
* (in units of 512-byte sectors).
|
|
|
|
*/
|
|
|
|
unsigned short device_logical_block_size_sects =
|
2009-06-22 17:12:34 +08:00
|
|
|
limits->logical_block_size >> SECTOR_SHIFT;
|
2009-06-22 17:12:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Offset of the start of the next table entry, mod logical_block_size.
|
|
|
|
*/
|
|
|
|
unsigned short next_target_start = 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Given an aligned bio that extends beyond the end of a
|
|
|
|
* target, how many sectors must the next target handle?
|
|
|
|
*/
|
|
|
|
unsigned short remaining = 0;
|
|
|
|
|
treewide: Remove uninitialized_var() usage
Using uninitialized_var() is dangerous as it papers over real bugs[1]
(or can in the future), and suppresses unrelated compiler warnings
(e.g. "unused variable"). If the compiler thinks it is uninitialized,
either simply initialize the variable or make compiler changes.
In preparation for removing[2] the[3] macro[4], remove all remaining
needless uses with the following script:
git grep '\buninitialized_var\b' | cut -d: -f1 | sort -u | \
xargs perl -pi -e \
's/\buninitialized_var\(([^\)]+)\)/\1/g;
s:\s*/\* (GCC be quiet|to make compiler happy) \*/$::g;'
drivers/video/fbdev/riva/riva_hw.c was manually tweaked to avoid
pathological white-space.
No outstanding warnings were found building allmodconfig with GCC 9.3.0
for x86_64, i386, arm64, arm, powerpc, powerpc64le, s390x, mips, sparc64,
alpha, and m68k.
[1] https://lore.kernel.org/lkml/20200603174714.192027-1-glider@google.com/
[2] https://lore.kernel.org/lkml/CA+55aFw+Vbj0i=1TGqCR5vQkCzWJ0QxK6CernOU6eedsudAixw@mail.gmail.com/
[3] https://lore.kernel.org/lkml/CA+55aFwgbgqhbp1fkxvRKEpzyR5J8n1vKT1VZdz9knmPuXhOeg@mail.gmail.com/
[4] https://lore.kernel.org/lkml/CA+55aFz2500WfbKXAx8s67wrm9=yVJu65TpLgN_ybYNv0VEOKA@mail.gmail.com/
Reviewed-by: Leon Romanovsky <leonro@mellanox.com> # drivers/infiniband and mlx4/mlx5
Acked-by: Jason Gunthorpe <jgg@mellanox.com> # IB
Acked-by: Kalle Valo <kvalo@codeaurora.org> # wireless drivers
Reviewed-by: Chao Yu <yuchao0@huawei.com> # erofs
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-04 04:09:38 +08:00
|
|
|
struct dm_target *ti;
|
2009-06-22 17:12:34 +08:00
|
|
|
struct queue_limits ti_limits;
|
2017-04-19 04:51:46 +08:00
|
|
|
unsigned i;
|
2009-06-22 17:12:31 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Check each entry in the table in turn.
|
|
|
|
*/
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(table); i++) {
|
|
|
|
ti = dm_table_get_target(table, i);
|
2009-06-22 17:12:31 +08:00
|
|
|
|
2012-01-11 23:27:11 +08:00
|
|
|
blk_set_stacking_limits(&ti_limits);
|
2009-06-22 17:12:34 +08:00
|
|
|
|
|
|
|
/* combine all target devices' limits */
|
|
|
|
if (ti->type->iterate_devices)
|
|
|
|
ti->type->iterate_devices(ti, dm_set_device_limits,
|
|
|
|
&ti_limits);
|
|
|
|
|
2009-06-22 17:12:31 +08:00
|
|
|
/*
|
|
|
|
* If the remaining sectors fall entirely within this
|
|
|
|
* table entry are they compatible with its logical_block_size?
|
|
|
|
*/
|
|
|
|
if (remaining < ti->len &&
|
2009-06-22 17:12:34 +08:00
|
|
|
remaining & ((ti_limits.logical_block_size >>
|
2009-06-22 17:12:31 +08:00
|
|
|
SECTOR_SHIFT) - 1))
|
|
|
|
break; /* Error */
|
|
|
|
|
|
|
|
next_target_start =
|
|
|
|
(unsigned short) ((next_target_start + ti->len) &
|
|
|
|
(device_logical_block_size_sects - 1));
|
|
|
|
remaining = next_target_start ?
|
|
|
|
device_logical_block_size_sects - next_target_start : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (remaining) {
|
|
|
|
DMWARN("%s: table line %u (start sect %llu len %llu) "
|
2009-09-05 03:40:24 +08:00
|
|
|
"not aligned to h/w logical block size %u",
|
2009-06-22 17:12:31 +08:00
|
|
|
dm_device_name(table->md), i,
|
|
|
|
(unsigned long long) ti->begin,
|
|
|
|
(unsigned long long) ti->len,
|
2009-06-22 17:12:34 +08:00
|
|
|
limits->logical_block_size);
|
2009-06-22 17:12:31 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
int dm_table_add_target(struct dm_table *t, const char *type,
|
|
|
|
sector_t start, sector_t len, char *params)
|
|
|
|
{
|
|
|
|
int r = -EINVAL, argc;
|
|
|
|
char **argv;
|
|
|
|
struct dm_target *tgt;
|
|
|
|
|
2011-11-01 04:19:00 +08:00
|
|
|
if (t->singleton) {
|
|
|
|
DMERR("%s: target type %s must appear alone in table",
|
|
|
|
dm_device_name(t->md), t->targets->type->name);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
dm table: remove unused buggy code that extends the targets array
A device mapper table is allocated in the following way:
* The function dm_table_create is called, it gets the number of targets
as an argument -- it allocates a targets array accordingly.
* For each target, we call dm_table_add_target.
If we add more targets than were specified in dm_table_create, the
function dm_table_add_target reallocates the targets array. However,
this reallocation code is wrong - it moves the targets array to a new
location, while some target constructors hold pointers to the array in
the old location.
The following DM target drivers save the pointer to the target
structure, so they corrupt memory if the target array is moved:
multipath, raid, mirror, snapshot, stripe, switch, thin, verity.
Under normal circumstances, the reallocation function is not called
(because dm_table_create is called with the correct number of targets),
so the buggy reallocation code is not used.
Prior to the fix "dm table: fail dm_table_create on dm_round_up
overflow", the reallocation code could only be used in case the user
specifies too large a value in param->target_count, such as 0xffffffff.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2013-11-23 08:51:39 +08:00
|
|
|
BUG_ON(t->num_targets >= t->num_allocated);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
tgt = t->targets + t->num_targets;
|
|
|
|
memset(tgt, 0, sizeof(*tgt));
|
|
|
|
|
|
|
|
if (!len) {
|
2006-06-26 15:27:35 +08:00
|
|
|
DMERR("%s: zero-length target", dm_device_name(t->md));
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
tgt->type = dm_get_target_type(type);
|
|
|
|
if (!tgt->type) {
|
2016-10-21 09:35:32 +08:00
|
|
|
DMERR("%s: %s: unknown target type", dm_device_name(t->md), type);
|
2005-04-17 06:20:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2011-11-01 04:19:00 +08:00
|
|
|
if (dm_target_needs_singleton(tgt->type)) {
|
|
|
|
if (t->num_targets) {
|
2016-10-21 09:35:32 +08:00
|
|
|
tgt->error = "singleton target type must appear alone in table";
|
|
|
|
goto bad;
|
2011-11-01 04:19:00 +08:00
|
|
|
}
|
2016-05-25 09:16:51 +08:00
|
|
|
t->singleton = true;
|
2011-11-01 04:19:00 +08:00
|
|
|
}
|
|
|
|
|
2011-11-01 04:19:02 +08:00
|
|
|
if (dm_target_always_writeable(tgt->type) && !(t->mode & FMODE_WRITE)) {
|
2016-10-21 09:35:32 +08:00
|
|
|
tgt->error = "target type may not be included in a read-only table";
|
|
|
|
goto bad;
|
2011-11-01 04:19:02 +08:00
|
|
|
}
|
|
|
|
|
2011-11-01 04:19:04 +08:00
|
|
|
if (t->immutable_target_type) {
|
|
|
|
if (t->immutable_target_type != tgt->type) {
|
2016-10-21 09:35:32 +08:00
|
|
|
tgt->error = "immutable target type cannot be mixed with other target types";
|
|
|
|
goto bad;
|
2011-11-01 04:19:04 +08:00
|
|
|
}
|
|
|
|
} else if (dm_target_is_immutable(tgt->type)) {
|
|
|
|
if (t->num_targets) {
|
2016-10-21 09:35:32 +08:00
|
|
|
tgt->error = "immutable target type cannot be mixed with other target types";
|
|
|
|
goto bad;
|
2011-11-01 04:19:04 +08:00
|
|
|
}
|
|
|
|
t->immutable_target_type = tgt->type;
|
|
|
|
}
|
|
|
|
|
2017-01-05 03:23:51 +08:00
|
|
|
if (dm_target_has_integrity(tgt->type))
|
|
|
|
t->integrity_added = 1;
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
tgt->table = t;
|
|
|
|
tgt->begin = start;
|
|
|
|
tgt->len = len;
|
|
|
|
tgt->error = "Unknown error";
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Does this target adjoin the previous one ?
|
|
|
|
*/
|
|
|
|
if (!adjoin(t, tgt)) {
|
|
|
|
tgt->error = "Gap in table";
|
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
r = dm_split_args(&argc, &argv, params);
|
|
|
|
if (r) {
|
2021-10-22 05:13:27 +08:00
|
|
|
tgt->error = "couldn't split parameters";
|
2005-04-17 06:20:36 +08:00
|
|
|
goto bad;
|
|
|
|
}
|
|
|
|
|
|
|
|
r = tgt->type->ctr(tgt, argc, argv);
|
|
|
|
kfree(argv);
|
|
|
|
if (r)
|
|
|
|
goto bad;
|
|
|
|
|
|
|
|
t->highs[t->num_targets++] = tgt->begin + tgt->len - 1;
|
|
|
|
|
2013-03-02 06:45:47 +08:00
|
|
|
if (!tgt->num_discard_bios && tgt->discards_supported)
|
|
|
|
DMWARN("%s: %s: ignoring discards_supported because num_discard_bios is zero.",
|
2011-08-02 19:32:01 +08:00
|
|
|
dm_device_name(t->md), type);
|
2010-08-12 11:14:08 +08:00
|
|
|
|
2022-03-27 02:14:00 +08:00
|
|
|
if (tgt->limit_swap_bios && !static_key_enabled(&swap_bios_enabled.key))
|
|
|
|
static_branch_enable(&swap_bios_enabled);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
bad:
|
2021-10-22 05:13:27 +08:00
|
|
|
DMERR("%s: %s: %s (%pe)", dm_device_name(t->md), type, tgt->error, ERR_PTR(r));
|
2005-04-17 06:20:36 +08:00
|
|
|
dm_put_target_type(tgt->type);
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2011-08-02 19:32:04 +08:00
|
|
|
/*
|
|
|
|
* Target argument parsing helpers.
|
|
|
|
*/
|
2017-06-23 02:32:45 +08:00
|
|
|
static int validate_next_arg(const struct dm_arg *arg,
|
|
|
|
struct dm_arg_set *arg_set,
|
2011-08-02 19:32:04 +08:00
|
|
|
unsigned *value, char **error, unsigned grouped)
|
|
|
|
{
|
|
|
|
const char *arg_str = dm_shift_arg(arg_set);
|
dm: reject trailing characters in sccanf input
Device mapper uses sscanf to convert arguments to numbers. The problem is that
the way we use it ignores additional unmatched characters in the scanned string.
For example, this `if (sscanf(string, "%d", &number) == 1)' will match a number,
but also it will match number with some garbage appended, like "123abc".
As a result, device mapper accepts garbage after some numbers. For example
the command `dmsetup create vg1-new --table "0 16384 linear 254:1bla 34816bla"'
will pass without an error.
This patch fixes all sscanf uses in device mapper. It appends "%c" with
a pointer to a dummy character variable to every sscanf statement.
The construct `if (sscanf(string, "%d%c", &number, &dummy) == 1)' succeeds
only if string is a null-terminated number (optionally preceded by some
whitespace characters). If there is some character appended after the number,
sscanf matches "%c", writes the character to the dummy variable and returns 2.
We check the return value for 1 and consequently reject numbers with some
garbage appended.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-03-29 01:41:26 +08:00
|
|
|
char dummy;
|
2011-08-02 19:32:04 +08:00
|
|
|
|
|
|
|
if (!arg_str ||
|
dm: reject trailing characters in sccanf input
Device mapper uses sscanf to convert arguments to numbers. The problem is that
the way we use it ignores additional unmatched characters in the scanned string.
For example, this `if (sscanf(string, "%d", &number) == 1)' will match a number,
but also it will match number with some garbage appended, like "123abc".
As a result, device mapper accepts garbage after some numbers. For example
the command `dmsetup create vg1-new --table "0 16384 linear 254:1bla 34816bla"'
will pass without an error.
This patch fixes all sscanf uses in device mapper. It appends "%c" with
a pointer to a dummy character variable to every sscanf statement.
The construct `if (sscanf(string, "%d%c", &number, &dummy) == 1)' succeeds
only if string is a null-terminated number (optionally preceded by some
whitespace characters). If there is some character appended after the number,
sscanf matches "%c", writes the character to the dummy variable and returns 2.
We check the return value for 1 and consequently reject numbers with some
garbage appended.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2012-03-29 01:41:26 +08:00
|
|
|
(sscanf(arg_str, "%u%c", value, &dummy) != 1) ||
|
2011-08-02 19:32:04 +08:00
|
|
|
(*value < arg->min) ||
|
|
|
|
(*value > arg->max) ||
|
|
|
|
(grouped && arg_set->argc < *value)) {
|
|
|
|
*error = arg->error;
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-06-23 02:32:45 +08:00
|
|
|
int dm_read_arg(const struct dm_arg *arg, struct dm_arg_set *arg_set,
|
2011-08-02 19:32:04 +08:00
|
|
|
unsigned *value, char **error)
|
|
|
|
{
|
|
|
|
return validate_next_arg(arg, arg_set, value, error, 0);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_read_arg);
|
|
|
|
|
2017-06-23 02:32:45 +08:00
|
|
|
int dm_read_arg_group(const struct dm_arg *arg, struct dm_arg_set *arg_set,
|
2011-08-02 19:32:04 +08:00
|
|
|
unsigned *value, char **error)
|
|
|
|
{
|
|
|
|
return validate_next_arg(arg, arg_set, value, error, 1);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_read_arg_group);
|
|
|
|
|
|
|
|
const char *dm_shift_arg(struct dm_arg_set *as)
|
|
|
|
{
|
|
|
|
char *r;
|
|
|
|
|
|
|
|
if (as->argc) {
|
|
|
|
as->argc--;
|
|
|
|
r = *as->argv;
|
|
|
|
as->argv++;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_shift_arg);
|
|
|
|
|
|
|
|
void dm_consume_args(struct dm_arg_set *as, unsigned num_args)
|
|
|
|
{
|
|
|
|
BUG_ON(as->argc < num_args);
|
|
|
|
as->argc -= num_args;
|
|
|
|
as->argv += num_args;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_consume_args);
|
|
|
|
|
2017-04-28 01:11:23 +08:00
|
|
|
static bool __table_type_bio_based(enum dm_queue_mode table_type)
|
2016-06-23 07:54:53 +08:00
|
|
|
{
|
|
|
|
return (table_type == DM_TYPE_BIO_BASED ||
|
2020-10-08 03:15:08 +08:00
|
|
|
table_type == DM_TYPE_DAX_BIO_BASED);
|
2016-06-23 07:54:53 +08:00
|
|
|
}
|
|
|
|
|
2017-04-28 01:11:23 +08:00
|
|
|
static bool __table_type_request_based(enum dm_queue_mode table_type)
|
2015-05-29 16:51:03 +08:00
|
|
|
{
|
2018-10-11 23:06:29 +08:00
|
|
|
return table_type == DM_TYPE_REQUEST_BASED;
|
2015-05-29 16:51:03 +08:00
|
|
|
}
|
|
|
|
|
2017-04-28 01:11:23 +08:00
|
|
|
void dm_table_set_type(struct dm_table *t, enum dm_queue_mode type)
|
2016-05-25 09:16:51 +08:00
|
|
|
{
|
|
|
|
t->type = type;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dm_table_set_type);
|
|
|
|
|
2019-05-17 04:26:29 +08:00
|
|
|
/* validate the dax capability of the target device span */
|
2021-11-29 18:21:42 +08:00
|
|
|
static int device_not_dax_capable(struct dm_target *ti, struct dm_dev *dev,
|
2019-07-31 02:39:43 +08:00
|
|
|
sector_t start, sector_t len, void *data)
|
2016-06-23 07:54:53 +08:00
|
|
|
{
|
2021-11-29 18:21:42 +08:00
|
|
|
if (dev->dax_dev)
|
|
|
|
return false;
|
2019-05-17 04:26:29 +08:00
|
|
|
|
2021-11-29 18:21:42 +08:00
|
|
|
DMDEBUG("%pg: error: dax unsupported by block device", dev->bdev);
|
|
|
|
return true;
|
2016-06-23 07:54:53 +08:00
|
|
|
}
|
|
|
|
|
2019-07-05 22:03:25 +08:00
|
|
|
/* Check devices support synchronous DAX */
|
2021-02-09 11:34:36 +08:00
|
|
|
static int device_not_dax_synchronous_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2019-07-05 22:03:25 +08:00
|
|
|
{
|
2021-02-09 11:34:36 +08:00
|
|
|
return !dev->dax_dev || !dax_synchronous(dev->dax_dev);
|
2019-07-05 22:03:25 +08:00
|
|
|
}
|
|
|
|
|
2021-11-29 18:21:42 +08:00
|
|
|
static bool dm_table_supports_dax(struct dm_table *t,
|
|
|
|
iterate_devices_callout_fn iterate_fn)
|
2016-06-23 07:54:53 +08:00
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
2017-04-19 04:51:46 +08:00
|
|
|
unsigned i;
|
2016-06-23 07:54:53 +08:00
|
|
|
|
|
|
|
/* Ensure that all targets support DAX. */
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
2016-06-23 07:54:53 +08:00
|
|
|
|
|
|
|
if (!ti->type->direct_access)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!ti->type->iterate_devices ||
|
2021-11-29 18:21:42 +08:00
|
|
|
ti->type->iterate_devices(ti, iterate_fn, NULL))
|
2016-06-23 07:54:53 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-11-05 23:43:44 +08:00
|
|
|
static int device_is_rq_stackable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2018-01-14 03:33:30 +08:00
|
|
|
{
|
2019-11-05 23:43:44 +08:00
|
|
|
struct block_device *bdev = dev->bdev;
|
|
|
|
struct request_queue *q = bdev_get_queue(bdev);
|
2018-01-14 03:33:30 +08:00
|
|
|
|
2019-11-05 23:43:44 +08:00
|
|
|
/* request-based cannot stack on partitions! */
|
2020-09-03 13:40:57 +08:00
|
|
|
if (bdev_is_partition(bdev))
|
2019-11-05 23:43:44 +08:00
|
|
|
return false;
|
2018-01-14 03:33:30 +08:00
|
|
|
|
2018-11-16 03:22:51 +08:00
|
|
|
return queue_is_mq(q);
|
2018-01-14 03:33:30 +08:00
|
|
|
}
|
|
|
|
|
2016-05-25 09:16:51 +08:00
|
|
|
static int dm_table_determine_type(struct dm_table *t)
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
{
|
|
|
|
unsigned i;
|
2013-08-23 06:21:38 +08:00
|
|
|
unsigned bio_based = 0, request_based = 0, hybrid = 0;
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
struct dm_target *tgt;
|
2016-05-25 09:16:51 +08:00
|
|
|
struct list_head *devices = dm_table_get_devices(t);
|
2017-04-28 01:11:23 +08:00
|
|
|
enum dm_queue_mode live_md_type = dm_get_md_type(t->md);
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
|
2016-05-25 09:16:51 +08:00
|
|
|
if (t->type != DM_TYPE_NONE) {
|
|
|
|
/* target already set the table's type */
|
2018-03-06 04:26:06 +08:00
|
|
|
if (t->type == DM_TYPE_BIO_BASED) {
|
|
|
|
/* possibly upgrade to a variant of bio-based */
|
|
|
|
goto verify_bio_based;
|
2017-12-05 10:07:37 +08:00
|
|
|
}
|
2016-06-23 07:54:53 +08:00
|
|
|
BUG_ON(t->type == DM_TYPE_DAX_BIO_BASED);
|
2016-05-25 09:16:51 +08:00
|
|
|
goto verify_rq_based;
|
|
|
|
}
|
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
for (i = 0; i < t->num_targets; i++) {
|
|
|
|
tgt = t->targets + i;
|
2013-08-23 06:21:38 +08:00
|
|
|
if (dm_target_hybrid(tgt))
|
|
|
|
hybrid = 1;
|
|
|
|
else if (dm_target_request_based(tgt))
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
request_based = 1;
|
|
|
|
else
|
|
|
|
bio_based = 1;
|
|
|
|
|
|
|
|
if (bio_based && request_based) {
|
2017-12-05 10:07:37 +08:00
|
|
|
DMERR("Inconsistent table: different target types"
|
|
|
|
" can't be mixed up");
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-23 06:21:38 +08:00
|
|
|
if (hybrid && !bio_based && !request_based) {
|
|
|
|
/*
|
|
|
|
* The targets can work either way.
|
|
|
|
* Determine the type from the live device.
|
|
|
|
* Default to bio-based if device is new.
|
|
|
|
*/
|
2015-05-29 16:51:03 +08:00
|
|
|
if (__table_type_request_based(live_md_type))
|
2013-08-23 06:21:38 +08:00
|
|
|
request_based = 1;
|
|
|
|
else
|
|
|
|
bio_based = 1;
|
|
|
|
}
|
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
if (bio_based) {
|
2018-03-06 04:26:06 +08:00
|
|
|
verify_bio_based:
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
/* We must use this table as bio-based */
|
|
|
|
t->type = DM_TYPE_BIO_BASED;
|
2021-11-29 18:21:42 +08:00
|
|
|
if (dm_table_supports_dax(t, device_not_dax_capable) ||
|
2017-12-05 10:07:37 +08:00
|
|
|
(list_empty(devices) && live_md_type == DM_TYPE_DAX_BIO_BASED)) {
|
2016-06-23 07:54:53 +08:00
|
|
|
t->type = DM_TYPE_DAX_BIO_BASED;
|
2017-12-05 10:07:37 +08:00
|
|
|
}
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
BUG_ON(!request_based); /* No targets in this table */
|
|
|
|
|
2016-05-25 09:16:51 +08:00
|
|
|
t->type = DM_TYPE_REQUEST_BASED;
|
|
|
|
|
|
|
|
verify_rq_based:
|
2014-12-19 05:26:47 +08:00
|
|
|
/*
|
|
|
|
* Request-based dm supports only tables that have a single target now.
|
|
|
|
* To support multiple targets, request splitting support is needed,
|
|
|
|
* and that needs lots of changes in the block-layer.
|
|
|
|
* (e.g. request completion process for partial completion.)
|
|
|
|
*/
|
|
|
|
if (t->num_targets > 1) {
|
2020-10-08 03:15:08 +08:00
|
|
|
DMERR("request-based DM doesn't support multiple targets");
|
2014-12-19 05:26:47 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2016-11-24 02:51:09 +08:00
|
|
|
if (list_empty(devices)) {
|
|
|
|
int srcu_idx;
|
|
|
|
struct dm_table *live_table = dm_get_live_table(t->md, &srcu_idx);
|
|
|
|
|
2018-10-11 10:49:26 +08:00
|
|
|
/* inherit live table's type */
|
|
|
|
if (live_table)
|
2016-11-24 02:51:09 +08:00
|
|
|
t->type = live_table->type;
|
|
|
|
dm_put_live_table(t->md, srcu_idx);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-12-05 10:07:37 +08:00
|
|
|
tgt = dm_table_get_immutable_target(t);
|
|
|
|
if (!tgt) {
|
|
|
|
DMERR("table load rejected: immutable target is required");
|
|
|
|
return -EINVAL;
|
|
|
|
} else if (tgt->max_io_len) {
|
|
|
|
DMERR("table load rejected: immutable target that splits IO is not supported");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
/* Non-request-stackable devices can't be used for request-based dm */
|
2018-01-14 03:33:30 +08:00
|
|
|
if (!tgt->type->iterate_devices ||
|
2019-11-05 23:43:44 +08:00
|
|
|
!tgt->type->iterate_devices(tgt, device_is_rq_stackable, NULL)) {
|
2018-01-14 03:33:30 +08:00
|
|
|
DMERR("table load rejected: including non-request-stackable devices");
|
|
|
|
return -EINVAL;
|
2014-12-18 10:08:12 +08:00
|
|
|
}
|
2016-12-08 08:56:06 +08:00
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-04-28 01:11:23 +08:00
|
|
|
enum dm_queue_mode dm_table_get_type(struct dm_table *t)
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
{
|
|
|
|
return t->type;
|
|
|
|
}
|
|
|
|
|
2011-11-01 04:19:04 +08:00
|
|
|
struct target_type *dm_table_get_immutable_target_type(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return t->immutable_target_type;
|
|
|
|
}
|
|
|
|
|
2016-02-01 06:22:27 +08:00
|
|
|
struct dm_target *dm_table_get_immutable_target(struct dm_table *t)
|
|
|
|
{
|
|
|
|
/* Immutable target is implicitly a singleton */
|
|
|
|
if (t->num_targets > 1 ||
|
|
|
|
!dm_target_is_immutable(t->targets[0].type))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return t->targets;
|
|
|
|
}
|
|
|
|
|
2016-02-07 07:38:46 +08:00
|
|
|
struct dm_target *dm_table_get_wildcard_target(struct dm_table *t)
|
|
|
|
{
|
2017-04-19 04:51:46 +08:00
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i;
|
2016-02-07 07:38:46 +08:00
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
2016-02-07 07:38:46 +08:00
|
|
|
if (dm_target_is_wildcard(ti->type))
|
|
|
|
return ti;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2016-06-23 07:54:53 +08:00
|
|
|
bool dm_table_bio_based(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return __table_type_bio_based(dm_table_get_type(t));
|
|
|
|
}
|
|
|
|
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
bool dm_table_request_based(struct dm_table *t)
|
|
|
|
{
|
2015-05-29 16:51:03 +08:00
|
|
|
return __table_type_request_based(dm_table_get_type(t));
|
2014-12-18 10:08:12 +08:00
|
|
|
}
|
|
|
|
|
2022-06-01 00:16:49 +08:00
|
|
|
static bool dm_table_supports_poll(struct dm_table *t);
|
2022-03-25 02:36:47 +08:00
|
|
|
|
2015-03-12 03:01:09 +08:00
|
|
|
static int dm_table_alloc_md_mempools(struct dm_table *t, struct mapped_device *md)
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
{
|
2017-04-28 01:11:23 +08:00
|
|
|
enum dm_queue_mode type = dm_table_get_type(t);
|
2016-02-01 02:28:26 +08:00
|
|
|
unsigned per_io_data_size = 0;
|
2017-12-09 03:40:52 +08:00
|
|
|
unsigned min_pool_size = 0;
|
|
|
|
struct dm_target *ti;
|
2012-12-22 04:23:38 +08:00
|
|
|
unsigned i;
|
2022-03-25 02:36:47 +08:00
|
|
|
bool poll_supported = false;
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
|
2015-06-26 22:01:13 +08:00
|
|
|
if (unlikely(type == DM_TYPE_NONE)) {
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
DMWARN("no table type is set, can't allocate mempools");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2022-03-25 02:36:47 +08:00
|
|
|
if (__table_type_bio_based(type)) {
|
2015-06-26 22:01:13 +08:00
|
|
|
for (i = 0; i < t->num_targets; i++) {
|
2017-12-09 03:40:52 +08:00
|
|
|
ti = t->targets + i;
|
|
|
|
per_io_data_size = max(per_io_data_size, ti->per_io_data_size);
|
|
|
|
min_pool_size = max(min_pool_size, ti->num_flush_bios);
|
2015-06-26 22:01:13 +08:00
|
|
|
}
|
2022-06-01 00:16:49 +08:00
|
|
|
poll_supported = dm_table_supports_poll(t);
|
2022-03-25 02:36:47 +08:00
|
|
|
}
|
2015-06-26 22:01:13 +08:00
|
|
|
|
2022-03-25 02:36:47 +08:00
|
|
|
t->mempools = dm_alloc_md_mempools(md, type, per_io_data_size, min_pool_size,
|
|
|
|
t->integrity_supported, poll_supported);
|
2015-06-26 21:42:57 +08:00
|
|
|
if (!t->mempools)
|
|
|
|
return -ENOMEM;
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static int setup_indexes(struct dm_table *t)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
unsigned int total = 0;
|
|
|
|
sector_t *indexes;
|
|
|
|
|
|
|
|
/* allocate the space for *all* the indexes */
|
|
|
|
for (i = t->depth - 2; i >= 0; i--) {
|
|
|
|
t->counts[i] = dm_div_up(t->counts[i + 1], CHILDREN_PER_NODE);
|
|
|
|
total += t->counts[i];
|
|
|
|
}
|
|
|
|
|
2021-04-07 21:25:22 +08:00
|
|
|
indexes = kvcalloc(total, NODE_SIZE, GFP_KERNEL);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (!indexes)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* set up internal nodes, bottom-up */
|
2008-02-08 10:10:04 +08:00
|
|
|
for (i = t->depth - 2; i >= 0; i--) {
|
2005-04-17 06:20:36 +08:00
|
|
|
t->index[i] = indexes;
|
|
|
|
indexes += (KEYS_PER_NODE * t->counts[i]);
|
|
|
|
setup_btree_index(i, t);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Builds the btree to index the map.
|
|
|
|
*/
|
2010-08-12 11:14:03 +08:00
|
|
|
static int dm_table_build_index(struct dm_table *t)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int r = 0;
|
|
|
|
unsigned int leaf_nodes;
|
|
|
|
|
|
|
|
/* how many indexes will the btree have ? */
|
|
|
|
leaf_nodes = dm_div_up(t->num_targets, KEYS_PER_NODE);
|
|
|
|
t->depth = 1 + int_log(leaf_nodes, CHILDREN_PER_NODE);
|
|
|
|
|
|
|
|
/* leaf layer has already been set up */
|
|
|
|
t->counts[t->depth - 1] = leaf_nodes;
|
|
|
|
t->index[t->depth - 1] = t->highs;
|
|
|
|
|
|
|
|
if (t->depth >= 2)
|
|
|
|
r = setup_indexes(t);
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
static bool integrity_profile_exists(struct gendisk *disk)
|
|
|
|
{
|
|
|
|
return !!blk_get_integrity(disk);
|
|
|
|
}
|
|
|
|
|
2011-04-02 03:02:31 +08:00
|
|
|
/*
|
|
|
|
* Get a disk whose integrity profile reflects the table's profile.
|
|
|
|
* Returns NULL if integrity support was inconsistent or unavailable.
|
|
|
|
*/
|
2015-10-22 01:19:49 +08:00
|
|
|
static struct gendisk * dm_table_get_integrity_disk(struct dm_table *t)
|
2011-04-02 03:02:31 +08:00
|
|
|
{
|
|
|
|
struct list_head *devices = dm_table_get_devices(t);
|
|
|
|
struct dm_dev_internal *dd = NULL;
|
|
|
|
struct gendisk *prev_disk = NULL, *template_disk = NULL;
|
2017-04-19 04:51:48 +08:00
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
struct dm_target *ti = dm_table_get_target(t, i);
|
|
|
|
if (!dm_target_passes_integrity(ti->type))
|
|
|
|
goto no_integrity;
|
|
|
|
}
|
2011-04-02 03:02:31 +08:00
|
|
|
|
|
|
|
list_for_each_entry(dd, devices, list) {
|
2014-08-14 02:53:43 +08:00
|
|
|
template_disk = dd->dm_dev->bdev->bd_disk;
|
2015-10-22 01:19:49 +08:00
|
|
|
if (!integrity_profile_exists(template_disk))
|
2011-04-02 03:02:31 +08:00
|
|
|
goto no_integrity;
|
|
|
|
else if (prev_disk &&
|
|
|
|
blk_integrity_compare(prev_disk, template_disk) < 0)
|
|
|
|
goto no_integrity;
|
|
|
|
prev_disk = template_disk;
|
|
|
|
}
|
|
|
|
|
|
|
|
return template_disk;
|
|
|
|
|
|
|
|
no_integrity:
|
|
|
|
if (prev_disk)
|
|
|
|
DMWARN("%s: integrity not set: %s and %s profile mismatch",
|
|
|
|
dm_device_name(t->md),
|
|
|
|
prev_disk->disk_name,
|
|
|
|
template_disk->disk_name);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2010-08-12 11:14:03 +08:00
|
|
|
/*
|
2015-10-22 01:19:49 +08:00
|
|
|
* Register the mapped device for blk_integrity support if the
|
|
|
|
* underlying devices have an integrity profile. But all devices may
|
|
|
|
* not have matching profiles (checking all devices isn't reliable
|
2011-04-02 03:02:31 +08:00
|
|
|
* during table load because this table may use other DM device(s) which
|
2015-10-22 01:19:49 +08:00
|
|
|
* must be resumed before they will have an initialized integity
|
|
|
|
* profile). Consequently, stacked DM devices force a 2 stage integrity
|
|
|
|
* profile validation: First pass during table load, final pass during
|
|
|
|
* resume.
|
2010-08-12 11:14:03 +08:00
|
|
|
*/
|
2015-10-22 01:19:49 +08:00
|
|
|
static int dm_table_register_integrity(struct dm_table *t)
|
2010-08-12 11:14:03 +08:00
|
|
|
{
|
2015-10-22 01:19:49 +08:00
|
|
|
struct mapped_device *md = t->md;
|
2011-04-02 03:02:31 +08:00
|
|
|
struct gendisk *template_disk = NULL;
|
2010-08-12 11:14:03 +08:00
|
|
|
|
2017-01-05 03:23:51 +08:00
|
|
|
/* If target handles integrity itself do not register it here. */
|
|
|
|
if (t->integrity_added)
|
|
|
|
return 0;
|
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
template_disk = dm_table_get_integrity_disk(t);
|
2011-04-02 03:02:31 +08:00
|
|
|
if (!template_disk)
|
|
|
|
return 0;
|
2010-08-12 11:14:03 +08:00
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
if (!integrity_profile_exists(dm_disk(md))) {
|
2016-05-25 09:16:51 +08:00
|
|
|
t->integrity_supported = true;
|
2015-10-22 01:19:49 +08:00
|
|
|
/*
|
|
|
|
* Register integrity profile during table load; we can do
|
|
|
|
* this because the final profile must match during resume.
|
|
|
|
*/
|
|
|
|
blk_integrity_register(dm_disk(md),
|
|
|
|
blk_get_integrity(template_disk));
|
|
|
|
return 0;
|
2011-04-02 03:02:31 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2015-10-22 01:19:49 +08:00
|
|
|
* If DM device already has an initialized integrity
|
2011-04-02 03:02:31 +08:00
|
|
|
* profile the new profile should not conflict.
|
|
|
|
*/
|
2015-10-22 01:19:49 +08:00
|
|
|
if (blk_integrity_compare(dm_disk(md), template_disk) < 0) {
|
2011-04-02 03:02:31 +08:00
|
|
|
DMWARN("%s: conflict with existing integrity profile: "
|
|
|
|
"%s profile mismatch",
|
|
|
|
dm_device_name(t->md),
|
|
|
|
template_disk->disk_name);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
/* Preserve existing integrity profile */
|
2016-05-25 09:16:51 +08:00
|
|
|
t->integrity_supported = true;
|
2010-08-12 11:14:03 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2021-02-01 13:10:17 +08:00
|
|
|
#ifdef CONFIG_BLK_INLINE_ENCRYPTION
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
struct dm_crypto_profile {
|
|
|
|
struct blk_crypto_profile profile;
|
2021-02-01 13:10:17 +08:00
|
|
|
struct mapped_device *md;
|
|
|
|
};
|
|
|
|
|
2021-02-01 13:10:18 +08:00
|
|
|
struct dm_keyslot_evict_args {
|
|
|
|
const struct blk_crypto_key *key;
|
|
|
|
int err;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int dm_keyslot_evict_callback(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct dm_keyslot_evict_args *args = data;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = blk_crypto_evict_key(bdev_get_queue(dev->bdev), args->key);
|
|
|
|
if (!args->err)
|
|
|
|
args->err = err;
|
|
|
|
/* Always try to evict the key from all devices. */
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When an inline encryption key is evicted from a device-mapper device, evict
|
|
|
|
* it from all the underlying devices.
|
|
|
|
*/
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static int dm_keyslot_evict(struct blk_crypto_profile *profile,
|
2021-02-01 13:10:18 +08:00
|
|
|
const struct blk_crypto_key *key, unsigned int slot)
|
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
struct mapped_device *md =
|
|
|
|
container_of(profile, struct dm_crypto_profile, profile)->md;
|
2021-02-01 13:10:18 +08:00
|
|
|
struct dm_keyslot_evict_args args = { key };
|
|
|
|
struct dm_table *t;
|
|
|
|
int srcu_idx;
|
|
|
|
int i;
|
|
|
|
struct dm_target *ti;
|
|
|
|
|
|
|
|
t = dm_get_live_table(md, &srcu_idx);
|
|
|
|
if (!t)
|
|
|
|
return 0;
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
|
|
|
if (!ti->type->iterate_devices)
|
|
|
|
continue;
|
|
|
|
ti->type->iterate_devices(ti, dm_keyslot_evict_callback, &args);
|
|
|
|
}
|
|
|
|
dm_put_live_table(md, srcu_idx);
|
|
|
|
return args.err;
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static int
|
|
|
|
device_intersect_crypto_capabilities(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
struct blk_crypto_profile *parent = data;
|
|
|
|
struct blk_crypto_profile *child =
|
|
|
|
bdev_get_queue(dev->bdev)->crypto_profile;
|
2021-02-01 13:10:17 +08:00
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
blk_crypto_intersect_capabilities(parent, child);
|
2021-02-01 13:10:17 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
void dm_destroy_crypto_profile(struct blk_crypto_profile *profile)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
struct dm_crypto_profile *dmcp = container_of(profile,
|
|
|
|
struct dm_crypto_profile,
|
|
|
|
profile);
|
2021-02-01 13:10:17 +08:00
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
if (!profile)
|
2021-02-01 13:10:17 +08:00
|
|
|
return;
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
blk_crypto_profile_destroy(profile);
|
|
|
|
kfree(dmcp);
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static void dm_table_destroy_crypto_profile(struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dm_destroy_crypto_profile(t->crypto_profile);
|
|
|
|
t->crypto_profile = NULL;
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
* Constructs and initializes t->crypto_profile with a crypto profile that
|
|
|
|
* represents the common set of crypto capabilities of the devices described by
|
|
|
|
* the dm_table. However, if the constructed crypto profile doesn't support all
|
|
|
|
* crypto capabilities that are supported by the current mapped_device, it
|
|
|
|
* returns an error instead, since we don't support removing crypto capabilities
|
|
|
|
* on table changes. Finally, if the constructed crypto profile is "empty" (has
|
|
|
|
* no crypto capabilities at all), it just sets t->crypto_profile to NULL.
|
2021-02-01 13:10:17 +08:00
|
|
|
*/
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static int dm_table_construct_crypto_profile(struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
struct dm_crypto_profile *dmcp;
|
|
|
|
struct blk_crypto_profile *profile;
|
2021-02-01 13:10:17 +08:00
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned int i;
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
bool empty_profile = true;
|
2021-02-01 13:10:17 +08:00
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dmcp = kmalloc(sizeof(*dmcp), GFP_KERNEL);
|
|
|
|
if (!dmcp)
|
2021-02-01 13:10:17 +08:00
|
|
|
return -ENOMEM;
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dmcp->md = t->md;
|
2021-02-01 13:10:17 +08:00
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
profile = &dmcp->profile;
|
|
|
|
blk_crypto_profile_init(profile, 0);
|
|
|
|
profile->ll_ops.keyslot_evict = dm_keyslot_evict;
|
|
|
|
profile->max_dun_bytes_supported = UINT_MAX;
|
|
|
|
memset(profile->modes_supported, 0xFF,
|
|
|
|
sizeof(profile->modes_supported));
|
2021-02-01 13:10:17 +08:00
|
|
|
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
|
|
|
|
|
|
|
if (!dm_target_passes_crypto(ti->type)) {
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
blk_crypto_intersect_capabilities(profile, NULL);
|
2021-02-01 13:10:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
if (!ti->type->iterate_devices)
|
|
|
|
continue;
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
ti->type->iterate_devices(ti,
|
|
|
|
device_intersect_crypto_capabilities,
|
|
|
|
profile);
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
if (t->md->queue &&
|
|
|
|
!blk_crypto_has_capabilities(profile,
|
|
|
|
t->md->queue->crypto_profile)) {
|
2021-02-01 13:10:17 +08:00
|
|
|
DMWARN("Inline encryption capabilities of new DM table were more restrictive than the old table's. This is not supported!");
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dm_destroy_crypto_profile(profile);
|
2021-02-01 13:10:17 +08:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
* If the new profile doesn't actually support any crypto capabilities,
|
|
|
|
* we may as well represent it with a NULL profile.
|
2021-02-01 13:10:17 +08:00
|
|
|
*/
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(profile->modes_supported); i++) {
|
|
|
|
if (profile->modes_supported[i]) {
|
|
|
|
empty_profile = false;
|
2021-02-01 13:10:17 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
if (empty_profile) {
|
|
|
|
dm_destroy_crypto_profile(profile);
|
|
|
|
profile = NULL;
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
* t->crypto_profile is only set temporarily while the table is being
|
|
|
|
* set up, and it gets set to NULL after the profile has been
|
|
|
|
* transferred to the request_queue.
|
2021-02-01 13:10:17 +08:00
|
|
|
*/
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
t->crypto_profile = profile;
|
2021-02-01 13:10:17 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static void dm_update_crypto_profile(struct request_queue *q,
|
|
|
|
struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
if (!t->crypto_profile)
|
2021-02-01 13:10:17 +08:00
|
|
|
return;
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
/* Make the crypto profile less restrictive. */
|
|
|
|
if (!q->crypto_profile) {
|
|
|
|
blk_crypto_register(t->crypto_profile, q);
|
2021-02-01 13:10:17 +08:00
|
|
|
} else {
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
blk_crypto_update_capabilities(q->crypto_profile,
|
|
|
|
t->crypto_profile);
|
|
|
|
dm_destroy_crypto_profile(t->crypto_profile);
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
t->crypto_profile = NULL;
|
2021-02-01 13:10:17 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
#else /* CONFIG_BLK_INLINE_ENCRYPTION */
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static int dm_table_construct_crypto_profile(struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
void dm_destroy_crypto_profile(struct blk_crypto_profile *profile)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static void dm_table_destroy_crypto_profile(struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
static void dm_update_crypto_profile(struct request_queue *q,
|
|
|
|
struct dm_table *t)
|
2021-02-01 13:10:17 +08:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif /* !CONFIG_BLK_INLINE_ENCRYPTION */
|
|
|
|
|
2010-08-12 11:14:03 +08:00
|
|
|
/*
|
|
|
|
* Prepares the table for use by building the indices,
|
|
|
|
* setting the type, and allocating mempools.
|
|
|
|
*/
|
|
|
|
int dm_table_complete(struct dm_table *t)
|
|
|
|
{
|
|
|
|
int r;
|
|
|
|
|
2016-05-25 09:16:51 +08:00
|
|
|
r = dm_table_determine_type(t);
|
2010-08-12 11:14:03 +08:00
|
|
|
if (r) {
|
2016-05-25 09:16:51 +08:00
|
|
|
DMERR("unable to determine table type");
|
2010-08-12 11:14:03 +08:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
r = dm_table_build_index(t);
|
|
|
|
if (r) {
|
|
|
|
DMERR("unable to build btrees");
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
r = dm_table_register_integrity(t);
|
2010-08-12 11:14:03 +08:00
|
|
|
if (r) {
|
|
|
|
DMERR("could not register integrity profile.");
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
r = dm_table_construct_crypto_profile(t);
|
2021-02-01 13:10:17 +08:00
|
|
|
if (r) {
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
DMERR("could not construct crypto profile.");
|
2021-02-01 13:10:17 +08:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2015-03-12 03:01:09 +08:00
|
|
|
r = dm_table_alloc_md_mempools(t, t->md);
|
2010-08-12 11:14:03 +08:00
|
|
|
if (r)
|
|
|
|
DMERR("unable to allocate mempools");
|
|
|
|
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
2006-03-27 17:18:20 +08:00
|
|
|
static DEFINE_MUTEX(_event_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
void dm_table_event_callback(struct dm_table *t,
|
|
|
|
void (*fn)(void *), void *context)
|
|
|
|
{
|
2006-03-27 17:18:20 +08:00
|
|
|
mutex_lock(&_event_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
t->event_fn = fn;
|
|
|
|
t->event_context = context;
|
2006-03-27 17:18:20 +08:00
|
|
|
mutex_unlock(&_event_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void dm_table_event(struct dm_table *t)
|
|
|
|
{
|
2006-03-27 17:18:20 +08:00
|
|
|
mutex_lock(&_event_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
if (t->event_fn)
|
|
|
|
t->event_fn(t->event_context);
|
2006-03-27 17:18:20 +08:00
|
|
|
mutex_unlock(&_event_lock);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_table_event);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2019-08-23 21:54:09 +08:00
|
|
|
inline sector_t dm_table_get_size(struct dm_table *t)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return t->num_targets ? (t->highs[t->num_targets - 1] + 1) : 0;
|
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_table_get_size);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
struct dm_target *dm_table_get_target(struct dm_table *t, unsigned int index)
|
|
|
|
{
|
2006-06-26 15:27:27 +08:00
|
|
|
if (index >= t->num_targets)
|
2005-04-17 06:20:36 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return t->targets + index;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Search the btree for the correct target.
|
2007-12-13 22:15:25 +08:00
|
|
|
*
|
2019-08-23 21:55:26 +08:00
|
|
|
* Caller should check returned pointer for NULL
|
2007-12-13 22:15:25 +08:00
|
|
|
* to trap I/O beyond end of device.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
struct dm_target *dm_table_find_target(struct dm_table *t, sector_t sector)
|
|
|
|
{
|
|
|
|
unsigned int l, n = 0, k = 0;
|
|
|
|
sector_t *node;
|
|
|
|
|
2019-08-23 21:54:09 +08:00
|
|
|
if (unlikely(sector >= dm_table_get_size(t)))
|
2019-08-23 21:55:26 +08:00
|
|
|
return NULL;
|
2019-08-23 21:54:09 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
for (l = 0; l < t->depth; l++) {
|
|
|
|
n = get_child(n, k);
|
|
|
|
node = get_node(t, l, n);
|
|
|
|
|
|
|
|
for (k = 0; k < KEYS_PER_NODE; k++)
|
|
|
|
if (node[k] >= sector)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return &t->targets[(KEYS_PER_NODE * n) + k];
|
|
|
|
}
|
|
|
|
|
2022-03-05 10:08:04 +08:00
|
|
|
static int device_not_poll_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
|
|
|
|
return !test_bit(QUEUE_FLAG_POLL, &q->queue_flags);
|
|
|
|
}
|
|
|
|
|
2021-02-02 11:35:28 +08:00
|
|
|
/*
|
|
|
|
* type->iterate_devices() should be called when the sanity check needs to
|
|
|
|
* iterate and check all underlying data devices. iterate_devices() will
|
|
|
|
* iterate all underlying data devices until it encounters a non-zero return
|
|
|
|
* code, returned by whether the input iterate_devices_callout_fn, or
|
|
|
|
* iterate_devices() itself internally.
|
|
|
|
*
|
|
|
|
* For some target type (e.g. dm-stripe), one call of iterate_devices() may
|
|
|
|
* iterate multiple underlying devices internally, in which case a non-zero
|
|
|
|
* return code returned by iterate_devices_callout_fn will stop the iteration
|
|
|
|
* in advance.
|
|
|
|
*
|
|
|
|
* Cases requiring _any_ underlying device supporting some kind of attribute,
|
|
|
|
* should use the iteration structure like dm_table_any_dev_attr(), or call
|
|
|
|
* it directly. @func should handle semantics of positive examples, e.g.
|
|
|
|
* capable of something.
|
|
|
|
*
|
|
|
|
* Cases requiring _all_ underlying devices supporting some kind of attribute,
|
|
|
|
* should use the iteration structure like dm_table_supports_nowait() or
|
|
|
|
* dm_table_supports_discards(). Or introduce dm_table_all_devs_attr() that
|
|
|
|
* uses an @anti_func that handle semantics of counter examples, e.g. not
|
2021-02-09 11:46:38 +08:00
|
|
|
* capable of something. So: return !dm_table_any_dev_attr(t, anti_func, data);
|
2021-02-02 11:35:28 +08:00
|
|
|
*/
|
|
|
|
static bool dm_table_any_dev_attr(struct dm_table *t,
|
2021-02-09 11:46:38 +08:00
|
|
|
iterate_devices_callout_fn func, void *data)
|
2021-02-02 11:35:28 +08:00
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
|
|
|
|
|
|
|
if (ti->type->iterate_devices &&
|
2021-02-09 11:46:38 +08:00
|
|
|
ti->type->iterate_devices(ti, func, data))
|
2021-02-02 11:35:28 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2012-09-27 06:45:45 +08:00
|
|
|
static int count_device(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
unsigned *num_devices = data;
|
|
|
|
|
|
|
|
(*num_devices)++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-06-01 00:16:49 +08:00
|
|
|
static bool dm_table_supports_poll(struct dm_table *t)
|
2022-03-05 10:08:04 +08:00
|
|
|
{
|
2022-06-01 00:16:49 +08:00
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i = 0;
|
|
|
|
|
|
|
|
while (i < dm_table_get_num_targets(t)) {
|
|
|
|
ti = dm_table_get_target(t, i++);
|
|
|
|
|
|
|
|
if (!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_poll_capable, NULL))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2022-03-05 10:08:04 +08:00
|
|
|
}
|
|
|
|
|
2012-09-27 06:45:45 +08:00
|
|
|
/*
|
|
|
|
* Check whether a table has no data devices attached using each
|
|
|
|
* target's iterate_devices method.
|
|
|
|
* Returns false if the result is unknown because a target doesn't
|
|
|
|
* support iterate_devices.
|
|
|
|
*/
|
|
|
|
bool dm_table_has_no_data_devices(struct dm_table *table)
|
|
|
|
{
|
2017-04-19 04:51:46 +08:00
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i, num_devices;
|
2012-09-27 06:45:45 +08:00
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(table); i++) {
|
|
|
|
ti = dm_table_get_target(table, i);
|
2012-09-27 06:45:45 +08:00
|
|
|
|
|
|
|
if (!ti->type->iterate_devices)
|
|
|
|
return false;
|
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
num_devices = 0;
|
2012-09-27 06:45:45 +08:00
|
|
|
ti->type->iterate_devices(ti, count_device, &num_devices);
|
|
|
|
if (num_devices)
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-02-09 11:46:38 +08:00
|
|
|
static int device_not_zoned_model(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2017-05-09 07:40:43 +08:00
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
enum blk_zoned_model *zoned_model = data;
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return blk_queue_zoned_model(q) != *zoned_model;
|
2017-05-09 07:40:43 +08:00
|
|
|
}
|
|
|
|
|
2021-03-16 12:36:02 +08:00
|
|
|
/*
|
|
|
|
* Check the device zoned model based on the target feature flag. If the target
|
|
|
|
* has the DM_TARGET_ZONED_HM feature flag set, host-managed zoned devices are
|
|
|
|
* also accepted but all devices must have the same zoned model. If the target
|
|
|
|
* has the DM_TARGET_MIXED_ZONED_MODEL feature set, the devices can have any
|
|
|
|
* zoned model with all zoned devices having the same zone size.
|
|
|
|
*/
|
2017-05-09 07:40:43 +08:00
|
|
|
static bool dm_table_supports_zoned_model(struct dm_table *t,
|
|
|
|
enum blk_zoned_model zoned_model)
|
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
|
|
|
|
2021-03-16 12:36:02 +08:00
|
|
|
if (dm_target_supports_zoned_hm(ti->type)) {
|
|
|
|
if (!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_zoned_model,
|
|
|
|
&zoned_model))
|
|
|
|
return false;
|
|
|
|
} else if (!dm_target_supports_mixed_zoned_model(ti->type)) {
|
|
|
|
if (zoned_model == BLK_ZONED_HM)
|
|
|
|
return false;
|
|
|
|
}
|
2017-05-09 07:40:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2021-02-09 11:46:38 +08:00
|
|
|
static int device_not_matches_zone_sectors(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2017-05-09 07:40:43 +08:00
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
unsigned int *zone_sectors = data;
|
|
|
|
|
2021-03-16 12:36:02 +08:00
|
|
|
if (!blk_queue_is_zoned(q))
|
|
|
|
return 0;
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return blk_queue_zone_sectors(q) != *zone_sectors;
|
2017-05-09 07:40:43 +08:00
|
|
|
}
|
|
|
|
|
2021-03-16 12:36:02 +08:00
|
|
|
/*
|
|
|
|
* Check consistency of zoned model and zone sectors across all targets. For
|
|
|
|
* zone sectors, if the destination device is a zoned block device, it shall
|
|
|
|
* have the specified zone_sectors.
|
|
|
|
*/
|
2017-05-09 07:40:43 +08:00
|
|
|
static int validate_hardware_zoned_model(struct dm_table *table,
|
|
|
|
enum blk_zoned_model zoned_model,
|
|
|
|
unsigned int zone_sectors)
|
|
|
|
{
|
|
|
|
if (zoned_model == BLK_ZONED_NONE)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!dm_table_supports_zoned_model(table, zoned_model)) {
|
|
|
|
DMERR("%s: zoned model is not consistent across all devices",
|
|
|
|
dm_device_name(table->md));
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check zone size validity and compatibility */
|
|
|
|
if (!zone_sectors || !is_power_of_2(zone_sectors))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2021-02-09 11:46:38 +08:00
|
|
|
if (dm_table_any_dev_attr(table, device_not_matches_zone_sectors, &zone_sectors)) {
|
2021-03-16 12:36:02 +08:00
|
|
|
DMERR("%s: zone sectors is not consistent across all zoned devices",
|
2017-05-09 07:40:43 +08:00
|
|
|
dm_device_name(table->md));
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-06-22 17:12:34 +08:00
|
|
|
/*
|
|
|
|
* Establish the new table's queue_limits and validate them.
|
|
|
|
*/
|
|
|
|
int dm_calculate_queue_limits(struct dm_table *table,
|
|
|
|
struct queue_limits *limits)
|
|
|
|
{
|
2017-04-19 04:51:46 +08:00
|
|
|
struct dm_target *ti;
|
2009-06-22 17:12:34 +08:00
|
|
|
struct queue_limits ti_limits;
|
2017-04-19 04:51:46 +08:00
|
|
|
unsigned i;
|
2017-05-09 07:40:43 +08:00
|
|
|
enum blk_zoned_model zoned_model = BLK_ZONED_NONE;
|
|
|
|
unsigned int zone_sectors = 0;
|
2009-06-22 17:12:34 +08:00
|
|
|
|
2012-01-11 23:27:11 +08:00
|
|
|
blk_set_stacking_limits(limits);
|
2009-06-22 17:12:34 +08:00
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(table); i++) {
|
2012-01-11 23:27:11 +08:00
|
|
|
blk_set_stacking_limits(&ti_limits);
|
2009-06-22 17:12:34 +08:00
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
ti = dm_table_get_target(table, i);
|
2009-06-22 17:12:34 +08:00
|
|
|
|
|
|
|
if (!ti->type->iterate_devices)
|
|
|
|
goto combine_limits;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Combine queue limits of all the devices this target uses.
|
|
|
|
*/
|
|
|
|
ti->type->iterate_devices(ti, dm_set_device_limits,
|
|
|
|
&ti_limits);
|
|
|
|
|
2017-05-09 07:40:43 +08:00
|
|
|
if (zoned_model == BLK_ZONED_NONE && ti_limits.zoned != BLK_ZONED_NONE) {
|
|
|
|
/*
|
|
|
|
* After stacking all limits, validate all devices
|
|
|
|
* in table support this zoned model and zone sectors.
|
|
|
|
*/
|
|
|
|
zoned_model = ti_limits.zoned;
|
|
|
|
zone_sectors = ti_limits.chunk_sectors;
|
|
|
|
}
|
|
|
|
|
2009-09-05 03:40:25 +08:00
|
|
|
/* Set I/O hints portion of queue limits */
|
|
|
|
if (ti->type->io_hints)
|
|
|
|
ti->type->io_hints(ti, &ti_limits);
|
|
|
|
|
2009-06-22 17:12:34 +08:00
|
|
|
/*
|
|
|
|
* Check each device area is consistent with the target's
|
|
|
|
* overall queue limits.
|
|
|
|
*/
|
2009-09-05 03:40:22 +08:00
|
|
|
if (ti->type->iterate_devices(ti, device_area_is_invalid,
|
|
|
|
&ti_limits))
|
2009-06-22 17:12:34 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
combine_limits:
|
|
|
|
/*
|
|
|
|
* Merge this target's queue limits into the overall limits
|
|
|
|
* for the table.
|
|
|
|
*/
|
|
|
|
if (blk_stack_limits(limits, &ti_limits, 0) < 0)
|
2010-01-11 16:21:50 +08:00
|
|
|
DMWARN("%s: adding target device "
|
2009-06-22 17:12:34 +08:00
|
|
|
"(start sect %llu len %llu) "
|
2010-01-11 16:21:50 +08:00
|
|
|
"caused an alignment inconsistency",
|
2009-06-22 17:12:34 +08:00
|
|
|
dm_device_name(table->md),
|
|
|
|
(unsigned long long) ti->begin,
|
|
|
|
(unsigned long long) ti->len);
|
|
|
|
}
|
|
|
|
|
2017-05-09 07:40:43 +08:00
|
|
|
/*
|
|
|
|
* Verify that the zoned model and zone sectors, as determined before
|
|
|
|
* any .io_hints override, are the same across all devices in the table.
|
|
|
|
* - this is especially relevant if .io_hints is emulating a disk-managed
|
|
|
|
* zoned model (aka BLK_ZONED_NONE) on host-managed zoned block devices.
|
|
|
|
* BUT...
|
|
|
|
*/
|
|
|
|
if (limits->zoned != BLK_ZONED_NONE) {
|
|
|
|
/*
|
|
|
|
* ...IF the above limits stacking determined a zoned model
|
|
|
|
* validate that all of the table's devices conform to it.
|
|
|
|
*/
|
|
|
|
zoned_model = limits->zoned;
|
|
|
|
zone_sectors = limits->chunk_sectors;
|
|
|
|
}
|
|
|
|
if (validate_hardware_zoned_model(table, zoned_model, zone_sectors))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-06-22 17:12:34 +08:00
|
|
|
return validate_hardware_logical_block_alignment(table, limits);
|
|
|
|
}
|
|
|
|
|
2009-04-09 07:27:12 +08:00
|
|
|
/*
|
2015-10-22 01:19:49 +08:00
|
|
|
* Verify that all devices have an integrity profile that matches the
|
|
|
|
* DM device's registered integrity profile. If the profiles don't
|
|
|
|
* match then unregister the DM device's integrity profile.
|
2009-04-09 07:27:12 +08:00
|
|
|
*/
|
2015-10-22 01:19:49 +08:00
|
|
|
static void dm_table_verify_integrity(struct dm_table *t)
|
2009-04-09 07:27:12 +08:00
|
|
|
{
|
2011-04-02 03:02:31 +08:00
|
|
|
struct gendisk *template_disk = NULL;
|
2009-04-09 07:27:12 +08:00
|
|
|
|
2017-01-05 03:23:51 +08:00
|
|
|
if (t->integrity_added)
|
|
|
|
return;
|
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
if (t->integrity_supported) {
|
|
|
|
/*
|
|
|
|
* Verify that the original integrity profile
|
|
|
|
* matches all the devices in this table.
|
|
|
|
*/
|
|
|
|
template_disk = dm_table_get_integrity_disk(t);
|
|
|
|
if (template_disk &&
|
|
|
|
blk_integrity_compare(dm_disk(t->md), template_disk) >= 0)
|
|
|
|
return;
|
|
|
|
}
|
2009-04-09 07:27:12 +08:00
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
if (integrity_profile_exists(dm_disk(t->md))) {
|
2011-09-26 06:26:17 +08:00
|
|
|
DMWARN("%s: unable to establish an integrity profile",
|
|
|
|
dm_device_name(t->md));
|
2015-10-22 01:19:49 +08:00
|
|
|
blk_integrity_unregister(dm_disk(t->md));
|
|
|
|
}
|
2009-04-09 07:27:12 +08:00
|
|
|
}
|
|
|
|
|
2011-08-02 19:32:08 +08:00
|
|
|
static int device_flush_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
2016-04-14 03:33:19 +08:00
|
|
|
unsigned long flush = (unsigned long) data;
|
2011-08-02 19:32:08 +08:00
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return (q->queue_flags & flush);
|
2011-08-02 19:32:08 +08:00
|
|
|
}
|
|
|
|
|
2016-04-14 03:33:19 +08:00
|
|
|
static bool dm_table_supports_flush(struct dm_table *t, unsigned long flush)
|
2011-08-02 19:32:08 +08:00
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
2017-04-19 04:51:46 +08:00
|
|
|
unsigned i;
|
2011-08-02 19:32:08 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Require at least one underlying device to support flushes.
|
|
|
|
* t->devices includes internal dm devices such as mirror logs
|
|
|
|
* so we need to use iterate_devices here, which targets
|
|
|
|
* supporting flushes must provide.
|
|
|
|
*/
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
2011-08-02 19:32:08 +08:00
|
|
|
|
2013-03-02 06:45:47 +08:00
|
|
|
if (!ti->num_flush_bios)
|
2011-08-02 19:32:08 +08:00
|
|
|
continue;
|
|
|
|
|
2012-07-27 22:08:07 +08:00
|
|
|
if (ti->flush_supported)
|
2015-03-31 01:43:18 +08:00
|
|
|
return true;
|
2012-07-27 22:08:07 +08:00
|
|
|
|
2011-08-02 19:32:08 +08:00
|
|
|
if (ti->type->iterate_devices &&
|
2016-04-14 03:33:19 +08:00
|
|
|
ti->type->iterate_devices(ti, device_flush_capable, (void *) flush))
|
2015-03-31 01:43:18 +08:00
|
|
|
return true;
|
2011-08-02 19:32:08 +08:00
|
|
|
}
|
|
|
|
|
2015-03-31 01:43:18 +08:00
|
|
|
return false;
|
2011-08-02 19:32:08 +08:00
|
|
|
}
|
|
|
|
|
2017-07-26 21:35:09 +08:00
|
|
|
static int device_dax_write_cache_enabled(struct dm_target *ti,
|
|
|
|
struct dm_dev *dev, sector_t start,
|
|
|
|
sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct dax_device *dax_dev = dev->dax_dev;
|
|
|
|
|
|
|
|
if (!dax_dev)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (dax_write_cache_enabled(dax_dev))
|
|
|
|
return true;
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2021-02-02 11:35:28 +08:00
|
|
|
static int device_is_rotational(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2011-11-01 04:18:50 +08:00
|
|
|
{
|
2022-04-15 12:52:42 +08:00
|
|
|
return !bdev_nonrot(dev->bdev);
|
2011-11-01 04:18:50 +08:00
|
|
|
}
|
|
|
|
|
2012-09-27 06:45:43 +08:00
|
|
|
static int device_is_not_random(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return !blk_queue_add_random(q);
|
2012-09-27 06:45:43 +08:00
|
|
|
}
|
|
|
|
|
2017-04-06 01:21:05 +08:00
|
|
|
static int device_not_write_zeroes_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return !q->limits.max_write_zeroes_sectors;
|
2017-04-06 01:21:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool dm_table_supports_write_zeroes(struct dm_table *t)
|
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i = 0;
|
|
|
|
|
|
|
|
while (i < dm_table_get_num_targets(t)) {
|
|
|
|
ti = dm_table_get_target(t, i++);
|
|
|
|
|
|
|
|
if (!ti->num_write_zeroes_bios)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_write_zeroes_capable, NULL))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-09-24 04:06:52 +08:00
|
|
|
static int device_not_nowait_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
|
|
|
{
|
|
|
|
struct request_queue *q = bdev_get_queue(dev->bdev);
|
|
|
|
|
2021-02-09 00:57:05 +08:00
|
|
|
return !blk_queue_nowait(q);
|
2020-09-24 04:06:52 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool dm_table_supports_nowait(struct dm_table *t)
|
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned i = 0;
|
|
|
|
|
|
|
|
while (i < dm_table_get_num_targets(t)) {
|
|
|
|
ti = dm_table_get_target(t, i++);
|
|
|
|
|
|
|
|
if (!dm_target_supports_nowait(ti->type))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_nowait_capable, NULL))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-11-15 04:40:52 +08:00
|
|
|
static int device_not_discard_capable(struct dm_target *ti, struct dm_dev *dev,
|
|
|
|
sector_t start, sector_t len, void *data)
|
2014-07-11 00:23:07 +08:00
|
|
|
{
|
2022-04-15 12:52:55 +08:00
|
|
|
return !bdev_max_discard_sectors(dev->bdev);
|
2014-07-11 00:23:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool dm_table_supports_discards(struct dm_table *t)
|
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
2017-04-19 04:51:46 +08:00
|
|
|
unsigned i;
|
2014-07-11 00:23:07 +08:00
|
|
|
|
2017-04-19 04:51:46 +08:00
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
2014-07-11 00:23:07 +08:00
|
|
|
|
|
|
|
if (!ti->num_discard_bios)
|
2017-11-15 04:40:52 +08:00
|
|
|
return false;
|
2014-07-11 00:23:07 +08:00
|
|
|
|
2017-11-15 04:40:52 +08:00
|
|
|
/*
|
|
|
|
* Either the target provides discard support (as implied by setting
|
|
|
|
* 'discards_supported') or it relies on _all_ data devices having
|
|
|
|
* discard support.
|
|
|
|
*/
|
|
|
|
if (!ti->discards_supported &&
|
|
|
|
(!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_discard_capable, NULL)))
|
|
|
|
return false;
|
2014-07-11 00:23:07 +08:00
|
|
|
}
|
|
|
|
|
2017-11-15 04:40:52 +08:00
|
|
|
return true;
|
2014-07-11 00:23:07 +08:00
|
|
|
}
|
|
|
|
|
2018-03-13 17:23:45 +08:00
|
|
|
static int device_not_secure_erase_capable(struct dm_target *ti,
|
|
|
|
struct dm_dev *dev, sector_t start,
|
|
|
|
sector_t len, void *data)
|
|
|
|
{
|
2022-04-15 12:52:57 +08:00
|
|
|
return !bdev_max_secure_erase_sectors(dev->bdev);
|
2018-03-13 17:23:45 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool dm_table_supports_secure_erase(struct dm_table *t)
|
|
|
|
{
|
|
|
|
struct dm_target *ti;
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
for (i = 0; i < dm_table_get_num_targets(t); i++) {
|
|
|
|
ti = dm_table_get_target(t, i);
|
|
|
|
|
|
|
|
if (!ti->num_secure_erase_bios)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!ti->type->iterate_devices ||
|
|
|
|
ti->type->iterate_devices(ti, device_not_secure_erase_capable, NULL))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2019-03-27 03:20:58 +08:00
|
|
|
static int device_requires_stable_pages(struct dm_target *ti,
|
|
|
|
struct dm_dev *dev, sector_t start,
|
|
|
|
sector_t len, void *data)
|
|
|
|
{
|
2022-04-15 12:52:45 +08:00
|
|
|
return bdev_stable_writes(dev->bdev);
|
2019-03-27 03:20:58 +08:00
|
|
|
}
|
|
|
|
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
int dm_table_set_restrictions(struct dm_table *t, struct request_queue *q,
|
|
|
|
struct queue_limits *limits)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2016-03-31 00:14:14 +08:00
|
|
|
bool wc = false, fua = false;
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
int r;
|
2011-08-02 19:32:08 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2009-06-22 17:12:32 +08:00
|
|
|
* Copy table's limits to the DM device's request_queue
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
2009-06-22 17:12:34 +08:00
|
|
|
q->limits = *limits;
|
2008-04-30 01:12:35 +08:00
|
|
|
|
2020-09-24 04:06:52 +08:00
|
|
|
if (dm_table_supports_nowait(t))
|
|
|
|
blk_queue_flag_set(QUEUE_FLAG_NOWAIT, q);
|
|
|
|
else
|
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_NOWAIT, q);
|
|
|
|
|
2017-11-17 04:42:26 +08:00
|
|
|
if (!dm_table_supports_discards(t)) {
|
|
|
|
q->limits.max_discard_sectors = 0;
|
|
|
|
q->limits.max_hw_discard_sectors = 0;
|
|
|
|
q->limits.discard_granularity = 0;
|
|
|
|
q->limits.discard_alignment = 0;
|
|
|
|
q->limits.discard_misaligned = 0;
|
2022-04-15 12:52:55 +08:00
|
|
|
}
|
2010-08-12 11:14:08 +08:00
|
|
|
|
2022-04-15 12:52:57 +08:00
|
|
|
if (!dm_table_supports_secure_erase(t))
|
|
|
|
q->limits.max_secure_erase_sectors = 0;
|
2018-03-13 17:23:45 +08:00
|
|
|
|
2016-04-14 03:33:19 +08:00
|
|
|
if (dm_table_supports_flush(t, (1UL << QUEUE_FLAG_WC))) {
|
2016-03-31 00:14:14 +08:00
|
|
|
wc = true;
|
2016-04-14 03:33:19 +08:00
|
|
|
if (dm_table_supports_flush(t, (1UL << QUEUE_FLAG_FUA)))
|
2016-03-31 00:14:14 +08:00
|
|
|
fua = true;
|
2011-08-02 19:32:08 +08:00
|
|
|
}
|
2016-03-31 00:14:14 +08:00
|
|
|
blk_queue_write_cache(q, wc, fua);
|
2011-08-02 19:32:08 +08:00
|
|
|
|
2021-11-29 18:21:42 +08:00
|
|
|
if (dm_table_supports_dax(t, device_not_dax_capable)) {
|
2018-03-08 09:10:10 +08:00
|
|
|
blk_queue_flag_set(QUEUE_FLAG_DAX, q);
|
2021-11-29 18:21:42 +08:00
|
|
|
if (dm_table_supports_dax(t, device_not_dax_synchronous_capable))
|
2019-07-05 22:03:25 +08:00
|
|
|
set_dax_synchronous(t->md->dax_dev);
|
|
|
|
}
|
2018-06-27 06:30:41 +08:00
|
|
|
else
|
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_DAX, q);
|
|
|
|
|
2021-02-09 11:46:38 +08:00
|
|
|
if (dm_table_any_dev_attr(t, device_dax_write_cache_enabled, NULL))
|
2017-07-26 21:35:09 +08:00
|
|
|
dax_write_cache(t->md->dax_dev, true);
|
|
|
|
|
2012-09-27 06:45:43 +08:00
|
|
|
/* Ensure that all underlying devices are non-rotational. */
|
2021-02-09 11:46:38 +08:00
|
|
|
if (dm_table_any_dev_attr(t, device_is_rotational, NULL))
|
2018-03-08 09:10:10 +08:00
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_NONROT, q);
|
2021-02-02 11:35:28 +08:00
|
|
|
else
|
|
|
|
blk_queue_flag_set(QUEUE_FLAG_NONROT, q);
|
2011-11-01 04:18:50 +08:00
|
|
|
|
2017-04-06 01:21:05 +08:00
|
|
|
if (!dm_table_supports_write_zeroes(t))
|
|
|
|
q->limits.max_write_zeroes_sectors = 0;
|
2012-12-22 04:23:30 +08:00
|
|
|
|
2015-10-22 01:19:49 +08:00
|
|
|
dm_table_verify_integrity(t);
|
dm: enable request based option
This patch enables request-based dm.
o Request-based dm and bio-based dm coexist, since there are
some target drivers which are more fitting to bio-based dm.
Also, there are other bio-based devices in the kernel
(e.g. md, loop).
Since bio-based device can't receive struct request,
there are some limitations on device stacking between
bio-based and request-based.
type of underlying device
bio-based request-based
----------------------------------------------
bio-based OK OK
request-based -- OK
The device type is recognized by the queue flag in the kernel,
so dm follows that.
o The type of a dm device is decided at the first table binding time.
Once the type of a dm device is decided, the type can't be changed.
o Mempool allocations are deferred to at the table loading time, since
mempools for request-based dm are different from those for bio-based
dm and needed mempool type is fixed by the type of table.
o Currently, request-based dm supports only tables that have a single
target. To support multiple targets, we need to support request
splitting or prevent bio/request from spanning multiple targets.
The former needs lots of changes in the block layer, and the latter
needs that all target drivers support merge() function.
Both will take a time.
Signed-off-by: Kiyoshi Ueda <k-ueda@ct.jp.nec.com>
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
2009-06-22 17:12:36 +08:00
|
|
|
|
2019-03-27 03:20:58 +08:00
|
|
|
/*
|
|
|
|
* Some devices don't use blk_integrity but still want stable pages
|
|
|
|
* because they do their own checksumming.
|
2021-02-02 11:35:28 +08:00
|
|
|
* If any underlying device requires stable pages, a table must require
|
|
|
|
* them as well. Only targets that support iterate_devices are considered:
|
|
|
|
* don't want error, zero, etc to require stable pages.
|
2019-03-27 03:20:58 +08:00
|
|
|
*/
|
2021-02-09 11:46:38 +08:00
|
|
|
if (dm_table_any_dev_attr(t, device_requires_stable_pages, NULL))
|
2020-09-24 14:51:38 +08:00
|
|
|
blk_queue_flag_set(QUEUE_FLAG_STABLE_WRITES, q);
|
2019-03-27 03:20:58 +08:00
|
|
|
else
|
2020-09-24 14:51:38 +08:00
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_STABLE_WRITES, q);
|
2019-03-27 03:20:58 +08:00
|
|
|
|
2012-09-27 06:45:43 +08:00
|
|
|
/*
|
|
|
|
* Determine whether or not this queue's I/O timings contribute
|
|
|
|
* to the entropy pool, Only request-based targets use this.
|
|
|
|
* Clear QUEUE_FLAG_ADD_RANDOM if any underlying device does not
|
|
|
|
* have it set.
|
|
|
|
*/
|
2021-02-09 11:46:38 +08:00
|
|
|
if (blk_queue_add_random(q) &&
|
|
|
|
dm_table_any_dev_attr(t, device_is_not_random, NULL))
|
2018-03-08 09:10:10 +08:00
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_ADD_RANDOM, q);
|
2018-10-12 18:08:50 +08:00
|
|
|
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
/*
|
|
|
|
* For a zoned target, setup the zones related queue attributes
|
|
|
|
* and resources necessary for zone append emulation if necessary.
|
|
|
|
*/
|
|
|
|
if (blk_queue_is_zoned(q)) {
|
|
|
|
r = dm_set_zones_restrictions(t, q);
|
|
|
|
if (r)
|
|
|
|
return r;
|
2022-03-27 02:14:00 +08:00
|
|
|
if (!static_key_enabled(&zoned_enabled.key))
|
|
|
|
static_branch_enable(&zoned_enabled);
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
}
|
2018-12-19 01:25:37 +08:00
|
|
|
|
blk-crypto: rename blk_keyslot_manager to blk_crypto_profile
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 <ulf.hansson@linaro.org> # For MMC
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20211018180453.40441-4-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-19 02:04:52 +08:00
|
|
|
dm_update_crypto_profile(q, t);
|
2021-08-09 22:17:41 +08:00
|
|
|
disk_update_readahead(t->md->disk);
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
|
2022-03-05 10:08:04 +08:00
|
|
|
/*
|
|
|
|
* Check for request-based device is left to
|
|
|
|
* dm_mq_init_request_queue()->blk_mq_init_allocated_queue().
|
|
|
|
*
|
|
|
|
* For bio-based device, only set QUEUE_FLAG_POLL when all
|
|
|
|
* underlying devices supporting polling.
|
|
|
|
*/
|
|
|
|
if (__table_type_bio_based(t->type)) {
|
|
|
|
if (dm_table_supports_poll(t))
|
|
|
|
blk_queue_flag_set(QUEUE_FLAG_POLL, q);
|
|
|
|
else
|
|
|
|
blk_queue_flag_clear(QUEUE_FLAG_POLL, q);
|
|
|
|
}
|
|
|
|
|
dm: introduce zone append emulation
For zoned targets that cannot support zone append operations, implement
an emulation using regular write operations. If the original BIO
submitted by the user is a zone append operation, change its clone into
a regular write operation directed at the target zone write pointer
position.
To do so, an array of write pointer offsets (write pointer position
relative to the start of a zone) is added to struct mapped_device. All
operations that modify a sequential zone write pointer (writes, zone
reset, zone finish and zone append) are intersepted in __map_bio() and
processed using the new functions dm_zone_map_bio().
Detection of the target ability to natively support zone append
operations is done from dm_table_set_restrictions() by calling the
function dm_set_zones_restrictions(). A target that does not support
zone append operation, either by explicitly declaring it using the new
struct dm_target field zone_append_not_supported, or because the device
table contains a non-zoned device, has its mapped device marked with the
new flag DMF_ZONE_APPEND_EMULATED. The helper function
dm_emulate_zone_append() is introduced to test a mapped device for this
new flag.
Atomicity of the zones write pointer tracking and updates is done using
a zone write locking mechanism based on a bitmap. This is similar to
the block layer method but based on BIOs rather than struct request.
A zone write lock is taken in dm_zone_map_bio() for any clone BIO with
an operation type that changes the BIO target zone write pointer
position. The zone write lock is released if the clone BIO is failed
before submission or when dm_zone_endio() is called when the clone BIO
completes.
The zone write lock bitmap of the mapped device, together with a bitmap
indicating zone types (conv_zones_bitmap) and the write pointer offset
array (zwp_offset) are allocated and initialized with a full device zone
report in dm_set_zones_restrictions() using the function
dm_revalidate_zones().
For failed operations that may have modified a zone write pointer, the
zone write pointer offset is marked as invalid in dm_zone_endio().
Zones with an invalid write pointer offset are checked and the write
pointer updated using an internal report zone operation when the
faulty zone is accessed again by the user.
All functions added for this emulation have a minimal overhead for
zoned targets natively supporting zone append operations. Regular
device targets are also not affected. The added code also does not
impact builds with CONFIG_BLK_DEV_ZONED disabled by stubbing out all
dm zone related functions.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
2021-05-26 05:25:00 +08:00
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
unsigned int dm_table_get_num_targets(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return t->num_targets;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct list_head *dm_table_get_devices(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return &t->devices;
|
|
|
|
}
|
|
|
|
|
2008-09-03 03:28:45 +08:00
|
|
|
fmode_t dm_table_get_mode(struct dm_table *t)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
return t->mode;
|
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_table_get_mode);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2014-10-29 08:13:31 +08:00
|
|
|
enum suspend_mode {
|
|
|
|
PRESUSPEND,
|
|
|
|
PRESUSPEND_UNDO,
|
|
|
|
POSTSUSPEND,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void suspend_targets(struct dm_table *t, enum suspend_mode mode)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
|
|
|
int i = t->num_targets;
|
|
|
|
struct dm_target *ti = t->targets;
|
|
|
|
|
2017-04-28 01:11:21 +08:00
|
|
|
lockdep_assert_held(&t->md->suspend_lock);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
while (i--) {
|
2014-10-29 08:13:31 +08:00
|
|
|
switch (mode) {
|
|
|
|
case PRESUSPEND:
|
|
|
|
if (ti->type->presuspend)
|
|
|
|
ti->type->presuspend(ti);
|
|
|
|
break;
|
|
|
|
case PRESUSPEND_UNDO:
|
|
|
|
if (ti->type->presuspend_undo)
|
|
|
|
ti->type->presuspend_undo(ti);
|
|
|
|
break;
|
|
|
|
case POSTSUSPEND:
|
2005-04-17 06:20:36 +08:00
|
|
|
if (ti->type->postsuspend)
|
|
|
|
ti->type->postsuspend(ti);
|
2014-10-29 08:13:31 +08:00
|
|
|
break;
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
ti++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void dm_table_presuspend_targets(struct dm_table *t)
|
|
|
|
{
|
2005-07-29 12:15:57 +08:00
|
|
|
if (!t)
|
|
|
|
return;
|
|
|
|
|
2014-10-29 08:13:31 +08:00
|
|
|
suspend_targets(t, PRESUSPEND);
|
|
|
|
}
|
|
|
|
|
|
|
|
void dm_table_presuspend_undo_targets(struct dm_table *t)
|
|
|
|
{
|
|
|
|
if (!t)
|
|
|
|
return;
|
|
|
|
|
|
|
|
suspend_targets(t, PRESUSPEND_UNDO);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void dm_table_postsuspend_targets(struct dm_table *t)
|
|
|
|
{
|
2005-07-29 12:15:57 +08:00
|
|
|
if (!t)
|
|
|
|
return;
|
|
|
|
|
2014-10-29 08:13:31 +08:00
|
|
|
suspend_targets(t, POSTSUSPEND);
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-10-03 16:15:36 +08:00
|
|
|
int dm_table_resume_targets(struct dm_table *t)
|
2005-04-17 06:20:36 +08:00
|
|
|
{
|
2006-10-03 16:15:36 +08:00
|
|
|
int i, r = 0;
|
|
|
|
|
2017-04-28 01:11:21 +08:00
|
|
|
lockdep_assert_held(&t->md->suspend_lock);
|
|
|
|
|
2006-10-03 16:15:36 +08:00
|
|
|
for (i = 0; i < t->num_targets; i++) {
|
|
|
|
struct dm_target *ti = t->targets + i;
|
|
|
|
|
|
|
|
if (!ti->type->preresume)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
r = ti->type->preresume(ti);
|
2013-10-25 02:10:29 +08:00
|
|
|
if (r) {
|
|
|
|
DMERR("%s: %s: preresume failed, error = %d",
|
|
|
|
dm_device_name(t->md), ti->type->name, r);
|
2006-10-03 16:15:36 +08:00
|
|
|
return r;
|
2013-10-25 02:10:29 +08:00
|
|
|
}
|
2006-10-03 16:15:36 +08:00
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
for (i = 0; i < t->num_targets; i++) {
|
|
|
|
struct dm_target *ti = t->targets + i;
|
|
|
|
|
|
|
|
if (ti->type->resume)
|
|
|
|
ti->type->resume(ti);
|
|
|
|
}
|
2006-10-03 16:15:36 +08:00
|
|
|
|
|
|
|
return 0;
|
2005-04-17 06:20:36 +08:00
|
|
|
}
|
|
|
|
|
2006-03-27 17:17:54 +08:00
|
|
|
struct mapped_device *dm_table_get_md(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return t->md;
|
|
|
|
}
|
2011-08-02 19:32:04 +08:00
|
|
|
EXPORT_SYMBOL(dm_table_get_md);
|
2006-03-27 17:17:54 +08:00
|
|
|
|
2018-10-10 04:13:42 +08:00
|
|
|
const char *dm_table_device_name(struct dm_table *t)
|
|
|
|
{
|
|
|
|
return dm_device_name(t->md);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(dm_table_device_name);
|
|
|
|
|
2014-02-28 22:33:43 +08:00
|
|
|
void dm_table_run_md_queue_async(struct dm_table *t)
|
|
|
|
{
|
|
|
|
if (!dm_table_request_based(t))
|
|
|
|
return;
|
|
|
|
|
2020-09-20 01:09:11 +08:00
|
|
|
if (t->md->queue)
|
|
|
|
blk_mq_run_hw_queues(t->md->queue, true);
|
2014-02-28 22:33:43 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(dm_table_run_md_queue_async);
|
|
|
|
|