>> @@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver
>> *drv, int channels,
>>
>> gig_dbg(DEBUG_INIT, "cs initialized");
>> return cs;
>> -
>> -error:
>> +free_bcs:
>> +kfree(cs->bcs);
>> +report_failure:
>> gig_dbg(DEBUG_INIT, "failed");
>>
>> @@ -772,8 +775,9 @@ struct cardstate *gigaset_initcs(struct gigaset_driver
>> *drv, int channels,
>>
>> gig_dbg(DEBUG_INIT, "cs initialized");
>> return cs;
>> -
>> -error:
>> +free_bcs:
>> +kfree(cs->bcs);
>> +report_failure:
>> gig_dbg(DEBUG_INIT, "failed");
>>
On Tue, Sep 27, 2016, at 14:52, SF Markus Elfring wrote:
> >> * Is it still correct nowadays that the function "gigaset_initcs" did not
> >> call the function "kfree" after a later function call failed?
> >
> > Yes, if it is handled in another place, Paul already did show you the place.
>
> To
On Tue, Sep 27, 2016, at 14:52, SF Markus Elfring wrote:
> >> * Is it still correct nowadays that the function "gigaset_initcs" did not
> >> call the function "kfree" after a later function call failed?
> >
> > Yes, if it is handled in another place, Paul already did show you the place.
>
> To
>> * Is it still correct nowadays that the function "gigaset_initcs" did not
>> call the function "kfree" after a later function call failed?
>
> Yes, if it is handled in another place, Paul already did show you the place.
To which source code place do you refer here?
>> * Do you expect that
>> * Is it still correct nowadays that the function "gigaset_initcs" did not
>> call the function "kfree" after a later function call failed?
>
> Yes, if it is handled in another place, Paul already did show you the place.
To which source code place do you refer here?
>> * Do you expect that
Am 27.09.2016 um 13:32 schrieb SF Markus Elfring:
>>> I got the impression that the exception handling was incomplete in the
>>> implementation of the function "gigaset_initcs".
>>
>> That impression is wrong. Careful reading of the code will confirm that.
>
> * Is it still correct nowadays that
Am 27.09.2016 um 13:32 schrieb SF Markus Elfring:
>>> I got the impression that the exception handling was incomplete in the
>>> implementation of the function "gigaset_initcs".
>>
>> That impression is wrong. Careful reading of the code will confirm that.
>
> * Is it still correct nowadays that
On Tue, Sep 27, 2016, at 13:32, SF Markus Elfring wrote:
> >> I got the impression that the exception handling was incomplete in the
> >> implementation of the function "gigaset_initcs".
> >
> > That impression is wrong. Careful reading of the code will confirm that.
>
> * Is it still correct
On Tue, Sep 27, 2016, at 13:32, SF Markus Elfring wrote:
> >> I got the impression that the exception handling was incomplete in the
> >> implementation of the function "gigaset_initcs".
> >
> > That impression is wrong. Careful reading of the code will confirm that.
>
> * Is it still correct
>> I got the impression that the exception handling was incomplete in the
>> implementation of the function "gigaset_initcs".
>
> That impression is wrong. Careful reading of the code will confirm that.
* Is it still correct nowadays that the function "gigaset_initcs" did not
call the
>> I got the impression that the exception handling was incomplete in the
>> implementation of the function "gigaset_initcs".
>
> That impression is wrong. Careful reading of the code will confirm that.
* Is it still correct nowadays that the function "gigaset_initcs" did not
call the
Hi,
as longtime maintainer of the code in question I feel compelled to chime
in at this point.
On Tue, Sep 27, 2016, at 11:34, SF Markus Elfring wrote:
> >> Will it matter here if the function "kfree" will be called for the
> >> data structure members "bcs" and "inbuf" after a later function
Hi,
as longtime maintainer of the code in question I feel compelled to chime
in at this point.
On Tue, Sep 27, 2016, at 11:34, SF Markus Elfring wrote:
> >> Will it matter here if the function "kfree" will be called for the
> >> data structure members "bcs" and "inbuf" after a later function
You're in Eliza mode again.
(Hat tip to Björn Mork, https://lkml.org/lkml/2016/1/4/259).
Paul Bolle
You're in Eliza mode again.
(Hat tip to Björn Mork, https://lkml.org/lkml/2016/1/4/259).
Paul Bolle
>> Will it matter here if the function "kfree" will be called for the
>> data structure members "bcs" and "inbuf" after a later function call
>> failed within the implementation of "gigaset_initcs"?
>
> My translation of this question is: could you please hold my hand while
> I read the code of a
>> Will it matter here if the function "kfree" will be called for the
>> data structure members "bcs" and "inbuf" after a later function call
>> failed within the implementation of "gigaset_initcs"?
>
> My translation of this question is: could you please hold my hand while
> I read the code of a
On Tue, 2016-09-27 at 07:20 +0200, SF Markus Elfring wrote:
> Will it matter here if the function "kfree" will be called for the
> data structure members "bcs" and "inbuf" after a later function call
> failed within the implementation of "gigaset_initcs"?
My translation of this question is: could
On Tue, 2016-09-27 at 07:20 +0200, SF Markus Elfring wrote:
> Will it matter here if the function "kfree" will be called for the
> data structure members "bcs" and "inbuf" after a later function call
> failed within the implementation of "gigaset_initcs"?
My translation of this question is: could
Ah well... Someone else discovered the double free bug first and gave
it away. Reassuring, I guess.
regards,
dan carpenter
Ah well... Someone else discovered the double free bug first and gave
it away. Reassuring, I guess.
regards,
dan carpenter
> This patch creates new bugs.
Thanks for your information.
> I have a policy of not telling Markus where the bug is,
I find this kind of response strange.
> because otherwise he'll just resend the patch
This can also happen when the other contributors request it.
> and I have told him
> This patch creates new bugs.
Thanks for your information.
> I have a policy of not telling Markus where the bug is,
I find this kind of response strange.
> because otherwise he'll just resend the patch
This can also happen when the other contributors request it.
> and I have told him
This patch creates new bugs.
I have a policy of not telling Markus where the bug is, because
otherwise he'll just resend the patch and I have told him many times to
stop sending these cleanup patches that just introduce bugs and waste
maintainer time.
regards,
dan carpenter
This patch creates new bugs.
I have a policy of not telling Markus where the bug is, because
otherwise he'll just resend the patch and I have told him many times to
stop sending these cleanup patches that just introduce bugs and waste
maintainer time.
regards,
dan carpenter
>> Memory was not released (as it would be expected) when one call
>> of further resource reservations failed.
>
> This was the only thing in this series that triggered more than a,
> very uninspired, "meh" on first read.
Will it matter here if the function "kfree" will be called for the
data
>> Memory was not released (as it would be expected) when one call
>> of further resource reservations failed.
>
> This was the only thing in this series that triggered more than a,
> very uninspired, "meh" on first read.
Will it matter here if the function "kfree" will be called for the
data
Markus,
On Mon, 2016-09-26 at 17:43 +0200, SF Markus Elfring wrote:
> Memory was not released (as it would be expected) when one call
> of further resource reservations failed.
This was the only thing in this series that triggered more than a, very
uninspired, "meh" on first read.
> * Split a
Markus,
On Mon, 2016-09-26 at 17:43 +0200, SF Markus Elfring wrote:
> Memory was not released (as it would be expected) when one call
> of further resource reservations failed.
This was the only thing in this series that triggered more than a, very
uninspired, "meh" on first read.
> * Split a
From: Markus Elfring
Date: Mon, 26 Sep 2016 16:30:50 +0200
Memory was not released (as it would be expected) when one call
of further resource reservations failed.
* Split a condition check for memory allocation failures so that
each pointer from these function
From: Markus Elfring
Date: Mon, 26 Sep 2016 16:30:50 +0200
Memory was not released (as it would be expected) when one call
of further resource reservations failed.
* Split a condition check for memory allocation failures so that
each pointer from these function calls will be checked
32 matches
Mail list logo