On Tue, 27 Jun 2006, Andrew Morton wrote:
> Peter Zijlstra <[email protected]> wrote:
> >
> > Tracking of dirty pages in shared writeable mmap()s.
>
> I mangled this a bit to fit it on top of Christoph's vm counters rewrite
> (mm/page-writeback.c).
>
> I worry about the changes to __set_page_dirty_nobuffers() and
> test_clear_page_dirty().
>
> They both already require that the page be locked (or that the
> address_space be otherwise pinned). But I'm not sure we get that right at
> present. With these changes, our exposure to that gets worse, and we
> additionally are exposed to the possibility of the page itself being
> reclaimed, and not just the address_space.
>
> So ho hum. I'll stick this:
>
> --- a/mm/page-writeback.c~mm-tracking-shared-dirty-pages-checks
> +++ a/mm/page-writeback.c
> @@ -625,6 +625,7 @@ EXPORT_SYMBOL(write_one_page);
> */
> int __set_page_dirty_nobuffers(struct page *page)
> {
> + WARN_ON_ONCE(!PageLocked(page));
I expect this warning to fire: __set_page_dirty_nobuffers is very
careful about page->mapping, it knows it might change precisely
because we often don't have PageLocked here.
> if (!TestSetPageDirty(page)) {
> struct address_space *mapping = page_mapping(page);
> struct address_space *mapping2;
> @@ -722,6 +723,7 @@ int test_clear_page_dirty(struct page *p
> struct address_space *mapping = page_mapping(page);
> unsigned long flags;
>
> + WARN_ON_ONCE(!PageLocked(page));
I don't expect this warning to fire: I checked a month or two ago,
and just checked again, I believe all paths have PageLocked here.
If not, we certainly do want to know about it.
> if (mapping) {
> write_lock_irqsave(&mapping->tree_lock, flags);
> if (TestClearPageDirty(page)) {
> _
>
> in there.
Hugh
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
