On Thu, Jan 11, 2007 at 06:13:29AM +0100, Adrian Bunk wrote: > This email lists some known regressions in 2.6.20-rc4 compared to 2.6.19 > with patches available. > > Subject : BUG: at mm/truncate.c:60 cancel_dirty_page() (XFS) > References : http://lkml.org/lkml/2007/1/5/308 > Submitter : Sami Farin <[EMAIL PROTECTED]> > Handled-By : David Chinner <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/1/7/201 > Status : patch available
Patch is broken, do not merge. The original had an off-by-one bug in it, and the fixed one I have has just shown a worse problem than before - partial page truncation (i.e. filesystem block size less than page size) is busted because invalidate_complete_page2_range() can only handle complete pages. Andrew - looking at unmap_mapping_pages, it says it cannot handle partial pages and must get rid of them whereas vmtrucate() handles partial pages but changes file size so can't be used. I see that vmtruncate handles this by not unmapping the first partial page. I can use the vmtruncate mechanism (unmap_mapping_pages, then truncate_inode_pages) but that seems racy to me because we are not actually truncating the file so a mmap could remap a page between the unmap and the truncate and hence we still get the warning. So the question is - is there any generic function that handles this case (i.e. don't unmap first partial page, unmap the rest, partial truncate of first page, complete truncate of the rest) without racing? Or do I need to write a variation of invalidate_inode_pages2_range() to do this? 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/