Messages in this thread | | | Date | Wed, 8 Apr 2009 11:41:59 +0200 | From | Andi Kleen <> | Subject | Re: [PATCH] [3/16] POISON: Handle poisoned pages in page free |
| |
On Wed, Apr 08, 2009 at 04:39:17PM +0900, Minchan Kim wrote: > On Wed, Apr 8, 2009 at 3:51 PM, Andi Kleen <andi@firstfloor.org> wrote: > >> > > >> > /* > >> > + * Page may have been marked bad before process is freeing it. > >> > + * Make sure it is not put back into the free page lists. > >> > + */ > >> > + if (PagePoison(page)) { > >> > + /* check more flags here... */ > >> > >> How about adding WARNING with some information(ex, pfn, flags..). > > > > The memory_failure() code is already quite chatty. Don't think more > > noise is needed currently. > > Sure. > > > Or are you worrying about the case where a page gets corrupted > > by software and suddenly has Poison bits set? (e.g. 0xff everywhere). > > That would deserve a printk, but I'm not sure how to reliably test for > > that. After all a lot of flag combinations are valid. > > I misunderstood your code. > That's because you add the code in bad_page. > > As you commented, your intention was to prevent bad page from returning buddy. > Is right ?
Yes. Well actually it should not happen anymore. Perhaps I should make it a BUG()
> If it is right, how about adding prevention code to free_pages_check ? > Now, bad_page is for showing the information that why it is bad page > I don't like emergency exit in bad_page.
There's already one in there, so i just reused that one. It was a convenient way to keep things out of the fast path
-Andi
ak@linux.intel.com -- Speaking for myself only. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |