BUG at rmap.c:212
Quoted 10 lines · Rik van Riel
Quoted 4 lines · Petr Vandrovec
yesterday I told (in IDE thread) that BUG at rmap.c:212 is probably
already fixed by changeset 520. Unfortunately, it is not, I got it again with BK tree. It happened again when 'ntpd' calledexit()upon receiving sigterm.Line 212 is '
pte_chain_unlock(page);' right ?What configuration are you running ? SMP ? PREEMPT ? What compiler ?
Nope. On my system (2.5.29-changeset548) it is a BUG() call which was added by akpm in rmap.c revision 1.5, in his 'Add BUG() on a can't-happen code path in page_remove_rmap()'. It just added #else BUG() branch to #ifdef DEBUG_RMAP conditional.
Kernel is SMP, non-preempt, running on UP P4. Compiler is 2.95.4 from Debian sid.
Quoted 12 lines
Quoted 12 lines
Stack trace:
page_remove_rmap
zap_pte_range
zap_pmd_range
unmap_page_range
exit_mmap
mmput
do_exit
sys_exit
syscall_call
Quoted 6 lines
Quoted 4 lines
If it is not known bug, I'll rebuild kernel with
DEBUG_RMAP. Unfortunately it looks like that machine must have uptime > 12hrs to trigger this. Probably updatedb or some other task must be run to try to swap ntpd out?It is not a known bug. In fact I've never seen this one before.
Probably because of your code did not do anything special when 'Not found. This should NEVER happen!' code path triggers. Code in bitkeeper since 27th July complains. I'm now running with DEBUG_RMAP set, so I'll see next time.
Petr Vandrovec [email protected]
Quoted 9 lines · Petr Vandrovec
Quoted 1 line
Line 212 is '
pte_chain_unlock(page);' right ?Nope. On my system (2.5.29-changeset548) it is a
BUG()call which was added by akpm inrmap.crevision 1.5, in his 'AddBUG()on a can't-happen code path inpage_remove_rmap()'. It just added #elseBUG()branch to #ifdefDEBUG_RMAPconditional.Probably because of your code did not do anything special when 'Not found. This should NEVER happen!' code path triggers.
It used to, until I found out that that regularly blew up for people mmap()ing devices and I had to remove that code again ;)
The reason for that problem is that a device driver would allocate memory, set PG_reserved on it and then let user programs mmap() it.
These reserved pages do not get a pte chain because the memory isn't swappable and if the page stays reserved page_remove_rmap won't even try searching for the pte chain.
However, some drivers (nvidia) clear PG_reserved without first having the programs exit, so page_remove_rmap will end up searching for the pte chain, which of course doesn't exist...
Of course, ntpd is probably running into a different problem, but the printk's enabled with DEBUG_RMAP should give us some hints.
regards,
Rik
Signature · 3 lines
Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/