okay, there can be optimization when reading exiting variable.
then is memory barrier is enough as Valdis Klētnieks said,
or spinlock is better choice?
2021년 5월 5일 (수) 오전 1:36, Hyeonggon Yoo <42.hyeyoo@xxxxxxxxx>님이 작성:
>
> Valdis Klētnieks, Thank you for your kind explanation.
>
>
> Okay, so 'timer is running' means it is not expired yet.
> and when timer is expired (as specified in 'expires' field),
> the timer_callback is called.
>
> and there can be race condition in running timer_callback.
> so locking is needed before re-registering timer.
>
> 2021년 5월 5일 (수) 오전 1:17, Valdis Klētnieks <valdis.kletnieks@xxxxxx>님이 작성:
> >
> > On Tue, 04 May 2021 23:59:12 +0900, Hyeonggon Yoo said:
> > > Does del_timer work well for timers that re-registers itself?
> > > what if the timer is currently running, and del_timer is called,
> > > and the running timer re-registers itself?
> >
> > Minor nit: while the timer is running, there's no problem.
> > When the timer has *expired* and timer_callback() is running
> > is when you have a race condition.
> >
> > So who's going to call del_timer()? The only thing that does that is
> > timer_exit. Soo... Apply some silly locking:
> >
> > static int exiting = 0;
> >
> > void timer_callback(struct timer_list *timer) {
> > struct timer_data *data = from_timer(data, timer, timer);
> > data->value++;
> > printk(KERN_INFO "[%s] value is = %d\n", __func__, data->value);
> > if (!exiting)
> > mod_timer(timer, jiffies + DELAY);
> > }
> >
> > void __exit timer_exit(void) {
> > exiting = 1;
> > int ret = del_timer(&data.timer);
> > printk("[%s] deleting timer..., ret = %d\n", __func__, ret);
> > }
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
