* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 19 Jul 2007 21:09:09 -0400
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
> > Coverity spotted what looks like a real possible case of using a
> > variable after it has been freed.
> > The problem is in kernel/relay.c::relay_open_buf()
> >
On Thu, 19 Jul 2007 21:09:09 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Coverity spotted what looks like a real possible case of using a
> variable after it has been freed.
> The problem is in kernel/relay.c::relay_open_buf()
>
> If the code hits "goto free_buf;" it ends up in this
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits "goto free_buf;" it ends up in this code :
free_buf:
relay_destroy_buf(buf); <--- calls kfree() on 'buf'.
free_name:
On 19/07/07, David J. Wilder <[EMAIL PROTECTED]> wrote:
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Ok, thank you for testing. I see that Mathieu Desnoyers also ack'ed
the patch (thank you
* Jesper Juhl ([EMAIL PROTECTED]) wrote:
> Hi,
>
> Coverity spotted what looks like a real possible case of using a
> variable after it has been freed.
> The problem is in kernel/relay.c::relay_open_buf()
>
> If the code hits "goto free_buf;" it ends up in this code :
>
> free_buf:
>
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Thanks
Dave
Jesper Juhl wrote:
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Thanks
Dave
Jesper Juhl wrote:
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The
* Jesper Juhl ([EMAIL PROTECTED]) wrote:
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits goto free_buf; it ends up in this code :
free_buf:
On 19/07/07, David J. Wilder [EMAIL PROTECTED] wrote:
ACK
Thanks for catching this. Your patch looks fine. I tested for
regression, no problems. I also tested the error path and had the
expected results.
Ok, thank you for testing. I see that Mathieu Desnoyers also ack'ed
the patch (thank you
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits goto free_buf; it ends up in this code :
free_buf:
relay_destroy_buf(buf); --- calls kfree() on 'buf'.
free_name:
On Thu, 19 Jul 2007 21:09:09 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits goto free_buf; it ends up in this code :
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Thu, 19 Jul 2007 21:09:09 -0400
Mathieu Desnoyers [EMAIL PROTECTED] wrote:
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits "goto free_buf;" it ends up in this code :
free_buf:
relay_destroy_buf(buf); <--- calls kfree() on 'buf'.
Hi,
Coverity spotted what looks like a real possible case of using a
variable after it has been freed.
The problem is in kernel/relay.c::relay_open_buf()
If the code hits goto free_buf; it ends up in this code :
free_buf:
relay_destroy_buf(buf); --- calls kfree() on 'buf'.
14 matches
Mail list logo
