From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Yan Subject: Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat Date: Tue, 23 Aug 2016 09:04:38 +0000 Message-ID: References: <20160822042321.24367-1-shaun@tancheff.com> <20160822042321.24367-2-shaun@tancheff.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: Received: from mail-qk0-f195.google.com ([209.85.220.195]:35953 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757310AbcHWJG7 (ORCPT ); Tue, 23 Aug 2016 05:06:59 -0400 In-Reply-To: Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Shaun Tancheff Cc: Shaun Tancheff , linux-ide@vger.kernel.org, LKML , Tejun Heo , Christoph Hellwig , "Martin K . Petersen" , Damien Le Moal , Hannes Reinecke , Josh Bingaman , Hannes Reinecke There's comment about `rq->__data_len` in sd.c (and blkdev.h, definition of struct `request`). Apparently it is "internal only" (in terms of the kernel). As for `cmd->transfersize`, it's probably talking about the CDB itself. Although different commands have CDB of various lengths (much shorter than 512-byte), but I guess when the actual command is sent to the device, we will still transfer it in a full logical block for some reason. Anyway these will not have anything to do with how we form the TRIM payload. The SATL simply read the LBA (starting offset) and NUMBER OF BLOCK (to TRIM) field in the CDB and pack ranges according to that. All we care is the actual TRIM limit of the ATA device (and conservative concern on bogus ones). On 23 August 2016 at 08:42, Shaun Tancheff wrote: > On Tue, Aug 23, 2016 at 2:53 AM, Tom Yan wrote: >> On 23 August 2016 at 06:20, Shaun Tancheff wrote: >>> On Tue, Aug 23, 2016 at 12:26 AM, Tom Yan wrote: >>> >>>> It is always 1 merely because we prefer sticking to that. Say we want >>>> to enable multi-block payload now, it won't be 1 anymore. >>> >>> Sorry, I though that DSM TRIM is using 512 bytes here because >>> WRITE_SAME_16 has a payload of a single logical sector. >> >> Nope, SCSI Write Same commands does not have payload (or in SCSI >> terms, parameter list / data-out buffer). > > Hmm. Not sure about T10, but that's not how I read > sd_setup_write_same_cmnd(), it always setups up a transfer of > sector_size for scsi_init_io(). > > As I understand things, this is how the cmd's sglist is populated and why > this should be using sg_copy_from_buffer() rather than open coding > to the page. > -- > Shaun Tancheff