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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5047EC433F5 for ; Fri, 24 Sep 2021 21:31:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B9C2A60F6D for ; Fri, 24 Sep 2021 21:31:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B9C2A60F6D Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 449146B0071; Fri, 24 Sep 2021 17:31:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F74F900002; Fri, 24 Sep 2021 17:31:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E60E6B0073; Fri, 24 Sep 2021 17:31:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 1C4966B0071 for ; Fri, 24 Sep 2021 17:31:43 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id C963730C7E for ; Fri, 24 Sep 2021 21:31:42 +0000 (UTC) X-FDA: 78623764044.05.A6D2E92 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by imf23.hostedemail.com (Postfix) with ESMTP id 807B890000AC for ; Fri, 24 Sep 2021 21:31:42 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id v10so16238576oic.12 for ; Fri, 24 Sep 2021 14:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version; bh=4tvahGfU7bi3KWoSnewxgiaf6DUj4AvCMOuBOdPy8Fs=; b=HO0E1PSRkatDJSpPLuGyHBzpfTv74fYTX3Agj8a67YOlcIIMKwMBJuNoZwkb8vu6UZ YvmCx3KFPp+tZJtWCaqnfvkeVmnsdZDVPNMQp94ps6aGgx7pBLXzJ6SfjkGWFkn5cMZK /o5tGVUTbVH/jXBMGYm4TWd2Qy2pwCy7BQnj5ARdA2msyGUm4AFdbMaS3RQlowhzKNRd fXadoIU9Vdy+VAOx8IlgxUy7TKVIiIZhL+3p0rqf/1+QJp+4G5DDxN0NapMeBP10Bai6 jLUypwix87Hd548u/DXIyGvsLzdflGeLeq9Rv5Iz/kaphB5eRSyNvzdP6aXKAwVjAKgD eVTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version; bh=4tvahGfU7bi3KWoSnewxgiaf6DUj4AvCMOuBOdPy8Fs=; b=JAisqlwTc9LKmXqa5mdeqLo2h3/3nZeFHtamw8jF83+aGhM0MKBTtFBetdnaNjXW7R 7tww4Qjga902icgIL634VZd4LduTrP/9Q4lSZadzBvjDDndBBnlDqs4OPNiga9X32M/I WL9R6B91lZRoZgZwJ9pfcd+lN0GIrMH29yoooi4o4KhX7zygNTbAPjyKGnujXvwQfOHw 5dyTjcvddCc79BIoO2VVmfxTR/rKFZglqVFZSz15+YSbjNDobanfgWbiDr5Ohz2NFqXo 3LUlnnXfE3xMMzJgawU0LxA3kXNZuUJwVp6YFBK1pdYLhcEAoyHIibxb649dIFMzyQ2/ /SFA== X-Gm-Message-State: AOAM531qz5TvNFSbLQWj7K79oIRQQf4vYjJz68pRcoaDHgOhawkNBlhb h8YnqN6YRvyoaT+NWOeELa7XRQ== X-Google-Smtp-Source: ABdhPJygS8JzZ4K3yFR3BhQbu1otgYVr7A9q2WBnn4X/dqFAD7UX6izpjsBbB9IanPoiUJHUHDGsNw== X-Received: by 2002:aca:f143:: with SMTP id p64mr3266120oih.161.1632519101628; Fri, 24 Sep 2021 14:31:41 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id r18sm2394632ooc.27.2021.09.24.14.31.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Sep 2021 14:31:41 -0700 (PDT) Date: Fri, 24 Sep 2021 14:31:29 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.anvils To: Liu Yuntao cc: kirill@shutemov.name, akpm@linux-foundation.org, hughd@google.com, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, liusirui@huawei.com, windspectator@gmail.com, wuxu.wu@huawei.com Subject: Re: [PATCH v2] fix judgment error in shmem_is_huge() In-Reply-To: <20210909032007.18353-1-liuyuntao10@huawei.com> Message-ID: <8a5bc69-193e-9b4a-2161-b03b69eebed2@google.com> References: <20210909032007.18353-1-liuyuntao10@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 807B890000AC X-Stat-Signature: k15xr7sg6omajw44u7g3cm9ppi8jqze9 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=HO0E1PSR; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of hughd@google.com designates 209.85.167.172 as permitted sender) smtp.mailfrom=hughd@google.com X-HE-Tag: 1632519102-909216 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 Thu, 9 Sep 2021, Liu Yuntao wrote: > In the case of SHMEM_HUGE_WITHIN_SIZE, the page index is not rounded > up correctly. When the page index points to the first page in a huge > page, round_up() cannot bring it to the end of the huge page, but > to the end of the previous one. > > an example: > HPAGE_PMD_NR on my machine is 512(2 MB huge page size). > After allcoating a 3000 KB buffer, I access it at location 2050 KB. Your example is certainly helpful, but weird! It's not impossible, but wouldn't it be easier to understand if you said "2048 KB" there? > In shmem_is_huge(), the corresponding index happens to be 512. > After rounded up by HPAGE_PMD_NR, it will still be 512 which is > smaller than i_size, and shmem_is_huge() will return true. > As a result, my buffer takes an additional huge page, and that > shouldn't happen when shmem_enabled is set to within_size. A colleague very recently opened my eyes to within_size on shmem_enabled: I've always been dubious of both, but they can work quite well together. > > Fixes: f3f0e1d2150b2b ("khugepaged: add support of collapse for tmpfs/shmem pages") > Signed-off-by: Liu Yuntao Thanks, with a nice simplification from Kirill. Acked-by: Hugh Dickins Ignore the comment I've added below - it's not worth worrying about. > --- > V1->V2: > add simplification of the condition after round_up() > --- > mm/shmem.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/mm/shmem.c b/mm/shmem.c > index 88742953532c..b5860f4a2738 100644 > --- a/mm/shmem.c > +++ b/mm/shmem.c > @@ -490,9 +490,9 @@ bool shmem_is_huge(struct vm_area_struct *vma, > case SHMEM_HUGE_ALWAYS: > return true; > case SHMEM_HUGE_WITHIN_SIZE: > - index = round_up(index, HPAGE_PMD_NR); > + index = round_up(index + 1, HPAGE_PMD_NR); Even without your change, I notice now that there's a possibility of index wrapping to 0 on 32-bit architecture here. But nothing goes terribly wrong in that case: it is not worth worrying about here. > i_size = round_up(i_size_read(inode), PAGE_SIZE); > - if (i_size >= HPAGE_PMD_SIZE && (i_size >> PAGE_SHIFT) >= index) > + if (i_size >> PAGE_SHIFT >= index) > return true; > fallthrough; > case SHMEM_HUGE_ADVISE: > -- > 2.23.0