Re: Please help me understand ->writepage. Was Re: segfault mdadm--write-behind, 2.6.14-mm2 (was: Re: RAID1 ramdisk patch)

From: Andrew Morton
Date: Mon Nov 21 2005 - 18:52:46 EST

Neil Brown <neilb@xxxxxxx> wrote:
> Help ???

Indeed. tmpfs is crackpottery.

> What md/bitmap wants to do is effectively memory map the file, make
> updates to pages occasionally, flush those pages out to storage, and
> wait for the flush to complete. It doesn't exactly memory map. It
> just reads all the pages and keeps them in an array (holding a
> reference to each).
> To write the pages out it effectively does ->prepare_write,
> ->commit_write, and then ->writepage.
> I'm not sure that prepare/commit is needed, but they don't seem to be
> the problem. writepage is.
> For tmpfs at least, writepage disconnects the page from the pagecache
> (via move_to_swap_cache), so the page that we are holding is no longer
> part of the file and, significantly, page->mapping become NULL.
> This suggests that the ->writepage usage is broken.
> However I tried to see what 'msync' does for real memory mapped files,
> and it eventually calls ->writepage too. So how does that work??
> Any advice would be most welcome!

Skip the writepage if !mapping_cap_writeback_dirty(page->mapping), I guess.
Or, if appropriate, just sync the file. Use filemap_fdatawrite() or even
refactor do_fsync() and use most of that.

Also, write_page() doesn't need to run set_page_dirty(); ->commit_write()
will do that.

Several kmap()s in there which can become kmap_atomic().

bitmap_init_from_disk() might be leaking bitmap->filemap on kmalloc-failed
error path.

bitmap->filemap_attr can be allocated with kzalloc() now.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at