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 25BE6C7EE2E for ; Mon, 12 Jun 2023 17:41:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8FED38E0003; Mon, 12 Jun 2023 13:41:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8AE728E0002; Mon, 12 Jun 2023 13:41:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 79DB38E0003; Mon, 12 Jun 2023 13:41:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6B12E8E0002 for ; Mon, 12 Jun 2023 13:41:49 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 21839A02D0 for ; Mon, 12 Jun 2023 17:41:49 +0000 (UTC) X-FDA: 80894813538.22.D71DA09 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id CF9871C000C for ; Mon, 12 Jun 2023 17:41:46 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ouxD9IGf; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686591707; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sNl+hcryem5Y2/j0f2cuNCgFGRudQH14t8rQ8cm/MbI=; b=DltpinbgJA3oPPTb4Oa1B+zSUp/mYRI1/FXvyVK0YOBMkdBXnAy309z7mpvku89dH9kRwF O8aXhHoILtq4kI1MKjqYtFRqJvzo+00sAi6R7vNxVWBjON0zYLk7Fp8zas78V1l48245bZ gSPn4zPnydfhASfSuWfSreWXbJFzzP0= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=ouxD9IGf; dmarc=none; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686591707; a=rsa-sha256; cv=none; b=sBI8TFCbxneFFIpH5/eC4SbQHmiAQ1ah03DaCxiNT3AtVhJQUcZ9YDP762Tuz1Aqc7Muh2 jbg8O6zuskXnxYmI+xB9727PKHnsOb8o9E+gPhK5urcidY+pXnrK4FBy5VzUSCsCQbsoyX 9uXnre8CqBfmbCdnKJqn7ClMrwXIvyE= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sNl+hcryem5Y2/j0f2cuNCgFGRudQH14t8rQ8cm/MbI=; b=ouxD9IGfTfZnLyn9OTfUsnd8nV ikl5mOZEPvINin0YG/uuz8Vmd3EmL3v2JrtasamcPwgkgZZK/lk3QLAq2qvnJYvNLweiZv4wa70yf U/1hkqg9xQDVeMIRJdSCNc3p4etLodMrI93p263iJ19Qtn7F/0C4yIK/3v9lSmNT0TVV3+KgBCBuy DDmexoIeChjyIrP81oD4HDoQogjvxhX9DZ+jEnZPpNhqauI2l7fswV5JUFMNHugWFh+MyHHTdxWL4 A21JLUyH1UmN9jwKXSPBpnCH17v4bdGh4xIn6Jc684SEL/UvxfQZxJyyIohyhubr7uhEwvhD9NDyi VYdTM8CQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1q8lXp-002sqC-KJ; Mon, 12 Jun 2023 17:41:33 +0000 Date: Mon, 12 Jun 2023 18:41:33 +0100 From: Matthew Wilcox To: Sidhartha Kumar Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, songmuchun@bytedance.com, mike.kravetz@oracle.com, almasrymina@google.com, linmiaohe@huawei.com, minhquangbui99@gmail.com, aneesh.kumar@linux.ibm.com Subject: Re: [PATCH v2 5/9] mm/hugetlb: convert isolate_or_dissolve_huge_page to folios Message-ID: References: <20221101223059.460937-1-sidhartha.kumar@oracle.com> <20221101223059.460937-6-sidhartha.kumar@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221101223059.460937-6-sidhartha.kumar@oracle.com> X-Rspamd-Queue-Id: CF9871C000C X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: kk6599w67wun3ims4wcydw9xbu7q69g7 X-HE-Tag: 1686591706-125074 X-HE-Meta: U2FsdGVkX18ZJYjBeqQrwKHCpkldB9qBfeJAfceSXfKV1xKmmgPlY3h6GlUl5iGw52CsNRIDrmNt0KxHkEgcwTcm45YiccP070QbpeSFtGLQ+iE1RIfZM1NoCdk0EI7PSRc08KemhtwETfeM0m/b6TeAWOXPzaSvoWZq6BieSckuwNz7Q5cMmMKXZkLUlTelyZVXD0kANE4/RwKoKnnrE2R68ydB9QPhSQncPxEEVD7gxprB2orPqwNNJf7HLwzun9VgtoQ6wUkudTHugr8uJtdxk+w3H5Zf5q8NeVF/PIo+XuIb1Sjxw1MeAnDoxnguul5vK8v7kEtJZ1jSeQCyLZrJjdadWkGmfzuhak0QZL9j25E8KI1XwLTev95bD6da2F0Efow/jqezW/NQwDvYo5HpCNe8pnCdBs5YmIFsStpg7CkozRzZ5yGOOhBwU/JRdrZ70QgWdINDAUtMPFaOVlvFHpGAxm8Xq4iVC4lIUnYdO0y5lzrlfjUuB+VuTHbq8AboeGreot62d+hz/lb+L2afYfMpmj9A1DT5Sw/T2X1PVgfaalRl5Ln1989z1BY5kKxgaSNvNjiZp3vpcSh+5EflrvbV9drC5MUH8arBTkSWgie8//eVJdkGgwBLElewEF0P3gby6MYOcHtb9o3w1kuOOtL7/vAFp/caPrJlLQcM9Byz35d9F8n9Mx9Mw1ZsAudnpcMY3TRVGiySx+YKOFcvx4OvrUZW9+acSfgz+ZLMiJea8dqvtR0mobG1Sqg2UFigJM2uGrAayVl4WnDHSKEG4JhemGsuxrq4yXsiAHAYRM36IFcD1dJzJJ9wc7bxM3MLh52re4OlJt3EhVTBD53KmWluETShkGA4GNAiS7SCqQ/W4oANkaDehJCsZxPULSw7On2j9ZaSns3TroforiVxmVTAjm1nL4rObzTPEphtYMUPk8+yI21lNu25qEpxkQ7qjqi4kRb24cKJbFP SuU3qeA7 WcVp8a6N3YJTbKUq3YD6mbcVAXeDt1hpbVGhRcxhcDZYyym3PfdHoJmvwvpeURm7OHlBn7+YkXABUH42f50oZ83VSVLUSgy4XV9GiGFIk7pLTaH3sjmWY6qA+hoIb0EyyUKTHGaWjOyq/x9Pf1ifeH+HwcMNSpF0DizMY9FB4qzX2cz7DOTv5cvYvIA== 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 Tue, Nov 01, 2022 at 03:30:55PM -0700, Sidhartha Kumar wrote: > +++ b/mm/hugetlb.c > @@ -2815,7 +2815,7 @@ static int alloc_and_dissolve_huge_page(struct hstate *h, struct page *old_page, > int isolate_or_dissolve_huge_page(struct page *page, struct list_head *list) > { > struct hstate *h; > - struct page *head; > + struct folio *folio = page_folio(page); Is this safe? I was reviewing a different patch today, and I spotted this. With THP, we can relatively easily hit this case: struct page points to a page with pfn 0x40305, in a folio of order 2. We call page_folio() on it and the resulting pointer is for the folio with pfn 0x40304. If we don't have our own refcount (or some other protection ...) against freeing, the folio can now be freed and reallocated. Say it's now part of an order-3 folio. Our 'folio' pointer is now actually a pointer to a tail page, and we have various assertions that a folio pointer doesn't point to a tail page, so they trigger. It seems to me that this ... /* * The page might have been dissolved from under our feet, so make sure * to carefully check the state under the lock. * Return success when racing as if we dissolved the page ourselves. */ spin_lock_irq(&hugetlb_lock); if (folio_test_hugetlb(folio)) { h = folio_hstate(folio); } else { spin_unlock_irq(&hugetlb_lock); return 0; } implies that we don't have our own reference on the folio, so we might find a situation where the folio pointer we have is no longer a folio pointer. Maybe the page_folio() call should be moved inside the hugetlb_lock protection? Is that enough? I don't know enough about how hugetlb pages are split, freed & allocated to know what's going on. But then we _drop_ the lock, and keep referring to ... > @@ -2841,10 +2840,10 @@ int isolate_or_dissolve_huge_page(struct page *page, struct list_head *list) > if (hstate_is_gigantic(h)) > return -ENOMEM; > > - if (page_count(head) && !isolate_hugetlb(head, list)) > + if (folio_ref_count(folio) && !isolate_hugetlb(&folio->page, list)) > ret = 0; > - else if (!page_count(head)) > - ret = alloc_and_dissolve_huge_page(h, head, list); > + else if (!folio_ref_count(folio)) > + ret = alloc_and_dissolve_huge_page(h, &folio->page, list); And I fall back to saying "I don't know enough to know if this is safe".