On Mon, Jan 12, 2015 at 10:54:50AM -0800, John Stultz wrote: > On Sun, Jan 11, 2015 at 4:41 AM, Richard Cochran > <richardcoch...@gmail.com> wrote: > > On Fri, Jan 09, 2015 at 04:34:24PM -0800, John Stultz wrote: > >> When calculating the current delta since the last tick, we > >> currently have no hard protections to prevent a multiplciation > >> overflow from ocurring. > > > > This is just papering over the problem. The "hard protection" should > > be having a tick scheduled before the range of the clock source is > > exhausted. > > So I disagree this is papering over the problem. > > You say the tick should be scheduled before the clocksource wraps - > but we have logic to do that.
Well that is a shame. To my way of thinking, having a reliable watchdog (clock readout) at half the period would be a real solution. Yes, I do mean providing some sort of "soft real time" guarantee. What is the use case here? I thought we are trying to fix unreliable clocks with random jumps. It is hard to see how substituting MAX_DURATION for RANDOM_JUMP_VALUE is helping to catch bad hardware. > However there are many ways that can still go wrong. Virtualization > can delay interrupts for long periods of time, fixable with some soft RT? > the timer/irq code isn't the simplest and there can be bugs, simplify and fix? > or timer hardware itself can have issues. for this we can have a compile time timer validation module, just like we have for locks, mutexs, rcu, etc. > The difficulty is that when something has gone wrong, the > only thing we have to measure the problem may become corrupted. And > worse, once the timekeeping code is having problems, that can result > in bugs that manifest in all sorts of strange ways that are very > difficult to debug (you can't trust your log timestamps, etc). But this this patch make the timestamps trustworthy? Not really. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
