Say yes or no to mod_timer!

Its been almost 20 days that I have not written any blog on my progress. Yes, I know I should and I am feeling sorry for that. đŸ˜¦ Anyways I am back. đŸ™‚ I worked on many new things and learnt a lot during last few days. I will not be able to sum up everything in a single blog. That’s why here I am going to post 3-4 blog posts back to back again. So, lets talk about mod_timer today.

I came to know about mod_timer function and its usage during Outreachy application. Actually one of Coccinelle challenge problem was for setup_timer function [View my blog on it to get more information]. While looking at the definition of setup_timer function, I got to know about mod_timer function. During application period, I sent few patches for that and they were accepted too. So, I decided to look at them again with the goal of writing one common semantic patch. But I ended up with skipping them completely. There are particular reason behind this. I was not sure about writing this post but then I thought outreachy is all about learning. And as I learnt something from this, I should share it.

Why mod_timer was introduced?

First of all, let me start with why mod_timer function was introduced. So, kernel documentation says that mod_timer is a more efficient way to update the expire field of an active timer (if the timer is inactive it will be activated). And if there are multiple unserialized concurrent users of the same timer, then mod_timer is the only safe way to modify the timeout. According to definition, mod_timer(timer, expires) is equivalent to:

timer->expires = expires;

What is the problem with using mod_timer for these kind of patterns?

It looks pretty obvious use, right?? But no, it is not. And reason is, it can be possible that instances of this pattern also modify the timer’s data and function fields which if the timer is still running and expiring while being fiddled with, might result in
a race condition. Which means that after the change there will be an old function but new data field being used in combination or something like that. So, it’s not a good idea to remove del_timer in the such cases and use mod_timer. One can look at the ROSE directory stack where such cases are present and we can’t use mod_timer there.

Is there any other pattern where mod_timer can be used?

Yes. I have seen some patches in sound directory from Takashi Iwai about introducing use of mod_timer. He introduced use of mod_timer for following kind of pattern:

timer->expires = expires;

I looked in to those cases where he refactored such code with mod_timer. And came across this particular case. Here, in the later one he uses setup_timer and mod_timer. There is no del_timer, because the timer is not yet running. It looked little strange because the code is not modifying an existing timer, but rather starting up a new one. So, Julia told me to ask Takashi for the same. I mailed him and also asked for suggestion about doing this in general in the kernel. He replied that “The behavior of mod_timer() for the first invocation in this case is defined to behave just like add_timer(), so it’s correct to use it. But yes it isn’t always intuitive as a replacement of add_timer()”.

So thing is for this kind of pattern mod_timer is a matter of taste and it depends on maintainers. And I guess when it comes to adding any semantic patch or doing something in a kernel, one should always think about general cases. So, Julia advised me that it could be more useful to work on other functions/macros which really need some work. And I ended up with closing chapter of mod_timer here. đŸ™‚