From: Boaz Harrosh <bharrosh@panasas.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Roel Kluin <roel.kluin@gmail.com>,
linux-scsi@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] zfcp: Test kmalloc failure in scsi_get_vpd_page()
Date: Sun, 30 Aug 2009 14:45:58 +0300 [thread overview]
Message-ID: <4A9A6676.8050304@panasas.com> (raw)
In-Reply-To: <1251416731.27356.8.camel@mulgrave.site>
On 08/28/2009 02:45 AM, James Bottomley wrote:
> On Mon, 2009-08-24 at 18:21 +0200, Roel Kluin wrote:
>> kmalloc() may fail, so test whether it succeeded.
>>
>> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>> ---
>> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
>> index 2de5f3a..34fdde0 100644
>> --- a/drivers/scsi/scsi.c
>> +++ b/drivers/scsi/scsi.c
>> @@ -1056,6 +1056,9 @@ unsigned char *scsi_get_vpd_page(struct scsi_device *sdev, u8 page)
>>
>> kfree(buf);
>> buf = kmalloc(len + 4, GFP_KERNEL);
>> + if (!buf)
>> + return NULL;
>> +
>
> Firstly, this won't actually apply ... you should be developing against
> either the SCSI trees or linux-next to get the latest versions in git.
>
> Secondly it's not really right for the most common use cases, which
> don't usually want the whole vpd buffer anyway. I don't really see a
> simple way of fixing it without altering the interface, though.
>
"most common use cases" do not have pages bigger then 255. Can you think
of any? For these few places that anticipate pages bigger then 255 I don't
see much choice, we just freed 255 bytes and tried a new size, say 317, which
failed with GFP_KERNEL, In such a busy system, better fail with NULL then BUG,
No? In any way caller must check for NULL because of the first allocation.
> James
>
Boaz
next prev parent reply other threads:[~2009-08-30 11:46 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-24 16:21 [PATCH] zfcp: Test kmalloc failure in scsi_get_vpd_page() Roel Kluin
2009-08-27 23:45 ` James Bottomley
2009-08-30 11:45 ` Boaz Harrosh [this message]
2009-08-30 14:35 ` James Bottomley
2009-11-03 18:33 ` James Bottomley
2009-11-04 8:54 ` Boaz Harrosh
2009-11-04 15:09 ` James Bottomley
2009-11-04 16:18 ` Boaz Harrosh
2009-11-04 17:50 ` James Bottomley
2009-11-05 8:29 ` Boaz Harrosh
2009-11-05 19:41 ` James Bottomley
2009-11-08 9:19 ` Boaz Harrosh
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=4A9A6676.8050304@panasas.com \
--to=bharrosh@panasas.com \
--cc=James.Bottomley@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-scsi@vger.kernel.org \
--cc=roel.kluin@gmail.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.