Add RCU section and example by visitorckw · Pull Request #387 · sysprog21/lkmpg

visitorckw · 2026-08-22T14:27:30Z

Introduce a new subsection in the synchronization chapter to explain basic RCU concepts. A new kernel module is also included to demonstrate RCU API usage for safely reading and updating shared data.

Summary by cubic

Adds an RCU subsection to the synchronization chapter and a runnable example_rcu kernel module to demonstrate lockless reads with serialized writers. Previously there was no RCU coverage or sample; now the docs and examples build include this by default.

Docs: lkmpg.tex builds; the RCU subsection renders; \samplec{examples/example_rcu.c} resolves.
Build/run: examples/Makefile builds example_rcu.o; loading the module starts a reader kthread, updates values, and frees old memory only after synchronize_rcu(); writers serialize with a spinlock.

^{Written for commit 5418701. Summary will update on new commits.}

cubic-dev-ai

All reported issues were addressed across 3 files

_{Reply with feedback, questions, or to request a fix.

Re-trigger cubic}

jserv

It is unnecessary to have filenames starting with example_ in examples/ directory.

linD026

Be careful about the line break.

linD026 · 2026-08-23T02:50:17Z

+        rcu_read_lock();
+        p = rcu_dereference(shared_data);
+        if (p)
+            pr_info("RCU Reader: value = %d\n", p->value);


As a best practice, it is better not to use pr_info() in the RCU read-side critical section.

I just added pr_info() to make the read value visible, otherwise reading it silently feels a bit meaningless for an example. How about copying the value to a local variable first, and then calling pr_info() after rcu_read_unlock()?

Looks good to me.

linD026 · 2026-08-23T02:56:04Z

+
+Keep in mind that RCU only protects the readers. Concurrent writers must still serialize among themselves using a standard lock, such as a spinlock or a mutex.
+
+The following example demonstrates a basic RCU implementation where a reader safely accesses shared data while a writer updates it.


Adding some official materials would be better:

https://docs.kernel.org/RCU/whatisRCU.html

linD026 · 2026-08-23T02:57:49Z

+
+Unlike spinlocks or mutexes, RCU readers do not acquire any locks or write to shared memory. This completely avoids cache-line bouncing and results in near-zero overhead for the read path. The tradeoff is that the updaters bear the cost of synchronization. When modifying a data structure, an updater creates a copy, modifies it, and then publishes the new version by replacing the old pointer in a single atomic operation.
+
+Because concurrent readers might still be accessing the old data, the updater cannot free it immediately. Instead, it must wait for a "grace period" to elapse---a duration long enough to ensure that all pre-existing readers have left their critical sections. Only then can the old memory be safely reclaimed.


Add a line break between sentences.

... cannot free it immediately. Instead, ...

linD026 · 2026-08-23T03:05:09Z

+\label{sec:rcu}
+Read-Copy-Update (RCU) is a synchronization mechanism that allows extremely fast, lock-free reads while still permitting concurrent updates. It is highly optimized for read-mostly scenarios.
+
+Unlike spinlocks or mutexes, RCU readers do not acquire any locks or write to shared memory. This completely avoids cache-line bouncing and results in near-zero overhead for the read path. The tradeoff is that the updaters bear the cost of synchronization. When modifying a data structure, an updater creates a copy, modifies it, and then publishes the new version by replacing the old pointer in a single atomic operation.


Ditto, add a line break.

linD026 · 2026-08-23T03:05:30Z


+\subsection{Read-Copy-Update (RCU)}
+\label{sec:rcu}
+Read-Copy-Update (RCU) is a synchronization mechanism that allows extremely fast, lock-free reads while still permitting concurrent updates. It is highly optimized for read-mostly scenarios.


linD026 · 2026-08-23T03:14:46Z

It is unnecessary to have filenames starting with example_ in examples/ directory.

Other sync examples have an example_ prefix.

obj-m += example_spinlock.o
obj-m += example_rwlock.o
obj-m += example_atomic.o
obj-m += example_mutex.o

I think the author just wants to follow the style?

jserv · 2026-08-23T03:58:47Z

Other sync examples have an example_ prefix.
I think the author just wants to follow the style?

Agree. We can use shorter prefixes that do not conflict with built-in Linux kernel module names later.

visitorckw · 2026-08-23T04:20:31Z

Other sync examples have an example_ prefix.
I think the author just wants to follow the style?

Agree. We can use shorter prefixes that do not conflict with built-in Linux kernel module names later.

Yeah, I was just aligning with the existing style, but I completely agree. Linus has actually complained about this exact kind of redundancy to maintainers before. I can send a follow up cleanup PR to rename them all once this gets merged.

Introduce a new subsection in the synchronization chapter to explain basic RCU concepts. A new kernel module is also included to demonstrate RCU API usage for safely reading and updating shared data.

jserv · 2026-08-23T12:25:40Z

Thank @visitorckw for contributing!

cubic-dev-ai Bot reviewed Aug 22, 2026

View reviewed changes

Comment thread lkmpg.tex

Comment thread lkmpg.tex Outdated

visitorckw force-pushed the add-rcu branch from 52e020c to 2d1a52e Compare August 22, 2026 14:43

jserv requested changes Aug 23, 2026

View reviewed changes

linD026 requested changes Aug 23, 2026

View reviewed changes

Add RCU section and example

5418701

Introduce a new subsection in the synchronization chapter to explain basic RCU concepts. A new kernel module is also included to demonstrate RCU API usage for safely reading and updating shared data.

visitorckw force-pushed the add-rcu branch from 2d1a52e to 5418701 Compare August 23, 2026 07:55

jserv merged commit 0e996e2 into sysprog21:master Aug 23, 2026
9 checks passed

visitorckw deleted the add-rcu branch August 24, 2026 05:02


		Keep in mind that RCU only protects the readers. Concurrent writers must still serialize among themselves using a standard lock, such as a spinlock or a mutex.

		The following example demonstrates a basic RCU implementation where a reader safely accesses shared data while a writer updates it.


		Unlike spinlocks or mutexes, RCU readers do not acquire any locks or write to shared memory. This completely avoids cache-line bouncing and results in near-zero overhead for the read path. The tradeoff is that the updaters bear the cost of synchronization. When modifying a data structure, an updater creates a copy, modifies it, and then publishes the new version by replacing the old pointer in a single atomic operation.

		Because concurrent readers might still be accessing the old data, the updater cannot free it immediately. Instead, it must wait for a "grace period" to elapse---a duration long enough to ensure that all pre-existing readers have left their critical sections. Only then can the old memory be safely reclaimed.

Conversation

visitorckw commented Aug 22, 2026 • edited by cubic-dev-ai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by cubic

Uh oh!

cubic-dev-ai Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jserv left a comment

Choose a reason for hiding this comment

Uh oh!

linD026 left a comment

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

visitorckw Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 Aug 23, 2026

Choose a reason for hiding this comment

Uh oh!

linD026 commented Aug 23, 2026

Uh oh!

jserv commented Aug 23, 2026

Uh oh!

visitorckw commented Aug 23, 2026

Uh oh!

Uh oh!

jserv commented Aug 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

visitorckw commented Aug 22, 2026 •

edited by cubic-dev-ai Bot

Loading

cubic-dev-ai Bot left a comment •

edited

Loading