From: Mikulas Patocka <mpatocka@redhat.com> To: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com> Cc: Eric Biggers <ebiggers@kernel.org>, Mike Snitzer <snitzer@redhat.com>, Damien.LeMoal@wdc.com, ssudhakarp@gmail.com, Martin Petersen <martin.petersen@oracle.com>, dm-crypt@saout.de, dm-devel@redhat.com, Shirley Ma <shirley.ma@oracle.com>, Milan Broz <gmazyland@gmail.com>, agk@redhat.com Subject: Re: [dm-crypt] [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Date: Thu, 24 Sep 2020 13:50:08 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.2009241345370.4229@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <7b6fdfd5-0160-4bcf-b7ed-d0e51553c678@default> On Thu, 24 Sep 2020, Sudhakar Panneerselvam wrote: > Hi Mikulas, > > > > Windows Guest <--> Vhost-Scsi <--> LIO(scsi/target/blockio) <--> dm-crypt > > <--> iSCSI block device > > > > > > One real example out of my debugging: Windows sends a I/O request with > > > 6656 bytes to vhost-scsi interface. Vhost-scsi uses translate_desc() in > > > drivers/vhost/vhost.c to convert windows user space memory buffers to > > > kernel iovecs. Vhost-scsi then converts the iovecs to sg entries in > > > vhost_scsi_mapal() which is then handed over to "target" subsystem and > > > eventually submitted to dm-crypt. This 6656 bytes IO has got 3 segments, > > > first segment had 1584, second 4096 and the last had 976 bytes. Dm-crypt > > > rejects the I/O after seeing the first segment length 1584 which is not > > > a 512 byte multiple. > > > > > > Let me know if there are further questions. > > > > > > Thanks > > > Sudhakar > > > > Hi > > > > I think it should be fixed in vhost-scsi. > > In the above example of 6656 bytes I/O, windows allocates 6656 bytes > virtually contiguous I/O. This IO, when it lands in the kernel, > translates to 3 physically discontiguous pages, that's why > translate_desc() had to create 3 iovecs to handle this I/O. I don't > understand how vhost-scsi could have solved this issue. By copying it to a temporary aligned buffer and issuing I/O on this buffer. > Only other > possibility I see is to have windows fix it by always sending 512 byte > aligned buffer lengths, but going with my earlier point that every other > component in the Linux IO path handles this case well except for > dm-crypt, so it make more sense to fix it in dm-crypt. > > Thanks > Sudhakar Are you sure that the problem is only with dm-crypt? You haven't tried all the existing block device drivers, have you? Mikulas
WARNING: multiple messages have this Message-ID (diff)
From: Mikulas Patocka <mpatocka@redhat.com> To: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com> Cc: Damien.LeMoal@wdc.com, ssudhakarp@gmail.com, Mike Snitzer <snitzer@redhat.com>, dm-crypt@saout.de, Eric Biggers <ebiggers@kernel.org>, dm-devel@redhat.com, Shirley Ma <shirley.ma@oracle.com>, Martin Petersen <martin.petersen@oracle.com>, Milan Broz <gmazyland@gmail.com>, agk@redhat.com Subject: Re: [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Date: Thu, 24 Sep 2020 13:50:08 -0400 (EDT) [thread overview] Message-ID: <alpine.LRH.2.02.2009241345370.4229@file01.intranet.prod.int.rdu2.redhat.com> (raw) In-Reply-To: <7b6fdfd5-0160-4bcf-b7ed-d0e51553c678@default> On Thu, 24 Sep 2020, Sudhakar Panneerselvam wrote: > Hi Mikulas, > > > > Windows Guest <--> Vhost-Scsi <--> LIO(scsi/target/blockio) <--> dm-crypt > > <--> iSCSI block device > > > > > > One real example out of my debugging: Windows sends a I/O request with > > > 6656 bytes to vhost-scsi interface. Vhost-scsi uses translate_desc() in > > > drivers/vhost/vhost.c to convert windows user space memory buffers to > > > kernel iovecs. Vhost-scsi then converts the iovecs to sg entries in > > > vhost_scsi_mapal() which is then handed over to "target" subsystem and > > > eventually submitted to dm-crypt. This 6656 bytes IO has got 3 segments, > > > first segment had 1584, second 4096 and the last had 976 bytes. Dm-crypt > > > rejects the I/O after seeing the first segment length 1584 which is not > > > a 512 byte multiple. > > > > > > Let me know if there are further questions. > > > > > > Thanks > > > Sudhakar > > > > Hi > > > > I think it should be fixed in vhost-scsi. > > In the above example of 6656 bytes I/O, windows allocates 6656 bytes > virtually contiguous I/O. This IO, when it lands in the kernel, > translates to 3 physically discontiguous pages, that's why > translate_desc() had to create 3 iovecs to handle this I/O. I don't > understand how vhost-scsi could have solved this issue. By copying it to a temporary aligned buffer and issuing I/O on this buffer. > Only other > possibility I see is to have windows fix it by always sending 512 byte > aligned buffer lengths, but going with my earlier point that every other > component in the Linux IO path handles this case well except for > dm-crypt, so it make more sense to fix it in dm-crypt. > > Thanks > Sudhakar Are you sure that the problem is only with dm-crypt? You haven't tried all the existing block device drivers, have you? Mikulas
next prev parent reply other threads:[~2020-09-24 17:50 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-16 18:40 [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Sudhakar Panneerselvam 2020-09-16 18:40 ` [RFC PATCH 1/2] dm crypt: Allow unaligned bio " Sudhakar Panneerselvam 2020-09-16 18:40 ` [RFC PATCH 2/2] dm crypt: Handle unaligned bio buffer lengths for lmk and tcw Sudhakar Panneerselvam 2020-09-23 17:01 ` [dm-crypt] [dm-devel] [RFC PATCH 0/2] dm crypt: Allow unaligned buffer lengths for skcipher devices Sudhakar Panneerselvam 2020-09-23 17:01 ` Sudhakar Panneerselvam 2020-09-24 1:27 ` [dm-crypt] " Mike Snitzer 2020-09-24 1:27 ` Mike Snitzer 2020-09-24 5:14 ` [dm-crypt] [dm-devel] " Eric Biggers 2020-09-24 5:14 ` Eric Biggers 2020-09-24 8:15 ` [dm-crypt] [dm-devel] " Milan Broz 2020-09-24 8:15 ` Milan Broz 2020-09-24 16:55 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 16:55 ` Sudhakar Panneerselvam 2020-09-24 16:44 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 16:44 ` Sudhakar Panneerselvam 2020-09-24 17:26 ` [dm-crypt] [dm-devel] " Mikulas Patocka 2020-09-24 17:26 ` Mikulas Patocka 2020-09-24 17:38 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 17:38 ` Sudhakar Panneerselvam 2020-09-24 17:50 ` Mikulas Patocka [this message] 2020-09-24 17:50 ` Mikulas Patocka 2020-09-24 18:11 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 18:11 ` Sudhakar Panneerselvam 2020-09-24 18:44 ` [dm-crypt] [dm-devel] " Mikulas Patocka 2020-09-24 18:44 ` Mikulas Patocka 2020-09-24 19:13 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 19:13 ` Sudhakar Panneerselvam 2020-09-25 1:09 ` [dm-crypt] [dm-devel] " Damien Le Moal 2020-09-25 1:09 ` Damien Le Moal 2020-09-25 20:15 ` Mike Snitzer 2020-09-25 20:15 ` Mike Snitzer 2020-09-25 20:15 ` [dm-crypt] " Mike Snitzer 2020-09-24 12:47 ` Mikulas Patocka 2020-09-24 12:47 ` Mikulas Patocka 2020-09-24 15:58 ` [dm-crypt] " Sudhakar Panneerselvam 2020-09-24 15:58 ` Sudhakar Panneerselvam 2020-09-24 12:40 ` [dm-crypt] [dm-devel] " Mikulas Patocka 2020-09-24 12:40 ` Mikulas Patocka 2020-09-24 17:12 ` [dm-crypt] [dm-devel] " Sudhakar Panneerselvam 2020-09-24 17:12 ` Sudhakar Panneerselvam
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LRH.2.02.2009241345370.4229@file01.intranet.prod.int.rdu2.redhat.com \ --to=mpatocka@redhat.com \ --cc=Damien.LeMoal@wdc.com \ --cc=agk@redhat.com \ --cc=dm-crypt@saout.de \ --cc=dm-devel@redhat.com \ --cc=ebiggers@kernel.org \ --cc=gmazyland@gmail.com \ --cc=martin.petersen@oracle.com \ --cc=shirley.ma@oracle.com \ --cc=snitzer@redhat.com \ --cc=ssudhakarp@gmail.com \ --cc=sudhakar.panneerselvam@oracle.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.