Re: [patch] mm: bug in set_page_dirty_buffers

[Andrew Morton <akpm@osdl.org>]

On Tue, 10 Oct 2006 08:19:58 +0200
Nick Piggin <npiggin@suse.de> wrote:

> On Mon, Oct 09, 2006 at 11:08:32PM -0700, Andrew Morton wrote:
> > On Tue, 10 Oct 2006 07:48:33 +0200
> > Nick Piggin <npiggin@suse.de> wrote:
> > > 
> > > Am I missing something?
> > 
> > Well it's a matter of reviewing all codepaths in the kernel which
> > manipulate internal page state and see if they're racy against their
> > ->set_page_dirty().  All because of zap_pte_range().
> 
> And page_remove_rmap.

page_remove_rmap()'s call to set_page_dirty().  Same thing.

> > The page lock protects internal page state.  It'd be better to fix
> > zap_pte_range().
> > 
> > How about we trylock the page and if that fails, back out and drop locks
> > and lock the page then dirty it and then resume the zap?  Negligible
> > overhead, would be nice and simple apart from that i_mmap_lock thing.
> 
> What about page_remove_rmap?
> 
> I don't see why. This has been the documented behaviour for ages, and
> it seems to be made fairly clear in comments around mm/ and filesystems.
> Considering the only nontrivial ->spds are those which set PageChecked
> as well, I don't see why there is much to audit (other than fs/buffer.c).

Which approach is a good design?

> Not that I think it would be a bad idea for filesystems writers to audit
> carefully against truncate,

Good luck with that.  It needs to be done for them.

> because that's been screwed up in the VM for
> so long...

What has?  Please be specific.

--
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>