lkml.org 
[lkml]   [2004]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.129 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site