PREV_LEC | NEXT_LEC

What You Will Learn

• The exact prototype of the write() file operation and what each argument means
• Why the write position (*pos) must always be validated before touching memory
• How copy_from_user() safely moves data from user space into kernel space
• How to add a working write() method to the ep_chardev driver from the previous lecture
• How to build, load, and test the driver, and what output to expect

Prerequisites

• Lecture 4.5 and 4.6 of this free linux device drivers course (major/minor numbers, file_operations, open()/release())
• A Linux VM or machine running kernel 6.x with headers installed (linux-headers-$(uname -r))
• Basic familiarity with pointers and structs in C

The write() Method Prototype

Every character driver that accepts data from user space defines a write() callback inside its file_operations structure. Its signature looks like this:

Here buf is the user-space buffer holding the data the application wants to write, count is how many bytes it wants to send, and f_pos is a pointer to the current file position. The return value is the number of bytes actually written, or a negative error code such as -EFAULT or -EINVAL on failure.

How Data Flows From App to Kernel

When an application calls the standard C library write(), the kernel’s Virtual File System (VFS) resolves the file descriptor back to your driver’s registered file_operations and calls your write() callback with the user’s buffer, byte count, and current offset.

Steps Inside a write() Implementation

A well-behaved write() method follows a consistent sequence of checks before touching any memory:

1. Bounds check the offset. If *f_pos is already past the end of your device’s storage, reject the write with -ENOSPC or -EINVAL depending on your device semantics.
2. Clamp the count. If the requested count would write past the end of the buffer, shrink it so the write only fills what is left.
3. Lock the shared resource. Since multiple processes can write concurrently, protect the buffer with a mutex.
4. Copy from user space. Use copy_from_user(), never a raw pointer dereference, since user pointers cannot be trusted directly.
5. Advance the position and return. Update *f_pos by the number of bytes written and return that count.

Why copy_from_user() Instead of memcpy()

User-space pointers can point to unmapped, swapped-out, or invalid memory, and a malicious process could pass a kernel-space address to trick a naive driver. copy_from_user() performs the necessary access checks and page faults safely, returning the number of bytes that could not be copied. A return value of zero means full success.

Full Example: Adding write() to ep_chardev

This continues the original ep_chardev driver from the previous lecture. We add a fixed-size in-memory buffer and a mutex-protected ep_write() function.

Notice that mutex_lock_interruptible() is used instead of a plain mutex_lock(). This lets a process waiting on the lock be interrupted by a signal (like Ctrl+C) instead of hanging forever, which is the recommended pattern for user-facing driver code on kernel 6.x.

Registering the write Callback

Building and Testing the Driver

Build the module with a standard out-of-tree Makefile and load it:

Expected output:

If you see -EFAULT style errors instead, double-check that you are using copy_from_user() and not directly dereferencing buf.

write() Return Values

Common Mistakes

• Dereferencing buf directly instead of using copy_from_user() — this crashes or corrupts memory.
• Forgetting to clamp count, causing a buffer overflow inside the kernel.
• Using a plain mutex_lock() in code reachable from user-triggered syscalls without considering signal interruption.
• Not updating *f_pos, which breaks sequential writes and tools like dd.

Best Practices

• Always validate *f_pos and count before any copy.
• Protect shared buffers with a mutex, and prefer the interruptible variant for code called from user context.
• Return partial writes rather than failing outright when only some of the request fits.
• Keep the critical section (the locked region) as short as possible.

Performance and Security Considerations

Holding a mutex across a large copy_from_user() call blocks every other writer for the duration of the copy. For high-throughput devices, consider copying into a temporary kernel buffer first and only locking while updating shared state. On the security side, never trust count from user space without clamping it, and never skip copy_from_user() even for “trusted” callers, since any process with the right permissions can open your device node.

Summary

• The write() file operation moves data from a user-space buffer into the kernel using copy_from_user().
• Always bounds-check the offset and count before copying.
• Use a mutex to protect shared driver state from concurrent writers.
• Update *f_pos and return the actual number of bytes written.

FAQ

Conclusion

You have now added a safe, modern write() method to the ep_chardev driver, completing one half of the read/write pair every character driver needs. In the next lecture of this free linux kernel development course, we implement the matching read() method so user-space applications can retrieve the data you just learned to store.

PREV_LEC | NEXT_LEC