lkml.org 
[lkml]   [2013]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: dm-crypt parallelization patches
On Tue, Apr 09, 2013 at 04:32:28PM -0400, Mikulas Patocka wrote:

[..]
> Generally, we shouldn't associate bios with "current" task in device
> mapper targets. For example suppose that we have two stacked dm-crypt
> targets:
>
> In the "current" process pointer in lower dm-crypt target's request
> function always points to the workqueue of the upper dm-crypt target that
> submits the bios. So if we associate the bio with "current" in the lower
> target, we are associating it with a preallocated workqueue and we already
> lost the information who submitted it.
>
> You should associate a bio with a task when you create the bio and "md"
> and "dm" midlayers should just forward this association to lower layer
> bios.

bio_associate_current() return -EBUSY if bio has already been associated
with an io context.

So in a stack if every driver calls bio_associate_current(), upon bio
submission, it will automatically amke sure bio gets associated with
submitter task in top level device and calls by lower level device
will be ignored.

Lower level devices I think just need to make sure this context
info is propogated to cloned bios.


[..]
> +#ifdef CONFIG_BLK_CGROUP
> + tio->clone.bi_ioc = ci->bio->bi_ioc;
> + tio->clone.bi_css = ci->bio->bi_css;

You also need to take references to ioc and css objects. I guess a helper
function will be better. May be something like.

bio_associate_bio_context(bio1, bio2)

And this initialize bio2's context with bio1's context.

Thanks
Vivek


\
 
 \ /
  Last update: 2013-04-09 23:41    [W:0.104 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site