On 2021/12/11 2:05, Theodore Y. Ts'o wrote:
On Fri, Dec 10, 2021 at 10:03:37AM +0800, Jia-Ju Bai wrote:
Thank you very much for the detailed explanation!
I will improve my static analysis tool for this point.
I'm not sure it will be possible to programatically detect why the
ABBA deadlock isn't possible without having the static analyzer having
a semantic understanding how the code works (so it can understand that
that code path which leads to the ABBA deadlock won't get executed).
It may very well be that being able to understand why the ABBA
deadlock can't happen in that case is equivalent to solving the
halting problem. But if you do come up with a clever way of improving
your static analysis tool, I'll be excited to see it!
Hi Ted,
Thanks a lot for your advice!
According to your last message, ext4_punch_hole() and
ext4_inline_data_truncate() both call ext4_has_inline_data() to check
whether the inode has inline data.
In ext4_inline_data_truncate(), when ext4_has_inline_data() returns
zero, the function returns.
In ext4_punch_hole(), when ext4_has_inline_data() returns zero, the
function continues.
Thus, I think I can add such "concurrency" path conditions in my tool to
filter out false positives, by assuming that the same function calls or
data structure fields should return/store the same value in concurrency
code paths without race conditions.
In fact, my tool can validate path conditions of each sequential code
path. I can find ways to validate "concurrency" path conditions in my
tool :)
Best wishes,
Jia-Ju Bai
