> The original patch was basically fine.
I propose to reconsider the interpretation of the software situation once more.
* Should the allocated clock object be kept usable even after
a successful return from this function?
* How much do “destructor” calls matter here for (sub)devices?
> Just
> On Tue, Jun 02, 2020 at 01:10:34PM +0200, Markus Elfring wrote:
> > > The original patch was basically fine.
> >
> > I propose to reconsider the interpretation of the software situation once
> > more.
> >
> > * Should the allocated clock object be kept usable even after
> > a successful re
On Tue, Jun 02, 2020 at 01:10:34PM +0200, Markus Elfring wrote:
> > The original patch was basically fine.
>
> I propose to reconsider the interpretation of the software situation once
> more.
>
> * Should the allocated clock object be kept usable even after
> a successful return from this fun
The original patch was basically fine. Just add a Fixes tag and resend.
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 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()
c
> > 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
> It's possible that we expect an usable clk pointer, though I could not find
> the exact usage yet.
I am curious if another developer would like to add helpful background
information.
> For security, I will release this pointer only on error paths in this
> function.
Do you tend to release o
>
> > For security, I will release this pointer only on error paths in this
> > function.
>
> Do you tend to release objects (which are referenced by pointers)?
>
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(
>
> > It's the same when gm20b_clk_new() returns from elsewhere following this
> > call.
>
> I suggest to reconsider the interpretation of the software situation once
> more.
> Can it be that the allocated clock object should be kept usable even after
> a successful return from this function?
>
> When gk20a_clk_ctor() returns an error code, pointer "clk"
> should be released.
Such an information is reasonable.
> It's the same when gm20b_clk_new() returns from elsewhere following this call.
I suggest to reconsider the interpretation of the software situation once more.
Can it be that t
> > 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
> > If there's *any* error, it'll check the pointer, if it's non-NULL,
> > it'll call the destructor. If kzalloc() fails, the pointer will be
> > NULL, there's no double-free bug. *every* subdev is written this way
> > to avoid duplicating cleanup logic.
> Actually, gm20b_clk_new_speedo0() may ha
> 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
___
dri-devel mailing list
dri-devel@lis
Hi Ben,
> > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > should be released. It's the same when gm20b_clk_new()
> > returns from elsewhere following this call.
> This shouldn't be necessary. If a subdev constructor fails, and
> returns a pointer, the core will call the destruc
On Mon, 1 Jun 2020 at 13:37, Ben Skeggs wrote:
>
> On Mon, 1 Jun 2020 at 13:27, wrote:
> >
> >
> > Hi Ben,
> >
> > > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > > should be released. It's the same when gm20b_clk_new()
> > > > returns from elsewhere following this call.
> >
On Mon, 1 Jun 2020 at 13:27, wrote:
>
>
> Hi Ben,
>
> > > When gk20a_clk_ctor() returns an error code, pointer "clk"
> > > should be released. It's the same when gm20b_clk_new()
> > > returns from elsewhere following this call.
> > This shouldn't be necessary. If a subdev constructor fails, and
>
On Sat, 30 May 2020 at 19:42, Dinghao Liu wrote:
>
> When gk20a_clk_ctor() returns an error code, pointer "clk"
> should be released. It's the same when gm20b_clk_new()
> returns from elsewhere following this call.
This shouldn't be necessary. If a subdev constructor fails, and
returns a pointer,
When gk20a_clk_ctor() returns an error code, pointer "clk"
should be released. It's the same when gm20b_clk_new()
returns from elsewhere following this call.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8
1 file changed, 4 insertions(+), 4 deletions(
18 matches
Mail list logo
