All of lore.kernel.org
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [patch] [SCSI] scsi_transport_sas: check for allocation failure
Date: Fri, 08 Mar 2013 23:25:00 +0000	[thread overview]
Message-ID: <513A734C.80807@interlog.com> (raw)
In-Reply-To: <1362783019.2370.45.camel@dabdike.int.hansenpartnership.com>

On 13-03-08 05:50 PM, James Bottomley wrote:
> On Fri, 2013-03-08 at 12:57 -0500, Douglas Gilbert wrote:
>> On 13-03-08 07:02 AM, Dan Carpenter wrote:
>>> Static checkers complain that this allocation isn't checked.  We
>>> should return zero if the allocation fails.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>
>>> diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
>>> index 1b68142..a022997 100644
>>> --- a/drivers/scsi/scsi_transport_sas.c
>>> +++ b/drivers/scsi/scsi_transport_sas.c
>>> @@ -379,9 +379,12 @@ sas_tlr_supported(struct scsi_device *sdev)
>>>    {
>>>    	const int vpd_len = 32;
>>>    	struct sas_end_device *rdev = sas_sdev_to_rdev(sdev);
>>> -	char *buffer = kzalloc(vpd_len, GFP_KERNEL);
>>> +	char *buffer;
>>>    	int ret = 0;
>>>
>>> +	buffer = kzalloc(vpd_len, GFP_KERNEL);
>>> +	if (!buffer)
>>> +		goto out;
>>>    	if (scsi_get_vpd_page(sdev, 0x90, buffer, vpd_len))
>>>    		goto out;
>>>
>>
>> For 32 bytes, why not use the stack?
>
> Because the buffer is a DMA target.  You can't DMA to stack because of
> padding and cacheline issues.

And I went to the definition of scsi_get_vpd_page()
to see if that was called out in the header comments.
Guess what ... and those same header comments talked
about freeing a returned pointer. It needs to be
cleaned up, IMO.

Doug Gilbert

/**
  * scsi_get_vpd_page - Get Vital Product Data from a SCSI device
  * @sdev: The device to ask
  * @page: Which Vital Product Data to return
  * @buf: where to store the VPD
  * @buf_len: number of bytes in the VPD buffer area
  *
  * SCSI devices may optionally supply Vital Product Data.  Each 'page'
  * of VPD is defined in the appropriate SCSI document (eg SPC, SBC).
  * If the device supports this VPD page, this routine returns a pointer
  * to a buffer containing the data from that page.  The caller is
  * responsible for calling kfree() on this pointer when it is no longer
  * needed.  If we cannot retrieve the VPD page this routine returns %NULL.
  */
int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf,
                       int buf_len)



WARNING: multiple messages have this Message-ID (diff)
From: Douglas Gilbert <dgilbert@interlog.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-janitors@vger.kernel.org
Subject: Re: [patch] [SCSI] scsi_transport_sas: check for allocation failure
Date: Fri, 08 Mar 2013 18:25:00 -0500	[thread overview]
Message-ID: <513A734C.80807@interlog.com> (raw)
In-Reply-To: <1362783019.2370.45.camel@dabdike.int.hansenpartnership.com>

On 13-03-08 05:50 PM, James Bottomley wrote:
> On Fri, 2013-03-08 at 12:57 -0500, Douglas Gilbert wrote:
>> On 13-03-08 07:02 AM, Dan Carpenter wrote:
>>> Static checkers complain that this allocation isn't checked.  We
>>> should return zero if the allocation fails.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>
>>> diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
>>> index 1b68142..a022997 100644
>>> --- a/drivers/scsi/scsi_transport_sas.c
>>> +++ b/drivers/scsi/scsi_transport_sas.c
>>> @@ -379,9 +379,12 @@ sas_tlr_supported(struct scsi_device *sdev)
>>>    {
>>>    	const int vpd_len = 32;
>>>    	struct sas_end_device *rdev = sas_sdev_to_rdev(sdev);
>>> -	char *buffer = kzalloc(vpd_len, GFP_KERNEL);
>>> +	char *buffer;
>>>    	int ret = 0;
>>>
>>> +	buffer = kzalloc(vpd_len, GFP_KERNEL);
>>> +	if (!buffer)
>>> +		goto out;
>>>    	if (scsi_get_vpd_page(sdev, 0x90, buffer, vpd_len))
>>>    		goto out;
>>>
>>
>> For 32 bytes, why not use the stack?
>
> Because the buffer is a DMA target.  You can't DMA to stack because of
> padding and cacheline issues.

And I went to the definition of scsi_get_vpd_page()
to see if that was called out in the header comments.
Guess what ... and those same header comments talked
about freeing a returned pointer. It needs to be
cleaned up, IMO.

Doug Gilbert

/**
  * scsi_get_vpd_page - Get Vital Product Data from a SCSI device
  * @sdev: The device to ask
  * @page: Which Vital Product Data to return
  * @buf: where to store the VPD
  * @buf_len: number of bytes in the VPD buffer area
  *
  * SCSI devices may optionally supply Vital Product Data.  Each 'page'
  * of VPD is defined in the appropriate SCSI document (eg SPC, SBC).
  * If the device supports this VPD page, this routine returns a pointer
  * to a buffer containing the data from that page.  The caller is
  * responsible for calling kfree() on this pointer when it is no longer
  * needed.  If we cannot retrieve the VPD page this routine returns %NULL.
  */
int scsi_get_vpd_page(struct scsi_device *sdev, u8 page, unsigned char *buf,
                       int buf_len)

  reply	other threads:[~2013-03-08 23:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-08 12:02 [patch] [SCSI] scsi_transport_sas: check for allocation failure Dan Carpenter
2013-03-08 12:02 ` Dan Carpenter
2013-03-08 17:57 ` Douglas Gilbert
2013-03-08 17:57   ` Douglas Gilbert
2013-03-08 19:58   ` Dan Carpenter
2013-03-08 19:58     ` Dan Carpenter
2013-03-08 22:50   ` James Bottomley
2013-03-08 23:25     ` Douglas Gilbert [this message]
2013-03-08 23:25       ` Douglas Gilbert
2013-03-11 13:10     ` Dan Carpenter
2013-03-11 13:10       ` Dan Carpenter
2013-03-11 14:48       ` Douglas Gilbert
2013-03-11 14:48         ` Douglas Gilbert
2013-03-11 15:10         ` James Bottomley

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=513A734C.80807@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dan.carpenter@oracle.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 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.