From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from userp2120.oracle.com (userp2120.oracle.com [156.151.31.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Thu, 24 Sep 2020 18:55:12 +0200 (CEST) MIME-Version: 1.0 Message-ID: <378f445c-2136-4d17-ac2f-355b7850d28a@default> Date: Thu, 24 Sep 2020 09:55:01 -0700 (PDT) From: Sudhakar Panneerselvam Sender: Sudhakar Panneerselvam References: <1600281606-1446-1-git-send-email-sudhakar.panneerselvam@oracle.com> <3be1ea32-b6a8-41ef-a9ba-ed691434d068@default> <20200924012732.GA10766@redhat.com> <20200924051419.GA16103@sol.localdomain> <1c44946e-9661-16f7-1c38-32d666b55fb2@gmail.com> In-Reply-To: <1c44946e-9661-16f7-1c38-32d666b55fb2@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [dm-crypt] [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Milan Broz , Eric Biggers , Mike Snitzer Cc: Damien.LeMoal@wdc.com, ssudhakarp@gmail.com, Martin Petersen , dm-crypt@saout.de, dm-devel@redhat.com, Shirley Ma , mpatocka@redhat.com, agk@redhat.com Hello Milan, > -----Original Message----- > From: Milan Broz [mailto:gmazyland@gmail.com] > Sent: Thursday, September 24, 2020 2:16 AM > To: Eric Biggers ; Mike Snitzer > Cc: Sudhakar Panneerselvam ; > Damien.LeMoal@wdc.com; ssudhakarp@gmail.com; Martin Petersen > ; dm-crypt@saout.de; dm-devel@redhat.com; > Shirley Ma ; mpatocka@redhat.com; > agk@redhat.com > Subject: Re: [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer > lengths for skcipher devices >=20 > On 24/09/2020 07:14, Eric Biggers wrote: > > On Wed, Sep 23, 2020 at 09:27:32PM -0400, Mike Snitzer wrote: > >> You've clearly done a nice job with these changes. Looks clean. > >> > >> BUT, I'm struggling to just accept that dm-crypt needs to go to these > >> extra lengths purely because of one bad apple usecase. > >> > >> These alignment constraints aren't new. Are there other portions of > >> Linux's crypto subsystem that needed comparable fixes in order to work > >> with Microsfot OS initiated IO through a guest? > >> > >> You forecast that these same kinds of changes are needed for AEAD and > >> dm-integrity... that's alarming. > >> > >> Are we _certain_ there is no other way forward? > >> (Sorry I don't have suggestions.. I'm in "fact finding mode" ;) > >> > > > > I don't understand why this is needed, since dm-crypt already sets its > > logical_block_size to its crypto sector_size. Isn't it expected that I= /O that > > isn't aligned to logical_block_size fails? It's the I/O submitter's > > responsibility to ensure logical_block_size alignment of all I/O segmen= ts. > > Exactly how is the misaligned I/O actually being submitted here? >=20 > Thanks for mentioning it - exactly that I asked when reading this patch..= . > It seems that we are here fixing a problem that is just caused when someo= ne > ignores clearly set restrictions. >=20 > Who is submitting these bioses? Why can it not be fixed there? >=20 > What happens with writes to fs journals, etc., is it still safe if we are > processing such unaligned bios? I don't follow your question regarding fs journals. I am not sure why it is= not safe to process unaligned bio segment lengths of fs journals writes. C= ould you explain with some example on why that would be a problem? Please see my reply to Eric's/Mike's email, in that, I explained why this i= ssue needs to be fixed in dm-crypt. I hope I have answered to your question= s there. If not, let me know, I will try to answer. Thanks Sudhakar >=20 > Milan From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sudhakar Panneerselvam Subject: Re: [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Date: Thu, 24 Sep 2020 09:55:01 -0700 (PDT) Message-ID: <378f445c-2136-4d17-ac2f-355b7850d28a@default> References: <1600281606-1446-1-git-send-email-sudhakar.panneerselvam@oracle.com> <3be1ea32-b6a8-41ef-a9ba-ed691434d068@default> <20200924012732.GA10766@redhat.com> <20200924051419.GA16103@sol.localdomain> <1c44946e-9661-16f7-1c38-32d666b55fb2@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1c44946e-9661-16f7-1c38-32d666b55fb2@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Milan Broz , Eric Biggers , Mike Snitzer Cc: Damien.LeMoal@wdc.com, ssudhakarp@gmail.com, Martin Petersen , dm-crypt@saout.de, mpatocka@redhat.com, dm-devel@redhat.com, Ma , Shirley, agk@redhat.com List-Id: dm-devel.ids Hello Milan, > -----Original Message----- > From: Milan Broz [mailto:gmazyland@gmail.com] > Sent: Thursday, September 24, 2020 2:16 AM > To: Eric Biggers ; Mike Snitzer > Cc: Sudhakar Panneerselvam ; > Damien.LeMoal@wdc.com; ssudhakarp@gmail.com; Martin Petersen > ; dm-crypt@saout.de; dm-devel@redhat.com; > Shirley Ma ; mpatocka@redhat.com; > agk@redhat.com > Subject: Re: [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer > lengths for skcipher devices > > On 24/09/2020 07:14, Eric Biggers wrote: > > On Wed, Sep 23, 2020 at 09:27:32PM -0400, Mike Snitzer wrote: > >> You've clearly done a nice job with these changes. Looks clean. > >> > >> BUT, I'm struggling to just accept that dm-crypt needs to go to these > >> extra lengths purely because of one bad apple usecase. > >> > >> These alignment constraints aren't new. Are there other portions of > >> Linux's crypto subsystem that needed comparable fixes in order to work > >> with Microsfot OS initiated IO through a guest? > >> > >> You forecast that these same kinds of changes are needed for AEAD and > >> dm-integrity... that's alarming. > >> > >> Are we _certain_ there is no other way forward? > >> (Sorry I don't have suggestions.. I'm in "fact finding mode" ;) > >> > > > > I don't understand why this is needed, since dm-crypt already sets its > > logical_block_size to its crypto sector_size. Isn't it expected that I/O that > > isn't aligned to logical_block_size fails? It's the I/O submitter's > > responsibility to ensure logical_block_size alignment of all I/O segments. > > Exactly how is the misaligned I/O actually being submitted here? > > Thanks for mentioning it - exactly that I asked when reading this patch... > It seems that we are here fixing a problem that is just caused when someone > ignores clearly set restrictions. > > Who is submitting these bioses? Why can it not be fixed there? > > What happens with writes to fs journals, etc., is it still safe if we are > processing such unaligned bios? I don't follow your question regarding fs journals. I am not sure why it is not safe to process unaligned bio segment lengths of fs journals writes. Could you explain with some example on why that would be a problem? Please see my reply to Eric's/Mike's email, in that, I explained why this issue needs to be fixed in dm-crypt. I hope I have answered to your questions there. If not, let me know, I will try to answer. Thanks Sudhakar > > Milan