[dm-thin] revert the recent inc_ds patch

I'll find the issue later.
[dm-thin] Add a thin_merge() fn.

http://www.redhat.com/archives/dm-devel/2013-September/msg00001.html

^^ Means we must define one, otherwise merge size will be 1 page.
[dm-cache] reinstate the inc_ds patch.

Was broken by a bad merge with something of Mike's.
[dm-cache] another stab at the inc_ds() tidy up
[dm-thin] remove bogus thin_merge fn.

It wasn't adjusting the sector, which we can't do in a race free way.
[dm-thin] Introduce an atomic_t to keep track of pending preparations for a new block.

Previously we used separate bools to track quiescing and copying
actions.  By making this we'll be able to support blocks that need a
partial copy and partial zero.
[dm-thin] Track the size of any external origin.
[dm-thin] Now supports external origins with different size to the snapshot.

Previously the external origin had to be a multiple of the block size
in size.  And we didn't support snapshots that were larger than the
origin.
[writeboost] Use dm_kcopyd_zero to zero out a region

Memory allocation by vmalloc may fail if kernel outside Writeboost
allocated lot of memory before Writeboost does. This because the total
amount of vmalloc-ed space is limited. So, generally, using vmalloc is
not preferable in kernel.

This patch uses dm_kcopyd_zero routine to zero out region in device.
Using this routine instead can remove dependency to vmalloc to get
zero-filled buffer.

do_zeroing_region() wrapper is defined to do this work synchonously and two
other routines (zeroing_full_superblock and do_clear_plog_dev_t1) use it
now. As a result, no vmalloc() can be seen in Writeboost.

Signed-off-by: Akira Hayakawa <ruby.wktk@gmail.com>
Merge pull request #16 from akiradeveloper/feature/use-kcopy-zero-for-zeroing-v2

[writeboost] Use dm_kcopyd_zero to zero out a region
[dm-io] Fix a race condition in the wake up code for sync_io

There's a race condition between the atomic_dec_and_test(&io->count)
in dec_count() and the waking of the sync_io() thread.  If the thread
is spuriously woken immediately after the decrement it may exit,
making the on the stack io struct invalid, yet the dec_count could
still be using it.

There are smaller fixes than the one here (eg, just take the io object
off the stack).  But I feel this code could use a clean up.

- simplify dec_count().

  - It always calls a callback fn now.
  - It always frees the io object back to the pool.

- sync_io()

  - Take the io object off the stack and allocate it from the pool the
    same as async_io.
  - Use a completion object rather than an explicit io_schedule()
    loop.  The callback triggers the completion.

Reported by: Minfei Huang
Merge branch 'thin-dev' of github.com:jthornber/linux-2.6 into thin-dev
[dm-cache] Change nr_dirty to be an atomic_t.

People were seeing under runs due to a race on increment/decrement of
this variable.
From: Satoru Takeuchi <satoru.takeuchi@gmail.com>

If users set a very large value to nr_rambuf_pool argument, kernel would hit
BUG() in the error route of init_rambuf_pool().

drivers/md/dm-writeboost-metadata.c:
===============================================================================
...
static int init_rambuf_pool(struct wb_device *wb)
{
        int r = 0;
        size_t i;

        wb->rambuf_pool = kmalloc(sizeof(struct rambuffer) * wb->nr_rambuf_pool,
                                  GFP_KERNEL);
        if (!wb->rambuf_pool)                   # It is true here.
                return -ENOMEM;

        wb->rambuf_cachep = kmem_cache_create("dmwb_rambuf",
                        1 << (wb->segment_size_order + SECTOR_SHIFT),
                        1 << (wb->segment_size_order + SECTOR_SHIFT),
                        SLAB_RED_ZONE, NULL);
        if (!wb->rambuf_cachep) {
                r = -ENOMEM;                    # Enter this route or ....
                goto bad_cachep;
        }

        for (i = 0; i < wb->nr_rambuf_pool; i++) {
                size_t j;
                struct rambuffer *rambuf = wb->rambuf_pool + i;

                rambuf->data = kmem_cache_alloc(wb->rambuf_cachep, GFP_KERNEL);
                if (!rambuf->data) {
                        ...                     # ... enter this route.
                        goto bad_alloc_data;
                }
                check_buffer_alignment(rambuf->data);
        }

        return r;

bad_alloc_data:
        kmem_cache_destroy(wb->rambuf_cachep);
bad_cachep:
        kfree(wb->rambuf_pool);
        BUG();                                  # Kernel panic happens here.
        return r;
}
...
===============================================================================

Probably this BUG() was introduced erroneously and is safe to remove.

Signed-off-by: Satoru Takeuchi <satoru.takeuchi@gmail.com>
Cc: Joe Thornber <ejt@redhat.com>
Cc: Akira Hayakawa <ruby.wktk@gmail.com>
Merge pull request #17 from satoru-takeuchi/dmwb-bugfix

From: Satoru Takeuchi <satoru.takeuchi@gmail.com>