lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ