From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TP2wsxUhWinS for ; Sun, 29 Jan 2012 23:30:52 +0100 (CET) Received: from nm9.bullet.mail.bf1.yahoo.com (nm9.bullet.mail.bf1.yahoo.com [98.139.212.168]) by mail.saout.de (Postfix) with SMTP for ; Sun, 29 Jan 2012 23:30:52 +0100 (CET) References: Message-ID: <1327876251.92493.YahooMailNeo@web161401.mail.bf1.yahoo.com> Date: Sun, 29 Jan 2012 14:30:51 -0800 (PST) From: FAN ZHANG In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1131079492-946446548-1327876251=:92493" Subject: [dm-crypt] dm-crypt design and decision Reply-To: FAN ZHANG List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "dm-crypt@saout.de" ---1131079492-946446548-1327876251=:92493 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I have two questions with the design of dm-crypt.=0A=A0=0A1. Why need call= =A0 kcryptd_queue_io() and =0Akcryptd_queue_crypt() =A0to put request bio t= o io_queue and crypt_queue?=0A=A0=0AActually, for read we could clone a bio= in crypt_map() and call =0Ageneric_make_request() directly=A0and in crypt_= endio(), we simply decrypt the data=0A=A0=0Afor write, we simply encrypt da= ta in crypt_map() and call generic_make_request() to write encrypted bio to= low level block device.=0A=A0=0A=A0=0A=A0=0A=A0=0A2. If we really need to = queue the bio request, why we need two queues instead combining=A0 io_queue= =A0 and crypt_queuetogether?=0A=A0=0A=A0=0A3. Why need to call kcryptd_cryp= t_write_io_submit(io, error, 1) in kcryptd_async_done() to do async write v= ia io_queue instead of call kcryptd_crypt_write_io_submit(io, error, 0) to = do sync write?=0A=A0=0A=A0=0AThanks=0A=A0=0AFan=A0 ---1131079492-946446548-1327876251=:92493 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

I have two questions with the design of d= m-crypt.

1. Why need call kcryptd_queue_io()= and

kcryptd_queue_crypt() to put request bio to io_queue and crypt_queue?=

Actually, for read we could clone a bio i= n crypt_map() and call

generic_make_request() directly and = in crypt_endio(), we simply decrypt the data

for write, we simply encrypt data in cryp= t_map() and call generic_make_request() to write encrypted bio to low level= block device.

2. If we really need to queue the bio req= uest, why we need two queues instead combining io_queue and crypt_queue<= SPAN style=3D"COLOR: black"> together?

3. Why need to call= kcryptd_crypt_write_io_submit(io, error, 1) in kcryptd_async_do= ne() to do async write via io_queue instead of call kcryptd_crypt_write_io_= submit(io, error, 0) to do sync write?<= o:p>

Thanks=

Fan

&n= bsp;

---1131079492-946446548-1327876251=:92493-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ib2imsBUNYtR for ; Mon, 30 Jan 2012 08:53:10 +0100 (CET) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 30 Jan 2012 08:53:09 +0100 (CET) Message-ID: <4F264C62.3030105@redhat.com> Date: Mon, 30 Jan 2012 08:53:06 +0100 From: Milan Broz MIME-Version: 1.0 References: <1327876251.92493.YahooMailNeo@web161401.mail.bf1.yahoo.com> In-Reply-To: <1327876251.92493.YahooMailNeo@web161401.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] dm-crypt design and decision List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: FAN ZHANG Cc: "dm-crypt@saout.de" On 01/29/2012 11:30 PM, FAN ZHANG wrote: > I have two questions with the design of dm-crypt. > 1. Why need call kcryptd_queue_io() and > kcryptd_queue_crypt() to put request bio to io_queue and crypt_queue? > Actually, for read we could clone a bio in crypt_map() and call > generic_make_request() directly and in crypt_endio(), we simply decrypt the data > for write, we simply encrypt data in crypt_map() and call generic_make_request() to write encrypted bio to low level block device. Long time ago it was this way. You cannot block in crypt_map (allocation etc), basically it is deadlock prevention. Imagine stacked dmcrypt mappings, if one device is blocked in crypt_map and waiting for another one to finish IO, it will deadlock. > 2. If we really need to queue the bio request, why we need two queues instead combining io_queueand crypt_queuetogether? the same, deadlock prevention. > 3. Why need to call kcryptd_crypt_write_io_submit(io, error, 1) in > kcryptd_async_done() to do async write via io_queue instead of call > kcryptd_crypt_write_io_submit(io, error, 0) to do sync write? You are probably missing asynchronous encryption path where you cannot submit (generic_make_request()) IO from async callback in interrupt mode. Most of the users use sync path (this include even AES_NI and similar accelerators) but if async crypto driver is used, you have to use separate workqueue for IO processing. For testing, you can force crypto layer to use cryptd and use async path im dmcrypt, just patch dmcrypt using this chunk (and enable proper crypto switches in .config for cryptd) @@ -1267,7 +1267,7 @@ static int crypt_ctr_cipher(struct dm_target *ti, goto bad_mem; ret = snprintf(cipher_api, CRYPTO_MAX_ALG_NAME, - "%s(%s)", chainmode, cipher); + "cryptd(%s(%s-generic))", chainmode, cipher); Milan