LINUX.ORG.RU

Ядро Linux 5.14

 ,

Ядро Linux 5.14

0

1

После двух месяцев разработки Линус Торвальдс представил выпуск ядра Linux 5.14. Среди наиболее заметных изменений: новые системные вызовы quotactl_fd() и memfd_secret(), удаление драйверов ide и raw, новый контроллер приоритетов ввода/вывода для cgroup, режим планирования задач SCHED_CORE, инфраструктура для создания загрузчиков верифицированных BPF-программ.

В новую версию принято 15883 исправлений от 2002 разработчиков, размер патча - 69 МБ (изменения затронули 12580 файлов, добавлено 861501 строк кода, удалено 321654 строк). Около 47% всех представленных в 5.14 изменений связаны с драйверами устройств, примерно 14% изменений имеют отношение к обновлению кода, специфичного для аппаратных архитектур, 13% связано с сетевым стеком, 3% - с файловыми системами и 3% c внутренними подсистемами ядра.

Основные новшества:

  • дисковая подсистема, ввод/вывод и файловые системы:
    • для cgroup реализован новый контроллер приоритезации ввода/вывода - rq-qos, который может управлять приоритетом обработки запросов к блочным устройствам, генерируемых участниками каждой cgroup. Поддержка нового контроллера приоритета добавлена в планировщик ввода/вывода mq-deadline;
    • в файловой системе ext4 реализована новая ioctl-команда EXT4_IOC_CHECKPOINT, принудительно сбрасывающая на диск все ожидающие транзакции из журнала и связанные с ними буферы, а также перезаписывающая используемую журналом область в хранилище. Изменение подготовлено в рамках инициативы по предотвращению утечек информации из файловых систем;
    • в Btrfs внесены оптимизации производительности: за счёт исключения лишнего журналирования расширенных атрибутов в процессе выполнения fsync производительность интенсивных операций с расширенными атрибутами увеличилась до 17%. Кроме того, при выполнении операций усечения, не затрагивающих экстенты, отключено выполнение полной синхронизации, что сократило время выполнения операции на 12%. В sysfs добавлена настройка для ограничения пропускной способности ввода/вывода при проверке ФС. Добавлены ioctl-вызовы для отмены операций изменения размера и удаления устройства;
    • в XFS переработана реализация буферного кэша, который переведён на выделение страниц памяти в пакетном режиме. Повышена эффективность работы кэша;
    • в F2FS добавлена опция для работы в режиме только для чтения и реализован режим кэширования сжатых блоков (compress_cache) для повышения производительности случайного чтения. Реализована поддержка сжатия файлов, отражённых в память при помощи операции mmap(). Для выборочного отключения сжатия файлов по маске предложена новая опция монтирования nocompress;
    • в драйвере exFAT проведена работа по улучшению совместимости с хранилищами некоторых цифровых камер;
    • добавлен системный вызов quotactl_fd(), который позволяет управлять квотами не через файл специального устройства, а через указание файлового дескриптора, связанного с файловой системой для которой применяется квота;
    • из ядра удалены старые драйверы для блочных устройств с интерфейсом IDE, на смену которым уже давно пришла подсистема libata. Поддержка старых устройств сохранена в полном объёме, изменения касаются только возможности использования старых драйверов, при использовании которых накопители именовались /dev/hd*, а не /dev/sd*;
    • из ядра удалён драйвер «raw», предоставляющий небуферизированный доступ к блочными устройствам через интерфейс /dev/raw. Указанная функциональность давно реализуется в приложениях при помощи флага O_DIRECT;
  • память и системные службы:
    • в планировщике задач реализован новый режим планирования SCHED_CORE, позволяющий управлять тем, какие процессы могут совместно выполнятся на одном ядре CPU. Каждому процессу может быть назначен cookie-индентификатор, определяющий область доверия между процессами (например, принадлежность одному пользователю или контейнеру). При организации выполнения кода планировщик может обеспечить совместное использование одного ядра CPU только для процессов, связанных с одним владельцем, что может использоваться для блокирования некоторых атак класса Spectre за счёт предотвращения выполнения в одном потоке SMT (Hyper Threading) заслуживающих и не заслуживающих доверия задач;
    • для механизма cgroup реализована поддержка операции kill, позволяющей разом завершить все привязанные к группе процессы (отправить SIGKILL), через запись «1» в виртуальный файл cgroup.kill;
    • расширены возможности, связанные с реагированием на выявление расщеплённых блокировок («split lock»), возникающих при доступе к невыровненным данным в памяти из-за того, что при выполнении атомарной инструкции данные пересекают две линии кеша CPU. Подобные блокировки приводят к значительному падению производительности, поэтому ранее яром предоставлялась возможность принудительного завершения приложения, вызвавшего блокировку. В новом выпуске добавлен параметр командной строки ядра «split_lock_detect=ratelimit:N», позволяющий определить общесистемный лимит интенсивности операций блокировки в секунду, после превышения которого любой процесс, ставший источником расщеплённой блокировки, вместо завершения будет принудительно остановлен на 20 мс;
    • в cgroup-контроллере пропускной способности CFS (CFS bandwidth controller), определяющим как много процессорного времени можно выделить каждой cgroup, реализована возможность определения лимитов, ограниченных заданным временем действия, что позволяет лучше регулировать нагрузки, чувствительные к задержкам. Например, установка значения cpu.cfs_quota_us в 50000 и cpu.cfs_period_us в 100000 даст возможность группе процессов каждые 100ms тратить 50ms времени CPU;
    • добавлена начальная инфраструктура для создания загрузчиков BPF-программ, которая в дальнейшем позволит разрешить загрузку только BPF-программ, подписанных заслуживающим доверия цифровым ключом;
    • добавлена новая futex-операция FUTEX_LOCK_PI2, использующая монотонный таймер для расчёта таймаута, который учитывает время проведённое системой в спящем режиме;
    • для архитектуры RISC-V реализована поддержка больших страниц памяти (Transparent Huge-Pages) и возможность применения механизма KFENCE для выявления ошибок при работе с памятью;
    • в системный вызов madvise(), предоставляющий средства для оптимизации управления памятью процесса, добавлены флаги MADV_POPULATE_READ и MADV_POPULATE_WRITE для генерации «page fault» во всех страницах памяти, отражённых для операций чтения или записи, без выполнения фактического чтения или записи (prefault). Применение флагов может быть полезным для снижения задержек в процессе работы программы, благодаря упреждающему выполнению обработчика «page fault» разом для всех невыделенных страниц, не дожидаясь фактического обращения к ним;
    • в системе unit-тестирования kunit добавлена поддержка запуска тестов в окружении QEMU;
    • добавлены новые трассировщики: «osnoise» для отслеживания задержек в приложениях, вызванных обработкой прерываний, и «timerlat» для вывода детальной информации о задержках при пробуждениях по сигналу таймера;
  • виртуализация и безопасность:
    • добавлен системный вызов memfd_secret(), позволяющий создать приватную область памяти в изолированном пространстве адресов, видимую только процессу-владельцу, неотражаемую в другие процессы и напрямую недоступную ядру;
    • в системе фильтрации системных вызовов seccomp при выносе обработчиков блокировки в пространство пользователя предоставлена возможность использования одной атомарной операции для создания файлового дескриптора для изолируемой задачи и его возвращения при обработке системного вызова. Предложенная операция решает проблему с прерыванием обработчика в пространстве пользователя при поступлении сигнала;
    • добавлен новый механизм для управления ограничением ресурсов в пространстве имён идентификаторов пользователей, который привязывает отдельные счётчики rlimit к пользователю в «user namespace». Изменение решает проблему с применением общих счётчиков ресурсов при запуске одним пользователем процессов в разных контейнерах;
    • в гипервизор KVM для систем ARM64 добавлена возможность использования в гостевых системах расширения MTE (MemTag, Memory Tagging Extension), позволяющего привязать теги к каждой операции выделения памяти и организовать проверку корректности использования указателей для блокирования эксплуатации уязвимостей, вызванных обращением к уже освобождённым блокам памяти, переполнениями буфера, обращениями до инициализации и использованием вне текущего контекста;
    • предоставляемые платформой ARM64 средства для аутентификации указателей (Pointer Authentication) теперь могут быть отдельно настроены для ядра и пространства пользователя. Технология позволяет использовать специализированные инструкции ARM64 для проверки адресов возврата при помощи цифровых подписей, которые хранятся в неиспользуемых верхних битах самого указателя;
    • в User-mode Linux добавлена поддержка использования драйверов к PCI-устройствам с виртуальной шиной PCI, реализуемой драйвером PCI-over-virtio;
    • для систем x86 добавлена поддержка паравиртуализированного устройства virtio-iommu, позволяющего отправлять IOMMU-запросы, такие как ATTACH, DETACH, MAP и UNMAP, поверх транспорта virtio без эмуляции таблиц страниц памяти;
    • для CPU Intel, начиная с семейства Skylake и заканчивая Coffee Lake, по умолчанию отключено использование расширений Intel TSX (Transactional Synchronization Extensions), предоставляющих средства для повышения производительности многопоточных приложений за счёт динамического исключения лишних операций синхронизации. Расширения отключены из-за возможности совершения атак Zombieload, манипулирующих утечкой сведений по сторонним каналам, возникающей при работе механизма асинхронного прерывания операций (TAA, TSX Asynchronous Abort);
  • сетевая подсистема:
    • продолжена интеграция в ядро MPTCP (MultiPath TCP), расширения протокола TCP для организации работы TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. В новом выпуске добавлен механизм для задания собственных политик хэширования трафика для IPv4 и IPv6 (multipath hash policy), дающих возможность из пространства пользователя определять, какие из полей в пакетах, в том числе инкапсулированных, будут использованы при вычислении хэша, определяющего выбор пути для пакета;
    • в виртуальный транспорт virtio добавлена поддержка сокетов SOCK_SEQPACKET (упорядоченная и надёжная передача датаграмм);
    • расширены возможности механизма сокетов SO_REUSEPORT, который позволяет сразу нескольким слушающим сокетам подключиться к одному порту для приёма соединений с распределением поступающих запросов одновременно по всем подключенным через SO_REUSEPORT сокетам, что упрощает создание многопоточных серверных приложений. В новой версии добавлены средства для передачи управления другому сокету в случае сбоя при обработки запроса изначально выбранным сокетом (решает проблему с потерей отдельных соединений при перезапуске сервисов);
  • оборудование:
    • в драйвере amdgpu реализована поддержка новых серий GPU AMD Radeon RX 6000, развиваемых под кодовыми именами «Beige Goby» (Navi 24) и «Yellow Carp», а также улучшена поддержка GPU Aldebaran (gfx90a) и APU Van Gogh. Добавлена возможность одновременной работы с несколькими панелями eDP. Для APU Renoir реализована поддержка работы с шифрованными буферами в видеопамяти (TMZ, Trusted Memory Zone). Добавлена поддержка горячего извлечения графических карт (hot-unplug). Для GPU Radeon RX 6000 (Navi 2x) и старых GPU AMD включена по умолчанию поддержка механизма энергосбережения ASPM (Active State Power Management), который ранее был активирован только для GPU Navi 1x, Vega и Polaris;
    • для чипов AMD добавлена поддержка разделяемой виртуальной памяти (SVM, shared virtual memory) на базе подсистемы HMM (Heterogeneous memory management), позволяющей использовать устройства с собственными блоками управления памятью (MMU, memory management unit), которые могут получать доступ к основной памяти. В том числе при помощи HMM можно организовать совместное адресное пространство между GPU и CPU, в котором GPU может получить доступ к основной памяти процесса;
    • добавлена начальная поддержка технологии AMD Smart Shift, динамически меняющей параметры энергопотребления CPU и GPU на ноутбуках с чипсетом и видеокартой AMD для форсирования производительности при играх, редактировании видео и 3D-рендеринге;
    • в драйвере i915 для видеокарт Intel включена поддержка чипов Intel Alderlake P;
    • добавлен драйвер drm/hyperv для виртуального графического адаптера Hyper-V;
    • добавлен графический драйвер simpledrm, использующий для вывода фреймбуфер EFI-GOP или VESA, предоставляемый UEFI-прошивкой или BIOS. Основным назначением драйвера является предоставление возможности графического вывода на начальных стадиях загрузки, до того как станет возможным использование полноценного DRM-драйвера. Драйвер также может использоваться как временное решение для оборудования, для которого пока отсутствуют родные DRM-драйверы;
    • добавлена поддержка компьютера-моноблока Raspberry Pi 400;
    • добавлен драйвер dell-wmi-privacy для поддержки поставляемых в ноутбуках Dell аппаратных выключателей камеры и микрофона;
    • для ноутбуков Lenovo добавлен WMI-интерфейс для изменения параметров BIOS через sysfs /sys/class/firmware-attributes/;
    • расширена поддержка устройств с интерфейсом USB4;
    • добавлена поддержка звуковых карт и кодеков AmLogic SM1 TOACODEC, Intel AlderLake-M, NXP i.MX8, NXP TFA1, TDF9897, Rockchip RK817, Qualcomm Quinary MI2 и Texas Instruments TAS2505. Улучшена поддержка звука на ноутбуках HP и ASUS. Добавлены патчи для снижения задержек перед началом воспроизведения звука на устройствах с интерфейсом USB.

Источник – opennet.ru.

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



Проверено: hobbit ()
Последнее исправление: xaizek (всего исправлений: 3)

удаление драйверов ide

Непонял?! У меня система на IDE и бекапы на одном шлейфе два диска, а хомяк на SATA. Это чё я обновлюсь у меня система не запустится? Это $#!@%$#!!!&^5!!!!! Вот гадость до подложили! Спасибо за дерьмовый релиз. Кому оно мешало?

Аппаратная поддержка IDE останется доступной в ядре Linux через уровень libata

Слава те хоспади. Всё продолжит работать.

LINUX-ORG-RU ★★★★★
()
Последнее исправление: LINUX-ORG-RU (всего исправлений: 4)

Только решил попробовать как живут в Винде (ребёнок приехал).
Жду пока обновы за полгода прилетят, дайка в лор загляну, а тут это.

s-warus ★★
()
Ответ на: комментарий от LINUX-ORG-RU

Работа с ide, было сильным местом linux, при переходе на sata, выигрыша в производительности не было, запись-чтение происходило когда читаемые записываемые сектора находились рядом, не полагаясь на контроллер hdd.
В отличии от windows, где разница была колоссальной.
Понятно, что поддерживать такую кучу кода сложно, наверно упростили до тупого чтения-записи блоков. (искренне надеюсь что это не так)

s-warus ★★
()
Последнее исправление: s-warus (всего исправлений: 3)
Ответ на: комментарий от Artamudo

И на то есть причины... Либо linux купят мелкомягкие (так как у них уже есть свой linux и уверен они на этом не остановятся), либо Линус и компания будут переписывать брак на rust (уже об этом кто то заикался в толксах)

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

У ЛОРа проблемы. При подтверждении новости пришлось выбирать между копипастой с опеннета и чем-то очень невнятным.

Я выбрал копипасту, но вообще с этим надо что-то делать. По уму хорошо написанная новость про ядро Linux должна в первую очередь появляться на сайте про линукс.

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

новость про ядро Linux должна в первую очередь появляться на сайте про линукс.

... а потом переведена на русский в гугл переводчике и почищена

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

linux купят мелкомягкие

и вместо linux будет какой-нибудь Julix. Oracle попытался огородить MySQL, теперь вместо MySQL — MariaDB.

Тут, скорее, вопрос, смогут ли мелкомягкие купить лично Линуса. И даже если смогут и если захотят (что тоже ещё не так очевидно, кстати) — да, для свободной системы, ранее называвшейся линуксом, это будет определённый ущерб, но скорее всего, она переживёт и это.

либо будут переписывать брак на rust

Ты для начала напиши, что понимаешь под браком. Не теоретизирования «си небезопасный устаревший язык», а указание, что именно сейчас в ядре не так. Причём настолько не так, что надо тащить в ядро новый ЯП.

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

Либо linux купят мелкомягкие (так как у них уже есть свой linux и уверен они на этом не остановятся)

С такой логикой Linux уже давно принадлежит гуглу, фейсбуку и редхату.

либо Линус и компания будут переписывать брак на rust

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

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

Что за бред? Как линукс(и я не про товарный знак) вообще можно купить?

либо Линус и компания будут переписывать брак на rust

И что с того? Это резко сломает всё ядро?

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

А на вопросы ответите? Многие делают свои дистрибутивы, это вообще не означает, что кто-то собирается «покупать линукс».

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

И что с того? Это резко сломает всё ядро?

Это ничего не сломает, просто они наконец возьмутся и будут зализывать «дырки» (как они сказали «ядро слишком дырявое, его нужно переписать» )

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

ЭТО я читал. Это мнение инженера из гугла. Человек в теме, да, но пока это его частное мнение.

просто они наконец возьмутся и будут зализывать «дырки»

Они их и сейчас зализывают.

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

Другими словами… Да, речь про реальные проблемы, но ты про них говоришь как про какое-то откровение. И Кис Кук тоже, кстати. У меня вот есть подозрение, что в других популярных ОС проблем ничуть не меньше. Только их не покажут ни тебе, ни мне, ни (что характерно) Кису Куку.

Don’t panic, короче.

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

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

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

Да это чушь, аналитика одного человека. Я сейчас напишу статью «давайте перепишем ядро на РНР», вы и это будете аргументом приводить?

fernandos ★★★
()
Ответ на: комментарий от Dumppper001
  1. Продемонстрируйте примеры этого «слишком громоздкого кода».
  2. Когда это стало решающим фактором?
  3. Как это влияет на «поворотливость языка»?
fernandos ★★★
()

Ну и партянка на главной.Поставил.Отвалился звук. Какие то ошибки при загрузке. Релиз-жесть.

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

Вы высказали своё мнение публично и у вас попросили объяснить это мнение, аргументов вы не приводите. Вам не кажется, что это несколько неверно?

fernandos ★★★
()
Ответ на: комментарий от LINUX-ORG-RU

Диски только будут обзываться не hd*, а sd* . В остальном без различий. Хотя возможно какие-нибудь замшелости с захардкоженным неймингом таки сломаются. Да и пофиг на них.

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

С такой логикой Linux уже давно принадлежит гуглу, фейсбуку и редхату.

Так и есть.
Развитие Linux уже давно принадлежит гуглу, фейсбуку и редхату.

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

Ну, если по тезисам:

  • больше автоматизированного тестирования - согласен
  • придумать «более лучший» способ коммуникации, контроля и принятия решений чем срач в мейл-листах - согласен (тут по-моему даже Линус согласен)
  • rust для драйверов - спорно, но скорей за (Линус, как я понял, тоже не против, но хочет не теоретизирования, а практических результатов)
  • перписать ядро на rust - против. Во-первых, переписывалка треснет. Во-вторых, при наличии пункта 1 (мощного автотестирования) профит сомнителен. В-третьих, профит в виде расширения коммьюнити - крайне сомнителен.
SkyMaverick ★★★★★
()
Ответ на: комментарий от Artamudo

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

Не нужно этого делать.
Не должно быть в ядре две CRT

Двойная бухгалтерия
anonymous
()
Ответ на: комментарий от Dumppper001

Прочитай это и все поймешь

ИМХО Rust лишь местами решает какие-то проблемы, а в целом - нет …

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

Так, баги будут чинить, это плохо для ядра?

Кто его знает, но свое «одеяло» начнут на Linux натягивать

Со всеми вытекающими /которые радостными не будут/ ...

Это же MICROSFOT, …

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

т.е. если у мну

#libata xxxxxx 3 pata_amd,pata_cs5536,ata_generic

  • то можно спать спокойно?
mumpster ★★★★★
()
Последнее исправление: mumpster (всего исправлений: 1)
Ответ на: комментарий от fernandos

дыа и разместить это на панораме! или тут - 1 апреля

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

Шутка

Канибалы зачем откармливают пленников /ну вы поняли о чем речь/ …?

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

раст … так и останется в нише

мусорного бака

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

Это попытка сделать винду удобной для разработки на большинстве ЯП

Может быть и так.
Кому то нравится, кому то нет.
У Microsoft быстро все deprecated переходит …
Это бизнес, а бизнес заботится лишь о чем?

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

Это бизнес, а бизнес заботится лишь о чем?

А вы думаете чего М$ линукс развивает? У них сервера, им он нужен живым.

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

А вы думаете чего М$ линукс развивает? У них сервера, им он нужен живым.

Безусловно, и понятно почему …

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