Re: [syzbot] KCSAN: data-race in start_this_handle / start_this_handle
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: 2021-03-19 14:16:43
Also in:
lkml
On 2021/03/12 0:54, Marco Elver wrote:
quoted
But the more we could have the compiler automatically figure out things without needing an explicit tag, it would seem to me that this would be better, since manual tagging is going to be more error-prone.What you're alluding to here would go much further than a data race detector ("data race" is still just defined by the memory model). The wish that there was a static analysis tool that would automatically understand the "concurrency semantics as intended by the developer" is something that'd be nice to have, but just doesn't seem realistic. Because how can a tool tell what the developer intended, without input from that developer?
Input from developers is very important for not only compilers and tools but also allowing bug-explorers to understand what is happening. ext4 currently has possible deadlock in start_this_handle (2) https://syzkaller.appspot.com/bug?id=38c060d5757cbc13fdffd46e80557c645fbe79ba which even maintainers cannot understand what is happening. How can bug-explorers know implicit logic which maintainers believe safe and correct? It is possible that some oversight in implicit logic is the cause of "possible deadlock in start_this_handle (2)". Making implicit assumptions clear helps understanding. Will "KCSAN: data-race in start_this_handle / start_this_handle" be addressed by marking? syzbot is already waiting for "KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata" at https://syzkaller.appspot.com/bug?id=5eb10023f53097f003e72c6a7c1a6f14b7c22929 .
If there's worry marking accesses is error-prone, then that might be a signal that the concurrency design is too complex (or the developer hasn't considered all cases). For that reason, we need to mark accesses to tell the compiler and tooling where to expect concurrency, so that 1) the compiler generates correct code, and 2) tooling such as KCSAN can double-check what the developer intended is actually what's happening.
and 3) bug-explorers can understand what the developers are assuming/missing.