Re: [BUG] fs: ext4: possible ABBA deadlock in ext4_inline_data_truncate() and ext4_punch_hole()

[Jia-Ju Bai <baijiaju1990@gmail.com>]

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