Re: [patch -mm series] ia64 specific /dev/mem handlers

From: Andrew Morton <akpm_at_osdl.org>
Date: 2005-03-10 17:55:16
Jes Sorensen <jes@wildopensource.com> wrote:
>
> Convert /dev/mem read/write calls to use arch_translate_mem_ptr if
>  available. Needed on ia64 for pages converted fo uncached mappings to
>  avoid it being accessed in cached mode after the conversion which can
>  lead to memory corruption. Introduces PG_uncached page flag for
>  marking pages uncached.

For some reason this patch still gives me the creeps.  Maybe it's because
we lose a page flag for something so obscure.

Nothing ever clears PG_uncached.  We'll end up with every page in the
machine marked as being uncached.

But then, nothing ever sets PG_uncached, either.  Is there some patch which
you're hiding from me?

If a page is marked uncached then it'll remain marked as uncached even
after it's unmapped.  Or will it?  Would like to see the other patch, please.

We should add PG_uncached checks to the page allocator.  Is this OK?


--- 25/mm/page_alloc.c~ia64-specific-dev-mem-handlers-checks	2005-03-09 22:53:12.000000000 -0800
+++ 25-akpm/mm/page_alloc.c	2005-03-09 22:53:44.000000000 -0800
@@ -108,6 +108,7 @@ static void bad_page(const char *functio
 			1 << PG_active	|
 			1 << PG_dirty	|
 			1 << PG_swapcache |
+			1 << PG_uncached |
 			1 << PG_writeback);
 	set_page_count(page, 0);
 	reset_page_mapcount(page);
@@ -321,6 +322,7 @@ static inline void free_pages_check(cons
 			1 << PG_reclaim	|
 			1 << PG_slab	|
 			1 << PG_swapcache |
+			1 << PG_uncached |
 			1 << PG_writeback )))
 		bad_page(function, page);
 	if (PageDirty(page))
@@ -446,6 +448,7 @@ static void prep_new_page(struct page *p
 			1 << PG_dirty	|
 			1 << PG_reclaim	|
 			1 << PG_swapcache |
+			1 << PG_uncached |
 			1 << PG_writeback )))
 		bad_page(__FUNCTION__, page);
 
_

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Thu Mar 10 01:56:43 2005

This archive was generated by hypermail 2.1.8 : 2005-08-02 09:20:36 EST