LINUX.ORG.RU

Релиз ядра Linux 3.17

 


1

6

Состоялся релиз ядра Linux 3.17, среди наиболее важных улучшений и изменений:

  • Включена поддержка техники маппинга памяти memfd, суть которого заключается в идентификации области памяти через файловый дескриптор, который может передаваться между процессами. Это позволяет после выделения памяти обращаться к ней по файловому дескриптору, то есть фактически как с файлом.
  • Добавлена техника запечатывания файла (file sealing), позволяющая ограничить операции, которые могут выполняться над файлом. Например можно запретить на уровне файлового дескриптора изменение содержимого файла.
  • Теперь по умолчанию включена технология Render Nodes, предназначенная для разделения монолитных устройств /dev/dri/card{num} на две категории. Первая категория Rendering Nodes (/dev/dri/renderD{num}) отвечает за аппаратное ускорение рендеринга и обсчет вычислительных заданий GPGPU. Вторая ModeSetting Nodes (/dev/dri/modeset{num}) обеспечивает переключение видеорежимов и управление экраном. Это позволяет более гибко управлять правами доступа и предоставляет возможность выполнения вычислений на GPU или рендеринга без вывода на экран и без привязки к активному дисплею.
  • Представлена реализация API DMA-BUF, позволяющего организовать совместное использования буферов драйверами и различными подсистемами, а также синхронизировать работу устройств (cross-device synchronization). Теперь она доступна для всех модулей ядра.
  • Для утилиты perf добавлена возможность трассировки обращений к невыделенным страницам памяти (page-fault) и генерации связанной с такими обращениями статистики.
  • При использовании файловой системы XFS теперь необходима сборка ядра с 64-разрядным числом секторов.
  • Добавлена начальная поддержка Multiqueue SCSI, рассчитанного на организацию многопоточного доступа к данным на многоядерных системах и позволяющего эффективно использовать возможности современных SSD-накопителей.
  • Добавлен системный вызов kexec_file_load(), позволяющий выполнить проверку по цифровой подписи для нового ядра, перед его запуском с использованием механизма kexec. Ранее функцию загрузки нового ядра из уже запущенного ядра Linux (kexec) приходилось отключать при использовании UEFI Secure Boot, так как невозможно было гарантировать сохранение цепочки доверия.
  • Для криптографической подсистемы добавлена поддержка детерминированного генератора псевдослучайных чисел, соответствующего спецификации NIST SP800-90A.
  • В подсистему LSM (linux security module) добавлен новый hook kernel_fw_from_file(), который можно использовать для проверки целостности бинарных прошивок перед их загрузкой ядром.
  • Полностью прекращена поддержка архитектур POWER3 и rs64;
  • Также прекращена поддержка систем Samsung S5P6440, S5P6450 и S5PC100.
  • В код для архитектуры ARM64 добавлена поддержка четырёхуровневых таблиц страниц памяти, что позволило значительно расширить размер адресуемой виртуальной памяти.
  • Гипервизор KVM адаптирован для big-endian ARM-систем.
  • Для DRM-драйвера Nouveau устранены проблемы с использованием GPU Kepler, добавлена поддержка режима Zero Bandwidth Clear для GPU Fermi, Kepler и Maxwell.
  • Поддержка чипов «Hawaii» (Radeon R9 290) добавлена в DRM-драйвер Radeon.
  • Проведена подготовка к поддержке DRM-драйвером Intel Atom SoC Cherry Trail, добавлена поддержка Universal plane.

>>> Подробности (на английском языке)

★★★★★

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

Добавлена техника запечатывания файла (file sealing), позволяющая ограничить операции, которые могут выполняться над файлом. Например можно запретить на уровне файлового дескриптора изменение содержимого файла

Прискорбно

KennyMinigun ★★★★★ ()

«А кто, скажем, крайний в цари? Никого?»

Не могу сказать, что потолок теперь кипятком облит, но порадовался продолжению развития.

Pronin ★★★★ ()

а как же «12 изменений от более 1300 разработчиков»?

etwrq ★★★ ()

отлично, ждал, жду ебилд.

vim ()

Также прекращена поддержка систем Samsung S5P6440, S5P6450 и S5PC100;

А за что их исключили?

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

Также прекращена поддержка систем Samsung S5P6440, S5P6450 и S5PC100;

А за что их исключили?

«Не нужно».

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

За аморалку. :-) Надоели они Самсунгу просто.

alt-x ★★★★★ ()

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

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

Почему прискорбно? Хороший метод, чтобы запечатать, например, лог, чтобы его никто не мог изменить.

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

а что неправильного в возможности блокировать файл?

teod0r ★★★★★ ()

ЮПредставлена реализация API DMA-BUF, позволяющего организовать совместное использования буферов драйверами и различными подсистемами, а также синхронизировать работу устройств (cross-device synchronization). Теперь она доступна для всех модулей ядра;

Главное из этого - убрали EXPORT_SYMBOL_GPL.

Теперь у Nvidia нету препятствий для реализации Optimus! Не прошло и...лет - ещё пару лет и будет счастье.

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

Как говорится «не unix-way». Моя пятая точка уже предвидит зависшие программы и неудаляемые (и не перемещаемые!) файлы (из-за чего эти программы перезапустить и нельзя). Вместе с файлом должна блочиться вся иерархия директорий, так как имя файла — это полный путь к нему.

Legioner

KennyMinigun ★★★★★ ()
Последнее исправление: KennyMinigun (всего исправлений: 1)

Не буду врать, но мне кажется у меня ssd стал чуть лучше рабоать. Хотя возможно и самовнушение

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

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

KennyMinigun ★★★★★ ()

Например можно запретить на уровне файлового дескриптора изменение содержимого файла.

chmod a-w file

?

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

Файловый дескриптор ≠ путь к файлу.

Удаление файла — вообще операция над директорией, а не файлом.

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

Файловый дескриптор ≠ путь к файлу.

А, тогда паника отменяется. Что-то я сей факт проигнорировал. Наверное планировалось запретить дочерним процессам, унаследовавшим дескриптор, изменять файл. Надо мне почитать оригинальный ченжлог

KennyMinigun ★★★★★ ()
Последнее исправление: KennyMinigun (всего исправлений: 1)

А как собрать с поддержкой Multiqueue SCSI?

Я не вижу в ядре scsi-mq, более того, не вижу use_blk_mq

vim ()

Когда в ubuntu ждать?

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

это параметр ядра. в грубе ака загрузчике его надо прописать

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

Legioner, teod0r, TOXA, iamweasel, afterlanding, PolarFox

Паника отменяется. Там вообще речь о блокировках, накладываемых на файловый дескриптор разделяемой памяти. Т.е. эффект запечатывания будет действовать только на процессы, которые поделились между собой shmem дескриптором (man shm_open). Эти самые файлы разделяемой памяти находятся в «shared memory filesystem» (она же /dev/shm) и их спокойно можно удалить другим процессом (напр. rm) при наличии необходимых разрешений.

Пруфлинки:
http://lwn.net/Articles/593918/
http://man7.org/tlpi/api_changes/#Linux-3.17

KennyMinigun ★★★★★ ()
Последнее исправление: KennyMinigun (всего исправлений: 2)

Rendering Nodes и ModeSetting Nodes я так понимаю решат вопрос с оптимусом?

Еще и «Представлена реализация API DMA-BUF»...

leg0las ★★★★★ ()
Последнее исправление: leg0las (всего исправлений: 1)

При использовании файловой системы XFS теперь необходима сборка ядра с 64-разрядным числом секторов.

Тут ещё не спросили, но я отвечу:

xfs: require 64-bit sector_t

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

Хороший метод, чтобы запечатать, например, лог, чтобы его никто не мог изменить.

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

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

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

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

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

TOXA ★★ ()

Поздравляю всех армоводов. Похоже это первый релиз который действительно почти (т.е. с минимум патчей) заводится на большинстве популярных платформ. Ну, там, всякие cubie, odroid, raspberry, etc.

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

функциональность блокировки файлов

блокируется не файл, а дескриптор

MyTrooName ★★★★★ ()

Представлена реализация API DMA-BUF, позволяющего организовать совместное использования буферов драйверами и различными подсистемами, а также синхронизировать работу устройств (cross-device synchronization). Теперь она доступна для всех модулей ядра.


Ждём работающий Optimus!

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

а само это приложение свой лог очищать не умеет

в том и суть, чтобы умело и можно было в любой момент сказать ему очистить лог или по расписанию

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

спасибо, уже понял, что фигню сморозил...

TOXA ★★ ()

И ни одного изменения в btrfs, плак-плак...

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

пока btrfs не станет дефолтом в дебиан, «btrfs? что это?»

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

Пока не будет 9000 улучшений в новом ядре, он дефолтом и не станет :)

vurdalak ★★★★★ ()

Нечитабельная простыня. К тому же, и на главной простыня...
Где же ты, постфактум :(

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

Пока не будет 9000 улучшений в новом ядре, он дефолтом и не станет :)

это дебиан. тут все наоборот

MyTrooName ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.