Linux kernel 2.6.15.5 released

Увиделось мне в Changelog:
commit 93e3d00a9f0158e522cada1088233fad23247882
Author: Trond Myklebust <trond.myklebust@netapp.com>
Date:   Wed Feb 15 00:42:26 2006 -0500

    [PATCH] Normal user can panic NFS client with direct I/O (CVE-2006-0555)

и захотелось обновить nfs клиентов на которых сейчас 2.6.15.4
мдя...

fs/nfs/direct.c: In function nfs_get_user_pages:
fs/nfs/direct.c:110: warning: implicit declaration of function nfs_free_user_pages
fs/nfs/direct.c: At top level:
fs/nfs/direct.c:127: warning: conflicting types for nfs_free_user_pages
fs/nfs/direct.c:127: error: static declaration of nfs_free_user_pages follows non-static declaration
fs/nfs/direct.c:110: error: previous implicit declaration of nfs_free_user_pages was here

Вот и называется пропатчил Trond Myklebust, чесное слово, 
уже как года 3 ошибок при компиляции ядра не наблюдал..

Я вот это не понял:

commit 245fdb596bc70bb93d5941d688916e29d6824955
Author: Jeff Mahoney <jeffm@suse.com>
Date:   Sun Feb 12 22:34:55 2006 -0800

    [PATCH] reiserfs: disable automatic enabling of reiserfs inode attributes
    
    Unfortunately, the reiserfs_attrs_cleared bit in the superblock flag can
    lie.  File systems have been observed with the bit set, yet still contain
    garbage in the stat data field, causing unpredictable results.
    
    This patch backs out the enable-by-default behavior.
    
    It eliminates the changes from: d50a5cd860ce721dbeac6a4f3c6e42abcde68cd8,
    and ef5e5414e7a83eb9b4295bbaba5464410b11e030.
    
    Signed-off-by: Jeff Mahoney <jeffm@suse.com>
    Signed-off-by: Andrew Morton <akpm@osdl.org>
    Signed-off-by: Linus Torvalds <torvalds@osdl.org>
    Signed-off-by: Chris Wright <chrisw@sous-sol.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

в каком случае и чем это может грозить, если не обновляться ?

> Я вот это не понял:

Насколько я понял, это то самое, когда загружаешься с reiserfs, созданной пару лет назад, и ловишь многочисленные "permission denied" в самых разнообразных местах.

commit 94069fb3035f4e9de4ce33f5910be0dded06677c Author: Stephen Hemminger <shemminger@osdl.org> Date: Wed Feb 22 13:52:35 2006 -0800

[PATCH] skge: fix SMP race If skge is attached to a bad cable, that goes up/down. It exposes an SMP race with the management of IRQ mask Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>

и

commit e501e04cf0b3cd2d89ebfd8ad6cd38e1a88a1a71 Author: Stephen Hemminger <shemminger@osdl.org> Date: Wed Feb 22 13:52:33 2006 -0800

[PATCH] skge: fix NAPI/irq race Fix a race in the receive NAPI, irq handling. The interrupt clear and the start need to be separated. Otherwise there is a window between the last frame received and the NAPI done level handling. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: Chris Wright <chrisw@sous-sol.org>

Хорошо что пофиксили - а то у меня сетевуха вырубалась в случайном времени (пару раз за существование 2.6.15 было) - очень некрасиво было :( Лечилось только полным restart машины ...

судя по описаниям баги довольно неприятные, но главное что их нашли и зафиксили...

в ext2 баг. Хотя незначительный, но все же... Rock stable filesystem была

Убери CONFIG_NFS_DIRECTIO и будет тебе счастье.

А почему у меня при дисковых операциях iowait ( wa in top ) отжирает весь процессор? З.Ы. Дма = он.

> А почему у меня при дисковых операциях iowait ( wa in top ) отжирает весь процессор?

А ты не думал, что оно именно wait? То есть в ядре взводится семафор, и оно уходит заниматься другой работой, когда io завершится, семафор будет спущен и программа продолжит выполняться. Это просто _методика подсчета_ поменялась.

Если у тебя iowait большой, значит у тебя дисковая система очень сильно неоптимизирована. Как минимум стоит посмотреть какой стоит scheduler (cat /sys/block/sda/queue/scheduler) и вероятно поменять его на CFQ, а вообще я подобные эффекты наблюдал когда юзеры пытаются делать селекты по огромным таблицам без соответствующих индексов в mysql, так что возможно рыть стоит именно там

У меня при этом самом "wait" начинает тормозить всё остальное. Любой ЦПУ монитор показывает 100% нагрузку.

Оптимизировать я ничего не пытался, все дефолтное. Генту 2005.1 обновлённая до последних версий полностью, ядро 2.6.15 сейчас. Просто десктоп.

cat /sys/block/sda/queue/scheduler

noop [anticipatory] deadline cfq

>У меня при этом самом "wait" начинает тормозить всё остальное. Любой ЦПУ монитор показывает 100% нагрузку.

Такая же фигня, не знаю что делать, файловая система reiserfs 3.6, при копировании систему лагает по страшному :-( шедулеры менял, не помогает, ACPI включено...

А какой чипсет? У меня нфорс2. Кстати без разницы, чтио рейзер что не рейзер. У меня рейзер 3.6 и ект3

у меня тоже nforce 2. Дохлый проц - Duron 1600. Ядро 2.6.14.2 нету проблем с iowait! может дело в том, что у меня винты hda вместо sda?

>А какой чипсет? У меня нфорс2. Кстати без разницы, чтио рейзер что не рейзер. У меня рейзер 3.6 и ект3

У меня тоже nForce2, я думал что возможно из-за рейзера :-(

>А ты не думал, что оно именно wait? То есть в ядре взводится семафор, и оно уходит заниматься другой работой, когда io завершится, семафор будет спущен и программа продолжит выполняться. Это просто _методика подсчета_ поменялась.

Я уже писал тут, что во время особо тяжких дисковых операций (циклическое копирование dvd-имиджей) система начинает просто ползать, загрузка прог замедляется раз в 20, а и без того долго запускающиеся вроде Opera не стартуют вообще никогда, пока не прибьешь копирование. С другой стороны на 2.4 (где iowait вообще не отображался) то же самое.

Кто-то советовал включить в ядре IO APIC support, но это не помогает.

Когда-то давно тут обсуждалась статейка на ксакеп.ру, там чел сравнивал скорость дисковой подсистемы ядер 2.4 и 2.6 методом компиляции ядра под нагрузкой постоянного копирования iso'шника. В итоге 2.4 справлялись за 10 минут, а 2.6 за полчаса. Хоть многие и обозвали этого чела ламерским идиотом, он написал сущую правду. Я проводил подобные тесты и 2.6 действительно сливали... до выхода 2.6.15, когда они сравнялись с 2.4.

Но тормознутый запуск прог от версии ядра не зависит вообще, поэтому я склонен винить корявый чипсет nforce2.

>Надоело трахаться - тогда может ... подрочить? Или поставить нормальную операционку (Solaris или FreeBSD ну или W2k на дырявый конец) или (если без линакса ломка крючит) ядро от например CentOS-4.2

К слову, W2k/Xp колбасит вообще неслабо под параллельным копированием двух файлов (в отличие от "ненормального" линукса).

А конфиг можно в студию?

Конфиг ядра 2.6.14.2 я хотел сказать

Блин, у меня тоже ошибка компиляции на nfs происходит :(

usbnet починили?

Вот патч, для всех тех у кого компиляция обламывается на nfs:

Index: linux-2.6.15-ck5/fs/nfs/direct.c
===================================================================
--- linux-2.6.15-ck5.orig/fs/nfs/direct.c 2006-03-02 13:06:57.000000000 +1100
+++ linux-2.6.15-ck5/fs/nfs/direct.c 2006-03-02 13:55:28.000000000 +1100
@@ -73,6 +73,8 @@ struct nfs_direct_req {
error; /* any reported error */
};

+static void
+nfs_free_user_pages(struct page **pages, int npages, int do_dirty);

/**
* nfs_get_user_pages - find and set up pages underlying user's buffer

> Блин, у меня тоже ошибка компиляции на nfs происходит :(

> usbnet починили?

Эх, ядрышко, куда ты котишься...

> Вот патч, для всех тех у кого компиляция обламывается на nfs:
Это то понятно, сам факт того что от человека приняли патч и не проверили ..... вот что стремно!

> Эх, ядрышко, куда ты котишься...

Во люди - им твердят ставь ядро из дистрибутива, а не девелоперскую хреноту версии 2.6 с kernel.org, а они как ежики, которые плакали и кололись, но продолжали жрать кактус... Стабильное ядро есть _только_ в дистрибутиве! Смотреть что у дистроклипателей: Debian 2.6.8, RHEL - 2.6.9, SuSe - 2.6.13, Gentoo - 2.6.15(ССЗБ).

> cat /sys/block/sda/queue/scheduler
> noop [anticipatory] deadline cfq

сделай 
echo "cfq" > /sys/block/sda/queue/scheduler
и так для каждого харда и посмотри, возможно полегчает. 
cfq с большими нагрузками справляется гораздо лучше. Можно еще deadline попробовать.

>сделай >echo "cfq" > /sys/block/sda/queue/scheduler >и так для каждого харда и посмотри, возможно полегчает.

У мну по дефолту стоит cfq - легче не стало...

Так при wa>0 и id=0 при сложении us, sy, ni, id, wa результат иногда должен получаться больше 100 процентов, если вы говорите, что на самом деле wa это когда проц ждёт IO, а пока ждёт, может занимается другими вещами. Но этого никогда не бывает, так куда же процессорное время уходит?

Debian 2.6.8, RHEL - 2.6.9, SuSe - 2.6.13, Gentoo - 2.6.15(ССЗБ).

И вы серьезно пологаете, что в RHEL до сих пор 2.6.9? Рассмешили. Там уже давно 2.6.15 (или около него) с дополнениями и изменениями. Просто, что бы не нарушать зависимости между rpm пакетами имя оставили старое.

Хотите я специально для вас сделаю скрин, где uname будет на полном серьезе говорить, что у меня ядро 4.23.128? Легко, достаточно отредактировать Makefile ядра и пересобрать его :)

А у меня вот такая проблема. 2.6.13.5 компилится и грузится нормально. Практически по тому же конфигу (делаю make oldconfig) собираю 2.6.14.7 и 2.6.15.5, оба ядра зависают при загрузке на строке:

hda: <здесь при успешной загрузке перечисляются разделы hda1 hda2 и т.д.>

дальше бесконечно идут строки:

бла-бла dma status=x0ff

Железо: мать Asus на nforce4, винт Seagate PATA.

Никто не сталкивался?

а кстати все эти проблемы с копированием интересны.

У меня теперь скорость копирования в пределах одного физического диска равна скорости копирования с одного физического диска на другой.

скорость копирования с одного физического диска на другой упала, но скорость копирования в пределах диска соответствует той, которая была раньше, когда скорость копирования с диска на диск была большой.

скорость копирования в пределах диска большая, не жалуюсь - 20 Мбт/с

Очевидно, что то с шиной IDE не так

>И вы серьезно пологаете, что в RHEL до сих пор 2.6.9? Рассмешили. Там уже давно 2.6.15 (или около него) с дополнениями и изменениями.

Вы что серьезно пологаете, что в RHEL "уже давно 2.6.15 (или около него) с дополнениями и изменениями." ? СМЭШНО! Загрузите src.rpm последнего (2.6.9-22.0.2) и посмотрите что там и какие патчи. Да даже и этого ненадо - найдите например там что нибудь типа "/sys/block/*/queue/scheduler" или другие сравнительно новые фичи.

Некоторым лучше сосать чем говорить.

У меня Slackware последняя, штатное ядро 2.4.31, предлагаешь мне на нем сидеть? У меня железо под 2.4 не все работает.

это стандартная фигня всей ветки 2.6
у меня помогло отключение опции ide taskfile в ядре

>у меня помогло отключение опции ide taskfile в ядре

Попробую, но думаю что не поможет винты SATA

>у меня помогло отключение опции ide taskfile в ядре

Сомневаюсь. По-моему это тут вообще никаким боком... У меня всегда было выключено во всяком случае.

Вот еще один пример того, что работа с диском сжирает весь проц:

Запускаем какое-нибудь долго стартующее приложение (OpenOffice или там Mozilla) и быстро смотрим в top'e проценты CPU отданные этому процессу. У меня это обычно от 40 до 90%.

Теперь зацикливаем копирование чего-нибудь большого и в соседней консоли повторяем вышеописанные действия.

Результат: wa - 90%, cp - 10%, а несчастному mozilla-bin жалкие 0.XX%! Будь этот самый wa тем, чем он должен быть, всё бы пускалось мгновенно. И никакая это не бага 2.6.x, на 2.4 то же самое, просто wa никак не отображается...

А где написано, что разрабы забили на эту проблему?

Блин! 2.6.15.5 - вообще все разломали похоже, на x86_64. NFS не собирается, XFS не собирается, дрова BCM5700 не собираются и т. п.

А так же jffs2, куча сказевых дров, сетевых, mm, usb... вредители какие-то.