Re: kernel BUG at mm/rmap.c:480 in 2.6.10-rc3-bk7

[Andrea Arcangeli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/