On Mon, Oct 19, 2020 at 12:55:01PM -0400, Brian Foster wrote: > On Thu, Oct 15, 2020 at 10:47:00AM +0100, Christoph Hellwig wrote: > > I don't think we can solve this properly. Due to the racyness we can > > always err one side. The beauty of treating all the uptodate pages > > as present data is that we err on the safe side, as applications > > expect holes to never have data, while "data" could always be zeroed. > > > > I don't think that's quite accurate. Nothing prevents a dirty page from > being written back and reclaimed between acquiring the (unwritten) > mapping and doing the pagecache scan, so it's possible to present valid > data (written to the kernel prior to a seek) as a hole with the current > code. True. I guess we need to go back and do another lookup to fully solve this problem. That doesn't change my opinion that this patch makes the problem worse.
