Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: jsmart2021@gmail.com
Cc: linux-scsi@vger.kernel.org
Subject: [bug report] scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware.
Date: Mon, 26 Aug 2019 16:40:44 +0300	[thread overview]
Message-ID: <20190826134044.GA8726@mwanda> (raw)

Hello James Smart,

The patch d79c9e9d4b3d: "scsi: lpfc: Support dynamic unbounded SGL
lists on G7 hardware." from Aug 14, 2019, leads to the following
static checker warning:

	drivers/scsi/lpfc/lpfc_init.c:4107 lpfc_new_io_buf()
	error: not allocating enough data 784 vs 768

drivers/scsi/lpfc/lpfc_init.c
  4071  /**
  4072   * lpfc_new_io_buf - IO buffer allocator for HBA with SLI4 IF spec
  4073   * @vport: The virtual port for which this call being executed.
  4074   * @num_to_allocate: The requested number of buffers to allocate.
  4075   *
  4076   * This routine allocates nvme buffers for device with SLI-4 interface spec,
  4077   * the nvme buffer contains all the necessary information needed to initiate
  4078   * an I/O. After allocating up to @num_to_allocate IO buffers and put
  4079   * them on a list, it post them to the port by using SGL block post.
  4080   *
  4081   * Return codes:
  4082   *   int - number of IO buffers that were allocated and posted.
  4083   *   0 = failure, less than num_to_alloc is a partial failure.
  4084   **/
  4085  int
  4086  lpfc_new_io_buf(struct lpfc_hba *phba, int num_to_alloc)
  4087  {
  4088          struct lpfc_io_buf *lpfc_ncmd;
  4089          struct lpfc_iocbq *pwqeq;
  4090          uint16_t iotag, lxri = 0;
  4091          int bcnt, num_posted;
  4092          LIST_HEAD(prep_nblist);
  4093          LIST_HEAD(post_nblist);
  4094          LIST_HEAD(nvme_nblist);
  4095  
  4096          /* Sanity check to ensure our sizing is right for both SCSI and NVME */
  4097          if (sizeof(struct lpfc_io_buf) > LPFC_COMMON_IO_BUF_SZ) {
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

We made the lpfc_io_buf struct larger so now this check is more likely
to trigger.  Why don't we make this condition a BUILD_BUG_ON()?

  4098                  lpfc_printf_log(phba, KERN_ERR, LOG_FCP,
  4099                                  "6426 Common buffer size %zd exceeds %d\n",
  4100                                  sizeof(struct lpfc_io_buf),
  4101                                  LPFC_COMMON_IO_BUF_SZ);
  4102                  return 0;

Zero means we're returning failure on this path.

  4103          }
  4104  
  4105          phba->sli4_hba.io_xri_cnt = 0;
  4106          for (bcnt = 0; bcnt < num_to_alloc; bcnt++) {
  4107                  lpfc_ncmd = kzalloc(LPFC_COMMON_IO_BUF_SZ, GFP_KERNEL);
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Smatch generates a warning here.  It's obviously not a problem, because
of the earlier check.  I guess I don't really understand why
LPFC_COMMON_IO_BUF_SZ is useful when it's so close to sizeof(*lpfc_ncmd).

  4108                  if (!lpfc_ncmd)
  4109                          break;
  4110                  /*
  4111                   * Get memory from the pci pool to map the virt space to
  4112                   * pci bus space for an I/O. The DMA buffer includes the
  4113                   * number of SGE's necessary to support the sg_tablesize.
  4114                   */
  4115                  lpfc_ncmd->data = dma_pool_zalloc(phba->lpfc_sg_dma_buf_pool,
  4116                                                    GFP_KERNEL,
  4117                                                    &lpfc_ncmd->dma_handle);
  4118                  if (!lpfc_ncmd->data) {

regards,
dan carpenter

             reply	other threads:[~2019-08-26 13:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26 13:40 Dan Carpenter [this message]
2019-08-26 16:24 ` [bug report] scsi: lpfc: Support dynamic unbounded SGL lists on G7 hardware James Smart

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=20190826134044.GA8726@mwanda \
    --to=dan.carpenter@oracle.com \
    --cc=jsmart2021@gmail.com \
    --cc=linux-scsi@vger.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