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=-14.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL 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 75096C433ED for ; Thu, 22 Apr 2021 20:46:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DD77461421 for ; Thu, 22 Apr 2021 20:46:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DD77461421 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3DD848E0003; Thu, 22 Apr 2021 16:46:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3664F8E0001; Thu, 22 Apr 2021 16:46:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E1278E0003; Thu, 22 Apr 2021 16:46:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id EBDFB8E0001 for ; Thu, 22 Apr 2021 16:46:46 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 9B61B181FFCA7 for ; Thu, 22 Apr 2021 20:46:46 +0000 (UTC) X-FDA: 78061186812.11.770BDC7 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf21.hostedemail.com (Postfix) with ESMTP id 7B1CFE00011A for ; Thu, 22 Apr 2021 20:46:43 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id e13so37905055qkl.6 for ; Thu, 22 Apr 2021 13:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=q4jCK/oxeOAevJ+QQnM3lBiBwG2OGtnOoyI45WiPj/0=; b=bm4tK+1+ztG0fhpXNYfdvm16338ubpObJL9yXAF6z5QbYek+XJkIPN5icxfAhQHZa9 5vHU3s4lI+K4LhMXS4o7k/nfFp4h1T2D/2idlxRt2E+KH+8MEGjnqj6WbRW/Occrn1ub GMWABtxA3Qa0pH+5bHwmHxHV0ytVM5PRa+hCytRC60NI1y2hUOh7ieNd8+12D82HvYI5 pTvN2mA66wfz1vd/dws+vtpU3kad6SV58lBRADz1VW6ZlvOvb8n4NfQv/NWfbrGmF8zN oD/0RCCjhIsKhandoRbU8KeYRvL+FzxbFIC6PK27w2Mg/ng/a/zrM37IDErgPKI7m1v0 /uOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=q4jCK/oxeOAevJ+QQnM3lBiBwG2OGtnOoyI45WiPj/0=; b=sdzxphkr7g5z4VwEkwM13VyYg6sdZiWExQIY0rx2xnbBIHIfuPllH/g49ihrUv7/fd oCXGCMAxEpoNwq5Jq7MDtlwZdSpO5qvU3kKZXrVt7l3vMH2ww5UvXjVBhQAKAXI5oCr+ VvXer4+GkvDP1d+bab48VMJK/ZKhHELJrLvt5jfHbFl3CTpL5VMoG2RrlHLSnaJrYnE5 jX8+IfuKpKwQ5E90OnQnhatZ4et4dvqQK1On+kVGkyG3wxw0TiECtwJjOAbxu4YJD9MR U2NKItwXwUIxqZg/Nn9E8viAmUzpRhaHi4aOeEWny1vigeankDWynaUaekR/OYIrFwU8 9/aA== X-Gm-Message-State: AOAM531zD/RTq86K9OBDqkzNnMWNLxsG20A4ShqQkXouZZrzOqeE2Xha CD1wte0tQUDBih97LM5AQD/xDQ== X-Google-Smtp-Source: ABdhPJy6B2uOuY8nlYlMlbZzimxyQS3rpI5s21XxaofwWAhrWMOPI3vCjUBaibuvfPrpBMjoQH4Omg== X-Received: by 2002:a37:b103:: with SMTP id a3mr652299qkf.261.1619124405346; Thu, 22 Apr 2021 13:46:45 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id m124sm2975451qkc.70.2021.04.22.13.46.43 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Thu, 22 Apr 2021 13:46:45 -0700 (PDT) Date: Thu, 22 Apr 2021 13:46:34 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: Andrew Morton , Hugh Dickins , William Kucharski , Christoph Hellwig , Jan Kara , Dave Chinner , Johannes Weiner , "Kirill A. Shutemov" , Yang Shi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 2/2] mm/filemap: fix mapping_seek_hole_data on THP & 32-bit In-Reply-To: Message-ID: References: <20210422011631.GL3596236@casper.infradead.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Stat-Signature: 78nx47ow9y4strgxyhiyn9j1pmss4k45 X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7B1CFE00011A Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf21; identity=mailfrom; envelope-from=""; helo=mail-qk1-f179.google.com; client-ip=209.85.222.179 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1619124403-326714 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 Wed, 21 Apr 2021, Hugh Dickins wrote: > On Thu, 22 Apr 2021, Matthew Wilcox wrote: > > On Wed, Apr 21, 2021 at 05:39:14PM -0700, Hugh Dickins wrote: > > > No problem on 64-bit without huge pages, but xfstests generic/285 > > > and other SEEK_HOLE/SEEK_DATA tests have regressed on huge tmpfs, > > > and on 32-bit architectures, with the new mapping_seek_hole_data(). > > > Several different bugs turned out to need fixing. > > > > > > u64 casts added to stop unfortunate sign-extension when shifting > > > (and let's use shifts throughout, rather than mixed with * and /). > > > > That confuses me. loff_t is a signed long long, but it can't be negative > > (... right?) So how does casting it to an u64 before dividing by > > PAGE_SIZE help? > > That is a good question. Sprinkling u64s was the first thing I tried, > and I'd swear that it made a good difference at the time; but perhaps > that was all down to just the one on xas.xa_index << PAGE_SHIFT. Or > is it possible that one of the other bugs led to a negative loff_t, > and the casts got better behaviour out of that? Doubtful. > > What I certainly recall from yesterday was leaving out one (which?) > of the casts as unnecessary, and wasting quite a bit of time until I > put it back in. Did I really choose precisely the only one necessary? > > Taking most of them out did give me good quick runs just now: I'll > go over them again and try full runs on all machines. You'll think me > crazy, but yesterday's experience leaves me reluctant to change without > full testing - but agree it's not good to leave ignorant magic in. And you'll be unsurprised to hear that the test runs went fine, with all but one of those u64 casts removed. And I did locate the version of filemap.c where I'd left out one "unnecessary" cast: I had indeed chosen to remove the only one that's necessary. v2 coming up now, thanks, Hugh