Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RCU-Deadlocks #275

Open
xeren opened this issue Jul 1, 2022 · 6 comments
Open

RCU-Deadlocks #275

xeren opened this issue Jul 1, 2022 · 6 comments

Comments

@xeren
Copy link
Collaborator

xeren commented Jul 1, 2022

Rcu-Sync should be treated as an await-loop, in order to model executions in programs that use it incorrectly, like C-RW-GR+RW-R+RW-R. The current encoding scheme applied to the linux-kernel memory model prohibits control paths where a deadlocking Rcu-Sync is executed. Dartagnan currently cannot find such lifeness violations.

@ThomasHaas
Copy link
Collaborator

I don't think this is possible that easily. The semantics of the RCU primitives are currently only defined via the .cat file in the form of consistency constraints; the primitives have no program semantics. I think not even flagging will help here, cause all executions that have incorrect usage of RCU-Sync will also be inconsistent.

This will be a general problem for all library calls that are solely defined by a .cat specification.
For example, if we ever get around to express SMR in .cat, we might run into similar issues.

@hernanponcedeleon
Copy link
Owner

@xeren why do you say we should treat it as a spinloop? Which problem did you encounter?

I actually run this test with herd7 and it reports that the program has no execution

herd7 -model cat/linux-kernel.cat -I cat/ -bell cat/linux-kernel.bell -macros cat/linux-kernel.def litmus/LKMM/auto/C-RW-GR+RW-R+RW-R.litmus 
Test auto/C-RW-GR+RW-R+RW-R Allowed
States 0
No
Witnesses
Positive: 0 Negative: 0
Condition exists (0:r1=1 /\ 1:r1=1 /\ 2:r1=1)
Observation auto/C-RW-GR+RW-R+RW-R Never 0 0
Time auto/C-RW-GR+RW-R+RW-R 0.02
Hash=fdd3d7ccf2f518dd30733131e81ff12d

@ThomasHaas
Copy link
Collaborator

This is exactly the problem he refers to. The real implementation would have a deadlock in this situation, but in the case of litmus tests, all such executions are considered inconsistent rather than dead.
This is because the semantics are solely defined by the cat file in the form of consistency constraints.

@hernanponcedeleon
Copy link
Owner

Yes, this is the way to deal with such situations in litmus test (at least to be consistent with herd). The question is, is there an "issue" to be solved? Otherwise I think we can close this one.

@ThomasHaas
Copy link
Collaborator

I don't think there is an issue for litmus tests. At best it is a reminder that for actual Linux-code, treating RCU primitives via .cat without inlining their implementation may cause Dartagnan to not find any problems although the real code would certainly get stuck.

@hernanponcedeleon
Copy link
Owner

Is the following pattern the only deadlocking scenario?

rcu_read_lock();
...
synchronize_rcu();
...
rcu_read_unlock();

If so, I think it is fair to assume kernel developer will not write such kind of code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants