Re: [patch] mm: bug in set_page_dirty_buffers

[Nick Piggin <npiggin@suse.de>]

On Tue, Oct 10, 2006 at 01:41:14AM -0700, Andrew Morton wrote:
> On Tue, 10 Oct 2006 10:18:20 +0200
> Nick Piggin <npiggin@suse.de> wrote:
> 
> > > If the buffer's redirtied after discard_buffer() got at it, we've got some
> > > nasty problems in there.
> > > 
> > > Are you sure this race can happen?  Nobody's allowed to have a page mapped
> > > while it's undergoing truncation (vmtruncate()).
> > 
> > Well, not technically. I think it can happen with nonlinear pages now,
> 
> How?

It is the pagefault vs invalidate race. It happens with truncate with
nonlinear mappings because they don't have the truncate_count logic.

It can also happen with normal pagecache vs invalidate_inode_pages2.

> > but that is a bug in truncate and I have some patches to fix them.
> > 
> > But anyone who has done a get_user_pages, AFAIKS, can later run a
> > set_page_dirty on the pages.
> 
> Most (all?) callers are (and should be) using set_page_dirty_lock().

They don't, and I haven't checked but I doubt it is because they
always have the page locked.

> > Nasty problem, but I think we are OK to
> > just ignore the dirty bits in this case, because the truncate might
> > well have happened _after_ the get_user_pages guy set the page dirty
> > anyway.
> > 
> > > There might be a problem with the final blocks in the page outside i_size. 
> > > iirc what happens here is that the bh outside i_size _is_ marked dirty, but
> > > writepage() will notice that it's outside i_size and will just mark it
> > > clean again without doing IO.
> > 
> > Didn't think of that. How does it get to writepage though, if it has
> > lost its mapping?
> 
> It was only partially truncated - it's still on the address_space.

Oh OK fine.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>