[dm-cache] remove basic and debug policies.  I'm going to put them in
a separate, less stable, branch.
dm cache: use sector_div rather than do_div in oblock_to_dblock
dm cache: sectors_per_block doesn't need to be 64 bits

mikulas: dm doesn't allow larger values than unsigned anyway.
dm cache: rename tmp to discard_blocks in oblock_to_dblock
dm cache: optimize sectors_per_block division in oblock_to_dblock
dm cache: fix whitespace damage I recently introduced
[dm-cache] remove some dead struct fields from mq policy
Merge branch 'remove-basic-policy' into thin-dev
dm cache policy mq: add missing initialization in iot_init
Merge branch 'thin-dev-next' of https://github.com/snitm/linux into thin-dev-next
[dm-cache] correct function comment in dm-cache-policy.h
[dm-cache] simplify writethrough implementation.

When the cache is in writethrough mode it needs to send WRITE bios to
both the origin and cache devices.

Previously we've been implementing this by having dm core query the
cache target on every write to find out how many copies of the bio it
wants.  The cache will ask for two bios if the block is in the cache,
and one otherwise.

Then main problem with this is it's racey.  At the time this check is
made the bio hasn't yet been submitted and so isn't being taken into
account when quiescing a block for migration (promotion or demotion).
This means a single bio may be submitted when two were needed because
the block has since been promoted to the cache (catastrophic), or two
bios where only one is needed (harmless).

I really don't want to start entering bios into the quiescing system
(deferred_set) in the get_num_write_bios callback.  Instead this patch
simplifies things; only one bio is submitted by the core, this is
first written to the origin and then the cache device in series.
Obviously this will have a latency impact.
[dm-cache] whitespace
[dm-cache] When writing the dirty bitset to the metadata device on clean shutdown, dirty bits were never being set to clean.

Harmless bug.
[dm-thin] Fix a bug in dm_btree_remove that could leave leaf values with incorrect reference counts.

Thinp uses a 2 level nested btree to store it's mappings.  This first
level is indexed by thin device, and the second level by logical
block.

Often when we're removing an entry in this mapping tree we need to
rebalance nodes, which can involve shadowing them, possibly creating a
copy if the block is shared.  If we do create a copy then children of
that node need to have their reference counts incremented.  In this
way reference counts percolate down the tree as shared trees diverge.

The rebalance functions were incrementing the children at the
appropriate time, but they were always assuming the children were
internal nodes.  This meant the leaf values (in our case packed
block/flags entries) were not being incremented.

The effect of this was removal of a shared block could result in the
space maps thinking the block was no longer used.  More concretely, if
you have a thin device and a snapshot of it, sending a discard to a
shared region of the thin could corrupt the snapshot.
[dm-cache] introduce block_div to squash various 32bit link errors.