From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 6 Aug 2015 12:12:58 +0200 (CEST) Message-ID: <55C3331C.7020301@freescale.com> Date: Thu, 6 Aug 2015 13:12:44 +0300 From: Vasile Catalin-B50542 MIME-Version: 1.0 References: <55C3060B.6030206@freescale.com> <55C325AE.6070604@gmail.com> In-Reply-To: <55C325AE.6070604@gmail.com> Content-Type: multipart/alternative; boundary="------------020202020101000106090602" Subject: Re: [dm-crypt] out of order encryption List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz Cc: dm-crypt@saout.de --------------020202020101000106090602 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit I was referring to the submitted requests. Does the underlying encryption layer (CryptoAPI) have to ensure the complete callbacks are called in the order the requests were submitted? Or does dm-crypt figure out where to read/write after request is done no matter in which order the crypto requests finished? On 06.08.2015 12:15, Milan Broz wrote: > On 08/06/2015 09:00 AM, Vasile Catalin-B50542 wrote: >> Would dm-crypt execute correctly if sector encryption ended asynchronously? >> For example: >> If sector 1, 2, 3 are sent to be done asynchronously to the same >> algorithm instance, >> and the jobs end in the following order: 2, 1, 3; does the dm-crypt >> module know to >> write the data in the proper place when the encryption "done" callback >> is called? > Not sure if I understand your question - encryption in dmcrypt works on sector > level, sectors are encrypted independetly, so order cannot influence result > of encryption of individual sectors. > > Or if the question is about order of submitted requests: > If you need to ensure order of processing, you have to issue "flush" operation > before submitting next data content. Filesystems typically must do this when > handling journal or so. > > In general, requests order can be rearranged (anywhere in block layer, not only in dmcrypt). > But this is correct behaviour. > > Milan -- CatalinVasile Intern, DN-Software FreescaleSemiconductor, Inc. www.freescale.com phone: 073-021-1938 e-mail: catalin.vasile@freescale.com *Freescale_Logo-nosemi_Lh_4c*** This e-mail, and any associated attachments have been classified as: [ ] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary --------------020202020101000106090602 Content-Type: multipart/related; boundary="------------090309060305000001060106" --------------090309060305000001060106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit I was referring to the submitted requests.
Does the underlying encryption layer (CryptoAPI) have to ensure the
complete callbacks are called in the order the requests were submitted?
Or does dm-crypt figure out where to read/write after request is done
no matter in which order the crypto requests finished?

On 06.08.2015 12:15, Milan Broz wrote:

On 08/06/2015 09:00 AM, Vasile Catalin-B50542 wrote:

Would dm-crypt execute correctly if sector encryption ended asynchronously?
For example:
If sector 1, 2, 3 are sent to be done asynchronously to the same 
algorithm instance,
and the jobs end in the following order: 2, 1, 3; does the dm-crypt 
module know to
write the data in the proper place when the encryption "done" callback 
is called?

Not sure if I understand your question - encryption in dmcrypt works on sector
level, sectors are encrypted independetly, so order cannot influence result
of encryption of individual sectors.

Or if the question is about order of submitted requests:
If you need to ensure order of processing, you have to issue "flush" operation
before submitting next data content. Filesystems typically must do this when
handling journal or so.

In general, requests order can be rearranged (anywhere in block layer, not only in dmcrypt).
But this is correct behaviour.

Milan

Catalin Vasile

Intern, DN-Software

Freescale Semiconductor, Inc.

www.freescale.com

phone: 073-021-1938

e-mail: catalin.vasile@freescale.com

This e-mail, and any associated attachments have been classified as:

[ ] Public

[ ] Freescale Semiconductor Internal Use Only

[ ] Freescale Semiconductor Confidential Proprietary

--------------090309060305000001060106 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="image002.gif" R0lGODlhwwBJAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALBkA EACeACgAhwAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBm ZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNm ZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2Zm ZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/ Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lm ZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/ Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xm ZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszMmczMzMzM/8z/AMz/M8z/ Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8zmf8zzP8z//9mAP9mM/9m Zv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/Mmf/MzP/M////AP//M/// Zv//mf//zP///wECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwj/AAEIHEiwIEFoBhMqXMiwocOHECNKnDgxGjRhyTxdi0ax o8ePIEOKHHhRmLBgJpNxHMmypcuXDFsBSIbskrBOwmwiQwizp8+fHZWZNIkyGLKdAp1Zuwa0 qVOn0UzinAqNJ4Bn1I5RU/q0q9eR2KAlOyls50przpo1c3ZsLQCmX+PKnQitlEBsz9I2O5aW rTNo2OYKHuzwmjO9atVyFTjWKuHHg6EdZrt360BTyYwGS5bMMeTPXtFScysw2liURIN5Bs36 KTWeY2/mvMm5te24pokO3Xy7t1dsymLbFBZtpe/jMK1Bg2uxrErk0FuG7essuvWezxIntna9 e0i0eylr/60OAFtg7+gdQhutXe0z7mE7K4t4Pv1xa3zzp10qsORmuwtdEcAVLLBwhX0dBRCA T9HAJVBeaz0zkFC6oWbcQK0IqKCCgiAoEQsbLvhSKWMVR9J7pdE01WyeQHOhQBpuyIKHEgki o3RikYVRZwWVVCFnqwHQCogKFjgjjQ8JEuOBLJWEk02XPFdQbDjxVl9BBG5okJJ3yYTlka14 qRCBd115V4cAkLmQIEdegWZBXqpp3kAFbvimQEPC+CaTYhLEGWq7JTMfAKuNhQwALw4UY5Ec AmAkC0oa+OajARTo5pZZgmhgn0JeIaCmkhYUKaiXDoSNp3VqWqpAIYo5aqVGBv+W4aoTJmPT isJYVU0zW3E3YUNEhqjgFUPKuKGXdQo74JsZKnsshsEKuymM0crI5KnVhqiotgIp6WyBQip5 p59DIZMMXOAldliQCWULq43KHumultsyKiyTWdobYpv7Jlspk8G6uSiT8FbabbwyjqsQNJ4k IxBTh+nH12JJEgkutTLWmWbCAiV7xXk3DsRtjGASCCmdG5aqaoefDohyo46m3HHKyMo8UXbt 8fqMgxBZPGnGccroqs3BCnJes40GzORd9Ro8kLjncRmmyPTG3OiSBAV7ZESGhcdXMxImWCRB +xJUsIGeshmy0mmH2KG0kLoZNccVV0u1guXtK66n3Db/FM152FiTrlLsNrQotCHP7GyIH88r bJiL6t3KqYknFFi+yhKs9+LSPjSWwwRZE7ZHWB9c5NIFc14pNo6P3LKygng77ELYqM0o5vim /LbqszPEGVnmthTwy06bXnxCtovoUOyalj38QgHXDPPwASv8UFm3zpaMmR4FK+bzxgfQZ6iK G0hQKwHcKUifyR8IPgCxd1i7zayOrXj6VuOPIYGc9jiUbJtRRqI8IrSmKQ9+jCtPh4h0IKS5 LFw+K9aMjHa/BbotdhsbEOsKmD/zAcBYGcTb5EJovVbYSjZUKQ9LUkeQ0hFvWdGSX7TQti/0 Mc5NWgtM6gbkrwORzE33QpPPeoQkrEhVriDK8A9GBOgSF+brZGbjHBTvl7nJRU5aaCrW4tC0 w8zByGYOjNfSFvY57onEYkurYUFq17wibQ1xlUrZGIektX+x73WwEhMdM1a6BHYLjyCy3nVa oaS0MaSQnuqfkAjpKWIpEn6FLGEkOxK7Rj4SSZikSEAAADs= --------------090309060305000001060106-- --------------020202020101000106090602--