Sortie du noyau Linux 6.19. Le prochain noyau sera numéroté 7.0.

Après deux mois de développement, Linus Torvalds a présenté la version du noyau Linux 6.19. Parmi les changements les plus notables, on trouve : le sous-système Live Update Orchestrator, le support de l'encryption PCIe Link, l'appel système listns, le mode Zero-Copy Receive dans io_uring, le support de l'extension ARM MPAM, klp-build pour la génération de live patches, le support de l'architecture LoongArch32, la QoS pour s2idle, l'optimisation du sous-système d'audit, l'Intel LASS pour se protéger contre Spectre, le support des hash SHA-3 et BLAKE2b, le mécanisme Confidential VMBus, les optimisations TX dans le sous-système réseau, le protocole CAN XL, et une API pour l'accélération matérielle de la sortie HDR.

Dans l'annonce de cette nouvelle version, Linus a déclaré que la prochaine version du noyau porterait le numéro 7.0, car un nombre suffisant de versions s'est accumulé dans la branche 6.x pour justifier un changement dans le chiffre principal de la version (à l'époque, la version 6.0 a été formée juste après 5.19). Ce changement de numérotation est effectué pour des raisons esthétiques et constitue une démarche formelle pour lever le malaise causé par l'accumulation d'un grand nombre de versions dans la série. Linus a plaisanté en disant que les grands chiffres le déconcertent au point qu'il n'a pas assez de doigts pour les compter. Cependant, il existe en réalité une raison formelle pour le changement significatif du numéro de version, car à partir de la prochaine version, il a été décidé de passer le support de Rust des options expérimentales aux fonctionnalités principales du noyau.

La nouvelle version inclut 15657 corrections de 2237 développeurs, la taille du patch est de 52 Mo (les changements affectent 13682 fichiers, 794649 lignes de code ont été ajoutées et 335498 lignes ont été supprimées). Dans la dernière version, il y avait 15035 corrections de 2217 développeurs, la taille du patch était de 45 Mo. Environ 40 % de tous les changements présentés dans 6.19 concernent des pilotes de périphériques, environ 13 % des changements sont liés à la mise à jour de code spécifique à l'architecture matérielle, 12 % concernent la pile réseau, 5 % les systèmes de fichiers et 3 % les sous-systèmes internes du noyau.

Les principales nouveautés dans le noyau 6.19 (1, 2, 3) :

• Sous-système de disque, entrée/sortie et systèmes de fichiers
  • Dans Btrfs, les processus de vérification du système de fichiers (scrub) et de remplacement des dispositifs ne bloquent plus la mise en veille du système (avant de se mettre en veille, l'état de la vérification scrub est sauvegardé ; après la sortie de veille, la vérification scrub reprendra et l'opération de remplacement des dispositifs redémarrera). Le support des blocs de taille supérieure à la taille de page mémoire a été ajouté à l'implémentation de RAID56. Une préparation a été réalisée pour le support de fscrypt. La performance des opérations liées à la réservation d'espace a été améliorée. Le support de l'opération ioctl 'shutdown' a été ajouté, permettant de mettre le système de fichiers dans un état où une tentative de terminer les opérations déjà lancées est faite, mais où toutes les nouvelles opérations sont bloquées.
  • Dans le système de fichiers Ext4, le support des blocs de taille supérieure à la taille de page mémoire (>4KB sur les systèmes x86) a été mis en œuvre. L'utilisation de grands blocs permet d'augmenter la performance des opérations d'écriture en mode tampon en moyenne de 50 %, mais réduit la performance des entrées/sorties directes en raison de l'augmentation du temps de calcul des sommes de contrôle. La nouvelle version comprend également des optimisations qui augmentent la bande passante lors de la défragmentation en ligne.
  • Dans la sous-système FUSE, le support de la lecture tamponnée avec de grands folios de taille mémoire (large folios) a été amélioré. Grâce à iomap, il est possible de suivre les folios partiellement à jour pour charger uniquement les données qui manquent dans le tampon.
  • Dans VFS, le support de la délégation de gestion de répertoire rétractable (recallable directory delegation) a été ajouté, permettant de réaliser dans NFS le transfert de gestion de répertoire du de serveurs client, afin que le client NFS puisse suivre l'état du répertoire sur la base du cache local sans consulter le serveur NFS. Si un autre client NFS effectue des modifications liées à ce répertoire, la délégation de gestion sera révoquée pour le premier client.
  • Pour NFS, le support de la lecture en mode d'entrée/sortie directe (direct I/O) a été ajouté. Les paramètres /sys/kernel/debug/nfsd/io_cache_read et /sys/kernel/debug/nfsd/io_cache_write ont été mis en place pour gérer l'activation du cache et des opérations d'entrée/sortie directe, la manipulation de ces paramètres permet de réduire les frais généraux côté client NFS lors de l'exécution de grandes opérations d'entrée/sortie.
  • NTFS prend en charge l'opération ioctl de mise hors tension, les options de montage « acl » et « prealloc » sont activées par défaut, et le support du temps jusqu'au 1er janvier 1970 a été ajouté.
  • Pour les dispositifs de bloc et le système de fichiers, un cache d'objets « bio » (Block I/O) distinct pour chaque CPU est activé par défaut, définissant les opérations actives d'entrée/sortie.
• Mémoire et services système
  • Le sous-système Live Update Orchestrator (LUO) a été intégré au noyau, permettant de redémarrer et de mettre à jour le noyau sans arrêter le fonctionnement et sans perdre l'état du système, des dispositifs et des processus. Le sous-système LUO est basé sur le mécanisme KHO (Kexec HandOver) précédemment ajouté au noyau, et en plus de la possibilité de lancer un nouveau noyau depuis l'ancien sans perdre l'état du système, il s'occupe de la sauvegarde de l'état des dispositifs et de la mémoire vive, ainsi que d'assurer la continuité des opérations liées à DMA et au traitement des interruptions. L'état est préservé jusqu'au changement vers le nouveau noyau et est restauré après l'activation du nouveau noyau sans perturber les opérations continues avec les dispositifs, effectuées par le système et les applications dans l'espace utilisateur.
  • L'appel système listns() a été ajouté pour afficher la liste des espaces de noms existants dans le système sans avoir à parcourir /proc//ns/ pour tous les processus.
  • Le système d'entrée/sortie asynchrone io_uring a ajouté le support de l'insertion d'éléments de tailles différentes dans la file d'attente de soumission (SQE, Submission Queue Entry), de manière similaire à ce qui était permis dans la version précédente pour le mélange des tailles de contenu de la file d'attente de résultats (CQE, Completion Queue Event). Avant cela, tous les éléments dans la file d'attente devaient avoir la même taille, ce qui entraînait une consommation excessive de mémoire en raison de la nécessité d'utiliser la taille maximale pour tous les éléments de la file d'attente.

    Dans io_uring, la prise en charge du mécanisme zcrx (Zero-Copy Receive) a également été ajoutée pour recevoir des données sans copie entre le noyau et l'espace utilisateur. La prise en charge des requêtes de disposition de la mémoire pour les files d'attente SQ (Submission Queue) et CQ (Completion Queue) a été ajoutée, permettant d'obtenir des informations sur la taille du buffer circulaire, nécessaire lors de l'allocation de mémoire par l'utilisateur grâce aux indicateurs IORING_SETUP_NO_MMAP et IORING_MEM_REGION_TYPE_USER.

  • Pour une traçabilité rapide de la pile à l'aide d'outils tels que perf, la prise en charge du format SFrame avec des informations sur le déroulement de la pile d'appels (unwind) a été ajoutée. SFrame est déjà pris en charge dans GCC et binutils, n'affecte pas les performances et, contrairement au format DWARF, contient uniquement le minimum d'informations nécessaires pour la traçabilité de la pile.
  • L'outil perf a ajouté la prise en charge d'une description unifiée des métriques et des événements au format JSON, ainsi que du déroulement différé (deferred unwinding) de la pile d'appels dans l'espace utilisateur.
  • Pour les processeurs AMD, un mécanisme d'injection de données dans le cache a été mis en œuvre, permettant aux dispositifs d'entrée/sortie d'injecter directement des données dans le cache L3 du CPU sans nécessité de les placer au préalable dans la RAM.
  • La prise en charge de MPAM (Memory System Resource Partitioning and Monitoring) a été ajoutée, une extension de l'architecture du jeu d'instructions ARMv8-A pour marquer chaque accès à la mémoire avec un identifiant de section (PARTID, Partition ID) et un identifiant de groupe de surveillance (PMG, Monitoring Group ID). En lien avec PARTID, il est possible de limiter la consommation de ressources, telles que la bande passante mémoire ou la taille du cache, afin qu'un groupe de tâches ne monopolise pas toutes les ressources. Dans le contexte de la surveillance, la combinaison de PMG et PARTID peut être utilisée pour suivre la consommation des ressources mémoire sous certaines charges.
  • En cas d'arrêt anormal d'un processus après réception d'un signal, un autre processus, ayant le pidfd du processus terminé, peut maintenant déterminer le numéro du signal qui a conduit à la terminaison du processus.
  • L'implémentation des séquences réinitialisables (restartable sequences) a été retravaillée, permettant aux applications d'organiser une exécution pseudo-atomique non interrompue d'un groupe d'instructions (en cas d'interruption par un autre fil, une nouvelle tentative d'exécution de la séquence est effectuée). La nouvelle implémentation se distingue par une meilleure une grande performance.
  • Des instructions BPF_JMP, BPF_X et BPF_JA ont été mises en œuvre pour effectuer des sauts indirects vers une position spécifique dans la table de sauts. Le concept de pointeurs dynamiques (dynptr) a été ajouté, permettant de lire des données à partir de fichiers structurés. La possibilité d'attacher plusieurs octets de métadonnées aux paquets réseau a été ajoutée.
  • Les modules en langage Python utilisés pour traiter la documentation du noyau ont été déplacés dans un répertoire séparé tools/lib/python.
  • Une fonction mempool_alloc_bulk() a été ajoutée pour allouer en toute sécurité des éléments à partir d'un pool de mémoire pour plusieurs objets à la fois.
  • La transition des modifications de la branche Rust-for-Linux a continué, concernant l'utilisation du langage Rust comme second langage pour le développement de pilotes et de modules du noyau (le support de Rust n'est pas activé par défaut et ne conduit pas à l'inclusion de Rust parmi les dépendances conditionnelles pour le noyau). Dans la nouvelle version, la bibliothèque « syn » avec un parseur de code Rust, simplifiant l'écriture de macros complexes, a été intégrée au noyau. Les capacités des bibliothèques kernel, pin-init et rbtree ont été étendues. Une bibliothèque ‘num’ avec un type Integer pour manipuler des entiers a été ajoutée. Le macro « module! » a été enrichi d'un support pour des paramètres entiers. La possibilité de spécifier des paramètres lors du chargement de modules du noyau écrits en Rust a été mise en œuvre. Des abstractions pour les sous-systèmes I2C et PWM (modulation de largeur d'impulsion) ont été réalisées.
  • Un macro « at_least » (par exemple, « param[at_least 7] »), indiquant la taille minimale acceptable d'un tableau passé à la fonction, a été ajouté. Si un tableau avec moins d'éléments est transmis à la fonction, le compilateur générera un avertissement.
  • Un script klp-build pour générer des modules du noyau, apportant des modifications au noyau en cours d'exécution (livepatch), basé sur un fichier de patch, a été intégré. Des modifications nécessaires à la création de live-patch ont été apportées à l'outil objtool.
  • Dans User-mode Linux (exécution du noyau en tant que processus utilisateur), un support limité du multiprocessus a été ajouté, mais les threads au sein d'un même processus ne peuvent pas encore s'exécuter simultanément. Le portage de User-mode Linux sur la bibliothèque nolibc a commencé.
  • Le support pour l'architecture LoongArch32 (LA32R, LA32S) a été ajouté en complément de LoongArch64.
  • Ajout de la possibilité de définir des limites QoS sur l'intensité de réveil du processeur en mode d'économie d'énergie s2idle (Suspend-To-Idle), gelant l'exécution des processus dans l'espace utilisateur tout en laissant certains gestionnaires actifs dans le noyau.
  • Ajout du support de la gestion des tables de pages mémoire pour les contrôleurs IOMMU (Unité de Gestion de Mémoire Entrée-Sortie), réalisant la traduction des adresses virtuelles visibles par le matériel en adresses physiques, avec la possibilité de filtrer les opérations DMA par adresses virtuelles, ainsi que de limiter et d'isoler les opérations d'entrée-sortie.
  • Dans les événements de traçage des appels système, il est maintenant possible de lire des buffers depuis l'espace utilisateur et d'inclure leur contenu (par exemple, des noms de fichiers) dans le résultat du traçage.
  • Les pages mémoire de garde (guard page), dont l'accès provoque une exception et un terminaison anormale du processus (SIGSEGV), sont maintenant marquées par une étiquette spéciale dans le fichier /proc/PID/smaps.
  • Ajout de la possibilité de gérer les grandes pages mémoire (transparent huge page) dans la mémoire privée des dispositifs zonés.
  • Dans le dispositif zram, utilisé pour le stockage compressé de la partition d'échange en mémoire, le support du remplacement de plusieurs structures « bio » (Block I/O) en mode de traitement en lot (writeback batching) a été introduit.
  • Le polices « Terminus 10×18 » est inclus, améliorant la lisibilité des informations à partir de la console sur les écrans de laptops avec une résolution moyenne (1440×900).
  • Le fonctionnement du sous-système d'audit a été considérablement optimisé — une réduction des frais généraux a été notée, avec une baisse de moitié.
• Virtualisation et sécurité
  • Le support de la fonctionnalité LASS (linear address-space separation) fournie par les processeurs Intel a été ajouté, permettant de séparer matériellement les plages d'adresses de l'espace utilisateur et du noyau pour renforcer la sécurité. L'espace d'adresses est séparé par le bit le plus significatif de l'adresse : la moitié de l'espace d'adresses avec le bit le plus significatif activé est utilisée pour le noyau, tandis que la partie inférieure est réservée à l'espace utilisateur. À un stade précoce de l'exécution des instructions (avant l'exécution spéculative), une vérification est effectuée pour déterminer la validité des accès depuis l'espace utilisateur vers les adresses avec le bit le plus significatif activé et vice versa. Cette séparation permet de bloquer les fuites de mémoire du noyau vers l'espace utilisateur par des canaux secondaires, même lors de l'exécution spéculative des instructions, ce qui permet d'appliquer LASS pour protéger contre les attaques de type Meltdown et Spectre, sans engendrer de coûts overhead importants.
  • Il est désormais possible d'activer des extensions de sécurité pour le bus PCI Express : la chiffrement de lien PCIe et l'authentification des appareils PCIe, permettant de vérifier l'authenticité et de chiffrer le canal de communication entre un dispositif PCIe et une machine virtuelle, protégée par les mécanismes Intel TDX (Trusted Domain Extensions) et AMD SEV-SNP (Secure Nested Paging). Les technologies mises en place empêchent l'interception, l'analyse et l'injection de données dans le trafic DMA en cas d'accès au système hôte ou à d'autres dispositifs.
  • La bibliothèque cryptographique intégrée a ajouté le support des algorithmes SHA-3 (SHA3-224, SHA3-256, SHA3-384, SHA3-512), SHAKE128, SHAKE256 et BLAKE2b.
  • Pour les modules LSM (Linux Security Modules), et en particulier pour SELinux, la possibilité de suivre la création de descripteurs memfd a été mise en œuvre pour appliquer des politiques de sécurité aux objets associés.
  • Dans le module LSM IPE (Integrity Policy Enforcement), qui définit la politique globale d'intégrité du système, le support du drapeau AT_EXECVE_CHECK dans la fonction execveat() a été ajouté, ce qui active la vérification de l'intégrité du script avant son exécution par l'interpréteur.
  • Des primitives scoped_user_read_access(), scoped_user_write_access et scoped_user_rw_access() ont été ajoutées pour un accès limité aux données dans l'espace utilisateur tout en protégeant contre les attaques spéculatives.
  • Ajout du support du mécanisme Confidential VMBus, utilisé dans l'hyperviseur HyperV pour des interactions protégées contre les intrusions entre le système invité, fonctionnant en mode confidentiel (avec chiffrement de la mémoire et isolation des registres à l'aide des technologies AMD SNP et Intel TDX), et le paravisor, qui gère l'accès aux dispositifs traitant des données confidentielles.
  • Ajout de la possibilité de transmettre des informations sur un processus ayant échoué (pour générer un coredump) via le mécanisme pidfd. L'identifiant PIDFD est lié à un processus spécifique et ne change pas, tandis que le PID peut être reassigné à un autre processus après l'arrêt du processus actuel associé à ce PID. L'utilisation de pidfd permet d'éviter les attaques par substitution d'un processus suid terminé par un autre processus, en atteignant un état de concurrence juste après le début du traitement par le noyau de l'arrêt anormal, mais avant que le gestionnaire vérifie dans l'espace utilisateur les paramètres du processus.
• Sous-système réseau
  • Des optimisations ont été apportées à la sous-système réseau pour améliorer l'efficacité de la transmission des données (TX). La suppression de l'auto-verrouillage de la fonction __dev_queue_xmit() et l'utilisation d'une structure llist sans verrouillage ont permis d'augmenter la performance par quatre sous forte charge et de doubler l'intensité d'envoi de paquets tout en réduisant la charge sur le CPU de moitié.
  • Il est désormais possible de désactiver pour des sockets réseau spécifiques les limites système d'utilisation de mémoire (dans ce cas, les limites de mémoire communes appliquées à des conteneurs individuels seront utilisées). Pour gérer la désactivation des limites, un sysctl net.core.bypass_prot_mem et un drapeau SK_BPF_BYPASS_PROT_MEM dans la fonction bpf_setsockopt ont été proposés.
  • Ajout du support de l'extension RFC 5837, qui inclut dans les messages ICMP « Time Exceeded », renvoyés à l'expiration du temps de vie (TTL) d'un paquet, des données sur les interfaces réseau entrantes afin d'obtenir des informations plus détaillées lors du traçage des routes avec l'utilitaire traceroute.
  • Ajout du support du polling actif continu (busy polling) dans un thread séparé du noyau afin d'extraire des descripteurs des files d'attente RX/TX pour des applications nécessitant des délais minimaux.
  • Ajout du support du protocole CAN XL (Controller Area Network eXtended Length), dans lequel la taille du champ de données est augmentée à 2048 octets pour assurer l'intégration avec les réseaux TCP/IP, mise en œuvre de la possibilité de tunneliser des trames Ethernet et ajout du support de la modulation par largeur d'impulsion, permettant de transmettre des données à des vitesses de 20 Mbit/s et plus.
  • Ajout du support de la structure sockaddr_unsized, une variante de la structure sockaddr utilisant un tableau à éléments flexibles au lieu d'un tableau à taille fixe (sa_data[] au lieu de sa_data[14], qui était essentiellement utilisé pour pointer vers d'autres structures de taille supérieure).
  • Ajout de la possibilité d'utiliser les fonctionnalités getsockname et getpeername via le sous-système io_uring.
  • Ajout des paramètres sysctl net.ipv4.tcp_rcvbuf_low_rtt et net.ipv4.tcp_comp_sack_rtt_percent pour optimiser le TCP.
  • Ajout du support des liaisons avec une bande passante de 1600 Gbps (1.6T).
• Matériel
  • Dans le sous-système DRM (Direct Rendering Manager), ajout d'une API pour exploiter les capacités matérielles de conversion de couleur, permettant d'éviter d'effectuer de telles conversions via des shaders ou d'exécuter du code sur le CPU. Pour afficher du contenu sur un écran HDR, des transformations de couleur complexes peuvent désormais être effectuées par le contrôleur d'affichage au stade avant et après le mélange des couches, au lieu d'un compositing logiciel du contenu dans le tampon d'affichage final. En plus de réduire les frais généraux et la consommation d'énergie lors de la sortie en HDR, la fonctionnalité proposée peut être utilisée pour un rendu des couleurs correct dans les éditeurs de vidéos ou d'images.
  • Ajout du pilote «ethosu» pour le NPU Arm Ethos U65 et U85, destinés à l'accélération matérielle de l'exécution des modèles AI.
  • Dans le pilote i915 pour GPU Lunar Lake et plus récent, prise en charge de l'amélioration matérielle de la netteté de l'image (Sharpening).
  • Poursuite du travail sur le pilote drm (Direct Rendering Manager) Xe pour GPU basé sur l'architecture Intel Xe, qui est utilisée dans les cartes graphiques Intel de la famille Arc et dans la graphique intégrée, à partir des processeurs Tiger Lake. Ajout du support initial de l'architecture Xe3P, utilisée dans les GPU Crescent Island et les familles de processeurs avec graphique intégrée Nova Lake.
  • Le pilote AMDGPU prend en charge pleinement les cartes graphiques AMD des familles GCN 1.0 « Southern Island » et 1.1 « Sea Islands », pour lesquelles le pilote Radeon était utilisé auparavant. Le pilote AMDGPU a été porté au même niveau de fonctionnalités que le pilote Radeon et est activé par défaut pour les GPU mentionnés. Les cartes GCN 1.x ont été produites de 2012 à 2019 et couvrent des modèles tels que Radeon HD 77xx/78xx/79xx/87xx/88xx/89xx, Radeon R9 280, FirePro W4000-W9000, Radeon Sky 700/900, Radeon R9 265/270/370, Radeon R9 290/390, HD 7790/8870, et d'autres cartes graphiques des familles Radeon Rx 200/Rx 300. En plus d'augmenter les performances en moyenne de 24 %, la transition vers AMDGPU a permis d'implémenter le support de l'API graphique Vulkan 1.3 pour ces GPU. De plus, AMDGPU a ajouté le support des connecteurs analogiques et de Video Coding Engine 1.0, et le stack DC (Display Core) est utilisé par défaut pour les GPU basés sur l'architecture micro d'Bonaire (Radeon HD 7700).
  • Le pilote Nouveau prend en charge l'accélérateur matériel NVJPG, présent dans le SoC Tegra210.
  • Le pilote Panthor a ajouté le support du GPU Mali-G1 et un soutien initial pour le chip MediaTek MT8196.
  • Ajout du support du sous-système audio des puces Intel Nova Lake S, des ordinateurs portables HP avec HDA CS35L41, ainsi que des interfaces audio CIX IPBLOQ HD et Onkyo SE-300PCIE.
  • La intégration des composants du pilote Nova pour les GPU NVIDIA, équipés des firmwares GSP, utilisés depuis la série NVIDIA GeForce RTX 2000 basée sur l'architecture Turing, s'est poursuivie. Le pilote est écrit en Rust. Dans la nouvelle version, le travail sur RPC a commencé et l'implémentation du chargement du coprocesseur GSP (GPU System Processor) a été achevée.
  • Ajout du support pour les plates-formes ARM, SoC et appareils : Bananapi r4 pro, LinkEase EasePi R1, Qualcomm MSM8937 (Snapdragon 430), Renesas R-Car X5H, FriendlyElec NanoPi R76S, TI AM62L, Black Sesame Technologies C1200, Aspeed AST2600, Genio 1200 EVK, grinn geniosbc-510/700, Tanix TX9 Pro, Radxa Dragon Q6A, Tinker Board 3/3S, Aquila AM69, phyBOARD-Segin-i.MX91, i.MX 95 Verdin Evaluation Kit, Toradex SMARC iMX95, VIDIA Jetson Nano 2GB, Renesas rz/g3s, Indiedroid Nova, 24 variantes de plates Enclustra Mercury.
  • Ajout du support pour les smartphones et tablettes basés sur le SoC Mediatek MT6582 (Alcatel yarisxl), Nvidia Tegra124 (Xiaomi Mi Pad) et Qualcomm MSM8939 (ASUS ZenFone 2). Ajout du support pour les ordinateurs portables basés sur le SoC Qualcomm sdm850, tels que le Huawei MateBook E 2019.
  • Ajout du support des SoC et des cartes basées sur l'architecture RISC-V : OrangePi R2S, OrangePi RV, Anlogic dr1v90, Tenstorrent Blackhole.

Simultanément, la Fondation latino-américaine pour le logiciel libre a créé une version entièrement libre du noyau 6.19 — Linux-libre 6.19-gnu, débarrassée des éléments de firmware et des pilotes contenant des composants libres ou des portions de code dont l'utilisation est limitée par le fabricant. Dans la version 6.19, le code de chargement des firmwares binaires a été supprimé de la sous-système audio SDCA. Le code de nettoyage des blobs dans les pilotes Intel XE, Nova-Core, Qualcomm Iris, Venus et Q6V5, TI PRUeth, Intel iwlwifi, Marvell mwifiex, FourSemi fs210x, Realtek rt1320 et les codecs audio TI tas2783 a été mis à jour. Le nettoyage des noms des blobs dans les fichiers dts (devicetree) pour les puces ARM a été effectué. Le nettoyage du pilote STM C8SECTPFE DVB, supprimé du noyau, a été arrêté.

Source : opennet.ru