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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F1B1C433F5 for ; Fri, 20 May 2022 22:19:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C162A6B0071; Fri, 20 May 2022 18:19:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BC4DD6B0072; Fri, 20 May 2022 18:19:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A66226B0073; Fri, 20 May 2022 18:19:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 949AA6B0071 for ; Fri, 20 May 2022 18:19:37 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 6F91831FDD for ; Fri, 20 May 2022 22:19:37 +0000 (UTC) X-FDA: 79487539194.24.05028AC Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf16.hostedemail.com (Postfix) with ESMTP id 61430180013 for ; Fri, 20 May 2022 22:19:24 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id c22so8846865pgu.2 for ; Fri, 20 May 2022 15:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=FJNM+SC0IIR+V8IbK3b8r/wd9vAA7Bdywff6gYSjtWo=; b=IAMIx2qmVQETKVtS+eBPNuWm9U9fFHmsYSExLr6IDKzceYJaksMhXffQk2IE+D7NiL wmXbzFxZLiUuy9QVTOWQm9RG3+vPowUfkO9qbhQkYe1LFO7/i674voMBdNYzc21ydd9y VbiCumoURfE5ioRSP3xY/gRPs5tCVwCgx8zwwAXczAzxev5vsydhEms8X+dpn2BRvqM/ nB23BMg4wyRlDNWhslbqYT0UF4PPu8Fj2YiPgxdXX+ywqOhhjIYg5msgduqq+0MkKevb 5+t+n+gaaYno1lbeY08X7cOYSAlFJqtvx+aLNBc/LWV208pz0X9JKLYdd+9VtQi02Evx RwAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=FJNM+SC0IIR+V8IbK3b8r/wd9vAA7Bdywff6gYSjtWo=; b=IgBMM/sz0+v6/fq3e/HOWIKNMIOxup9XIEVpuIYusL7dh3uVuuW7MNoDR2pcCQa8CR BFFZhpdnpKioKx6WRCB6bnI22l+oBEHamtJm2UYa8F4uZGAvKGmvTAvf2eOyp+/RXmqB IUh/u1OmB+ua/jJPC2DSDGIHmcwF5s8Lx2eIErBnNcF/OcH60KfzIkULhdLBKzazd8EW m2UcE5hrjoF3koP5L+krI/iUwggwMStlOJslpYcfaXkTE7x6LyJ+rC64OEnYBH+OfJKJ gOq47pnlPOkNDnJrSvlLswrydZQt9AEyaubErMSSh/2PzmmzmhOny/Yw08J9WzfI/r++ p39w== X-Gm-Message-State: AOAM530uvc2cYpo83GJLBza4czhJFVVllavRS7uXzQL0R65/o7r1yL04 uS6IuM3MJIymFYZZLY+9sZg= X-Google-Smtp-Source: ABdhPJzTA7NI8raUHUFL9b5veywXOFMcEpgKQYOTLQnyOSWCcy0yzWIrM0H3Vl3f6/l4yp2/RT5+MA== X-Received: by 2002:a63:5c22:0:b0:3db:141c:6db2 with SMTP id q34-20020a635c22000000b003db141c6db2mr10186919pgb.198.1653085175156; Fri, 20 May 2022 15:19:35 -0700 (PDT) Received: from google.com ([2620:15c:211:201:828d:ad52:eebc:6659]) by smtp.gmail.com with ESMTPSA id q7-20020a170902edc700b0016168e90f37sm224221plk.152.2022.05.20.15.19.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 May 2022 15:19:34 -0700 (PDT) Date: Fri, 20 May 2022 15:19:32 -0700 From: Minchan Kim To: Mike Kravetz Cc: John Hubbard , Andrew Morton , syzbot , linux-kernel@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com, syzkaller-bugs@googlegroups.com, trix@redhat.com, Matthew Wilcox , Stephen Rothwell , David Hildenbrand Subject: Re: [syzbot] WARNING in follow_hugetlb_page Message-ID: References: <00000000000077377c05dee75f63@google.com> <20220513102617.c464c4f566052838e911a3ec@linux-foundation.org> <75f09063-d184-7d44-17a1-ed04be5eb953@oracle.com> <20220513161910.d1b73583cdb2e33562aa86e5@linux-foundation.org> <4809b134-a37a-50b8-4c25-44548bc1048f@nvidia.com> <6d281052-485c-5e17-4f1c-ef5689831450@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d281052-485c-5e17-4f1c-ef5689831450@oracle.com> X-Rspam-User: X-Rspamd-Queue-Id: 61430180013 X-Stat-Signature: 369f1atys8eeeyb159mkhhq6ec1m8m7z Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=IAMIx2qm; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none); spf=pass (imf16.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com X-Rspamd-Server: rspam04 X-HE-Tag: 1653085164-560950 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, May 16, 2022 at 08:37:01PM -0700, Mike Kravetz wrote: < snip > > > I need to look at this a little more closely, it is making me wonder > > whether the is_pinnable_page() check is a problem in this path. The > > comment in try_grab_folio() indicates that the early return is a hack > > (it assumes that the caller is in the gup fast path), and maybe the hack > > is just wrong here--I think we're actually on the slow gup path. Not > > good. > > > > Mike, any thoughts here? > > > > Do you know why try_grab_compound_page(now try_grab_folio) checks for > pinnable when try_grab_page does not? > > Then I guess the next question is 'Should we allow pinning of hugetlb pages > in these areas?'. My first thought would be no. But, recall it was 'allowed' > until that commit which changed try_grab_page to try_grab_compound_page. The reason we don't allow longterm pinning in CMA area is to improve big contigus memory allocation sccuess ratio when someone claim the memory space. Thus, any pages mapped at userspace given the CMA area shouldn't be pinned with longterm. Otherwise, the cma_alloc will fail due to migration failure. In hugetlb case(I might miss something..), the CMA memory was already claimed by hugeTLB and the big contiguous memory was mapped at userspace so there is no reason to prevent longterm pinning since HugeTLB will never claim those CMA memory until user release the memory and HugeTLB free the range using cma_release. > In the 'common' case of compaction, we do not attempt to migrate/move hugetlb > pages (last time I looked), so long term pinning should not be an issue. > However, for things like memory offline or alloc_contig_range() we want to The memory offline would be an issue so we shouldn't allow pinning of any pages in *movable zone*. Isn't alloc_contig_range just best effort? Then, it wouldn't be a big problem to allow pinning on those area. The matter is what target range on alloc_contig_range is backed by CMA or movable zone and usecases. IOW, movable zone should be never allowed. But CMA case, if pages are used by normal process memory instead of hugeTLB, we shouldn't allow longterm pinning since someone can claim those memory suddenly. However, we are fine to allow longterm pinning if the CMA memory already claimed and mapped at userspace(hugeTLB case IIUC). Please correct me if I miss something. Thanks.