On Wed, 16 Feb 2005, Erik de Castro Lopo wrote: > > The problem is triggered by a user space application which > mmaps memory space on a custom PCI card via /dev/mem, reads > some data and munmaps it. The program works perfectly on a > 2.4.26 kernel. On 2.6.10 I get this on the console: > > kernel BUG at mm/rmap.c:483! > EIP is at page_remove_rmap+0x26/0x40 > [<c0135a38>] zap_pte_range+0x138/0x250 ... > [<c0139870>] sys_munmap+0x40/0x70 > > Is there anything I have missed? Does /dev/mem on a 2.6 > kerel behave the same way as on a 2.4 kernel?
Yes, I believe /dev/mem handling on 2.4 and 2.6 is much the same, but the rmap.c BUG you're hitting in 2.6 had no equivalent in 2.4 - maybe the 2.4 case has actually been unsafe too, or maybe not. Though there have been other reports of this BUG, some remaining mysterious, some down to bad ram, your case is almost certainly due to mismatched PageReserved accounting. mmap of /dev/mem only works usefully when the mapped pages are outside of ordinary ram, or temporarily marked PageReserved, normally by the relevant driver. It seems that when the user space application mapped that part of /dev/mem, the pages were marked PageReserved, and rmap accounting skipped. But when the user space application unmapped that part of /dev/mem, the pages were no longer marked PageReserved, so rmap accounting hit the BUG. I may be wrong, but I think it's fair to say that usually when there's to be cooperation between driver and user space of this kind, the driver would offer its own device and mmap entry point, user space would be mapping that rather than /dev/mem, and file reference counting would avoid the possibility that driver clears PageReserved while the page is mapped. Beyond this particular BUG, clearing PageReserved too soon is likely to lead to freeing an already freed page - noticed with a warning if the page is still free, but mayhem if by then reused. Which is the driver involved? Or, might the user space application be (arguably) at fault, mmap'ing an indeterminate uncontrolled area of /dev/mem, some pages of which may or may not be PageReserved at any instant? (Yes, PageReserved is an unsatisfactory notion we should have weaned the kernel off long ago.) Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/