xref: /OK3568_Linux_fs/kernel/Documentation/litmus-tests/rcu/RCU+sync+free.litmus (revision 4882a59341e53eb6f0b4789bf948001014eff981)
1*4882a593SmuzhiyunC RCU+sync+free
2*4882a593Smuzhiyun
3*4882a593Smuzhiyun(*
4*4882a593Smuzhiyun * Result: Never
5*4882a593Smuzhiyun *
6*4882a593Smuzhiyun * This litmus test demonstrates that an RCU reader can never see a write that
7*4882a593Smuzhiyun * follows a grace period, if it did not see writes that precede that grace
8*4882a593Smuzhiyun * period.
9*4882a593Smuzhiyun *
10*4882a593Smuzhiyun * This is a typical pattern of RCU usage, where the write before the grace
11*4882a593Smuzhiyun * period assigns a pointer, and the writes following the grace period destroy
12*4882a593Smuzhiyun * the object that the pointer used to point to.
13*4882a593Smuzhiyun *
14*4882a593Smuzhiyun * This is one implication of the RCU grace-period guarantee, which says (among
15*4882a593Smuzhiyun * other things) that an RCU read-side critical section cannot span a grace period.
16*4882a593Smuzhiyun *)
17*4882a593Smuzhiyun
18*4882a593Smuzhiyun{
19*4882a593Smuzhiyunint x = 1;
20*4882a593Smuzhiyunint *y = &x;
21*4882a593Smuzhiyunint z = 1;
22*4882a593Smuzhiyun}
23*4882a593Smuzhiyun
24*4882a593SmuzhiyunP0(int *x, int *z, int **y)
25*4882a593Smuzhiyun{
26*4882a593Smuzhiyun	int *r0;
27*4882a593Smuzhiyun	int r1;
28*4882a593Smuzhiyun
29*4882a593Smuzhiyun	rcu_read_lock();
30*4882a593Smuzhiyun	r0 = rcu_dereference(*y);
31*4882a593Smuzhiyun	r1 = READ_ONCE(*r0);
32*4882a593Smuzhiyun	rcu_read_unlock();
33*4882a593Smuzhiyun}
34*4882a593Smuzhiyun
35*4882a593SmuzhiyunP1(int *x, int *z, int **y)
36*4882a593Smuzhiyun{
37*4882a593Smuzhiyun	rcu_assign_pointer(*y, z);
38*4882a593Smuzhiyun	synchronize_rcu();
39*4882a593Smuzhiyun	WRITE_ONCE(*x, 0);
40*4882a593Smuzhiyun}
41*4882a593Smuzhiyun
42*4882a593Smuzhiyunexists (0:r0=x /\ 0:r1=0)
43