Проблемът очевидно се случва в kernelspace, което в случая въпреки че не си пейстнал стойност на EIP, може да се докаже лесно
Значи адресното пространство на един процес (32-битова архитектура) почва от 0х00000000 и стига до 0хffffffff. Имаш 3/1 разделение userspace/kernelspace, което значи че първите 3 гигабайта са ти паметта на процеса, a "горният" 1 гигабайт се ползва от ядрото. Ако превърнеш 3*1024*1024*1024 (3 гигабайта) в шеснадесетичен вид ще установиш, че паметта на ядрото ти се мапва на адресите след 0xc000000 (3221225472).
Въпросния crashdump реве че проблемният адрес се намира на 0хc19a3580, което е в последния гигабайт, т.е паметта използвана от ядрото.
Въпросният последен 1 гигабайт се мапва по един и същ начин в адресното пространство на всеки един процес. Въпреки което, в usermode (ring3) тази памет не може да се чете, страниците, които я съдържат се маркират без read флаг (с малки изключения).
Една програма не би следвало да достъпва памет на такива адреси. Ако това се случи (поради някакъв бъг), възниква page fault, прави се една проверка може ли или не може да се чете паметта и ако не може (какъвто е случая), програмата се терминира със SIGSEGV. Такива stack traces и тем подобни неща не се изгенерират.
Когато от usermode се прехвърлим в kernelmode обаче (което обикновенно става когато процеса извика някой syscall), управлението се прехвърля на ядрото, което работи с по-високи привилегии (ring0). Оттам въпросната памет над 3-тия гигабайт може да се достъпва. Въпреки което, ядрото, както и процеса използват виртуална памет. Ако ядрото се опита да достъпи невалиден адрес (примерно такъв виртуален адрес, на който няма мапирана физическа памет или пък страницата има идиотски атрибути, тогава най-вероятно ще възникне kernel panic или нещо стряскащо от сорта, в зависимост от това къде точно се е случило.
Според твоят stack trace всичко е започнало когато imapd е извикало syscall-а read(), за да изчете нещо си от някакъв файл:
^^^
..........
Dec 15 09:06:30 XXX kernel: [<c01726ed>] vfs_read+0x9d/0x140
Dec 15 09:06:30 XXX kernel: [<c0172bf1>] sys_read+0x41/0x70
Dec 15 09:06:30 XXX kernel: [<c0104092>] syscall_call+0x7/0xb
.....
А, да, това:
Dec 15 09:06:30 XXX kernel: [<f8dc383a>] rtl8169_rx_interrupt+0x3aa/0x590 [r8169
Не би трябвало да е проблем. Просто се е вдигнало прекъсването на мрежовата карта и въпросния interrupt handler инсталиран от r8169 се е вдигнал, за да ти обработи пристигналия пакет.
Защо забива само в imapd...е интересен въпрос, но може да се намерят доста обяснения. Примерно imap гледам, че ползва асинхронно I/O, за да чете от файловата система, това не е нещо толкова често срещано. Може би наистина това ядро има бъг свързан с VFS layer-a и асинхронното И/О.
Също така може да имаш проблем с паметта...generic_file_aio_read ти изчита файла и съхранява изчетеното в страници от паметта, намиращи се на ъъъъм....дефектно място.
И да, на теория е възможно (макар и малко вероятно) самият r8169 драйвер да е бъглив и да презаписва по грешка памет с глупости. Това, което ме кара да се съмнявам в тази теория е че се случва както казваш единствено в imapd. Би следвало да става и с други процеси, би следвало да става и по-често.
Всъщност мога да измисля и още доста конспиративни теории по въпроса, но не мисля, че това ще помогне с нещо. Това, което според мен е най-вероятното е или дефектирала памет, или някакъв бъг точно в тази версия на ядрото, която ползваш.
Автор
Тема: Кернел бъг или imap бъг (Прочетена 1264 пъти)
Jun 07, 2005, 13:09