linux.git/drivers/md/dm-crypt.c, branch v2.6.30

dm crypt: use kzfree

2009-04-02T18:55:28+00:00

Use kzfree() instead of memset() + kfree().

Signed-off-by: Johannes Weiner 
Reviewed-by: Pekka Enberg 
Signed-off-by: Andrew Morton 
Signed-off-by: Alasdair G Kergon

dm crypt: wait for endio to complete before destruction

2009-03-16T17:44:36+00:00

The following oops has been reported when dm-crypt runs over a loop device.

...
[   70.381058] Process loop0 (pid: 4268, ti=cf3b2000 task=cf1cc1f0 task.ti=cf3b2000)
...
[   70.381058] Call Trace:
[   70.381058]  [] ? crypt_dec_pending+0x5e/0x62 [dm_crypt]
[   70.381058]  [] ? crypt_endio+0xa2/0xaa [dm_crypt]
[   70.381058]  [] ? crypt_endio+0x0/0xaa [dm_crypt]
[   70.381058]  [] ? bio_endio+0x2b/0x2e
[   70.381058]  [] ? dec_pending+0x224/0x23b [dm_mod]
[   70.381058]  [] ? clone_endio+0x79/0xa4 [dm_mod]
[   70.381058]  [] ? clone_endio+0x0/0xa4 [dm_mod]
[   70.381058]  [] ? bio_endio+0x2b/0x2e
[   70.381058]  [] ? loop_thread+0x380/0x3b7
[   70.381058]  [] ? do_lo_send_aops+0x0/0x165
[   70.381058]  [] ? autoremove_wake_function+0x0/0x33
[   70.381058]  [] ? loop_thread+0x0/0x3b7

When a table is being replaced, it waits for I/O to complete
before destroying the mempool, but the endio function doesn't
call mempool_free() until after completing the bio.

Fix it by swapping the order of those two operations.

The same problem occurs in dm.c with md referenced after dec_pending.
Again, we swap the order.

Cc: stable@kernel.org
Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: fix kcryptd_async_done parameter

2009-03-16T17:44:33+00:00

In the async encryption-complete function (kcryptd_async_done), the
crypto_async_request passed in may be different from the one passed to
crypto_ablkcipher_encrypt/decrypt.  Only crypto_async_request->data is
guaranteed to be same as the one passed in.  The current
kcryptd_async_done uses the passed-in crypto_async_request directly
which may cause the AES-NI-based AES algorithm implementation to panic.

This patch fixes this bug by only using crypto_async_request->data,
which points to dm_crypt_request, the crypto_async_request passed in.
The original data (convert_context) is gotten from dm_crypt_request.

[mbroz@redhat.com: reworked]
Cc: stable@kernel.org
Signed-off-by: Huang Ying 
Cc: Herbert Xu 
Signed-off-by: Milan Broz 
Signed-off-by: Andrew Morton 
Signed-off-by: Alasdair G Kergon

dm: consolidate target deregistration error handling

2009-01-06T03:04:58+00:00

Change dm_unregister_target to return void and use BUG() for error
reporting.

dm_unregister_target can only fail because of programming bug in the
target driver. It can't fail because of user's behavior or disk errors.

This patch changes unregister_target to return void and use BUG if
someone tries to unregister non-registered target or unregister target
that is in use.

This patch removes code duplication (testing of error codes in all dm
targets) and reports bugs in just one place, in dm_unregister_target. In
some target drivers, these return codes were ignored, which could lead
to a situation where bugs could be missed.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon

bio: allow individual slabs in the bio_set

2008-12-29T07:29:23+00:00

Instead of having a global bio slab cache, add a reference to one
in each bio_set that is created. This allows for personalized slabs
in each bio_set, so that they can have bios of different sizes.

This means we can personalize the bios we return. File systems may
want to embed the bio inside another structure, to avoid allocation
more items (and stuffing them in ->bi_private) after the get a bio.
Or we may want to embed a number of bio_vecs directly at the end
of a bio, to avoid doing two allocations to return a bio. This is now
possible.

Signed-off-by: Jens Axboe

dm crypt: remove waitqueue

2008-10-21T16:45:03+00:00

Remove waitqueue no longer needed with the async crypto interface.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: fix async split

2008-10-21T16:45:02+00:00

When writing io, dm-crypt has to allocate a new cloned bio
and encrypt the data into newly-allocated pages attached to this bio.
In rare cases, because of hw restrictions (e.g. physical segment limit)
or memory pressure, sometimes more than one cloned bio has to be used,
each processing a different fragment of the original.

Currently there is one waitqueue which waits for one fragment to finish
and continues processing the next fragment.

But when using asynchronous crypto this doesn't work, because several
fragments may be processed asynchronously or in parallel and there is
only one crypt context that cannot be shared between the bio fragments.
The result may be corruption of the data contained in the encrypted bio.

The patch fixes this by allocating new dm_crypt_io structs (with new
crypto contexts) and running them independently.

The fragments contains a pointer to the base dm_crypt_io struct to
handle reference counting, so the base one is properly deallocated
after all the fragments are finished.

In a low memory situation, this only uses one additional object from the
mempool.  If the mempool is empty, the next allocation simple waits for
previous fragments to complete.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm crypt: tidy sector

2008-10-21T16:45:00+00:00

Prepare local sector variable (offset) for later patch.
Do not update io->sector for still-running I/O.

No functional change.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon

dm: remove dm header from targets

2008-10-21T16:44:59+00:00

Change #include "dm.h" to #include  in all targets.
Targets should not need direct access to internal DM structures.

Signed-off-by: Mikulas Patocka 
Signed-off-by: Alasdair G Kergon

dm crypt: avoid unnecessary wait when splitting bio

2008-10-10T12:37:08+00:00

Don't wait between submitting crypt requests for a bio unless
we are short of memory.

There are two situations when we must split an encrypted bio:
  1) there are no free pages;
  2) the new bio would violate underlying device restrictions
(e.g. max hw segments).

In case (2) we do not need to wait.

Add output variable to crypt_alloc_buffer() to distinguish between
these cases.

Signed-off-by: Milan Broz 
Signed-off-by: Alasdair G Kergon