LINUX.ORG.RU

Намеренное целочисленное переполнение в версиях двух LTS ядер ради тестирования

 ,


2

2

Несколько часов назад Greg Kroah-Hartman выпустил две новые версии LTS ядер серии 4.9.y и 4.4.y в которых y == 256, что должно привести к целочисленному переполнению и к тому, что KERNEL_VERSION(4, 9, 256) == KERNEL_VERSION(4, 10, 0). Никаких других изменений в этих ядрах нет. Сделано это ради тестирования такой нумерации и в частности LINUX_VERSION_CODE в user space (используется такими компоненитами системы, как glibc и gcc) на множестве дистрибутивов. Greg просит пересобрать всю систему вместе с этими версиями ядер и сообщить ему, если что-то перестанет работать или компилироваться. Данное тестирование расчитано, как минимум, на неделю, после которой появятся следующие версии ядер 4.9.y и 4.4.y с настоящими изменениями.

Первоисточник для Ъ:

I'm announcing the release of the 4.9.256 kernel.

This, and the 4.4.256 release are a little bit "different" than normal.

This contains only 1 patch, just the version bump from .255 to .256 which ends
up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
than normal due to the "overflow".

With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).

Nothing in the kernel build itself breaks with this change, but given that this
is a userspace visible change, and some crazy tools (like glibc and gcc) have
logic that checks the kernel version for different reasons, I wanted to do this
release as an "empty" release to ensure that everything still works properly.

So, this is a YOU MUST UPGRADE requirement of a release.  If you rely on the
4.9.y kernel, please throw this release into your test builds and rebuild the
world and let us know if anything breaks, or if all is well.

Go forth and do full system rebuilds!  Yocto and Gentoo are great for this, as
will systems that use buildroot.

I'll try to hold off on doing a "real" 4.9.y release for a 9eek to give
everyone a chance to test this out and get back to me.  The pending patches in
the 4.9.y queue are pretty serious, so I am loath to wait longer than that,
consider yourself warned...

The updated 4.9.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-s...

thanks,

greg k-h

>>> Подробности



Проверено: Shaman007 ()

Ответ на: комментарий от intelfx

Что отсталость/продвинутость компилятора измеряется не только поддержкой стандартов.

Да, архитектурно Clang/LLVM гораздо лучше GCC и является по-настоящему UNIX-Way’ным компилятором, части которого в соответствии с этой концепцией и философией активно переиспользуются. От этого компилятора легко отделить front-end парсер C/C++/ObjC/ObjC++ и использовать его для разработки IDE, положив на его плечи корректный разбор, автодополнение, и подсветку кода. Благодаря этой модульности на основе libclang можно делать высокоточные инструменты вроде статических анализаторов и утилит, форматирующих код в определённом стиле. Ну и главное – back-end в виде LLVM можно успешно переиспользовать для других языков программирования.

GCC не соответствует парадигме UNIX-Way и является монолитным. Внутри него есть, конечно, front-end и back-end части, но они сильно связаны друг с другом, а их переиспользование существенно затруднено, в том числе и по чисто идеологическим причинам и мотивам, которые связанны с его лицензионной политикой.

Однако, GCC должен развиваться и быть конкурентноспособным. Вообще создание Clang/LLVM сильно подстегнуло развитие GCC: вспомним нулевые годы и вялотекущую шизофазию «в год по чайной ложке» и сравним эту ситуацию с сегодняшней.

Конкуренция между GCC и Clang идёт на пользу всем компиляторам. Если один из них полностью проиграет, то всё скатится в совок и «стабильность», которая как известно – смерть.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

«Совок, стабильность и смерть» произошли как раз в процессе конкурирования, так что если мы берем эту аналогию как модель развития, gcc может доускоряться, и таки развалиться.

seiken ★★★★★ ()

Данное тестирование расчитано, как минимум, на неделю, после которой появятся следующие версии ядер 4.9.y и 4.4.y с настоящими изменениями.

А ну да. В которых KERNEL_VERSION(4, 9, 257) == KERNEL_VERSION(4, 10, 1)

AlexVR ★★★★★ ()
Ответ на: комментарий от mord0d

А платить за тестинг кто будет?

Вот лично ты и будешь. Разработчики сначала хотели с зарплаты скинуться, но я перевёл им на английский «лох это судьба» поэтому решили что заплатишь именно ты.

zabbal ★★★ ()
Ответ на: комментарий от EXL

GCC не соответствует парадигме UNIX-Way и является монолитным. Внутри него есть, конечно, front-end и back-end части, но они сильно связаны друг с другом, а их переиспользование существенно затруднено

затруднено тем, что между ними ещё есть middle end который их «сильно связывает» или чем?

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

anonymous ()
Ответ на: комментарий от mord0d

Что за тупая практика тестировать на юзерах?

Так сейчас так все делают.

Ты что, не замечаешь?

А этому товарищу спасибо за то, что хоть предупредил.

Kroz ★★★★★ ()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от mord0d

А мне кто платить будет?

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

Ну вот и жрите сами. ☺

Спасибо, что разрешил, это было важно.

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

Обезьяны не могут писать софт. Они вообще ничего создавать не могут. Они могут только потреблять, визжать и кидаться какашками. Использование их в качестве подопытных субъектов позволяет извлекать хоть какую-то пользу из их существования.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Обезьяны не могут писать софт. Они вообще ничего создавать не могут.

Да чот листаю иногда GitHub, и вижу только обезьяний код. Там хоть немного человеков есть?

визжать и кидаться какашками

Как разработчики ядра Linux, что ли?

Использование их в качестве подопытных субъектов позволяет извлекать хоть какую-то пользу из их существования.

Для этого есть ЛОР, тут планктона много. ☺

mord0d ★★★★ ()
Ответ на: комментарий от hummer

GCC постепенно отстаёт от clang

Ну как отстаёт - от былой скорости сборки шланга осталось лишь жалкое подобие.
Да и оптимизировать код нормально так и не научились пока.

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

devl547 ★★★★★ ()
Последнее исправление: devl547 (всего исправлений: 1)
Ответ на: комментарий от Legioner

Обезьяны не могут писать софт.

Но думают, что могут, и поэтому постоянно пишут.

Мань, проснись, вся история ойти, начиная с жабы - это история создания инструмента, который сможет освоить любая макака.

anonymous ()
Ответ на: комментарий от mord0d

Так задонать и будет хватать :) Оно конечно курируется и спонсируется, но это всё же OpenSource. С каких пор OSS тестируется на чём-то кроме пользователей если это связано с зависимостями? Если даже контора выпустила новую версию либы, а её втянули другие продукты, то контора должна их все тестировать? Да с чего бы? Мы так код вообще писать перестанем, пусть тестируют и фиксят те, у кого есть контекст. Называется «саморегулирующаяся система».

steinburzum ()
Ответ на: комментарий от devl547

Ну gcc с 11й версии начал тоже требовать С++11, так что подталкивает его шланг, да.

У шланга же кто основные разработчики - Google и Apple. Первым наверное стало не актуально (или основные движители фокус поменяли, стал good enough), вторые - С++ не приоритетный, там swift, objective-c…

anonymous ()
Ответ на: комментарий от mord0d

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

Потому, что он один не справляется? Вот он и запросил помощь тех, кому нужны LTS ядра. Тех, кому они не нужны, он помогать не просит.

saahriktu ★★★★★ ()
Ответ на: комментарий от fsb4000

Не знаешь, сколько c и c++ компоненты студии весят? В интернете нет точной инфы. Есть ли смысл пытаться ставить на раздел, где свободно 13 гб? Система x86. Можно ли поставить студию на несистемный диск и что будет, если его потом отключить?

anonymous ()
Ответ на: комментарий от anonymous

У меня уже установлена Community версия, попробовал выбрать Preview Professional, установщик показал что нужно 4.58гб: https://i.imgur.com/sYvjGwB.png

Но вообще больше будет, так как он не стал устанавливать Windows SDK, так как уже установлено у меня…

Да, на несистемный диск некоторые ставят студию, вроде норм.

Сейчас студия модульная и меньше стала весить. По идее 13 гб должно хватить. Посмотри что тебе установщик пишет…

fsb4000 ★★★★ ()
Ответ на: комментарий от EXL

Конкуренция между GCC и Clang идёт на пользу всем компиляторам. Если один из них полностью проиграет, то всё скатится в совок и «стабильность», которая как известно – смерть.

Всё так.

Проблема в том, что шланг и GCC конкурируют «в одну сторону». С точки зрения сообщества вокруг СПО, шланг — конкурент GCC. А с точки зрения корпораций, которые этот шланг пилят — конкуренции нет, т. к. у GCC слишком нерукопожатная лицензия.

intelfx ★★★★★ ()
Ответ на: комментарий от mord0d

Ну это уже откровенная ахинея, reductio ad absurdum. Вы много кода в ядре написали? Он лучше того что делают эти ребята?

Про мой опыт можете не спрашивать - мало и нормально работал. Но это даже и не важно, по-моему всё хорошо и Грег сделал всё правильно и очень предусмотрительно.

steinburzum ()
Ответ на: комментарий от anonymous

проверенные временем процы которые после взрыва ЭМИ продолжат работать

Журнал «Юный техник» перечитал? Технология защиты от ЭМИ не привязана к конкретной микросхеме, а является общей рекомендацией, начиная от непосредственной защиты корпуса радиодеталей до рекомендаций по защите периметра эксплуатируемого объекта.

splinter ★★★★★ ()
Ответ на: комментарий от intelfx

Ты теоретизируешь. Польза от конкуренции - налицо.

К примеру, gcc быстренько сделали и цветные сообщения, и удобочитанмые, и с подсказками после того, как их все заклевали. Тот же переход на с++11.

С лицензиями - палка о двух концах: тот же clion если и пилит какие плагины, так из ок раскрывает. ARM - хочешь оптимизацию нормальную, покупай. Исходников, естественно, не дадут. И это обидно также, как в случае с Эластиком: если что наконтрибьютил, то это не просто будут продавать с поддержкой, а закрывая от конечного пользователя.

anonymous ()
Ответ на: комментарий от anonymous

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

а я всё думал: нах*я они это делают? так вот оказывается кто виноват.

anonymous ()