From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=x9eJ=SK=vger.kernel.org=linux-fsdevel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no
	version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id F3354C10F13
	for <linux-fsdevel@archiver.kernel.org>; Mon,  8 Apr 2019 11:03:26 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id C193020857
	for <linux-fsdevel@archiver.kernel.org>; Mon,  8 Apr 2019 11:03:26 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1726005AbfDHLDZ (ORCPT
        <rfc822;linux-fsdevel@archiver.kernel.org>);
        Mon, 8 Apr 2019 07:03:25 -0400
Received: from mx2.suse.de ([195.135.220.15]:53044 "EHLO mx1.suse.de"
        rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
        id S1725881AbfDHLDZ (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
        Mon, 8 Apr 2019 07:03:25 -0400
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.220.254])
        by mx1.suse.de (Postfix) with ESMTP id 2BB02AE80;
        Mon,  8 Apr 2019 11:03:24 +0000 (UTC)
Received: by quack2.suse.cz (Postfix, from userid 1000)
        id 25F961E424A; Mon,  8 Apr 2019 13:03:22 +0200 (CEST)
Date:   Mon, 8 Apr 2019 13:03:22 +0200
From:   Jan Kara <jack@suse.cz>
To:     Dave Chinner <david@fromorbit.com>
Cc:     Amir Goldstein <amir73il@gmail.com>,
        "Darrick J . Wong" <darrick.wong@oracle.com>,
        Christoph Hellwig <hch@lst.de>,
        Matthew Wilcox <willy@infradead.org>,
        linux-xfs <linux-xfs@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [POC][PATCH] xfs: reduce ilock contention on buffered randrw
 workload
Message-ID: <20190408110322.GA18662@quack2.suse.cz>
References: <20190404165737.30889-1-amir73il@gmail.com>
 <20190404211730.GD26298@dastard>
 <CAOQ4uxjQNmxqmtA_VbYW0Su9rKRk2zobJmahcyeaEVOFKVQ5dw@mail.gmail.com>
 <20190407232728.GF26298@dastard>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190407232728.GF26298@dastard>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-fsdevel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-fsdevel.vger.kernel.org>
X-Mailing-List: linux-fsdevel@vger.kernel.org

On Mon 08-04-19 09:27:28, Dave Chinner wrote:
> The result of this is that, AFAICT, ext4 does not protect against
> read() vs hole punch races - it's hole punching code it does:
> 
> Hole Punch:				read():
> 
> inode_lock()
> inode_dio_wait(inode);
> down_write(i_mmap_sem)
> truncate_pagecache_range()
> 					ext4_file_iter_read()
> 					  ext4_map_blocks()
> 					    down_read(i_data_sem)
> 					     <gets mapping>
> 					<populates page cache over hole>
> 					<reads stale data into cache>
> 					.....
> down_write(i_data_sem)
>   remove extents
> 
> IOWs, ext4 is safe against truncate because of the
> change-inode-size-before-invalidation hacks, but the lack of
> serialise buffered reads means that hole punch and other similar
> fallocate based extent manipulations can race against reads....

Hum, you are right. Ext4 is buggy in this regard. I've fixed the race for
page fault in ea3d7209ca01 "ext4: fix races between page faults and hole
punching" but didn't realize the problem is there for buffered reads as
well. I'll think how we can fix this. Thanks for noticing this!

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR