From: walter harms <wharms@bfs.de>
To: Benny Halevy <bhalevy@tonian.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
Boaz Harrosh <bharrosh@panasas.com>,
"James E.J. Bottomley" <JBottomley@parallels.com>,
osd-dev@open-osd.org, linux-scsi@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [patch] [SCSI] libosd: check for kzalloc() failure
Date: Wed, 30 Jan 2013 14:34:39 +0000 [thread overview]
Message-ID: <51092F7F.2090105@bfs.de> (raw)
In-Reply-To: <CAEMWVhsAysz6QQnBkNteVExAVdQ6YRZd62WE0vzmd1hvNa0-zg@mail.gmail.com>
Am 30.01.2013 14:40, schrieb Benny Halevy:
> On Wed, Jan 30, 2013 at 3:00 PM, walter harms <wharms@bfs.de> wrote:
>>
>>
>> Am 30.01.2013 10:51, schrieb Benny Halevy:
>>> On Wed, Jan 30, 2013 at 10:57 AM, walter harms <wharms@bfs.de> wrote:
>>>>
>>>>
>>>> Am 30.01.2013 09:27, schrieb Dan Carpenter:
>>>>> On Wed, Jan 30, 2013 at 09:15:43AM +0100, walter harms wrote:
>>>>>>
>>>>>>
>>>>>> Am 30.01.2013 08:06, schrieb Dan Carpenter:
>>>>>>> There wasn't any error handling for this kzalloc().
>>>>>>>
>>>>>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>>>>>
>>>>>>> diff --git a/drivers/scsi/osd/osd_initiator.c b/drivers/scsi/osd/osd_initiator.c
>>>>>>> index c06b8e5..d8293f2 100644
>>>>>>> --- a/drivers/scsi/osd/osd_initiator.c
>>>>>>> +++ b/drivers/scsi/osd/osd_initiator.c
>>>>>>> @@ -144,6 +144,10 @@ static int _osd_get_print_system_info(struct osd_dev *od,
>>>>>>> odi->osdname_len = get_attrs[a].len;
>>>>>>> /* Avoid NULL for memcmp optimization 0-length is good enough */
>>>>>>> odi->osdname = kzalloc(odi->osdname_len + 1, GFP_KERNEL);
>>>>>>> + if (!odi->osdname) {
>>>>>>> + ret = -ENOMEM;
>>>>>>> + goto out;
>>>>>>> + }
>>>>>>> if (odi->osdname_len)
>>>>>>> memcpy(odi->osdname, get_attrs[a].val_ptr, odi->osdname_len);
>>>>>>> OSD_INFO("OSD_NAME [%s]\n", odi->osdname);
>>>>>>> --
>>>>>>
>>>>>> this looks like strdup() ?
>>>>>>
>>>>>
>>>>> Maybe? It's a funny thing going on with the NUL terminator and I
>>>>> don't understand what the comment is about.
>>>>>
>>>>> It appears that normally "get_attrs[a].val_ptr" is a NUL terminated
>>>>> string but "get_attrs[a].len" does not count the terminator.
>>>>>
>>>>> Odd.
>>>>>
>>>> i have no clue what the programmer was thinking. if i read this correct
>>>> osdname is u8 *osdname; so a simple strdup() or strndup() would be ok
>>>> the comment seems to indicate that get_attrs[a].val_ptr could be NULL
>>>> but where is the check ?
>>>> Perhaps they are not using ascii here ? then a memdup(get_attrs[a].len)
>>>> would be better.
>>>
>>> There are subtle differences between kstrdup or kmemdup and this implementation.
>>>
>>> kmemdup is problematic as get_attrs[a].val_ptr does not contain the
>>> NUL terminator
>>
>> ok, i understand - but can we assume that we are talking ascii here ?
>>
>
> No, it can be anything. UTF-8 is more likely but not guaranteed either.
>
I start to see the complexity of the situation. Would you mind to add
the comment "it can be anything. UTF-8 is more likely but not guaranteed either" ?
For now using a pascal-string seems the best solution but it should be warned
that get_attrs[a].val_ptr is NOT a c-string and therefore can not be used with
the printf-family (i guess the situation will become more clear in future)
I have no clue why you need that, using c-strings makes life more easy in the
last minute a sprintf(buf,"%u") will save the day ;)
>>> In the following case:
>>> if get_attrs[a].len = 0
>>> then get_attrs[a].val_ptr = NULL
>>>
>>> The end result should be
>>> odi->osdname_len = 0
>>> odi->osdname = kzalloc(1, GFP_KERNEL);
>>>
>>> while with kstrdup, odi->osdname will end up being NULL
>>> as it's input arg "s" is NULL.
>>>
>>
>> and you want the argument to be "" ?
>> May i ask why ? kfree() can handle NULL and kprintf() (-family) also.
>
> It was Boaz' decision at the time to simplify internal tests
> like _the_same_or_null in drivers/scsi/osd/osd_uld.c
> that doesn't check for NULL
>
It look clever to add the NULL test here.
Noone reviewing the code will understand that.
(Rule of least surprise)
just my 2 cents,
re,
wh
> Nothing spectacular :)
>
> Benny
>
>>
>> re,
>> wh
>>
>>
>>> Benny
>>>
>>>>
>>>> re,
>>>> wh
>>>>
>>>>
>>>
>>>
>
>
next prev parent reply other threads:[~2013-01-30 14:34 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-30 7:06 [patch] [SCSI] libosd: check for kzalloc() failure Dan Carpenter
2013-01-30 8:15 ` walter harms
2013-01-30 8:27 ` Dan Carpenter
2013-01-30 8:57 ` walter harms
2013-01-30 9:51 ` Benny Halevy
2013-01-30 13:00 ` walter harms
2013-01-30 13:40 ` Benny Halevy
2013-01-30 14:34 ` walter harms [this message]
2013-01-30 15:51 ` Boaz Harrosh
2013-01-30 10:05 ` Benny Halevy
2013-01-30 15:56 ` 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=51092F7F.2090105@bfs.de \
--to=wharms@bfs.de \
--cc=JBottomley@parallels.com \
--cc=bhalevy@tonian.com \
--cc=bharrosh@panasas.com \
--cc=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=osd-dev@open-osd.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