On 16 April 2014 00:14, Thomas Gleixner <[email protected]> wrote: > On Tue, 15 Apr 2014, Viresh Kumar wrote: > >> In tick_do_update_jiffies64() we are processing ticks only if delta is >> greater >> than tick_period. This is what we are supposed to do here and it broke a bit >> with this patch: >> >> commit 47a1b796306356f358e515149d86baf0cc6bf007 >> Author: John Stultz <[email protected]> >> Date: Thu Dec 12 13:10:55 2013 -0800 >> >> tick/timekeeping: Call update_wall_time outside the jiffies lock > > Please look how I massaged the change log. There is no point in > copying the whole gunk.
I see.. Nice. >> With above patch, we might end up calling update_wall_time() even if delta is >> found to be smaller that tick_period. Fix this by reversing the check and >> returning early. > > Well. > >> Cc: <[email protected]> # v3.14+ >> Cc: John Stultz <[email protected]> >> Signed-off-by: Viresh Kumar <[email protected]> >> --- >> kernel/time/tick-sched.c | 32 +++++++++++++++++--------------- >> 1 file changed, 17 insertions(+), 15 deletions(-) > > That's not how we do bug fixes if they can be done with 3 lines of > change. See the commit. I tried that initially but with these changes as well (which must be done now ??), which probably makes it more clear ?: diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 3cafe7d..0e70b1c 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -84,12 +84,12 @@ static void tick_do_update_jiffies64(ktime_t now) /* Keep the tick_next_period variable up to date */ tick_next_period = ktime_add(last_jiffies_update, tick_period); + + write_sequnlock(&jiffies_lock); + update_wall_time(); } else { write_sequnlock(&jiffies_lock); - return; } - write_sequnlock(&jiffies_lock); - update_wall_time(); } /* -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
