[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d50ea531-c5cf-81d5-9cc5-0ab92b39232d@gmail.com>
Date: Sat, 5 Nov 2022 09:12:37 +0100
From: Christian König <ckoenig.leichtzumerken@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>,
Christian König <christian.koenig@....com>
Cc: linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Stephen Boyd <sboyd@...nel.org>,
Guenter Roeck <linux@...ck-us.net>,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linaro-mm-sig@...ts.linaro.org
Subject: Re: [Linaro-mm-sig] Re: [RFC][PATCH v3 12/33] timers: dma-buf: Use
timer_shutdown_sync() before freeing timer
Am 04.11.22 um 19:58 schrieb Steven Rostedt:
> On Fri, 4 Nov 2022 08:15:53 +0100
> Christian König <christian.koenig@....com> wrote:
>
>>> index fb6e0a6ae2c9..5d3e7b503501 100644
>>> --- a/drivers/dma-buf/st-dma-fence.c
>>> +++ b/drivers/dma-buf/st-dma-fence.c
>>> @@ -412,7 +412,7 @@ static int test_wait_timeout(void *arg)
>>>
>>> err = 0;
>>> err_free:
>>> - del_timer_sync(&wt.timer);
>>> + timer_shutdown_sync(&wt.timer);
>> Mhm, what exactly is the benefit of renaming the function?
>>
>> Not that I'm against the change, but my thinking is more if there are
>> more functions which don't re-arm the time than those which do that then
>> why not forbid it in general?
> Timers are more often re-armed then not. I had to look for the
> locations where del_timer*() was called just before freeing, and other
> locations where they are freed later.
>
> I didn't rename del_timer_sync() to timer_shutdown_sync(), this version
> renamed the new "del_timer_shutdown()" to "timer_shutdown_sync()".
>
> Maybe I'm just confused at what you are asking.
No, that explains it a bit better. I was just wondering what exactly the
different to del_timer_sync() is.
Maybe shorten the summary in the cover letter a bit. The history how
this change came to be is not as interesting as why we are changing
something.
Regards,
Christian.
>
> -- Steve
> _______________________________________________
> Linaro-mm-sig mailing list -- linaro-mm-sig@...ts.linaro.org
> To unsubscribe send an email to linaro-mm-sig-leave@...ts.linaro.org
Powered by blists - more mailing lists