All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Douglas Gilbert <dgilbert@interlog.com>
Cc: Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
	jejb@linux.vnet.ibm.com, hare@suse.de, bvanassche@acm.org
Subject: Re: [PATCH v2 0/6] scsi: fix scsi_cmd::cmd_len
Date: Mon, 11 Apr 2022 17:52:58 +0200	[thread overview]
Message-ID: <20220411155258.GA25715@lst.de> (raw)
In-Reply-To: <aa2a08cc-ba98-b538-2448-d528e8eef917@interlog.com>

On Mon, Apr 11, 2022 at 11:06:17AM -0400, Douglas Gilbert wrote:
> On 2022-04-11 01:03, Christoph Hellwig wrote:
>> This still misses any good explanation of why we want all this.
>
> Advantages:
>    - undoes regression in ce70fd9a551af, that is:
>        - cdb_len > 32 no longer allowed (visible to the user space), undone

What exact regression causes this for real users and no just people
playing around with scsi_debug?

>        - but we still have this one:
>            - prior to lk5.18 sizeof(scsi_cmnd::cmnd) is that of a
>              pointer but >= lk5.18 sizeof(scsi_cmnd::cmnd) is 32 (or 16)

Please check the total size of struct scsi_cmnd, which is what really
matters.

>    - makes all scsi_cmnd objects 16 bytes smaller

Do we have data why this matters?

>    - hides the poorly named dtor for scsi_cmnd objects (blk_mq_free_request)
>      within a more intuitively named inline: scsi_free_cmnd

I don't think this is in any way poorly named.

> Disadvantages:
>     - burdens each access to a CDB with (scsi_cmnd::flags & SCMD_LONG_CDB)
>       check
>     - LLDs that want to fetch 32 byte CDBs (or longer) need to use the
>       scsi_cmnd_get_cdb() access function. For CDB lengths <= 16 bytes
>       they can continue to access scsi_cmnd::cmnd directly

It adds back the dynamic allocation for 32-byte CDBs that we got rid of.
It also breaks all LLDS actually using 32-byte CDBS currently as far as
I can tell.

  reply	other threads:[~2022-04-11 15:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-10 17:36 [PATCH v2 0/6] scsi: fix scsi_cmd::cmd_len Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 1/6] scsi_cmnd: reinstate support for cmd_len > 32 Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 2/6] sd, sd_zbc: use scsi_cmnd cdb access functions Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 3/6] sg: reinstate cmd_len > 32 Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 4/6] bsg: allow " Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 5/6] scsi_debug: reinstate " Douglas Gilbert
2022-04-10 17:36 ` [PATCH v2 6/6] st,sr,stex: use scsi_cmnd cdb access functions Douglas Gilbert
2022-04-11  5:03 ` [PATCH v2 0/6] scsi: fix scsi_cmd::cmd_len Christoph Hellwig
2022-04-11 15:06   ` Douglas Gilbert
2022-04-11 15:52     ` Christoph Hellwig [this message]
2022-04-12  3:05       ` Douglas Gilbert
2022-04-19  3:26         ` Martin K. Petersen

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=20220411155258.GA25715@lst.de \
    --to=hch@lst.de \
    --cc=bvanassche@acm.org \
    --cc=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=jejb@linux.vnet.ibm.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@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: link
Be 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.