From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 726C9C2D0DB for ; Mon, 20 Jan 2020 17:04:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2618520882 for ; Mon, 20 Jan 2020 17:04:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2618520882 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id ADE5B6B0696; Mon, 20 Jan 2020 12:04:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A8DD86B0697; Mon, 20 Jan 2020 12:04:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A3556B0698; Mon, 20 Jan 2020 12:04:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0056.hostedemail.com [216.40.44.56]) by kanga.kvack.org (Postfix) with ESMTP id 817BD6B0696 for ; Mon, 20 Jan 2020 12:04:11 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 4B041181AC9CC for ; Mon, 20 Jan 2020 17:04:11 +0000 (UTC) X-FDA: 76398635502.14.start28_7bcf0d973971e X-HE-Tag: start28_7bcf0d973971e X-Filterd-Recvd-Size: 4274 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 17:04:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 594B1ABED; Mon, 20 Jan 2020 17:04:09 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 2A2191E0D08; Mon, 20 Jan 2020 17:58:30 +0100 (CET) Date: Mon, 20 Jan 2020 17:58:30 +0100 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , linux-xfs , Linux MM , "Darrick J. Wong" , Boaz Harrosh , linux-fsdevel , Matthew Wilcox , Jens Axboe , Kent Overstreet Subject: Re: [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching Message-ID: <20200120165830.GB28285@quack2.suse.cz> References: <20190829131034.10563-1-jack@suse.cz> <20200120120333.GG19861@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 20-01-20 15:54:28, Amir Goldstein wrote: > On Mon, Jan 20, 2020 at 2:03 PM Jan Kara wrote: > > On Fri 17-01-20 12:50:58, Amir Goldstein wrote: > > > On Thu, Aug 29, 2019 at 4:10 PM Jan Kara wrote: > > > > > > > > Hello, > > > > > > > > this is a patch series that addresses a possible race between readahead and > > > > hole punching Amir has discovered [1]. The first patch makes madvise(2) to > > > > handle readahead requests through fadvise infrastructure, the third patch > > > > then adds necessary locking to XFS to protect against the race. Note that > > > > other filesystems need similar protections but e.g. in case of ext4 it isn't > > > > so simple without seriously regressing mixed rw workload performance so > > > > I'm pushing just xfs fix at this moment which is simple. > > > > > > > > > > Could you give a quick status update about the state of this issue for > > > ext4 and other fs. I remember some solutions were discussed. > > > > Shortly: I didn't get to this. I'm sorry :-|. I'll bump up a priority but I > > can't promise anything at the moment. > > > > > Perhaps this could be a good topic for a cross track session in LSF/MM? > > > > Maybe although this is one of the cases where it's easy to chat about > > possible solutions but somewhat tedious to write one so I'm not sure how > > productive that would be. BTW my discussion with Kent [1] is in fact very > > related to this problem (the interval lock he has is to stop exactly races > > like this). > > > > Well, I was mostly interested to know if there is an agreement on the way to > solve the problem. If we need to discuss it to reach consensus than it might > be a good topic for LSF/MM. If you already know what needs to be done, > there is no need for a discussion. So I have an idea how it could be solved: Change calling convention for ->readpage() so that it gets called without page locked and take i_mmap_sem there (and in ->readpages()) to protect from the race. But I wanted to present it in the form of patches as the devil here is in the details and it may prove to be too ugly to be bearable. If I won't get to writing the patches, you're right it may be sensible to present the idea to people at LSF/MM what they think about it. > > > Aren't the challenges posed by this race also relevant for RWF_UNCACHED? > > > > Do you have anything particular in mind? I don't see how RWF_UNCACHED would > > make this any better or worse than DIO / readahead... > > > > Not better nor worse. I meant that RFW_UNCACHED is another case that > would suffer the same races. Yes, that's right. Honza -- Jan Kara SUSE Labs, CR