Nouveau - May 2020 - drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new()

> > I just found that clk is referenced by pclk in this function. When clk
is freed,
> > pclk will be allocated in gm20b_clk_new_speedo0(). Thus we should not
release clk
> > in this function and there is no bug here.
> 
> Can there be a need to release a clock object after a failed
gk20a_clk_ctor() call?
> 
I think this mainly depends on pclk pointer. It seems that the caller of 
gm20b_clk_new() always expects pclk to be allocated unless it returns -ENOMEM,
which means kzalloc() failed. If gk20a_clk_ctor() never returns such an error 
code, we may need not to release this clock object.

Regards,
Dinghao

> If gk20a_clk_ctor() never returns such an error code,
> we may need not to release this clock object.
Would you like to achieve complete exception handling
also for this function implementation?

Regards,
Markus

> > If gk20a_clk_ctor() never returns such an error code,
> > we may need not to release this clock object.
> 
> Would you like to achieve complete exception handling
> also for this function implementation?
> 
It seems that it's possible to get -ENOMEM from gk20a_clk_ctor().
The call chain is as follows:
gk20a_clk_ctor() <- nvkm_clk_ctor() <- nvkm_notify_init()

When nvkm_notify_init() returns -ENOMEM, all of its callers (and 
callers of callers) will be influenced if there is a failed
kzalloc inside which. 

In this case, maybe we should check the return value of 
gk20a_clk_ctor() and release clk if it returns -ENOMEM. 
And many other functions also have the same issue (e.g.,
gm20b_clk_new_speedo0). Do you have any idea about this 
problem?

Regards,
Dinghao