linux-kernel - Re: [dm-devel] Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request() to be called from interrupt context

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 21 Dec 2006 12:57:49 -0600
From:	Mike Christie <michaelc@...wisc.edu>
To:	Jens Axboe <jens.axboe@...cle.com>
CC:	device-mapper development <dm-devel@...hat.com>,
	mchristi@...hat.com, linux-kernel@...r.kernel.org, agk@...hat.com
Subject: Re: [dm-devel] Re: [RFC PATCH 1/8] rqbased-dm: allow blk_get_request()
  to be called from interrupt context

Jens Axboe wrote:
> On Thu, Dec 21 2006, Mike Christie wrote:
>> Mike Christie wrote:
>>> Jens Axboe wrote:
>>>> On Thu, Dec 21 2006, Mike Christie wrote:
>>>>> Or the block layer code could set up the clone too. elv_next_request
>>>>> could prep a clone based on the orignal request for the driver then dm
>>>>> would not have to worry about that part.
>>>> It really can't, since it doesn't know how to allocate the clone
>>>> request. I'd rather export this functionality as helpers.
>>>>
>>> What do you think about dm's plan to break up make_request into a
>>> mapping function and in to the part the builds the bio into a request.
>>> This would fit well with them being helpers and being able to allocate
>>> the request from the correct context.
>>>
>>> I see patches for that did not get posted, but I thought Joe and
>>> Alasdair used to talk about that a lot and in the dm code I think there
>>> is sill comments about doing it. Maybe the dm comments mentioned the
>>> merge_fn, but I guess the merge_fn did not fit what they wanted to do or
>>> something. I think Alasdair talked about this at one of his talks at OLS
>>> or it was in a proposal for the kernel summit. I can dig up the mail if
>>> you want.
>>>
>> Ignore that. The problem would be that we may not want to decide which
>> path to use at map time.
> 
> Latter part, or both paragraphs? Dipping into ->make_request_fn() for
> some parts do seem to make sense to me. It'll be cheaper than at
> potential soft irq time (from elv_next_request()).
> 

I think we got crisscrossed.

The original idea but using your helper suggestion would have been this:

dm->make_request_fn(bio)
{
	rq = __make_request(bio)
	if (this is a new request) {
		allocate clone from either a real device/path specific mempool() or a
dm q mempool
}


dm->prep_fn(rq)
{
	setup clone rq fields based on orig request fields.
}

dm->request_fn(rq)
{
	figure out which path to use;
	set rq->q;
	send cloned rq to real device;
}


The second idea based on Joe and Alasdair to break up make_request would
just have been a more formal break up of the dm->make_request_fn above,
because I thought your comment about not knowing how to allocate the
clone request meant that we did not know which q's mempool to take the
request from if we were going to take the cloned request from the real
device/path's mempool. I guess this does not really matter since we can
have just a dm q mempool of requests to use for cloned requests.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/