From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (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 07:14:24 +0200 (CEST) Date: Wed, 23 Sep 2020 22:14:19 -0700 From: Eric Biggers Message-ID: <20200924051419.GA16103@sol.localdomain> References: <1600281606-1446-1-git-send-email-sudhakar.panneerselvam@oracle.com> <3be1ea32-b6a8-41ef-a9ba-ed691434d068@default> <20200924012732.GA10766@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200924012732.GA10766@redhat.com> 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: 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, Milan Broz , agk@redhat.com 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? - Eric From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Subject: Re: [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Date: Wed, 23 Sep 2020 22:14:19 -0700 Message-ID: <20200924051419.GA16103@sol.localdomain> References: <1600281606-1446-1-git-send-email-sudhakar.panneerselvam@oracle.com> <3be1ea32-b6a8-41ef-a9ba-ed691434d068@default> <20200924012732.GA10766@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20200924012732.GA10766@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com Content-Disposition: inline To: Mike Snitzer Cc: Damien.LeMoal@wdc.com, ssudhakarp@gmail.com, Martin Petersen , dm-crypt@saout.de, Sudhakar Panneerselvam , dm-devel@redhat.com, Shirley Ma , mpatocka@redhat.com, Milan Broz , agk@redhat.com List-Id: dm-devel.ids 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? - Eric