On Tue, Nov 27, 2007 at 04:51:38PM +0100, Rafael J. Wysocki wrote: > On Monday, 26 of November 2007, Rafael J. Wysocki wrote: > > On Monday, 26 of November 2007, David Chinner wrote: > > > Now there's a message that I haven't seen in about 3 years. > > > > > > It indicates that the linux inode connected to the xfs_inode is not > > > the correct one. i.e. that the linux inode cache is out of step with > > > the XFS inode cache. > > > > > > Basically, that is not supposed to happen. I suspect that the way > > > threads are frozen is resulting in an inode lookup racing with > > > a reclaim. The reclaim thread gets stopped after any use threads, > > > and so we could have the situation that a process blocked in lookup > > > has the XFS inode reclaimed and reused before it gets unblocked. > > > > > > The question is why is it happening now when none of that code in > > > XFS has changed? > > > > > > Rafael, when are threads frozen? Only when they schedule or call > > > try_to_freeze()? > > > > Kernel threads freeze only when they call try_to_freeze(). User space tasks > > freeze while executing the signals handling code. > > > > > Did the freezer mechanism change in 2.6.23 (this is on 2.6.23.1)? > > > > Yes. Kernel threads are not sent fake signals by the freezer any more. > > Ah, sorry, this change has been merged after 2.6.23. However, before 2.6.23 > we had another important change that caused all kernel threads to have > PF_NOFREEZE set by default, unless they call set_freezable() explicitly.
So try_to_freeze() will never freeze a thread if it has not been set_freezable()? And xfsbufd will never be frozen? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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/
