On Fri, Oct 28, 2016 at 3:48 AM, robbieko wrote:
> From: Robbie Ko
>
> We found a fsync deadlock in log_new_dir_dentries, because
> btrfs_search_forward get path lock, then call btrfs_iget will
> get another extent_buffer lock, maybe occur deadlock.
From: Robbie Ko
We found a fsync deadlock in log_new_dir_dentries, because
btrfs_search_forward get path lock, then call btrfs_iget will
get another extent_buffer lock, maybe occur deadlock.
Fix this by release path before call btrfs_iget, avoid deadlock occur.
Example:
On Tue, Oct 11, 2016 at 8:47 AM, robbieko wrote:
> Hi Filipe:
>
> why did you replace the continue statement with a break statement:
> because we released ahead of the path, it can not continue to use,
> need to jump out, and then go to again.
Seeing the code and not only
Hi Filipe:
why did you replace the continue statement with a break statement:
because we released ahead of the path, it can not continue to use,
need to jump out, and then go to again.
supplement:
We found a fsync deadlock ie. 32021->32020->32028->14431->14436->32021,
the number id pid.
On Fri, Oct 7, 2016 at 11:43 AM, robbieko wrote:
> Hi Filipe,
>
> I am sorry, I express not clear enough.
> This number is pid, and the above are their call trace respectively.
And why did you replace the continue statement with a break statement?
Also please avoid mixing
On Fri, Oct 7, 2016 at 11:05 AM, robbieko wrote:
> From: Robbie Ko
>
> We found a fsync deadlock ie. 32021->32020->32028->14431->14436->32021,
> in log_new_dir_dentries, because btrfs_search_forward get path lock, then
> call btrfs_iget will get
From: Robbie Ko
We found a fsync deadlock ie. 32021->32020->32028->14431->14436->32021,
in log_new_dir_dentries, because btrfs_search_forward get path lock, then
call btrfs_iget will get another extent_buffer lock, maybe occur deadlock.
we can release path before call