Linux

Software Engineering / 17 Sep 2026 / 4 min read

io_uring Multishot Accept Keeps One Request Active Across Connections

A Linux io_uring multishot accept request can produce several completion queue entries from one submission queue entry. The kernel keeps the accept operation active after a successful completion when the CQE carries IORING_CQE_F_MORE, so a server does not need to submit a fresh accept SQE for every connection. This changes the lifetime contract between submission and completion. A normal oneshot request is finished after its CQE. A multishot accept can remain in flight across many accepted connections, and the CQE flags determine whether that request still exists.

Software Engineering Linux

Software Engineering / 17 Sep 2026 / 4 min read

inotify Rename Cookies Correlate Move Events Without Making Them Atomic

A Linux rename() observed through inotify can produce two records carrying the same nonzero cookie: IN_MOVED_FROM for the old directory entry and IN_MOVED_TO for the new one. The cookie correlates those records, but it does not turn them into one atomic queue item. That boundary matters for software maintaining a pathname index, synchronizing directory state, or converting filesystem notifications into higher-level change records. A rename is one filesystem operation while its inotify representation can be a pair whose delivery has weaker grouping properties.

Software Engineering Linux

Software Engineering / 17 Sep 2026 / 5 min read

eventfd Counter Coalesces Notifications Before Read

A Linux eventfd can receive several writes before any consumer runs, yet the descriptor does not retain those writes as separate messages. Each accepted write adds its unsigned 64-bit value to a kernel-maintained counter. Without EFD_SEMAPHORE, one successful read returns the current counter and resets it to zero. That behavior makes eventfd a counter-backed notification primitive rather than a message queue. Readiness indicates that the counter is nonzero; it does not preserve the number, ordering, or boundaries of individual write operations.

Software Engineering Linux

Software Engineering / 17 Sep 2026 / 5 min read

EPOLLET Reports Readiness Transitions, Not Buffer Drainage

With EPOLLET, a file descriptor can still contain unread data after its readiness event has already been consumed. A later epoll_wait() is not required to report that descriptor again merely because the old readable state persists. That behavior is the central boundary of edge-triggered epoll: notification tracks changes in readiness, while the underlying I/O object retains its own state independently. Readiness state and event delivery are separate An epoll instance maintains an interest list and a ready list. Registration through epoll_ctl() defines which open file descriptions matter and which event classes are relevant. epoll_wait() returns entries that have reached the ready list.

Software Engineering Linux

Software Engineering / 17 Sep 2026 / 9 min read

Epoll Edge Triggering Turns Readiness Into a Drain Obligation

An edge-triggered epoll registration can stop producing notifications while unread bytes still remain in a socket or pipe. The descriptor is still usable for I/O, but the event loop has already consumed the notification associated with the readiness transition. If the handler reads only part of the available data and returns to epoll_wait(), no fresh transition is required to occur, so the pending bytes can remain untouched indefinitely. This behavior makes EPOLLET more than a notification preference. It changes the contract between the kernel’s ready list and application state. A level-triggered loop can repeatedly receive a descriptor while the requested I/O condition remains true. An edge-triggered loop must preserve enough local state to treat a delivered event as an obligation to exhaust the currently available nonblocking I/O, normally until an operation reports EAGAIN.

Software Engineering Linux

Linux / 17 Sep 2026 / 4 min read

Duplicated File Descriptors Share an Open File Description

Two file descriptor numbers can move the same file offset. On Linux, this occurs when both descriptors refer to one open file description, as happens after dup() and across inherited descriptors after fork(). The distinction matters because a file descriptor is a process-visible integer, while the open file description is the kernel object that carries state for an open instance of a file. Treating those layers as interchangeable can produce offset interference, status-flag changes that cross descriptor boundaries, and surprising behavior after process creation.

Linux File Descriptors

Cybersecurity / 17 Sep 2026 / 5 min read

close_range with UNSHARE Detaches Descriptor Tables Before Bulk Closure

A multithreaded Linux process can reach an awkward boundary just before execve(): one thread wants to discard every file descriptor above standard input, output, and error, while another thread can still create descriptors in the same table. A loop of close() calls treats descriptor numbers individually, but it does not by itself change the fact that the table is shared. close_range() with CLOSE_RANGE_UNSHARE addresses that specific race. The kernel first gives the caller a file descriptor table that is no longer shared with the other users of the old table, then applies the requested bulk closure to the caller’s table. The security property is about table ownership during cleanup, not merely fewer system calls.

Cybersecurity Linux

Linux / 16 Sep 2026 / 5 min read

Linux TCP TIME_WAIT Retains Closed Connection State

A TCP socket can disappear from an application while the kernel still retains state for the closed connection. On Linux, the endpoint that completes the active close commonly enters TIME_WAIT, keeping enough protocol state to protect a later connection from delayed segments associated with the old one. This state is not evidence that a process forgot to close a file descriptor. The application-visible socket can already be gone. TIME_WAIT belongs to TCP’s connection-lifecycle machinery and persists independently of the process that initiated the close.

Linux TCP

Linux / 16 Sep 2026 / 4 min read

Linux TCP Autocorking Coalesces Consecutive Small Writes

A small TCP write does not always trigger an immediate packet transmission on Linux. With TCP autocorking enabled, the stack can defer a new small send when an earlier packet from the same flow is still waiting in a qdisc or device transmit queue, giving a following write a chance to join the pending data. The mechanism targets packet count rather than application-visible buffering semantics. A successful write() or sendmsg() still reports bytes accepted by the socket; autocorking influences when queued bytes advance into transmission.

Linux TCP

Linux / 16 Sep 2026 / 6 min read

Linux Readahead Expands Sequential Page-Cache Reads

A buffered file read can cause Linux to fetch more data than the application explicitly requested. The extra I/O is readahead: the kernel populates nearby page-cache folios in anticipation of continued access. This behavior sits between application read size and storage request size. A process may issue modest read() calls while the kernel submits larger reads to keep later accesses from waiting on storage. Readahead is page-cache speculation Buffered file I/O normally passes through the page cache. When requested file data is absent, the kernel must arrange I/O for that miss. The readahead path can extend that operation across additional folios that are not yet present in the cache.

Linux Memory

Linux / 16 Sep 2026 / 5 min read

Linux PSI Separates Partial and Total Resource Stalls

A Linux host can report modest CPU utilization while runnable work is delayed, or ample memory capacity while tasks repeatedly stall in reclaim. Utilization counters describe resource activity; pressure stall information records time in which work cannot make progress because a resource is contended. PSI exposes that lost execution opportunity through CPU, memory, and I/O pressure files. Its central distinction is between a stall affecting at least one task and a stall that leaves every non-idle task unable to make progress.

Linux PSI

Linux / 16 Sep 2026 / 6 min read

Linux cgroup memory.high Converts Overage into Reclaim Pressure

A cgroup can remain alive after its memory usage crosses memory.high. The boundary does not behave like a hard allocation ceiling: tasks in the cgroup are throttled and pushed into heavy reclaim pressure, and usage can remain above the configured value under extreme conditions. That behavior makes memory.high materially different from memory.max. The former converts excess usage into execution cost and reclaim work. The latter is a hard limit that can lead to a cgroup OOM when reclaim cannot reduce usage enough.

Linux cgroup v2

Linux / 16 Sep 2026 / 5 min read

io_uring Registered Files Bypass Repeated Descriptor Lookup

An io_uring request that uses a normal file descriptor still has to resolve that descriptor through the submitting task’s file table. A registered file takes a different path: the ring holds a reference to the open file, and an SQE names a slot in that ring-local table. That distinction removes repeated descriptor lookup from the request path. It also changes resource lifetime, update semantics, and the meaning of the SQE fd field.

Linux io_uring

Tech / 16 Sep 2026 / 5 min read

fsync on a File Does Not Persist Its Directory Entry

A successful fsync() on a regular file does not, by itself, guarantee that the directory entry naming that file has reached persistent storage. Linux documents this boundary explicitly: file synchronization covers the file’s data and associated metadata, while persistence of the containing directory entry requires an fsync() on a file descriptor for that directory. This distinction matters when software creates a new file or atomically replaces an existing pathname. File contents and pathname metadata are separate pieces of filesystem state, and a crash can test the durability boundary between them.

Linux Filesystem

Linux / 16 Sep 2026 / 5 min read

epoll Edge-Triggered Readiness Requires Draining

An edge-triggered epoll consumer can block while unread data is still buffered. The failure appears when an event is consumed, only part of the available input is read, and the event loop returns to epoll_wait() expecting another notification for the bytes that remain. This behavior follows directly from EPOLLET. Edge-triggered notification reports changes in readiness rather than continuously reporting a ready condition. Once a readiness transition has produced an event, leaving the file descriptor ready does not itself create a new transition.

Linux epoll

Software Engineering / 16 Sep 2026 / 7 min read

Duplicate File Descriptors Share Offsets but Not Descriptor Flags

Calling dup() does not create an independent stream position. The returned descriptor refers to the same open file description as the source descriptor, so a seek through either descriptor changes the offset observed through both. At the same time, descriptor-local state such as the close-on-exec flag remains attached to each descriptor separately. That split is easy to miss because both kinds of state are manipulated through integer file descriptors. The integer is only a process-local reference. Several descriptors can point at one open file description, and that shared object carries state with consequences for reads, writes, seeks, and status-flag changes.

Software Engineering Linux

Tech / 15 Sep 2026 / 7 min read

ARP Neighbor Cache Reuses Local IP-to-MAC Mappings

Sending an IPv4 packet across an Ethernet network requires two different kinds of addresses. The IP layer selects a next-hop IPv4 address, while the Ethernet frame needs a destination MAC address that identifies the next hop on the local link. Address Resolution Protocol (ARP) connects those two layers. A host can ask which MAC address corresponds to a local IPv4 address, receive a reply, and store the resulting mapping. Keeping that result in a neighbor cache avoids broadcasting the same question before every packet.

Networking ARP

Linux / 07 Sep 2026 / 12 min read

Understand Sparse Files on Linux Without Wasting Disk Space

A file can report a size of 100 GiB without consuming 100 GiB of disk blocks. That sounds contradictory until you separate two ideas that ordinary file APIs often present together: a file’s logical size and the storage that the filesystem has actually allocated for it. Linux filesystems can represent long ranges of unwritten bytes as holes. Reading a hole returns zero bytes, but the filesystem does not need to store one physical zero byte for every logical byte in that range. A regular file that contains holes is called a sparse file.

Linux File Systems

Linux / 06 Sep 2026 / 13 min read

Choose the Right Advisory File Lock on Linux

Two processes can open the same file and both write to it successfully. That is often exactly what Unix applications need, but sometimes the programs are supposed to coordinate: only one worker should update a state file, several readers may share a resource, or a process must avoid changing a byte range while another process is using it. Linux offers several advisory file-locking mechanisms. The confusing part is not how to request a lock. The confusing part is what owns the lock and when that lock disappears.

Linux System Calls

Linux / 05 Sep 2026 / 11 min read

Wake Linux Event Loops from Other Threads with eventfd

A file-descriptor event loop can wait efficiently for sockets, pipes, timers, and other kernel objects. A common problem appears when work originates somewhere that is not already represented by a file descriptor: another thread changes shared state and needs the loop to wake immediately. Polling shared state on a timer adds latency or wastes wakeups. A condition variable can wake a thread, but it cannot be placed directly in the same poll() or epoll wait set as a socket. A pipe can bridge the two models, but using a pipe only as a wakeup signal means maintaining a read end, a write end, and byte-buffer semantics that the application may not actually need.

Linux Concurrency

Linux / 05 Sep 2026 / 12 min read

Pass Open File Descriptors Between Linux Processes with SCM_RIGHTS

Processes often need to hand each other access to an already-open resource. A supervisor may accept a client connection and delegate it to a worker. A privileged helper may open a protected file, then give an unprivileged process access without revealing broader filesystem permissions. A service may create an anonymous in-memory file and transfer it to another process. Sending the integer value of a file descriptor does not solve this problem. File descriptor numbers are meaningful only inside one process’s descriptor table. Descriptor 7 in one process can refer to a socket while descriptor 7 in another process refers to an unrelated file.

Linux IPC

Linux / 05 Sep 2026 / 10 min read

Move Data Between Linux File Descriptors with splice()

A conventional file-copy loop reads bytes into a user-space buffer and then writes those bytes somewhere else. That pattern is portable and easy to understand, but sometimes the program does not need to inspect or transform the data at all. It only needs to move bytes from one file descriptor to another. On Linux, splice() can handle that case differently. It transfers data between file descriptors while keeping the transferred data out of a user-space buffer. At least one endpoint must be a pipe, so a pipe can act as the kernel-side bridge between a source and a destination.

Linux System Calls

Linux / 05 Sep 2026 / 9 min read

Create Sealable In-Memory Files on Linux with memfd_create

Applications often need a temporary chunk of data that behaves like a file without needing a persistent pathname. A process may build a configuration snapshot, compiled artifact, or serialized message, then map it into memory or pass it to another process. A regular temporary file can do that, but it introduces filesystem naming, cleanup, permissions, and lifetime concerns. An anonymous mmap() avoids the pathname, but it does not produce an ordinary file descriptor that can be passed to APIs expecting file-backed data.

Linux System Calls

Linux / 04 Sep 2026 / 8 min read

Write Files Atomically on Linux with rename and fsync

Updating a small file looks simple: open it, truncate it, write the new contents, and close it. That works when nothing interrupts the write. The failure mode appears when a process crashes, the machine loses power, or another process reads the file while it is being rewritten. A reader can observe an empty or partially written file, and a crash can leave the pathname referring to incomplete data. For configuration files, state snapshots, generated metadata, and similar single-file updates, a better pattern is to write a complete replacement beside the original file and then rename it into place.

Linux Filesystems