linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Yan <tom.ty89@gmail.com>
To: Shaun Tancheff <shaun.tancheff@seagate.com>
Cc: Shaun Tancheff <shaun@tancheff.com>,
	linux-ide@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Tejun Heo <tj@kernel.org>, Christoph Hellwig <hch@lst.de>,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	Damien Le Moal <damien.lemoal@hgst.com>,
	Hannes Reinecke <hare@suse.de>,
	Josh Bingaman <josh.bingaman@seagate.com>,
	Hannes Reinecke <hare@suse.com>
Subject: Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat
Date: Mon, 22 Aug 2016 23:49:04 +0000	[thread overview]
Message-ID: <CAGnHSE=t1qg5ukA7btSwD=AaQZB6W6bmF9HMC_K2JsCqoSNGVg@mail.gmail.com> (raw)
In-Reply-To: <CAJVOszBVXftz9hqmOgWG5DvxW7cQjFPUFaGygWcj_exgNwT4=w@mail.gmail.com>

The only 512 I can see in the old code is the one in:

> -       used_bytes = ALIGN(i * 8, 512);

where the alignment is necessary because 'used_bytes' will be returned
as 'size', which will be used for setting the number of 512-byte block
payload when we construct the ATA taskfile / command. It may NOT be a
good idea to replace it with ATA_SECT_SIZE. Some comment could be
nice.

So I don't think it makes any sense to check ATA_SCSI_RBUF_SIZE
against 512 here.

On 22 August 2016 at 22:00, Shaun Tancheff <shaun.tancheff@seagate.com> wrote:
> Because this is re-using the response buffer in a new way.
> Such reuse could be a surprise to someone refactoring that
> code, although it's pretty unlikely. The build bug on
> gives some level of confidence that it won't go unnoticed.
> It also codifies the assumption that we can write 512 bytes
> to the global ata_scsi_rbuf buffer.
>
> As to using a literal 512, I was just following what was here
> before.
>
> It looks like there is a ATA_SECT_SIZE that can replace most
> of the literal 512's in here though. That might be a nice cleanup
> overall. Not sure it belongs here though.
>

>>> +       used_bytes = ALIGN(i * 8, 512);
>>> +       memset(buffer + i, 0, used_bytes - i * 8);
>>> +       sg_copy_from_buffer(scsi_sglist(cmd), scsi_sg_count(cmd), buffer, 512);

And I don't think you have a reason to use 512 here either. It appears
to me that you should use ATA_SCSI_RBUF_SIZE instead (see
ata_scsi_rbuf_put in libata-scsi). If not, it should probably be a
_derived_ value (e.g. from `i`) that tells the _actual_ size of
`buffer`.

Again, note that even when we prefer to stick with _one_ 512-byte
block TRIM payload, we should probably NEVER _hard code_ such limit
(for it's really ugly and unnecessary) in functions like this. All we
need to do is to advertise the limit (or lower) as Maximum Write
Length, and make sure our SATL works as per SBC that it will reject
SCSI Write Same commands that is "larger" than that.

>>> +       spin_unlock_irqrestore(&ata_scsi_rbuf_lock, flags);
>>> +
>>> +       return used_bytes;
>>> +}

  reply	other threads:[~2016-08-22 23:50 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-22  4:23 [PATCH v6 0/4] SCT Write Same Shaun Tancheff
2016-08-22  4:23 ` [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat Shaun Tancheff
2016-08-22  6:27   ` Hannes Reinecke
2016-08-22 19:27   ` Tom Yan
2016-08-22 19:51     ` Shaun Tancheff
2016-08-22 20:12       ` Tom Yan
2016-08-22 21:20   ` Tom Yan
2016-08-22 22:00     ` Shaun Tancheff
2016-08-22 23:49       ` Tom Yan [this message]
2016-08-23  1:01         ` Shaun Tancheff
2016-08-23  5:26           ` Tom Yan
2016-08-23  6:20             ` Shaun Tancheff
2016-08-23  7:53               ` Tom Yan
2016-08-23  8:42                 ` Shaun Tancheff
2016-08-23  9:04                   ` Tom Yan
2016-08-24  3:33                 ` Martin K. Petersen
2016-08-24  5:31                   ` Tom Yan
2016-08-24 21:28                     ` Shaun Tancheff
2016-08-25  6:31                       ` Tom Yan
2016-08-25  7:18                         ` Shaun Tancheff
2016-08-22  4:23 ` [PATCH v6 2/4] Add support for SCT Write Same Shaun Tancheff
2016-08-22  6:27   ` Hannes Reinecke
2016-08-22 19:20   ` Tom Yan
2016-08-22 19:43     ` Shaun Tancheff
2016-08-22 20:14       ` Tom Yan
2016-08-22 22:07         ` Shaun Tancheff
2016-08-22 23:09           ` Tom Yan
2016-08-23  0:36             ` Shaun Tancheff
2016-08-23  5:55               ` Tom Yan
2016-08-23  6:11                 ` Shaun Tancheff
2016-08-23  7:57                   ` Tom Yan
2016-08-23 10:37   ` Tom Yan
2016-08-23 10:56     ` Shaun Tancheff
2016-08-24  5:57       ` Tom Yan
2016-08-24  6:10         ` Tom Yan
2016-08-24 22:04           ` Shaun Tancheff
2016-08-25  6:23             ` Tom Yan
2016-08-25  7:31               ` Shaun Tancheff
2016-08-22  4:23 ` [PATCH v6 3/4] SCT Write Same / DSM Trim Shaun Tancheff
2016-08-22  6:30   ` Hannes Reinecke
2016-08-24 18:08     ` [PATCH v6 3/4 RESEND] " Shaun Tancheff
2016-08-25  7:01       ` Tom Yan
2016-08-25  8:03         ` Shaun Tancheff
2016-08-25  9:30           ` Tom Yan
2016-08-22  8:31   ` [PATCH v6 3/4] " Tom Yan
2016-08-22  8:33     ` Tom Yan
2016-08-22 15:04       ` Shaun Tancheff
2016-08-22 17:02         ` Tom Yan
2016-08-22 18:00           ` Shaun Tancheff
2016-08-22 18:52             ` Tom Yan
2016-08-22 20:57               ` Tom Yan
2016-08-22  4:23 ` [PATCH v6 4/4] SCT Write Same handle ATA_DFLAG_PIO Shaun Tancheff
2016-08-22  6:31   ` Hannes Reinecke
2016-08-22  6:32 ` [PATCH v6 0/4] SCT Write Same Hannes Reinecke
2016-08-25 15:28 ` Tejun Heo

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='CAGnHSE=t1qg5ukA7btSwD=AaQZB6W6bmF9HMC_K2JsCqoSNGVg@mail.gmail.com' \
    --to=tom.ty89@gmail.com \
    --cc=damien.lemoal@hgst.com \
    --cc=hare@suse.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=josh.bingaman@seagate.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=shaun.tancheff@seagate.com \
    --cc=shaun@tancheff.com \
    --cc=tj@kernel.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).