…
>> A few update suggestions were taken into account
>> from static source code analysis.
…
>> Return directly after a failed kzalloc() in smc_fill_gid_list()
>> Improve exception handling in smc_llc_cli_add_link_invite()
>>
>> net/smc/af_smc.c | 2 +-
>> net/smc/smc_llc.c | 15 +++++++--------
>> 2 files changed, 8 insertions(+), 9 deletions(-)
…
> I see you want to fix the kfree(NULL) issues in these two patches.
I propose to avoid redundant function calls at various source code places.
> But I am wondering if this is necessary, since kfree() can handle NULL correctly.
Would you prefer only required data processing in affected function implementations?
Regards,
Markus
On 2024/1/2 16:51, Markus Elfring wrote:
> …
>>> A few update suggestions were taken into account
>>> from static source code analysis.
> …
>>> Return directly after a failed kzalloc() in smc_fill_gid_list()
>>> Improve exception handling in smc_llc_cli_add_link_invite()
>>>
>>> net/smc/af_smc.c | 2 +-
>>> net/smc/smc_llc.c | 15 +++++++--------
>>> 2 files changed, 8 insertions(+), 9 deletions(-)
> …
>> I see you want to fix the kfree(NULL) issues in these two patches.
>
> I propose to avoid redundant function calls at various source code places.
>
>
>> But I am wondering if this is necessary, since kfree() can handle NULL correctly.
>
> Would you prefer only required data processing in affected function implementations?
>
Thank you Markus. I understood that you want to avoid redundant function calls.
But it is not very attractive to me since the calls occur on low-frequency paths
or unlikely condition, resulting in limited performance loss and the current
kfree() usage is fine and common. So what is the benfit?
I noticed that some other discussions are on-going. It seems like you are trying
to change other similiar places. Let's collect more opinions.
https://lore.kernel.org/netdev/[email protected]/
https://lore.kernel.org/netdev/[email protected]/
https://lore.kernel.org/netdev/[email protected]/
https://lore.kernel.org/netdev/[email protected]/
Thanks.
> Regards,
> Markus
> But it is not very attractive to me since the calls occur on low-frequency paths
> or unlikely condition, resulting in limited performance loss and the current
> kfree() usage is fine and common.
The prioritisation of development activities influences progress in related areas.
> So what is the benfit?
* Source code clarity
* Nicer run time characteristics
See also:
https://wiki.sei.cmu.edu/confluence/display/c/MEM12-C.+Consider+using+a+goto+chain+when+leaving+a+function+on+error+when+using+and+releasing+resources
> I noticed that some other discussions are on-going. It seems like you are trying
> to change other similiar places.
I would appreciate if improvements can be achieved also for similarly affected
software components.
Regards,
Markus
On Tue, Jan 02, 2024 at 07:33:18PM +0800, Wen Gu wrote:
>
>
> On 2024/1/2 16:51, Markus Elfring wrote:
> > …
> > > > A few update suggestions were taken into account
> > > > from static source code analysis.
> > …
> > > > Return directly after a failed kzalloc() in smc_fill_gid_list()
> > > > Improve exception handling in smc_llc_cli_add_link_invite()
> > > >
> > > > net/smc/af_smc.c | 2 +-
> > > > net/smc/smc_llc.c | 15 +++++++--------
> > > > 2 files changed, 8 insertions(+), 9 deletions(-)
> > …
> > > I see you want to fix the kfree(NULL) issues in these two patches.
> >
> > I propose to avoid redundant function calls at various source code places.
> >
> >
> > > But I am wondering if this is necessary, since kfree() can handle NULL correctly.
> >
> > Would you prefer only required data processing in affected function implementations?
> >
>
> Thank you Markus. I understood that you want to avoid redundant function calls.
>
> But it is not very attractive to me since the calls occur on low-frequency paths
> or unlikely condition, resulting in limited performance loss and the current
> kfree() usage is fine and common. So what is the benfit?
>
> I noticed that some other discussions are on-going. It seems like you are trying
> to change other similiar places. Let's collect more opinions.
>
> https://lore.kernel.org/netdev/[email protected]/
> https://lore.kernel.org/netdev/[email protected]/
> https://lore.kernel.org/netdev/[email protected]/
> https://lore.kernel.org/netdev/[email protected]/
As as been explained to Markus many times recently,
calling kfree(NULL) is not only perfectly fine,
it is the preferred way of handling things.
Markus, please stop posting patches of this nature to Netdev.
--
pw-bot: rejected