Messages in this thread | | | Date | Thu, 16 Dec 2004 15:28:20 +0100 | From | Andrea Arcangeli <> | Subject | Re: kernel BUG at mm/rmap.c:480 in 2.6.10-rc3-bk7 |
| |
On Thu, Dec 16, 2004 at 05:18:59AM +0000, Hugh Dickins wrote: > going on, such avoidance may be the right course of action; but not yet.
Yes, the real reason of my changes are quite unrelated to this bug: i.e. we to keep mapcount zero for all pages with page->mapping = NULL so they don't even enter objrmap.c, and to enforce other nice bits like that page-reserved must have page->mapping = NULL and other VM_RESERVED related enforcements. It wasn't meant to hide bugs and infact we should remove anything that that hides real bugs if my changes are truly hiding them. I still don't excude they're a real fix though, the fact I can't tell the exact reason why they help doesn't mean they're not fixing the real bug (there's quite some code in objrmap.c that definitely should not be involved with non-pageable pages, and my patch enforces this, unlike mainline).
Infact if a page becomes suddenly unreserved, shouldn't the accounting break anyways at the page->count level? The page would be freed twice instead of once.
I wonder if the sg_cleanup explains why some mapped reserved page suddenly become unreserved. Can you track if the DRM_IOCTL_SG_FREE is being called in a mapped vma? I guess you could start by enabling DRM(flags) in drm_init.h.
#if 0 int DRM(flags) = DRM_FLAG_DEBUG; #else int DRM(flags) = 0; #endif
(set to 1 and then it should print something) - 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/
| |