On Wed, 01 Apr 2009 22:22:06 +0200 Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > Jeff Layton <jlayton@xxxxxxxxxx> writes: > > > > The problem is that these checks assume that dirtied_when is updated > > periodically. If an inode is continuously being used for I/O it can be > > persistently marked as dirty and will continue to age. Once the time > > difference between dirtied_when and the jiffies value it is being > > compared to is greater than or equal to half the maximum of the jiffies > > type, the logic of the time_*() macros inverts and the opposite of what > > is needed is returned. On 32-bit architectures that's just under 25 days > > (assuming HZ == 1000). > > I wonder if this can happen in other places using jiffies time stamp > too. Why not? Perhaps that check macro should be in timer.h and some auditing done > over the whiole code base? > It certainly can happen in other places. We've seen very similar problems in NFS, and they were fixed in similar ways. That's where the time_in_range macro came from. I agree that a thorough audit of jiffies usage would be a fine thing... One possibility might be a new debugging option. We could add replacement time_after() and time_before() macros that also check whether the difference in times is beyond a certain threshold (maybe a day or week or so), and pop a printk or otherwise record info about it when one is detected? That wouldn't find all of the problem cases, but it might help ID some of them. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
