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,URIBL_BLOCKED,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 4301CC4320D for ; Tue, 24 Sep 2019 15:23:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 11589214DA for ; Tue, 24 Sep 2019 15:23:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11589214DA 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 B62E56B0008; Tue, 24 Sep 2019 11:23:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEE1B6B000A; Tue, 24 Sep 2019 11:23:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01846B000C; Tue, 24 Sep 2019 11:23:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id 7C2296B0008 for ; Tue, 24 Sep 2019 11:23:24 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 1C448180AD804 for ; Tue, 24 Sep 2019 15:23:24 +0000 (UTC) X-FDA: 75970183128.29.nerve58_57d71aca4ec4d X-HE-Tag: nerve58_57d71aca4ec4d X-Filterd-Recvd-Size: 2761 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Tue, 24 Sep 2019 15:23:23 +0000 (UTC) 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 457ADAFB6; Tue, 24 Sep 2019 15:23:22 +0000 (UTC) Received: by quack2.suse.cz (Postfix, from userid 1000) id 49C5D1E4427; Tue, 24 Sep 2019 17:23:37 +0200 (CEST) Date: Tue, 24 Sep 2019 17:23:37 +0200 From: Jan Kara To: Boaz Harrosh Cc: Jan Kara , "Darrick J. Wong" , linux-xfs@vger.kernel.org, linux-mm@kvack.org, Amir Goldstein , Boaz Harrosh , linux-fsdevel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH 3/3] xfs: Fix stale data exposure when readahead races with hole punch Message-ID: <20190924152337.GE11819@quack2.suse.cz> References: <20190829131034.10563-1-jack@suse.cz> <20190829131034.10563-4-jack@suse.cz> <20190829155204.GD5354@magnolia> <20190830152449.GA25069@quack2.suse.cz> <20190918123123.GC31891@quack2.suse.cz> <53b7b7b9-7ada-650c-0a32-291a242601f3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53b7b7b9-7ada-650c-0a32-291a242601f3@gmail.com> 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 23-09-19 15:33:05, Boaz Harrosh wrote: > On 18/09/2019 15:31, Jan Kara wrote: > <> > >>> Is there a test on xfstests to demonstrate this race? > >> > >> No, but I can try to create one. > > > > I was experimenting with this but I could not reproduce the issue in my > > test VM without inserting artificial delay at appropriate place... So I > > don't think there's much point in the fstest for this. > > > > Honza > > > > If I understand correctly you will need threads that direct-write > files, then fadvise(WILL_NEED) - in parallel to truncate (punch_hole) these > files - In parallel to trash caches. > (Direct-write is so data is not present in cache when you come to WILL_NEED > it into the cache, otherwise the xfs b-trees are not exercised. Or are you > more worried about the page_cache races? > ) What I was testing was: Fill file with data. One process does fadvise(WILLNEED) block by block from end of the file. Another process punches hole into the file. If they race is the right way, following read will show old data instead of zeros. And as I said I'm able to hit this but only if I add artificial delay between truncating page cache and actually removing blocks. Honza -- Jan Kara SUSE Labs, CR