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 BC560C33CAA for ; Mon, 20 Jan 2020 12:03:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8BC1F208E4 for ; Mon, 20 Jan 2020 12:03:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BC1F208E4 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 1D5816B0639; Mon, 20 Jan 2020 07:03:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 186556B063B; Mon, 20 Jan 2020 07:03:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0C3876B063C; Mon, 20 Jan 2020 07:03:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0129.hostedemail.com [216.40.44.129]) by kanga.kvack.org (Postfix) with ESMTP id EAB7A6B0639 for ; Mon, 20 Jan 2020 07:03:41 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id A12CC8248047 for ; Mon, 20 Jan 2020 12:03:41 +0000 (UTC) X-FDA: 76397878242.01.wave82_7780033e08a29 X-HE-Tag: wave82_7780033e08a29 X-Filterd-Recvd-Size: 3069 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 20 Jan 2020 12:03:41 +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 5D6BAAC24; Mon, 20 Jan 2020 12:03:39 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id AF8751E0CF1; Mon, 20 Jan 2020 13:03:33 +0100 (CET) Date: Mon, 20 Jan 2020 13:03:33 +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 Subject: Re: [PATCH 0/3 v2] xfs: Fix races between readahead and hole punching Message-ID: <20200120120333.GG19861@quack2.suse.cz> References: <20190829131034.10563-1-jack@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: Hi Amir! 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). > 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... Honza [1] https://lore.kernel.org/linux-fsdevel/20191216193852.GA8664@kmo-pixel/ -- Jan Kara SUSE Labs, CR