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 D93E5C433EF for ; Sat, 21 May 2022 15:24:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 28D3B6B0072; Sat, 21 May 2022 11:24:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 23BF76B0073; Sat, 21 May 2022 11:24:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DE6C6B0074; Sat, 21 May 2022 11:24:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id F24586B0072 for ; Sat, 21 May 2022 11:24:04 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id CB1856074F for ; Sat, 21 May 2022 15:24:04 +0000 (UTC) X-FDA: 79490120808.23.ABE8A10 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by imf15.hostedemail.com (Postfix) with ESMTP id C06A5A00D8 for ; Sat, 21 May 2022 15:23:46 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id u15so10011259pfi.3 for ; Sat, 21 May 2022 08:24:04 -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:content-transfer-encoding:in-reply-to; bh=8YvF0KYGyvLD152mJvK3OUAMYa/Ocvv7YJlQJIs4ik8=; b=af9MHzJRzmze6ujHO9brZL+H2NvNqfPjqLGqWgliNVyc/E9oPF/5W9kG/ljuSr6yn/ 8l5qEuhbR5QE2k0HzmVYryCqIel/mV+KgizRZyjM2C1LULQ/YI+mUAEFsDf1UIghLb8i GhTUpatcUxKWeDvzzrYwNutQ+ewV2LdOdwe/UgOwTMmlWCOWnh+G0NOgNo7FNc4WLJLQ 2Sb1O+kOFV0vfADqaU31XJFRSwa5tUdR7gDEvzdDU0t1hJjBWrB0Xjr5wCLr6c5iRusW 1aY79RK3M7UCPBf9CP3Iak9CF37XFO3guCH5mjVbxN22cqkgVCSj+PZr22JGeiZGd7wZ arsA== 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 :content-transfer-encoding:in-reply-to; bh=8YvF0KYGyvLD152mJvK3OUAMYa/Ocvv7YJlQJIs4ik8=; b=lPy7ZoQBgEkvvvc33NHhLNxxi6j8Z+sSlpMdecl0MCq3YK/MEoo9L6oTHO1b/eBbmQ s77cePJBwlsVgjxPoSPRG+LvxtI0g1RYUmYAY/ZgmrN3l88LHofbsMg4l45o0D/Jzmj3 x62+wyeZ1on5k+B44HqRFR/Z4kBRgrlxPioD0g7Q9FLb67Sydt1kbPlBIDHsQjbbFeqt KAoVOOjWnlZvvpYDlZWcnlPM+JBrAVn1av/qNQKB96oKLpgkOajWDqLVQiM5fGjgY4xK kC4eJexIIHdSB6i923BA4V9uKcJyaQx1TaXR8QVIX4QkMLooxFpIIFeGWDVQ9bOsSWtq DR9A== X-Gm-Message-State: AOAM532kWRB/1kccvMNIz1jQQTJHXu2qkdkNJZ5aoG7VdWmJd7rtDY2K H9nFGxSOuVI/9VKuk8a5FbE= X-Google-Smtp-Source: ABdhPJw6PqHysQWzfQL5PnhngJIzNIKSlfaYQM0thj7WAe4NVqMIp1iKtNDDFJ6EAOIlKv169VylHQ== X-Received: by 2002:a63:600c:0:b0:3f9:f4c8:e862 with SMTP id u12-20020a63600c000000b003f9f4c8e862mr2324765pgb.131.1653146642845; Sat, 21 May 2022 08:24:02 -0700 (PDT) Received: from google.com ([2620:15c:211:201:ef57:ac0e:cc3e:9974]) by smtp.gmail.com with ESMTPSA id t4-20020a654084000000b003f6ba49bc57sm1675852pgp.71.2022.05.21.08.24.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 21 May 2022 08:24:02 -0700 (PDT) Date: Sat, 21 May 2022 08:24:00 -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: <4809b134-a37a-50b8-4c25-44548bc1048f@nvidia.com> <6d281052-485c-5e17-4f1c-ef5689831450@oracle.com> <0be9132d-a928-9ebe-a9cf-6d140b907d59@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: C06A5A00D8 X-Stat-Signature: fwm7ur4qcyrbdrxc5xc1k5564ntm1tpd X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=af9MHzJR; spf=pass (imf15.hostedemail.com: domain of minchan.kim@gmail.com designates 209.85.210.169 as permitted sender) smtp.mailfrom=minchan.kim@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-HE-Tag: 1653146626-323749 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 Fri, May 20, 2022 at 05:04:22PM -0700, Mike Kravetz wrote: > On 5/20/22 16:43, Minchan Kim wrote: > > On Fri, May 20, 2022 at 04:31:31PM -0700, Mike Kravetz wrote: > >> On 5/20/22 15:56, John Hubbard wrote: > >>> On 5/20/22 15:19, Minchan Kim wrote: > >>>> 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). > >>>> > >>> > >>> From Mike's comments and yours, plus a rather quick reading of some > >>> CMA-related code in mm/hugetlb.c (free_gigantic_page(), alloc_gigantic_pages()), the following seems true: > >>> > >>> a) hugetlbfs can allocate pages *from* CMA, via cma_alloc() > >>> > >>> b) while hugetlbfs is using those CMA-allocated pages, it is debatable > >>> whether those pages should be allowed to be long term pinned. That's > >>> because there are two cases: > >>> > >>>     Case 1: pages are longterm pinned, then released, all while > >>>             owned by hugetlbfs. No problem. > >>> > >>>     Case 2: pages are longterm pinned, but then hugetlbfs releases the > >>>             pages entirely (via unmounting hugetlbfs, I presume). In > >>>             this case, we now have CMA page that are long-term pinned, > >>>             and that's the state we want to avoid. > >> > >> I do not think case 2 can happen. A hugetlb page can only be changed back > >> to 'normal' (buddy) pages when ref count goes to zero. > >> > >> It should also be noted that hugetlb code sets up the CMA area from which > >> hugetlb pages can be allocated. This area is never unreserved/freed. > >> > >> I do not think there is a reason to disallow long term pinning of hugetlb > >> pages allocated from THE hugetlb CMA area. > >> > >> But, I wonder if it is possible for hugetlb pages to be allocated from > >> another (non-hugetlb) area. For example if someone sets up a huge CMA area > >> and hugetlb allocations spill over into that area. If this is possible > >> (still need to research), then we would not want to long term pin such > >> hugetlb pages. We can check this in the hugetlb code to determine if > >> long term pinning is allowed. > > > > I don't think it's possible because cma_alloc needs "struct cma" just > > like handle and VM doesn't maintain any fallback list of cma chains > > so unless someone could steal the handle somehow, there is no way to > > claim memory others reserved for the CMA purpose. > > I was thinking about the case where a hugetlb page is allocated via > __alloc_pages(). Not sure if that can fall back to a CMA area that > someone else might have created/reserved. > > Unless I do not understand, normal movable memory allocations can fall > back to CMA areas? In the case, Yes, it would be fallback if gfp_flag was __GFP_MOVABLE. If HugeTLB support it(I think so), pin_user_pages with FOLL_LONGTERM will migrate the page out of movable/CMA before the longterm pinning so IMHO, we shouldn't have the problem. __gup_longterm_locked __get_user_pages_locked check_and_migrate_movable_pages > -- > Mike Kravetz