lkml.org 
[lkml]   [2021]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [BUG] fs: ext4: possible ABBA deadlock in ext4_inline_data_truncate() and ext4_punch_hole()
From
Date


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

\
 
 \ /
  Last update: 2021-12-12 13:58    [W:0.053 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site