Skip to content

Instantly share code, notes, and snippets.

C srcu-impl-write-prop
(*
* Can an SRCU reader propogate it stores to CPUs after
* a grace period ends.
*)
{
}
// Synchronous updater
@joelagnel
joelagnel / srcu_gp_mb_case1_2readers.litmus
Created January 17, 2023 03:24
SRCU ordering for updates within writer and loads from 2 readers.
C srcu
(*
* Can SRCU satisfy grace-period ordering guarantees?
* Case 1: Updates within writer and loads from 2 readers.
*)
{
int x = 1;
int *y = &x;
int z = 1;
@joelagnel
joelagnel / srcu_gp_mb_case2_2readers.litmus
Last active January 17, 2023 03:39
SRCU ordering case 2 litmus with 2 readers
C srcu
(*
* Can SRCU satisfy grace-period ordering guarantees?
* Case 2: Updates within readers.
*)
{
int x0 = 0; int y0 = 0; int x1 = 0; int y1 = 0;
}
diff --git a/drivers/ptp/ptp_kvm_x86.c b/drivers/ptp/ptp_kvm_x86.c
index 4991054a2135..4f428d104d12 100644
--- a/drivers/ptp/ptp_kvm_x86.c
+++ b/drivers/ptp/ptp_kvm_x86.c
@@ -20,7 +20,7 @@ static struct kvm_clock_pairing clock_pair;
int kvm_arch_ptp_init(void)
{
- long ret;
@joelagnel
joelagnel / srcu_gp_mb_case2.litmus
Created January 8, 2023 23:18
SRCU GP ordering case 2 (writes in critical section, reads in updater)
C srcu
(*
* Can SRCU satisfy grace-period ordering guarantees?
* Case 2: writes in critical section, reads in updater
*)
{
int x = 0; int y = 0;
}
@joelagnel
joelagnel / srcu_gp_mb_case1.litmus
Last active January 10, 2023 18:29
SRCU GP ordering case 1 (writes in updater, reads in critical section)
C srcu
(*
* Can SRCU satisfy grace-period ordering guarantees?
* Case 1: Updates are seen properly in reader.
*)
{
int x = 1;
int *y = &x;
int z = 1;

Kernel Debugging Tricks

Introduction

Debugging the kernel is a difficult task. Thankfully there are quite a few built-in kernel debugging tools and techniques that help one quickly identify the source and/or the cause of an issue.

Enable debug information

@joelagnel
joelagnel / rqlock_drop_issue.md
Created January 2, 2023 05:23
Description of race that happens if dropping rq lock too early, before put_prev_task()

Ordering of class-balancing with put-prev-task

During a context switch, the schedule() loop calls the class-level pick_next_task() to find the next task to run on the CPU.

It looks something like this:

First schedule() calls pick_next_task() passing it the previous task as shown in \ref{lst:rq2}.

/* Here is the output of below module:
[ 3.069018] rd1: rwsem read acquired
[ 3.276624] wr1: about to acquire // Writer blocked on lock before..
[ 4.107213] rd2: about to acquire // ..the 2nd reader blocked on it.
[ 6.154863] rd1: rwsem read released
[ 6.155651] wr1: rwsem write acquired // Writer got the lock first.
[ 6.362821] wr1: rwsem write released
[ 6.363150] rd2: rwsem read acquired // Then new reader got it.
[ 6.578677] rd2: msleep done
use std::sync::{Arc, Mutex};
use std::thread;
use std::thread::JoinHandle;
use std::fs;
fn debug(msg: &str) {
println!("{}", msg);
_ = fs::write("/sys/kernel/debug/tracing/trace_marker", msg);
}