All of lore.kernel.org
 help / color / mirror / Atom feed
From: walter harms <wharms@bfs.de>
To: Belisko Marek <marek.belisko@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
	kernel-janitors@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@suse.de>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: ft1000: fix error path
Date: Sun, 26 Sep 2010 17:18:06 +0000	[thread overview]
Message-ID: <4C9F804E.8010902@bfs.de> (raw)
In-Reply-To: <AANLkTin_4D6fF85+4dFe+qN9-nEBS8+oDMKRCtixMCPU@mail.gmail.com>


hi Marek,
IMHO the alloc sequencs is building a linked list of allocated buffer.
And if  kfree() does no magiclly follow the list this is not working.

re,
 wh


Belisko Marek schrieb:
> On Sun, Sep 26, 2010 at 3:11 PM, Dan Carpenter <error27@gmail.com> wrote:
>> On Sun, Sep 26, 2010 at 12:59:55PM +0400, Vasiliy Kulikov wrote:
>>> +err_free:
>>> +     for (i--; i>=0; i--) {
>>> +             kfree(pdpram_blk->pbuffer);
>>> +             kfree(pdpram_blk);
>>> +     }
>> This is wrong.  I don't have linux-next so I can't see the context, why
>> are we looping here?  The second iteration through the loop will cause a
>> NULL dereference.
> Some lines upper there is allocation of structure and it's internal
> buffer in loop:
> for (i=0; i<NUM_OF_FREE_BUFFERS; i++) {
>     // Get memory for DPRAM_DATA link list
>     pdpram_blk = kmalloc ( sizeof(DPRAM_BLK), GFP_KERNEL );
>     // Get a block of memory to store command data
>     pdpram_blk->pbuffer = kmalloc ( MAX_CMD_SQSIZE, GFP_KERNEL );
>     // link provisioning data
>     list_add_tail (&pdpram_blk->list, &freercvpool);
> }
> 
> Free loop is correct in my opinion but kfree should be extended by checking
> of NULL pointer because allocation of pdpram_blk could fail and we free also
> pdpram_blk->pbuffer.
>> Also there should be spaces before and after the ">=".
>>
>> regards,
>> dan carpenter
>>
>>> +     return STATUS_FAILURE;
>>>  }
>>>
>>
> 
> marek
> 

WARNING: multiple messages have this Message-ID (diff)
From: walter harms <wharms@bfs.de>
To: Belisko Marek <marek.belisko@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
	kernel-janitors@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@suse.de>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: ft1000: fix error path
Date: Sun, 26 Sep 2010 19:18:06 +0200	[thread overview]
Message-ID: <4C9F804E.8010902@bfs.de> (raw)
In-Reply-To: <AANLkTin_4D6fF85+4dFe+qN9-nEBS8+oDMKRCtixMCPU@mail.gmail.com>


hi Marek,
IMHO the alloc sequencs is building a linked list of allocated buffer.
And if  kfree() does no magiclly follow the list this is not working.

re,
 wh


Belisko Marek schrieb:
> On Sun, Sep 26, 2010 at 3:11 PM, Dan Carpenter <error27@gmail.com> wrote:
>> On Sun, Sep 26, 2010 at 12:59:55PM +0400, Vasiliy Kulikov wrote:
>>> +err_free:
>>> +     for (i--; i>=0; i--) {
>>> +             kfree(pdpram_blk->pbuffer);
>>> +             kfree(pdpram_blk);
>>> +     }
>> This is wrong.  I don't have linux-next so I can't see the context, why
>> are we looping here?  The second iteration through the loop will cause a
>> NULL dereference.
> Some lines upper there is allocation of structure and it's internal
> buffer in loop:
> for (i=0; i<NUM_OF_FREE_BUFFERS; i++) {
>     // Get memory for DPRAM_DATA link list
>     pdpram_blk = kmalloc ( sizeof(DPRAM_BLK), GFP_KERNEL );
>     // Get a block of memory to store command data
>     pdpram_blk->pbuffer = kmalloc ( MAX_CMD_SQSIZE, GFP_KERNEL );
>     // link provisioning data
>     list_add_tail (&pdpram_blk->list, &freercvpool);
> }
> 
> Free loop is correct in my opinion but kfree should be extended by checking
> of NULL pointer because allocation of pdpram_blk could fail and we free also
> pdpram_blk->pbuffer.
>> Also there should be spaces before and after the ">=".
>>
>> regards,
>> dan carpenter
>>
>>> +     return STATUS_FAILURE;
>>>  }
>>>
>>
> 
> marek
> 

  reply	other threads:[~2010-09-26 17:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-26  8:59 [PATCH] staging: ft1000: fix error path Vasiliy Kulikov
2010-09-26  8:59 ` Vasiliy Kulikov
2010-09-26 13:11 ` Dan Carpenter
2010-09-26 13:11   ` Dan Carpenter
2010-09-26 16:56   ` Belisko Marek
2010-09-26 16:56     ` Belisko Marek
2010-09-26 17:18     ` walter harms [this message]
2010-09-26 17:18       ` walter harms
2010-09-26 19:41   ` Vasiliy Kulikov
2010-09-26 19:41     ` Vasiliy Kulikov
2010-10-03 17:58   ` [PATCH v2] " Vasiliy Kulikov
2010-10-03 17:58     ` Vasiliy Kulikov

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=4C9F804E.8010902@bfs.de \
    --to=wharms@bfs.de \
    --cc=devel@driverdev.osuosl.org \
    --cc=error27@gmail.com \
    --cc=gregkh@suse.de \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marek.belisko@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.