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 ()
Последнее исправление: Wizard_ (всего исправлений: 2)
Ответ на: комментарий от vurdalak

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

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

Явись нам! Спаси наш грешных, от чтения плохо оформленных новостей про ядро!

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

А солнцеликому-то зачем писать? Тут Тролльвадсу надо.

anonymous
()

Отлично, жду linux-libre.

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

Ганс нужен, этот темный гений запилит отличную ФС, чтобы всякие брфсы-выскочки либо умерли, либо привели себя в нормальное состояние.

leg0las ★★★★★
()

детерминированно псевдослучайные - если вы не хотите, мы все равно заставим

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

Пруф или не было. То, что он физикой занялся - не в счет.

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

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

Где вас, идиотов, штампуют? Давно пора закрыть это заведение.

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

Файловый дескриптор, это-же на уровне процесса, а не файловой системы.
На уровне файловой системы можно делать что-то похожее через расширенные атрибуты (chattr) ну и обычные права доступа. Но это не вполне те самые блокировки.

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

Не дескриптор а файл, причем на уровне inode. Иначе это было бы бессмысленно.memfd_create(2):

Note that seals are per file, not per file-descriptor (nor per file-description). That means, any file-descriptor for the same underlying inode will share the same seals.

A-234 ★★★★★
()

Как я понял, эта система блокировок будет полезна СУБД, которая разными процессами держат один файл. Т.е. один процесс блокнул дескриптор, записал данные, разблокировал....

BeerSeller ★★★★
()

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

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

Для DRM-драйвера Nouveau устранены проблемы с использованием GPU Kepler

где подробности? проблем много, а сам Kepler используется много в каких картах

Поддержка чипов «Hawaii» (Radeon R9 290) добавлена в DRM-драйвер Radeon.

ура! рад за них

reprimand ★★★★★
()

В этой версии говорили сделают чтоб ядро корректно собиралось clang'ом. Но что-то упоминаний об этом не нахожу.

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

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

На практике означает ли это, что если я использую XFS в обычном популярном дистре, у меня ВНЕЗАПНО после обновления эти диски станут не доступными. После чего придется пересобирать ядро или хотя бы искать в репозитории уже собранный такой вариант.

Это маразм...

praseodim ★★★★★
()

Когда же поддержку чипов SAA716x добавят?

petyanamlt ★★★★
()

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

Ахтунг в ядрописатели вантузятнеги пробрались!

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

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

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

револьвера и одного патрона ему хватило бы с лихвой для решения этой и множества других проблем.

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

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

Паники и не должно быть даже если можно было бы блокировать файлы/директории. Я не вижу никакой проблемы реализовать автоматическую разблокировку по таймауту или отваливанию блокируещей программы. Зато это был бы первый шаг к атомарным операциям над набором файлов и подобию транзакций поверх любой фс.

d9d9 ★★★★
()

И это хорошо, уже обновился. Ждём плюшек в 3.18.

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

На практике означает ли это, что если я использую XFS в обычном популярном дистре, у меня ВНЕЗАПНО после обновления эти диски станут не доступными.

Нет, конечно. Это означает, что если на твоей экзотической платформе sector_t будет короче 64 бит, то XFS для >=3.17 откажется собираться.

Относись к этому, как к переходу на 64-битный time_t.

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

Нет, конечно. Это означает, что если на твоей экзотической платформе sector_t будет короче 64 бит, то XFS для >=3.17 откажется собираться.

А как он тогда раньше собирался и в чем тогда новость?

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

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

Где zfs изкоробки?

zfs из коробки в Linux не будет никогда. По крайней мере пока лицензию на zfs не поменяют на совместимую с GPL.

praseodim ★★★★★
()

а броадкомовский вифи уже работает на этом ядре искаропке?

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

Почему раньше не додумались сделать логи ридонли даже для рута...

Потому что файл по-сути всё равно «именованный кусок памяти», который, очевидно, всё равно придётся удалять/модифицировать/копировать и т.п. Если на этом этапе разложить грабли (как вот эти идиоты в ядре), это принесёт гемороя больше, чем собственно защитит сам файл.

Если логи так важны, делается их защищённый бэкап + вешается ЭЦП. «Запечатывать» файл для этого вовсе не обязательно.

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

вот эти идиоты в ядре

Если логи так важны, делается их защищённый бэкап + вешается ЭЦП. «Запечатывать» файл для этого вовсе не обязательно.

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

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

В этой версии говорили сделают чтоб ядро корректно собиралось clang'ом. Но что-то упоминаний об этом не нахожу.

А для этого обязательно ядро надо патчить? Может это шланг надо?

ados ★★★★★
()

Теперь по умолчанию включена технология Render Nodes, предназначенная для разделения монолитных устройств /dev/dri/card{num} на две категории. Первая категория Rendering Nodes (/dev/dri/renderD{num}) отвечает за аппаратное ускорение рендеринга и обсчет вычислительных заданий GPGPU. Вторая ModeSetting Nodes (/dev/dri/modeset{num}) обеспечивает переключение видеорежимов и управление экраном. Это позволяет более гибко управлять правами доступа и предоставляет возможность выполнения вычислений на GPU или рендеринга без вывода на экран и без привязки к активному дисплею.

Мне это было нужно в 2008ом, на моей первой работе

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

Еще может быть в качестве предосторожности. Например СУБД на базе SSTable после записи могут запечатать файл чтобы случайно его никто не начал менять.

И еще наклевывается гарантировано не разрастающийся Copy-On-Write, который для запечатываемых файлов может работать очень экономно

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

А как он тогда раньше собирался и в чем тогда новость?

Я патчи не смотрел, но возможно, что добавили функциональность, которая не работает при коротком sector_t. Раньше её не было или были костыли. Новость в том, что реализация XFS в новых ядрах требует sector_t не короче 64 бит.

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

А что, в ядре никогда не дропают поддержку чего-нибудь? Старых железок, старых платформ. Даже вот в этой новости есть:

Полностью прекращена поддержка архитектур POWER3 и rs64

Без 64-битного sector_t ты всё равно не сможешь задействовать новые фичи, сиди на lts. Sector_t не требует от системы быть 64-битной или чего-то подобного.

А вообще, вот:

#ifdef CONFIG_LBDAF
typedef u64 sector_t;
typedef u64 blkcnt_t;
#else
typedef unsigned long sector_t;
typedef unsigned long blkcnt_t;
#endif

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

таки есть, но немного:

    fix for the infamous deadlock [1]
    fixed longstanding bug in qgroups accounting after snapshot deletion [2]
    updated (less inaccurate) df numbers [3]
    speedup for rename and truncate, less strict flushes [4]
    updated and fixes to the seeding feature 

https://btrfs.wiki.kernel.org/index.php/Main_Page#News

anonymous
()

Ура! Добавили поддержку Asus Xonar Essence STX II

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

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

Пруф?

Теперь у Nvidia нету препятствий для реализации Optimus!

Да щаз.

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

Где чудо правки для радеонодров?

нужно ещё чуть-чуть подождать

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

расходимся

/usr/src/linux-3.17.0/drivers/dma-buf/dma-buf.c:
dma-buf.c:344: EXPORT_SYMBOL_GPL(dma_buf_export_named);
dma-buf.c:369: EXPORT_SYMBOL_GPL(dma_buf_fd);
dma-buf.c:395: EXPORT_SYMBOL_GPL(dma_buf_get);
dma-buf.c:410: EXPORT_SYMBOL_GPL(dma_buf_put);
dma-buf.c:454: EXPORT_SYMBOL_GPL(dma_buf_attach);
dma-buf.c:476: EXPORT_SYMBOL_GPL(dma_buf_detach);
dma-buf.c:504: EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
dma-buf.c:527: EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
dma-buf.c:555: EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
dma-buf.c:577: EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
dma-buf.c:594: EXPORT_SYMBOL_GPL(dma_buf_kmap_atomic);
dma-buf.c:612: EXPORT_SYMBOL_GPL(dma_buf_kunmap_atomic);
dma-buf.c:629: EXPORT_SYMBOL_GPL(dma_buf_kmap);
dma-buf.c:647: EXPORT_SYMBOL_GPL(dma_buf_kunmap);
dma-buf.c:700: EXPORT_SYMBOL_GPL(dma_buf_mmap);
dma-buf.c:747: EXPORT_SYMBOL_GPL(dma_buf_vmap);
dma-buf.c:771: EXPORT_SYMBOL_GPL(dma_buf_vunmap);

anonymous
()

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

Я джва года ждал!

LinuxPlay
()

Релиз ядра Linux 3.17

Идем в верном направлении.

garik_keghen ★★★★★
()

Ёпрст, когда успевают...

Hertz ★★★★★
()

Включена поддержка техники маппинга памяти memfd, суть которого заключается в идентификации области памяти через файловый дескриптор, который может передаваться между процессами. Это позволяет после выделения памяти обращаться к ней по файловому дескриптору, то есть фактически как с файлом.

Не понял. Чем это отличается от POSIX Shared Memory? И почему POSIX Shared Memory не хватает?

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