[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <71acc295-3a5b-176d-a58e-2aa3ba7627d6@huawei.com>
Date: Sat, 16 Apr 2022 16:41:35 +0800
From: Zhihao Cheng <chengzhihao1@...wei.com>
To: Christoph Hellwig <hch@....de>
CC: <viro@...iv.linux.org.uk>, <torvalds@...ux-foundation.org>,
<linux-fsdevel@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<yukuai3@...wei.com>
Subject: Re: [PATCH] fs-writeback: Flush plug before next iteration in
wb_writeback()
在 2022/4/16 13:42, Christoph Hellwig 写道:
>> I think the root cause is fsync gets buffer head's lock without locking
>> corresponding page, fixing 'progess' and flushing plug are both
>> workarounds.
>
> So let's fix that.
>
I think adding page lock before locking buffer head is a little
difficult and risky:
1. There are too many places getting buffer head before submitting bio,
and not all filesystems behave same in readpage/writepage/write_inode.
For example, ntfs_read_block() has locked page before locking buffer
head and then submitting bh, ext4(no journal) and fat may lock buffer
head without locking page while writing inode. It's a huge work to check
all places.
2. Import page lock before locking buffer head may bring new unknown
problem(other deadlocks about page ?). Taking page lock before locking
buffer head(in all processes which can be concurrent with wb_writeback)
is a dangerous thing.
So, how about applying the safe and simple method(flush plug) for the
time being?
PS: Maybe someday buffer head is removed from all filesystems, then we
can remove this superfluous blk_flush_plug.
Powered by blists - more mailing lists