Messages in this thread | | | Subject | Re: [BUG] fs: ext4: possible ABBA deadlock in ext4_inline_data_truncate() and ext4_punch_hole() | From | Jia-Ju Bai <> | Date | Sun, 12 Dec 2021 20:56:57 +0800 |
| |
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
| |