On Sat, 2016-03-05 at 10:51 -0800, Greg KH wrote: > On Fri, Mar 04, 2016 at 12:45:10PM -0800, Kamal Mostafa wrote: > > From: Mike Christie <mchristi@xxxxxxxxxx> > > > > commit 8a9ebe717a133ba7bc90b06047f43cc6b8bcb8b3 upstream. > > > > In a couple places we are not converting to/from the Linux > > block layer 512 bytes sectors. > > > > 1. > > > > The request queue values and what we do are a mismatch of > > things: > > > > max_discard_sectors - This is in linux block layer 512 byte > > sectors. We are just copying this to max_unmap_lba_count. > > > > discard_granularity - This is in bytes. We are converting it > > to Linux block layer 512 byte sectors. > > > > discard_alignment - This is in bytes. We are just copying > > this over. > > > > The problem is that the core LIO code exports these values in > > spc_emulate_evpd_b0 and we use them to test request arguments > > in sbc_execute_unmap, but we never convert to the block size > > we export to the initiator. If we are not using 512 byte sectors > > then we are exporting the wrong values or are checks are off. > > And, for the discard_alignment/bytes case we are just plain messed > > up. > > > > 2. > > > > blkdev_issue_discard's start and number of sector arguments > > are supposed to be in linux block layer 512 byte sectors. We are > > currently passing in the values we get from the initiator which > > might be based on some other sector size. > > > > There is a similar problem in iblock_execute_write_same where > > the bio functions want values in 512 byte sectors but we are > > passing in what we got from the initiator. > > > > Signed-off-by: Mike Christie <mchristi@xxxxxxxxxx> > > Cc: stable@xxxxxxxxxxxxxxx # 3.10+ > > Signed-off-by: Nicholas Bellinger <nab@xxxxxxxxxxxxxxx> > > [ kamal: backport to 4.4-stable: no unmap_zeroes_data ] > > Signed-off-by: Kamal Mostafa <kamal@xxxxxxxxxxxxx> > > Thanks, but what about a 3.14 and 3.10-stable backport as well? > Hi Greg-KH, I'm working on <= v4.1 stable backports today, and will include Mike's patch to the series. Thank you, --nab -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html