Nous vous avons entendu. Les dépêches noyaux me manquent aussi. Et entre Google qui veut les attraper tous, sudo qui n’est plus sudo sûr que ça, des pays qui sortent d’Internet, les chats qu’on veut surveiller parce qu’ils ne miaulent pas droit et le rythme de travail pour bien vivre, il est temps de revenir aux fondamentaux.
Alors sans plus attendre, quoi de neuf dans la 6.17 ? D’après Linus Torvalds lui-même, It's not exciting — ce n’est pas intéressant. Ce qui, pour lui, est un gage de qualité. Le noyau Linux 6.17 a été officiellement publié le 28 septembre, après la RC7.
Points marquants de la version
- Des corrections de sécurité et de stabilité dans la pile Bluetooth (beaucoup de bugs de type use-after-free).
- Des corrections pour les pilotes GPU et réseau (beaucoup de petites corrections).
- Prise en charge de patch à la volée (live patching) sur ARM 64 bits.
- Meilleur contrôle sur les atténuations de Spectre/x86.
- Suppression officielle de la gestion des architectures monoprocesseur, (nous y reviendrons).
- Introduction de nouveaux syscalls
file_getattr()etfile_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur. - Gestion du protocole
DualPI2pour la gestion de congestion TCP.
Sommaire
- Architecture
- Systèmes de fichiers et stockage
- Réseau et connectivité
- Virtualisation
- Sécurité et cryptographie
- Changements internes et outils
- Le bilan en chiffres
- Appel à volontaires
Architecture
Résumé
- Intégration et mise à jour de la prise en charge de nombreux SoC ARM, Intel, AMD et RISC-V, dont :
- Mediatek MT6572 (Disponible sur l'Orange Pi IoT3G), Exynos2200, NVIDIA Tegra264, BeagleBone Green Eco et OrangePi 4A sur ARM.
- Nouvelles cartes STM32, Imx6, Radxa Rock 5T, FriendlyElec NanoPi M5, et Raspberry Pi RP1 PCI device.
- Ajout de nouveaux contrôleurs mémoire, avec prise en charge étendue de divers matériels industriels.
- Pilotes GPU : beaucoup de patchs pour amdgpu, i915/xe (options de debug et prise en charge de nouveaux formats colorimétrique).
- Les cartes Realtek 8851BU/8852BU sont désormais prises en compte sur le bus USB.
- Suppression officielle de la gestion des architectures monoprocesseur.
En détails
La suppression de la gestion spécifique des architectures monoprocesseur dans Linux 6.17 concerne toutes les architectures (x86, ARM, RISC-V, MIPS, etc.) où le noyau pouvait jusqu’ici être compilé et exécuté en mode UP (pour Uni Processor), opposé au mode SMP (Symmetric MultiProcessing).
Désormais, même les machines avec un seul cœur ou un seul processeur utiliseront des noyaux compilés avec gestion SMP activée. Cette modernisation simplifie le code de l’ordonnanceur (scheduler) et d’autres sous-systèmes internes du noyau, qui peuvent désormais partir du postulat que le système est au moins SMP, même si physiquement un seul cœur est présent. Cela permet un énorme nettoyage du code spécifique à cette fonctionnalité, et donc, à terme, une meilleure maintenance et une plus grande cohérence.
Néanmoins, l’impact, même très léger et invisible sur beaucoup de systèmes modernes, est réel. Le coût mémoire et processeur (dû à la gestion des locks) va augmenter légèrement, et impactera plus fortement les systèmes embarqués très contraints.
Pour les chiffres (et des explications), les tests effectués sur des systèmes monoprocesseurs avec un noyau SMP ont montré une baisse de performance de 5 %, et une augmentation de 0,3 % de la taille. Ingo Molnar, à l’initiative de ce changement, avait pointé le fait qu’il y avait, dans l’ordonnanceur actuel, 175 #ifdef dépendant de #CONFIG_SMP qui ont pu être nettoyés, et avec, plus de 1000 lignes de code supprimées.
Systèmes de fichiers et stockage
Résumé
- Btrfs : la gestion de
large foliosest ajoutée (expérimental), tout comme des options étendues pour la défragmentation et la compression intelligente des extents. Les premiers tests de performance montrent un gain de 20 % pour la création de fichiers et diverses améliorations… - Ext4 : introduction du flag
RWF_DONTCACHEpermettant la purge automatique des données du cache après écriture, ce qui améliore certains workloads orientés I/O. - NFS : prise en charge des délégations d’écriture même en mode write-only, accélérant des cas d’usage précis.
- Introduction de nouveaux syscalls file_getattr() et file_setattr(), permettant la manipulation directe des attributs d’inodes via l’espace utilisateur.
- Bcachefs : Les relations entre le développeur de ce système de fichiers (Kent Overstreet) et les autres mainteneurs du noyau se sont largement dégradées. Plusieurs mainteneurs ont fait part de leur refus de travailler à l’avenir avec Kent ce qui a conduit Linus a ne plus accepter les demandes de mises à jour (pull requests). Bcachefs est donc figé dans cette version 6.17 du noyau (et il a été complètement retiré de la future version 6.18). Un module DKMS externe est maintenant disponible pour les utilisateurs voulant continuer à utiliser ce système de fichiers.
En détails
Pour ceux qui s’intéressent aux performances et comparatifs des différents systèmes de fichiers avec le kernel, Phoronix a testé ces FS sur ce noyau 6.17. Pas de comparatif avec les précédents noyaux, mais un comparatif entre les FS.
Le flag RWF_DONTCACHE permet des opérations de lecture ou d’écriture passant par le cache mais où les données lues ou écrites ne sont pas conservées dans ce cache une fois l’opération terminée. Autrement dit, les données ne « polluent » pas le cache mémoire, ce qui est utile pour certains types d’I/O où l’on ne veut pas fatiguer le cache avec des données temporaires ou volumineuses qui ne seront pas réutilisées rapidement. Ce flag est une option pour les appels systèmes preadv2() et pwritev2()
ret = pwritev2(fd, &iov, 1, 0, RWF_DONTCACHE);
En ce qui concerne les délégations d’écriture, cela permet de réduire les appels réseaux (jusqu’à 90 % dans certains cas d’usages — rapport)
Les syscalls file_getattr() et file_setattr() introduits dans Linux 6.16/6.17 permettent la manipulation directe des attributs d’inode depuis l’espace utilisateur, avec une interface plus simple et plus complète que les méthodes existantes.
Réseau et connectivité
Résumé
- Plusieurs nouveaux flags et options : SO_INQ pour AF_UNIX, extension de la gestion de MSG_MORE pour les paquets TCP volumineux et application plus stricte de la fenêtre TCP.
- Introduction de la prise en charge du protocole de congestion
DualPI2(RFC 9332) pour TCP/IP, notamment sur IPv6. - Nouveau sysctl
force_forwardingsur IPv6 permettant l’activation du mode forwarding. - Remplacement progressif de la gestion des pages réseau par des descripteurs spécialisés (
struct netmem_desc), préparant l’évolution vers les folios.
En détails
Le nouveau sysctl force_forwarding permet de forcer l’activation du forwarding indépendamment d’autres configurations potentiellement conflictuelles. (En particulier sur des profils limitatifs ou locaux)
sudo sysctl -w net.ipv6.conf.all.force_forwarding=1
Petits rappels sur les folios (aussi utilisés dans ce noyau pour Btrfs). Historiquement, le noyau Linux gère la mémoire en unités appelées « pages » (généralement 4K octets). Un folio est un regroupement logique de pages (souvent pages, comme 16 pages de 4K pour former un folio de 64K). Les folios permettent une gestion mémoire plus efficace, évitent les appels redondants liés aux pages individuelles et optimisent les copies.
netmem_desc sert d’abstraction générique pour la mémoire réseau, et utilisant les folios, remplace progressivement le struct page d’origine.
L’algorithme DualPI2 est un exemple d’algorithme de gestion active de file d’attente à double file couplée (AQM) spécifié dans la RFC 9332. Il sert de composant de base AQM au sein du cadre DualQ Coupled AQM conçu pour gérer deux files d’attente : une file « Classique » pour les contrôles de congestion compatibles Reno et une file « L4S » pour les contrôles de congestion Scalables. Vous trouverez plus de détails dans l'article en lien, avec, page 6 un ensemble de tests de performance en ce qui concerne DualPI2.
Virtualisation
Résumé
- Gestion de GSO (
Generic Segmentation Offload) sur tunnel UDP dans virtio - KVM : Unicité des enregistrements irqfd
-
vhost-net: Prise en charge deVIRTIO_F_IN_ORDER -
vsock: Introduction de la prise en chargeioctl SIOCINQ -
iommu: Révision complète de la prise en charge des IRQs postées -
vfio/qat: Prise en charge des function virutelleIntel QAT 6xxx
En détails
La prise en charge des GSO permet d’améliorer les performances des machines virtuelles en réduisant la charge CPU liée au traitement des paquets UDP.
L’irqfd (interrupt request fd) a été modifié pour être globalement unique, ce qui améliore la gestion des interruptions virtuelles et évite des collisions ou conflits dans la gestion des événements d’interruption, renforçant la stabilité et sécurité des VM.
VIRTIO_F_IN_ORDER permet de gérer un ordre strict pour les paquets pour les cartes réseaux virtuelles.
vfio, qui expose des périphériques aux machines virtuelles, ajoute la prise en charge des fonctions virtuelles des accélérateurs Intel QAT 6xxx (QuickAssist Technology), améliorant ainsi les capacités de calcul cryptographique et compression dans les environnements virtualisés.
Sécurité et cryptographie
Résumé
- AppArmor peut désormais contrôler l’accès aux sockets AF_UNIX.
- Ajout de nouvelles fonctions pour SHA-1, SHA-256 et SHA-512 dans la bibliothèque crypto.
- Optimisation de CRC32c sur les CPU récents (AVX-512).
- La gestion de la profondeur de pile via GCC/Clang permet désormais l’effacement automatisé de la stack (voir SafeStack pour plus de détails).
- Meilleur contrôle sur les atténuations (mitigations) de Spectre/x86.
- Ajout d’un délai de 5 secondes sur /sys/fs/selinux/user.
- Introduction des types
neversauditdans le contexteSELinux.
En détails
Pour rappel, AF_UNIX est une classe de socket Unix permettant la communication interprocessus. Avant cet ajout, AppArmor ne gérait pas la sécurité avec ce niveau de finesse pour ces sockets. Désormais, il est possible de restreindre dans les profils AppArmor, la communication via ces sockets, entre deux applications.
Phoronix a testé les améliorations sur CRC32C sur différentes architectures récentes, qui sont résumées dans le graphique ci-dessous.

Le noyau 6.17 introduit un meilleur contrôle sur les atténuations Spectre, grâce à un mécanisme appelé Attack Vector Controls (AVC). Le principe est simple, plutôt que d’activer ou désactiver des dizaines de protections individuelles contre les bugs d’exécution spéculative (Spectre, variantes de Meltdown, etc.), il est désormais possible de les piloter par groupes, selon la portée des attaques. Le noyau classe les atténuations en cinq catégories :
- attaques utilisateur-vers-noyau (
user-to-kernel) - attaques utilisateur-vers-utilisateur (
user-to-user) - attaques invité-vers-hôte (
guest-to-host) - attaques invité-vers-invité (
guest-to-guest) - attaques inter-threads (
cross-thread)
Avec un seul paramètre de démarrage mitigations=, il devient possible d’exclure une catégorie entière d’attaques (par exemple, désactiver toutes les protections invité-vers-invité si aucune VM non fiable n’est utilisée) et ainsi récupérer des performances.
Example: disable user-to-kernel attack mitigations, keep others at auto defaults
GRUB_CMDLINE_LINUX="... mitigations=auto,no_user_kernel ..."
Cette page liste l’ensemble des vulnérabilités CPU, et est une bonne source d’informations à ce propos.
Changements internes et outils
Résumé
- L'ordonnanceur ajoute le cgroup v2
cpu.maxpour gérer de manière plus fine l’utilisation du CPU. - Ajout de
DAMON_STATpour le monitoring. - Le montage automatique de
tracefssur/sys/kernel/debug/tracingest devenu obsolète au profit de/sys/kernel/tracing. - La migration vers des outils plus modernes : l’outil gconfig bascule sur GTK3.
- Toujours plus de
Rustavec de nouvelles abstractions pour la gestion du matériel et des propriétés firmware.
En détails
cpu.max est plus précis et global que les précédentes méthodes (utilisant cpu.cfs_quota_us et cpu.cfs_period_us ou cpu.shares), en s’appuyant sur l’extension CFS Bandwidth Control de CFS (Completely Fair Scheduler)
# Limite de 50ms d’utilisation CPU toutes les 100ms (50%)
echo "50000 100000" > /sys/fs/cgroup/cpu.max
DAMON_STAT est un module noyau statique de surveillance de l’espace d’adressage mémoire beaucoup plus léger que les précédentes méthodes
# Si DAMON_STAT est compilé en module
$ sudo modprobe damon_stat
# Activation du monitoring
$ echo 1 | sudo tee /sys/kernel/mm/damon/stat/enable
# lecture des informations
$ cat /sys/kernel/mm/damon/stat/statistics
damon_latency_avg: 23 ms
damon_bandwidth_bytes_per_sec: 5242880
damon_coldness_percentile_75: 40%
# Désactivation
echo 0 | sudo tee /sys/kernel/mm/damon/stat/enable
Le bilan en chiffres
Statistiquement, ce n’est certes pas le noyau le plus calme de la série 6.x, comme nous pouvons le voir sur les graphiques ci-dessous, néanmoins, il reste plutôt tranquille, avec du nettoyage et peu d’ajouts.




Appel à volontaires
Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| Architecture | Aucun | |
| Développeurs | Aucun | |
| Systèmes de fichiers | Aucun | patrick_g |
| Réseau | Aucun | |
| Virtualisation | Aucun | |
| Sécurité | Aucun | |
| Changements internes | Aucun | |
| Édition générale | Aucun | BAud - vmagnin - orfenor |
Un peu de vocabulaire :
- le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
- un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.
Nous sommes particulièrement à la recherche de mainteneurs pour toutes les parties.
Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, vous pouvez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
Aller plus loin
- kernelnewbies 6.17 (50 clics)
- lwn.net : Release (18 clics)
- lwn.net : Part 1 (25 clics)
- lwn.net : Part 2 (13 clics)

# Merci !
Posté par mahikeulbody . Évalué à 10 (+13/-0).
Un grand merci pour cette super dépêche !
# Merci !
Posté par Dring . Évalué à 10 (+9/-0).
Merci pour la dépêche ; un enôôôrme merci aux contributeurs.
# Monoprocesseur
Posté par lym . Évalué à 7 (+6/-0).
Vu de haut, on peut quand même se poser la question de l'intérêt de supprimer 1000 lignes de code sur les dizaines de millions du noyau, avec une pénalité de 5% pour des systèmes monoprocesseur qui ne sont certes plus si fréquents… sauf dans l'embarqué, avec des systèmes rentrant dans des infra télécoms et autres trucs à maintenir sur des décennies et qui tournent presque tous sous Linux.
Et là, comme initialement ces systèmes sont taillés pour une charge à 70/80% à la sortie commerciale (faut pas gâcher… sinon un concurrent arrivera à mieux se placer côté prix!) pour monter progressivement jusqu'à plus de 90% avec les ajouts en cours de vie. Eh bien 5%, cela peut sembler peu mais pour beaucoup de ces systèmes suivant les noyaux LTS cela peut ne plus passer. Combiné à un raccourcissement du support de ces noyaux, ce n'est donc pas une très bonne nouvelle.
[^] # Re: Monoprocesseur
Posté par Renault (site web personnel) . Évalué à 8 (+5/-0).
Une bonne partie du code du noyau n'est exécuté que très peu souvent donc la taille globale du code n'est pas forcément une bonne métrique.
Ici c'est une partie du code complexe et centrale, car exécutée sur tous les systèmes, avoir une bonne maintenance est assez importante aussi pour éviter des régressions ou des problèmes subtiles.
Notons que la pénalité est au cas par cas, ce n'est pas 5% pour tous, pour tous les cas d'usage et tous les sytèmes. Et rien n'indique que cela ne peut pas être récupéré après permis par justement un code plus simple avec moins d'hypothèse. ;)
[^] # Re: Monoprocesseur
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
D'accord, mais je suis quand même de l'avis de lym.
Après peut-être que pour un monoprocesseur, et donc embarqué ultra-contraint, un noyau Linux n'est pas le meilleur choix. J'entends par là, que même un nanoPC au format Raspberry PI est déjà sur du dual-core minimum. Alors le mono est vraiment destiné à l'embarqué qui n'a pas besoin de UI et de la plupart des logiciels Linux. Il y a sans doute alors des noyaux plus légers pour eux… surtout si les performances sont essentielles. Je pense à FreeBSD ou en temps-réel type FreeRTOS?
En fait même les projets qui refont l'OS pour de l’embarqué comme Yocto et BuildRoot se basent sur Linux.
Donc oui je pense que l'impact est quand même pas négligeable.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Monoprocesseur
Posté par lym . Évalué à 4 (+3/-0).
La bascule de ces systèmes s'est faite autour de 2005 (+- 2 ans selon les industriels): On est passé de RTOS type vxWorks à des Linux (alors patché RT) très (puis moins) minimalistes bien entendu sans UI.
2 raisons à cela:
-Linux (boite blanche préférée des chercheurs/universitaires) était toujours le 1er servi pour les nouveaux protocoles réseau et leurs évolutions… et les télécoms tout entiers basculaient hors de trucs conceptuellement intéressants (le dernier en date aura été ATM avec l'UMTS) mais n'ayant jamais percé ailleurs avec à la clef des composants chers (un switch ATM, ouille!), jamais bien déverminés car peu d'utilisateurs, puis une fois dans leur vie commerciale personne ne savait gérer cela pour en tirer le meilleur! A la fin, Ethernet killed'em all, même si la qualité de service y est venu aux forceps et sur le tard il était bien plus économique et simple de surdimensionner en mode désormais switché pour ne jamais avoir de congestion, avec pléthore de gens sachant installer/gérer.
-Moins de besoin RT dur, du fait des évolutions protocolaires et matérielles le code "machine à laver" est passé un peu plus côté DSP (voir carrément dans de la logique programmée de FPGA): Donc les patch full preempt RT suffisaient côté processeur généraliste, voir même un noyau vanilla non patché RT et en faisant de l'affinité CPU on collait le code "machine à laver" dans une scheduler propriétaire séparé tournant à côté selon les choix/habitudes des industriels. On a bien vu des hyperviseurs passer, mais jamais s'imposer dans les choix architecturaux contrairement au monde serveur.
Et, pour en revenir à ma préoccupation, il y a encore pas mal de systèmes (3G voir début 4G) tournant sur des SoC genre PowerQUICC III (de chez Motorola semi-conducteur devenu Freescale puis NXP) avec un unique coeur e500… qui doit transpirer un peu désormais, mais ils sont seront sans doute encore là pour 5 à 10 ans avec un suivi qui demeure.
Dans cet ordre d'idée, il y a encore 2 ans je voyais au grès de mes ballades en campagne/zone peu dense, au pied des antennes de sites relais, des armoires de matériel GSM sur lequel je bossais 25 ans plus tôt et devaient encore contenir des cartes à base de MPC860, qu'un Raspberry PI même 1er du nom ferait passer pour un dinosaure. Mais eux tournaient encore sous vxWorks!
[^] # Re: Monoprocesseur
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Le suport LTS a déménagé dans un projet à part mais il y a toujours un support de 10 ans pour plusieurs versions du noyau, ça se passe ici: https://wiki.linuxfoundation.org/civilinfrastructureplatform/start
# The winner is ?
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
ah merci, j'apprécie particulièrement ça:
… voir que les mastodons s'investissent dans le LL.
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: The winner is ?
Posté par Tiwaz . Évalué à 5 (+4/-0). Dernière modification le 08 octobre 2025 à 12:16.
J’aime beaucoup aussi, j’espère que mon script pour créer ces graphiques est juste :D.
J’ai oublié de faire des statistiques sur le nombre moyen de lignes par commit et par entité ; ce pourrait être intéressant de voir ceux qui poussent de gros changements et ceux qui sont plus atomiques. (C’est d’ailleurs pour cela que j’ai gardé les deux représentations : lignes et commits.)
Par contre, il sera intéressant de noter l’évolution sur les prochains noyaux. Suite à cet article sur les paquets
debianabandonnés à cause des licenciements chez Intel, je me pose des questions.[^] # Re: The winner is ?
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Au sujet d'Intel, j'ai du mal à cerner s'il s'agit d'une mesure économique de réduction de la masse salariale ou s'il y a un vrai revirement stratégique vis à vis du LL.
C'est pas réjouissant.
"Si tous les cons volaient, il ferait nuit" F. Dard
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.