Unwinding a failed character-device registration

Unwinding a failed character-device registration releases resources acquired before an initialization failure while preserving the lifetime of anything that concurrent users can still access. In Linux, reserving device numbers, publishing the character-device object and creating userspace-visible names are distinct steps. The cleanup path must know which steps actually succeeded.

Consider an original abstract initialization sequence: reserve a number range, initialize a character-device object, publish it, then finish a later setup step. The following table tracks successful acquisitions; it is not a complete driver implementation.

alloc_chrdev_region reserves a range and reports failure through its return value. cdev_init initializes the object with its operations; cdev_add publishes it and makes it live immediately. unregister_chrdev_region releases a successful number reservation. Pair each release with the acquisition that actually succeeded, using the same first number and count.^[ref]

For a concrete bookkeeping example, suppose a successful reservation contains four interfaces starting at returned pair $(M,20)$. Failure before publication requires releasing that four-number range. Releasing only three leaves part of the reservation behind; releasing a guessed starting major or an unacquired range is a different error. The returned major from dynamic character-device number allocation must be retained rather than reconstructed from a pathname.

Publication changes the lifetime problem. cdev_del prevents new opens, but existing open file descriptors can still invoke their file operations. Therefore removing the device from lookup is not a proof that its backing state can immediately be freed. Character-device lifetime after deletion must account for the references and callbacks already in progress.^[ref]

The combined cdev_device_add helper has an especially important failure contract: callers must assume userspace could open the device and call operations even if the helper returns failure. A blanket error handler that immediately frees all backing state would violate that contract.^[ref] Design ownership and reference handling around the documented publication boundary, then release each owned resource once. The general lesson is that reverse acquisition order must be combined with concurrency-aware lifetime management.

Character-device lifetime after deletion is the interval during which a removed character device still needs valid backing state because existing users can invoke its operations. Linux cdev_del removes the device from new-open lookup; it does not invalidate already-open file descriptors. The kernel explicitly permits their file-operation callbacks after deletion returns.^[ref]

Consider an original event sequence. Process A opens an interface and retains a pointer to driver state. Removal calls cdev_del; process B can no longer obtain a new open through that registration. Process A then calls read. Freeing the state immediately after deletion would make that callback access dead storage: a use-after-free. The lookup lifetime and the backing allocation lifetime are different.

A useful ownership model gives the allocation one registration reference and one reference for each successful open. In a simplified reference counting design with $n$ opens, the reference count is $1+n$. Removal drops the registration reference; each final close drops its open reference. With two opens, the sequence is $3\to 2\to 1\to 0$, and storage is reclaimed only at zero. This is a model of ownership, not a complete driver implementation: taking references must itself be synchronized with removal, and asynchronous work can require additional references.

The character device may be disconnected from its hardware before its storage is reclaimed. Existing operations can observe a synchronized disconnected state and return an appropriate error while the allocation remains valid. Reference protection alone does not make removed hardware usable or serialize simultaneous operations.

For combined device objects, cdev_device_add and cdev_device_del have their own documented pairing and parent-reference rules. The add helper can expose callbacks even when it reports failure; the delete helper distinguishes stopped sysfs callbacks from still-callable operations on existing opens.^[ref] Therefore unwinding a failed character-device registration must follow the actual publication and ownership state. Releasing the device number reservation is separate from proving that every user of private storage has finished.