From e62c41a24534067addb61bd2e8fc56bb0f16287f Mon Sep 17 00:00:00 2001 From: seantywork Date: Thu, 25 Sep 2025 08:12:03 +0000 Subject: [PATCH] update rcu cmap material --- krcu-cmap/README.md | 56 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/krcu-cmap/README.md b/krcu-cmap/README.md index a61ec23..d225b8c 100644 --- a/krcu-cmap/README.md +++ b/krcu-cmap/README.md @@ -55,10 +55,57 @@ struct node { }; ``` +With all these, our scenario will flow like the diagram below. +The critical part to look for (in my opinion) is \ +`delete all nodes` part from writer thread. +If this `rcu` thing cannot guarantee the basic functionality\ +we expect from things such as `pthread_rwlock`, then this part\ +will cause the GD kernel panic. ```shell +|---(r)eader thread------------|---(w)riter thread-----------| +| wait for cmap to be ready | | +| | create cmap | +| | update cmap (fill up) | +| | ready! | +| | | +| read values from cmap | update cmap | +| (interval 100ms) | (interval 1000ms) | +| continue | continue | +| continue | continue | +| continue | continue | +| continue | delete all nodes | +| continue... | exit | +| untile there is no value | | +| (sum == 0) | | +| exit | | +-------------------------------------------------------------- +``` + +Now, let's compile the kernel module. + +```shell +$ make +``` +Pop up another terminal, and use `dmesg` command to follow. + +```shell + +$ sudo dmesg -wH +``` + +Load the kernel module with `insmod` command. \ +As soon as you do this, `dmesg` will output the result \ +described in the diagram above. + +```shell +$ sudo insmod rcucmap.ko +``` + +```shell +# `dmesg -wH` outpu [Sep24 09:06] r: init [ +0.000007] r: wait... [ +0.000087] w: init @@ -131,6 +178,15 @@ struct node { ``` +As you can see, the program is working as expected and (thank god) \ +there is no kernel panic! + +Pleased, unload the kernel module. + +```shell +$ sudo rmmod rcucmap +``` + ```shell [ +17.767446] rcucmap: deleting cmap [ +0.000007] rcucmap: exit -- 2.43.0