Re: 2.6.20-rc4: known regressions with patches (v3)

[David Chinner <dgc@sgi.com>]

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 <7atbggg02@sneakemail.com>
> Handled-By : David Chinner <dgc@sgi.com>
> 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