2005-04-17 02:20:36 +04:00
/*
* Internal header file for device mapper
*
* Copyright ( C ) 2001 , 2002 Sistina Software
2006-06-26 11:27:32 +04:00
* Copyright ( C ) 2004 - 2006 Red Hat , Inc . All rights reserved .
2005-04-17 02:20:36 +04:00
*
* This file is released under the LGPL .
*/
# ifndef DM_INTERNAL_H
# define DM_INTERNAL_H
# include <linux/fs.h>
# include <linux/device-mapper.h>
# include <linux/list.h>
# include <linux/blkdev.h>
2015-05-23 00:13:32 +03:00
# include <linux/backing-dev.h>
2006-03-27 13:17:54 +04:00
# include <linux/hdreg.h>
2014-01-07 08:01:22 +04:00
# include <linux/completion.h>
2014-01-14 04:37:54 +04:00
# include <linux/kobject.h>
2005-04-17 02:20:36 +04:00
2013-08-16 18:54:23 +04:00
# include "dm-stats.h"
2006-12-08 13:41:04 +03:00
/*
* Suspend feature flags
*/
# define DM_SUSPEND_LOCKFS_FLAG (1 << 0)
2006-12-08 13:41:07 +03:00
# define DM_SUSPEND_NOFLUSH_FLAG (1 << 1)
2006-12-08 13:41:04 +03:00
2012-07-27 18:08:16 +04:00
/*
* Status feature flags
*/
# define DM_STATUS_NOFLUSH_FLAG (1 << 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 13:12:36 +04:00
/*
* Type of table and mapped_device ' s mempool
*/
2014-12-18 05:08:12 +03:00
# define DM_TYPE_NONE 0
# define DM_TYPE_BIO_BASED 1
# define DM_TYPE_REQUEST_BASED 2
# define DM_TYPE_MQ_REQUEST_BASED 3
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 13:12:36 +04:00
2005-04-17 02:20:36 +04:00
/*
* List of devices that a metadevice uses and should open / close .
*/
2008-10-10 16:37:09 +04:00
struct dm_dev_internal {
2005-04-17 02:20:36 +04:00
struct list_head list ;
atomic_t count ;
2014-08-13 22:53:43 +04:00
struct dm_dev * dm_dev ;
2005-04-17 02:20:36 +04:00
} ;
struct dm_table ;
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 13:12:36 +04:00
struct dm_md_mempools ;
2005-04-17 02:20:36 +04:00
/*-----------------------------------------------------------------
2006-06-26 11:27:33 +04:00
* Internal table functions .
2005-04-17 02:20:36 +04: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 06:05:10 +03:00
void dm_table_destroy ( struct dm_table * t ) ;
2005-04-17 02:20:36 +04:00
void dm_table_event_callback ( struct dm_table * t ,
void ( * fn ) ( void * ) , void * context ) ;
struct dm_target * dm_table_get_target ( struct dm_table * t , unsigned int index ) ;
struct dm_target * dm_table_find_target ( struct dm_table * t , sector_t sector ) ;
2012-09-27 02:45:45 +04:00
bool dm_table_has_no_data_devices ( struct dm_table * table ) ;
2009-06-22 13:12:34 +04:00
int dm_calculate_queue_limits ( struct dm_table * table ,
struct queue_limits * limits ) ;
void dm_table_set_restrictions ( struct dm_table * t , struct request_queue * q ,
struct queue_limits * limits ) ;
2005-04-17 02:20:36 +04:00
struct list_head * dm_table_get_devices ( struct dm_table * t ) ;
void dm_table_presuspend_targets ( struct dm_table * t ) ;
2014-10-29 03:13:31 +03:00
void dm_table_presuspend_undo_targets ( struct dm_table * t ) ;
2005-04-17 02:20:36 +04:00
void dm_table_postsuspend_targets ( struct dm_table * t ) ;
2006-10-03 12:15:36 +04:00
int dm_table_resume_targets ( struct dm_table * t ) ;
2005-04-17 02:20:36 +04:00
int dm_table_any_congested ( struct dm_table * t , int bdi_bits ) ;
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 13:12:36 +04:00
unsigned dm_table_get_type ( struct dm_table * t ) ;
2011-11-01 00:19:04 +04:00
struct target_type * dm_table_get_immutable_target_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 13:12:36 +04:00
bool dm_table_request_based ( struct dm_table * t ) ;
2014-12-18 05:08:12 +03:00
bool dm_table_mq_request_based ( 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 13:12:36 +04:00
void dm_table_free_md_mempools ( struct dm_table * t ) ;
struct dm_md_mempools * dm_table_get_md_mempools ( struct dm_table * t ) ;
2005-04-17 02:20:36 +04:00
2010-08-12 07:14:01 +04:00
void dm_lock_md_type ( struct mapped_device * md ) ;
void dm_unlock_md_type ( struct mapped_device * md ) ;
void dm_set_md_type ( struct mapped_device * md , unsigned type ) ;
unsigned dm_get_md_type ( struct mapped_device * md ) ;
2011-11-01 00:19:04 +04:00
struct target_type * dm_get_immutable_target_type ( struct mapped_device * md ) ;
2010-08-12 07:14:01 +04:00
2010-08-12 07:14:02 +04:00
int dm_setup_md_queue ( struct mapped_device * md ) ;
2007-12-13 17:15:25 +03:00
/*
* To check the return value from dm_table_find_target ( ) .
*/
# define dm_target_is_valid(t) ((t)->table)
2013-08-23 02:21:38 +04:00
/*
* To check whether the target type is bio - based or not ( request - based ) .
*/
# define dm_target_bio_based(t) ((t)->type->map != NULL)
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 13:12:36 +04:00
/*
* To check whether the target type is request - based or not ( bio - based ) .
*/
2014-12-19 00:26:47 +03:00
# define dm_target_request_based(t) (((t)->type->map_rq != NULL) || \
( ( t ) - > type - > clone_and_map_rq ! = NULL ) )
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 13:12:36 +04:00
2013-08-23 02:21:38 +04:00
/*
* To check whether the target type is a hybrid ( capable of being
* either request - based or bio - based ) .
*/
# define dm_target_hybrid(t) (dm_target_bio_based(t) && dm_target_request_based(t))
2005-04-17 02:20:36 +04:00
/*-----------------------------------------------------------------
* A registry of target types .
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
int dm_target_init ( void ) ;
void dm_target_exit ( void ) ;
struct target_type * dm_get_target_type ( const char * name ) ;
2009-04-02 22:55:28 +04:00
void dm_put_target_type ( struct target_type * tt ) ;
2005-04-17 02:20:36 +04:00
int dm_target_iterate ( void ( * iter_func ) ( struct target_type * tt ,
void * param ) , void * param ) ;
int dm_split_args ( int * argc , char * * * argvp , char * input ) ;
2009-12-11 02:52:20 +03:00
/*
* Is this mapped_device being deleted ?
*/
int dm_deleting_md ( struct mapped_device * md ) ;
2009-12-11 02:52:26 +03:00
/*
* Is this mapped_device suspended ?
*/
int dm_suspended_md ( struct mapped_device * md ) ;
2014-10-29 01:34:52 +03:00
/*
* Internal suspend and resume methods .
*/
int dm_suspended_internally_md ( struct mapped_device * md ) ;
void dm_internal_suspend_fast ( struct mapped_device * md ) ;
void dm_internal_resume_fast ( struct mapped_device * md ) ;
void dm_internal_suspend_noflush ( struct mapped_device * md ) ;
void dm_internal_resume ( struct mapped_device * md ) ;
2013-11-02 02:27:41 +04:00
/*
* Test if the device is scheduled for deferred remove .
*/
int dm_test_deferred_remove_flag ( struct mapped_device * md ) ;
/*
* Try to remove devices marked for deferred removal .
*/
void dm_deferred_remove ( void ) ;
2005-04-17 02:20:36 +04:00
/*
* The device - mapper can be driven through one of two interfaces ;
* ioctl or filesystem , depending which patch you have applied .
*/
int dm_interface_init ( void ) ;
void dm_interface_exit ( void ) ;
2009-01-06 06:05:12 +03:00
/*
* sysfs interface
*/
2014-01-14 04:37:54 +04:00
struct dm_kobject_holder {
struct kobject kobj ;
struct completion completion ;
} ;
static inline struct completion * dm_get_completion_from_kobject ( struct kobject * kobj )
{
return & container_of ( kobj , struct dm_kobject_holder , kobj ) - > completion ;
}
2009-01-06 06:05:12 +03:00
int dm_sysfs_init ( struct mapped_device * md ) ;
void dm_sysfs_exit ( struct mapped_device * md ) ;
struct kobject * dm_kobject ( struct mapped_device * md ) ;
struct mapped_device * dm_get_from_kobject ( struct kobject * kobj ) ;
2014-01-14 04:37:54 +04:00
/*
* The kobject helper
*/
void dm_kobject_release ( struct kobject * kobj ) ;
2009-01-06 06:05:12 +03:00
2005-04-17 02:20:36 +04:00
/*
* Targets for linear and striped mappings
*/
int dm_linear_init ( void ) ;
void dm_linear_exit ( void ) ;
int dm_stripe_init ( void ) ;
void dm_stripe_exit ( void ) ;
dm: separate device deletion from dm_put
This patch separates the device deletion code from dm_put()
to make sure the deletion happens in the process context.
By this patch, device deletion always occurs in an ioctl (process)
context and dm_put() can be called in interrupt context.
As a result, the request-based dm's bad dm_put() usage pointed out
by Mikulas below disappears.
http://marc.info/?l=dm-devel&m=126699981019735&w=2
Without this patch, I confirmed there is a case to crash the system:
dm_put() => dm_table_destroy() => vfree() => BUG_ON(in_interrupt())
Some more backgrounds and details:
In request-based dm, a device opener can remove a mapped_device
while the last request is still completing, because bios in the last
request complete first and then the device opener can close and remove
the mapped_device before the last request completes:
CPU0 CPU1
=================================================================
<<INTERRUPT>>
blk_end_request_all(clone_rq)
blk_update_request(clone_rq)
bio_endio(clone_bio) == end_clone_bio
blk_update_request(orig_rq)
bio_endio(orig_bio)
<<I/O completed>>
dm_blk_close()
dev_remove()
dm_put(md)
<<Free md>>
blk_finish_request(clone_rq)
....
dm_end_request(clone_rq)
free_rq_clone(clone_rq)
blk_end_request_all(orig_rq)
rq_completed(md)
So request-based dm used dm_get()/dm_put() to hold md for each I/O
until its request completion handling is fully done.
However, the final dm_put() can call the device deletion code which
must not be run in interrupt context and may cause kernel panic.
To solve the problem, this patch moves the device deletion code,
dm_destroy(), to predetermined places that is actually deleting
the mapped_device in ioctl (process) context, and changes dm_put()
just to decrement the reference count of the mapped_device.
By this change, dm_put() can be used in any context and the symmetric
model below is introduced:
dm_create(): create a mapped_device
dm_destroy(): destroy a mapped_device
dm_get(): increment the reference count of a mapped_device
dm_put(): decrement the reference count of a mapped_device
dm_destroy() waits for all references of the mapped_device to disappear,
then deletes the mapped_device.
dm_destroy() uses active waiting with msleep(1), since deleting
the mapped_device isn't performance-critical task.
And since at this point, nobody opens the mapped_device and no new
reference will be taken, the pending counts are just for racing
completing activity and will eventually decrease to zero.
For the unlikely case of the forced module unload, dm_destroy_immediate(),
which doesn't wait and forcibly deletes the mapped_device, is also
introduced and used in dm_hash_remove_all(). Otherwise, "rmmod -f"
may be stuck and never return.
And now, because the mapped_device is deleted at this point, subsequent
accesses to the mapped_device may cause NULL pointer references.
Cc: stable@kernel.org
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>
2010-08-12 07:13:56 +04:00
/*
* mapped_device operations
*/
void dm_destroy ( struct mapped_device * md ) ;
void dm_destroy_immediate ( struct mapped_device * md ) ;
2006-06-26 11:27:34 +04:00
int dm_open_count ( struct mapped_device * md ) ;
2013-11-02 02:27:41 +04:00
int dm_lock_for_deletion ( struct mapped_device * md , bool mark_deferred , bool only_deferred ) ;
int dm_cancel_deferred_remove ( struct mapped_device * md ) ;
2013-08-16 18:54:23 +04:00
int dm_request_based ( struct mapped_device * md ) ;
sector_t dm_get_size ( struct mapped_device * md ) ;
2014-02-28 18:33:43 +04:00
struct request_queue * dm_get_md_queue ( struct mapped_device * md ) ;
2014-08-13 22:53:43 +04:00
int dm_get_table_device ( struct mapped_device * md , dev_t dev , fmode_t mode ,
struct dm_dev * * result ) ;
void dm_put_table_device ( struct mapped_device * md , struct dm_dev * d ) ;
2013-08-16 18:54:23 +04:00
struct dm_stats * dm_get_stats ( struct mapped_device * md ) ;
2005-04-17 02:20:36 +04:00
2010-03-06 05:32:31 +03:00
int dm_kobject_uevent ( struct mapped_device * md , enum kobject_action action ,
unsigned cookie ) ;
2007-12-13 17:15:57 +03:00
2013-08-16 18:54:23 +04:00
void dm_internal_suspend ( struct mapped_device * md ) ;
void dm_internal_resume ( struct mapped_device * md ) ;
2015-03-11 22:01:09 +03:00
bool dm_use_blk_mq ( struct mapped_device * md ) ;
2009-12-11 02:51:57 +03:00
int dm_io_init ( void ) ;
void dm_io_exit ( void ) ;
2008-04-25 00:43:49 +04:00
int dm_kcopyd_init ( void ) ;
void dm_kcopyd_exit ( void ) ;
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 13:12:36 +04:00
/*
* Mempool operations
*/
2015-06-26 17:01:13 +03:00
struct dm_md_mempools * dm_alloc_md_mempools ( struct mapped_device * md , unsigned type ,
unsigned integrity , unsigned per_bio_data_size ) ;
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 13:12:36 +04:00
void dm_free_md_mempools ( struct dm_md_mempools * pools ) ;
2013-08-16 18:54:23 +04:00
/*
* Helpers that are used by DM core
*/
2013-09-13 02:06:12 +04:00
unsigned dm_get_reserved_bio_based_ios ( void ) ;
2013-09-13 02:06:12 +04:00
unsigned dm_get_reserved_rq_based_ios ( void ) ;
2013-08-16 18:54:23 +04:00
static inline bool dm_message_test_buffer_overflow ( char * result , unsigned maxlen )
{
return ! maxlen | | strlen ( result ) + 1 > = maxlen ;
}
2015-02-26 08:50:28 +03:00
ssize_t dm_attr_rq_based_seq_io_merge_deadline_show ( struct mapped_device * md , char * buf ) ;
ssize_t dm_attr_rq_based_seq_io_merge_deadline_store ( struct mapped_device * md ,
const char * buf , size_t count ) ;
2005-04-17 02:20:36 +04:00
# endif