Skip to content

L
linux
Switch branch/tag
  1. 17 Jan, 2018 16 commits
  3. 06 Jan, 2018 2 commits
  5. 05 Jan, 2018 1 commit
    • Mike Snitzer's avatar
      dm mpath: implement NVMe bio-based support · cd025384
      Mike Snitzer authored 
      This DM multipath NVMe bio-based support requires CONFIG_NVME_MULTIPATH
to not be set.  In the future hopefully NVMe multipath and DM multipath
can co-exist more seemlessly.  But as is, if CONFIG_NVME_MULTIPATH=Y
then all the individal NVMe paths will remain hidden to upper layers and
as such DM multipath will not be able to manage them.

Though NVMe's native multipathing doesn't multipath namespaces across
subsystems; so technically a user _could_ use CONFIG_NVME_MULTIPATH=Y
and also use DM multipath to multipath across subsystems.
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      cd025384
  7. 03 Jan, 2018 1 commit
  9. 20 Dec, 2017 5 commits
  11. 17 Dec, 2017 6 commits
  13. 13 Dec, 2017 9 commits
    • Mike Snitzer's avatar
      dm: set QUEUE_FLAG_DAX accordingly in dm_table_set_restrictions() · ad3793fc
      Mike Snitzer authored 
      Rather than having DAX support be unique by setting it based on table
type in dm_setup_md_queue().
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      ad3793fc
    • Mike Snitzer's avatar
      dm: fix __send_changing_extent_only() to send first bio and chain remainder · 3d7f4562
      Mike Snitzer authored 
      __send_changing_extent_only() must follow the same pattern that was
established with commit "dm: ensure bio submission follows a depth-first
tree walk".  That is: submit first bio up to split boundary and then
split the remainder to further submissions.
Suggested-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      3d7f4562
    • Mike Snitzer's avatar
      dm: ensure bio-based DM's bioset and io_pool support targets' maximum IOs · 0776aa0e
      Mike Snitzer authored 
      alloc_multiple_bios() assumes it can allocate the requested number of
bios but until now there was no gaurantee that the mempools would be
accomodating.
Suggested-by: default avatarMikulas Patocka <mpatocka@redhat.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      0776aa0e
    • Mike Snitzer's avatar
      dm: remove BIOSET_NEED_RESCUER based dm_offload infrastructure · 4a3f54d9
      Mike Snitzer authored 
      Now that all of DM has been revised and/or verified to no longer require
the use of BIOSET_NEED_RESCUER the dm_offload code may be removed.
Suggested-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      4a3f54d9
    • Mike Snitzer's avatar
      dm: safely allocate multiple bioset bios · 318716dd
      Mike Snitzer authored 
      DM targets can request multiple bios be sent to them by DM core (see:
num_{flush,discard,write_same,write_zeroes}_bios).  But until now these
bios were allocated in an unsafe manner than could potentially exhaust
the DM device's bioset -- in the face of multiple threads each trying to
do multiple allocations from the same DM device's bioset.

Fix __send_duplicate_bios() by using the new alloc_multiple_bios().  The
allocation strategy used by alloc_multiple_bios() models that used by
dm-crypt.c:crypt_alloc_buffer().

Neil Brown initially proposed this fix but the implementation has been
revised enough that it inappropriate to attribute the entirety of it to
him.
Suggested-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      318716dd
    • NeilBrown's avatar
      dm: remove unused 'num_write_bios' target interface · f31c21e4
      NeilBrown authored 
      No DM target provides num_write_bios and none has since dm-cache's
brief use in 2013.

Having the possibility of num_write_bios > 1 complicates bio
allocation.  So remove the interface and assume there is only one bio
needed.

If a target ever needs more, it must provide a suitable bioset and
allocate itself based on its particular needs.
Signed-off-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      f31c21e4
    • NeilBrown's avatar
      dm: ensure bio submission follows a depth-first tree walk · 18a25da8
      NeilBrown authored 
      A dm device can, in general, represent a tree of targets, each of which
handles a sub-range of the range of blocks handled by the parent.

The bio sequencing managed by generic_make_request() requires that bios
are generated and handled in a depth-first manner.  Each call to a
make_request_fn() may submit bios to a single member device, and may
submit bios for a reduced region of the same device as the
make_request_fn.

In particular, any bios submitted to member devices must be expected to
be processed in order, so a later one must never wait for an earlier
one.

This ordering is usually achieved by using bio_split() to reduce a bio
to a size that can be completely handled by one target, and resubmitting
the remainder to the originating device. bio_queue_split() shows the
canonical approach.

dm doesn't follow this approach, largely because it has needed to split
bios since long before bio_split() was available.  It currently can
submit bios to separate targets within the one dm_make_request() call.
Dependencies between these targets, as can happen with dm-snap, can
cause deadlocks if either bios gets stuck behind the other in the queues
managed by generic_make_request().  This requires the 'rescue'
functionality provided by dm_offload_{start,end}.

Some of this requirement can be removed by changing the order of bio
submission to follow the canonical approach.  That is, if dm finds that
it needs to split a bio, the remainder should be sent to
generic_make_request() rather than being handled immediately.  This
delays the handling until the first part is completely processed, so the
deadlock problems do not occur.

__split_and_process_bio() can be called both from dm_make_request() and
from dm_wq_work().  When called from dm_wq_work() the current approach
is perfectly satisfactory as each bio will be processed immediately.
When called from dm_make_request(), current->bio_list will be non-NULL,
and in this case it is best to create a separate "clone" bio for the
remainder.

When we use bio_clone_bioset() to split off the front part of a bio
and chain the two together and submit the remainder to
generic_make_request(), it is important that the newly allocated
bio is used as the head to be processed immediately, and the original
bio gets "bio_advance()"d and sent to generic_make_request() as the
remainder.  Otherwise, if the newly allocated bio is used as the
remainder, and if it then needs to be split again, then the next
bio_clone_bioset() call will be made while holding a reference a bio
(result of the first clone) from the same bioset.  This can potentially
exhaust the bioset mempool and result in a memory allocation deadlock.

Note that there is no race caused by reassigning cio.io->bio after already
calling __map_bio().  This bio will only be dereferenced again after
dec_pending() has found io->io_count to be zero, and this cannot happen
before the dec_pending() call at the end of __split_and_process_bio().

To provide the clone bio when splitting, we use q->bio_split.  This
was previously being freed by bio-based dm to avoid having excess
rescuer threads.  As bio_split bio sets no longer create rescuer
threads, there is little cost and much gain from restoring the
q->bio_split bio set.
Signed-off-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      18a25da8
    • NeilBrown's avatar
      dm io: remove BIOSET_NEED_RESCUER flag from bios bioset · c110a4b6
      NeilBrown authored 
      The BIOSET_NEED_RESCUER flag is only needed when a make_request_fn might
do two allocations from the one bioset, and the second one could block
until the first bio completes.

dm_io() is called from make_request_fn() context.  The closest it comes
to multiple allocations is in chunk_io() in dm-snap-persistent.  But
there the code uses a separate thread to avoid problems.

So BIOSET_NEED_RESCUER is not needed.
Signed-off-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      c110a4b6
    • NeilBrown's avatar
      dm crypt: remove BIOSET_NEED_RESCUER flag · 80cd1757
      NeilBrown authored 
      The BIOSET_NEED_RESCUER flag is only needed when a make_request_fn might
do two allocations from the one bioset, and the second one could block
until the first bio completes.

dm-crypt does allocate from this bioset inside the dm make_request_fn,
but does so using GFP_NOWAIT so that the allocation will not block.

So BIOSET_NEED_RESCUER is not needed.
Signed-off-by: default avatarNeilBrown <neilb@suse.com>
Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      80cd1757
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7