Skip to content

Lighting talks

ChristianTedDerekKentEricChuckJamesAlAndrew MortonJohan

Blue TeamThe Linux Foundation43 minOpen on YouTube ↗

Demonstrates lighting talks and evaluates key implications for security practitioners.

Summary

### Overview This transcript captures a series of Linux kernel lightning talks and open discussions focused on kernel maintenance, deprecating unmaintained code, and simplifying internal subsystems. The main discussions revolve around aggressive removal of obsolete and unmaintained file systems, improving stable directory cookies for tmpfs over NFS, and stripping back High Memory (HIGHMEM) support for 32-bit systems.

### Key Topics - **Evicting Legacy File Systems**: Developers discussed overcoming the hesitation to remove obsolete or unmaintained file systems (such as ntfs3, ReiserFS, MinixFS, and older read-only formats). While Linus Torvalds' rule against breaking user space is acknowledged, maintainers noted the massive ongoing burden of accumulating syzbot bug reports, unmaintained code, and incompatibility with major VFS/kernel API overhauls like iomap, the new mount API, and folios. - **Userspace and VM Compatibility Fallbacks**: To resolve concerns about users needing access to legacy data, participants evaluated running legacy kernels in a lightweight virtual machine or User-Mode Linux (UML) and exposing file systems to the host via FUSE, or using shared network file systems (NFS/SMB) or archive extraction utilities like tar. - **tmpfs Stable Directory Cookies**: Chuck presented a proposal to resolve directory offset instability in tmpfs, which causes issues when exporting tmpfs directories over NFS because stateless readdir calls drop the internal cursor. - **Reducing HIGHMEM Footprint**: Proposing the reduction of HIGHMEM support across the kernel by eliminating HIGHMEM for metadata, page tables, and directory entries on aging 32-bit systems.

### Technical Details - **File System Deprecation & API Modernization**: Developers noted that changing core APIs—such as folio migrations, the new mount API, and the transition to iomap—creates severe development friction across ancient file systems (e.g., JFS, HFS, BFS, Minix, UDF, and ISO 9660). Many of these file systems fail extensively in automated testing environments (xfs_tests) and generate syzbot reports without an active maintainer to patch them. ReiserFS was noted as already being on a deprecation trajectory due to known security bugs. For simple reference implementations, developers suggested standardizing on well-maintained EXT2 rather than MinixFS. - **xarray Mechanism for tmpfs/libfs**: In tmpfs, creating or deleting files modifies directory offsets, breaking stateless `getdents` traversals over NFS. Chuck proposed an xarray-based approach to assign stable offsets to dentries for the lifecycle of the directory. Discussion addressed whether this should be localized to tmpfs or integrated into `libfs` helper functions (`iterate_shared`, `dir_llseek`) without penalizing synthetic or specialized file systems. - **Stripping HIGHMEM Subsystems**: As 32-bit x86 systems are virtually obsolete and Fedora 38 dropped 32-bit ARM support, HIGHMEM remains relevant mainly for legacy ARM systems (such as routers with ~1GB of RAM). The speaker proposed retaining HIGHMEM strictly for anonymous memory and page cache, while removing support for mapping kernel metadata, directories, and page tables into HIGHMEM. This simplifies folio management and removes complex `kmap` requirements, echoing cleanups already completed in Btrfs.

### Takeaways Developers agreed to present a unified position to Linus Torvalds advocating for aggressive eviction of unmaintained, legacy file systems. For tmpfs, discussions will continue around integrating stable directory offset mechanisms either via custom helpers or `libfs`. Finally, participants voiced broad consensus for simplifying the memory management subsystem by purging file system metadata and page table support from HIGHMEM.

Related talks

The Linux Foundation·14 min

  • LINUX FOUNDATION
  • Blue Team
  • Date: 2025
  • Location: Linux Foundation

Demonstrates lighting talks and evaluates key implications for security practitioners.

lightingvulnerability-researchlighting-talks+2

The Linux Foundation·20 min

  • LINUX FOUNDATION
  • Blue Team
  • Date: 2025
  • Location: Linux Foundation

Demonstrates lighting talks and evaluates key implications for security practitioners.

lightingvulnerability-researchlighting-talks+2

The Linux Foundation·45 min

  • LINUX FOUNDATION
  • Blue Team
  • Date: 2025
  • Location: Linux Foundation

Investigates lightning Talks and evaluates key implications for security practitioners.

lightningvulnerability-researchlightning-talks+2