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 E56E3C43334 for ; Tue, 21 Jun 2022 08:02:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7FB9A6B0072; Tue, 21 Jun 2022 04:02:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7852D6B0073; Tue, 21 Jun 2022 04:02:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5FD508E0001; Tue, 21 Jun 2022 04:02:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4B1D36B0072 for ; Tue, 21 Jun 2022 04:02:05 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9E3C4210F2 for ; Tue, 21 Jun 2022 08:02:04 +0000 (UTC) X-FDA: 79601499768.05.504B810 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id 37FF3400AE for ; Tue, 21 Jun 2022 08:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655798523; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=odfmvDZicXBGV9BNCqYRut3jKMvFr9kgGN63h8//0S8=; b=WatGbo4idTqksvEGcW55igbCHB0FQshxH3irRGdg4aYuHHUxZQTY+NU6mQF9dr7Z370qiB 5u2JkpoIStz5hkfVuxlQwWahwC+iCkMNiJUyPwVO7iTOCHK84951sY9hwJ5D/2P4cIkxjI RswoRrPUEywl58Jv41JFtefwRnsas5o= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-616-1MT-u8vcNY2e54IcbZb6KA-1; Tue, 21 Jun 2022 04:01:58 -0400 X-MC-Unique: 1MT-u8vcNY2e54IcbZb6KA-1 Received: by mail-wr1-f72.google.com with SMTP id j14-20020adfa54e000000b0021b8c8204easo1619447wrb.0 for ; Tue, 21 Jun 2022 01:01:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=odfmvDZicXBGV9BNCqYRut3jKMvFr9kgGN63h8//0S8=; b=iGQ3Cs2XmRZqu2rqsj4BCr0a5Ip148ZXgRdWf7B5LKecUc6x5BiuS/DXGi6fCdOjJI Wdl29LAuQFsY8iFmAZMpuYpe38boovm8JbAo7JOBnbaQUPqoJEOsd/P6u+FgELinUHnz tJUHZyzBMnlW4c34CLUdOJz97Ooqp14x4LFYQGGGzsVJ3xpzVtC+PhCvnnqK4PfSVc+B dN1iyxnKC5V7AFvDaG21+IeZWqfi6UovmEjXxdAyFY88M3KU0sIrnYH0Re2HUwGDlMmK T4+ixqv41YoSHrSxdSUkADzbyPyyIPPybUXS3h3bVNLlzFfMrcQ2wtJkY6Ps3PVbtida MUcw== X-Gm-Message-State: AJIora8b7zMqZw9hdN/Zl1CNhRiRt47lCjb3gZ9P18gJSJVJAiGYY1Ep OOBtmoGV7c5ZqFZuTqEKEHUkiDhxMThcANHIcTGN88ld2kDwDdZ41oGOJnwzLDC1D//Q4w7VssU 8QOY7vbDT0CE= X-Received: by 2002:adf:dc09:0:b0:218:5f6a:f5db with SMTP id t9-20020adfdc09000000b002185f6af5dbmr26665209wri.480.1655798517535; Tue, 21 Jun 2022 01:01:57 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vZNwW8e6Rj6IHQIbhTyUdMFDurbwBo3yfnFs1OTbM2oN9e4yp1wELe2N9RSD7BZybV8QmNuA== X-Received: by 2002:adf:dc09:0:b0:218:5f6a:f5db with SMTP id t9-20020adfdc09000000b002185f6af5dbmr26665186wri.480.1655798517242; Tue, 21 Jun 2022 01:01:57 -0700 (PDT) Received: from ?IPV6:2003:d8:2f04:2500:cdb0:9b78:d423:43f? (p200300d82f042500cdb09b78d423043f.dip0.t-ipconnect.de. [2003:d8:2f04:2500:cdb0:9b78:d423:43f]) by smtp.gmail.com with ESMTPSA id y12-20020adff6cc000000b0021126891b05sm14987265wrp.61.2022.06.21.01.01.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jun 2022 01:01:56 -0700 (PDT) Message-ID: Date: Tue, 21 Jun 2022 10:01:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH] mm: fixup validation of buddy pfn To: Xianting Tian , akpm@linux-foundation.org, ziy@nvidia.com Cc: guoren@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220621031118.3650529-1-xianting.tian@linux.alibaba.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220621031118.3650529-1-xianting.tian@linux.alibaba.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655798524; a=rsa-sha256; cv=none; b=Kx/Vg2mTur+a8qf8gSHhKFJPMqRN2vLoOHwPjM70pOy5N7UuU50HgHE/l4v7dFnnrkDb6o ORUONzyHNYLWRekzel9LjSPD/6mznjVTOYNqMEkBOgFik95wc1bEVcnA1XAzXCntrobs6z z0dISWbIrVthDnhXXpan1el84W0/wcw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655798524; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=odfmvDZicXBGV9BNCqYRut3jKMvFr9kgGN63h8//0S8=; b=TCdKycKN03uF8q4lJdvn4+QIrU/rpeGML9kjzrzNz7TG+gSf1FLDN+fijxDcXJYSE17oON NAFTxSxiCux/8h+D7FCT8H0NhHgpohC5nIzdmGbRh9I8OTyMeYq84f3Wq/CccRhRad9NYb HHzkSWo4R2/QPglIMy2l0eWvhqNFgj4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WatGbo4i; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WatGbo4i; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf17.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 37FF3400AE X-Stat-Signature: cgzpbht53nbcwugiuubxigntrreat59s X-HE-Tag: 1655798524-105359 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 21.06.22 05:11, Xianting Tian wrote: > For RISC-V arch the first 2MB RAM could be reserved for opensbi, > and the arch code may don't create pages for the first 2MB RAM, > so it would have pfn_base=512 and mem_map began with 512th PFN when > CONFIG_FLATMEM=y. > > But __find_buddy_pfn algorithm thinks the start PFN 0, it could get > 0 PFN or less than the pfn_base value, so page_is_buddy() can't > verify the page whose PFN is 0 ~ 511, actually we don't have valid > pages for PFN 0 ~ 511. > > Actually, buddy system should not assume Arch cretaed pages for > reserved memory, Arch may don't know the implied limitation. Ehm, sorry, no. Archs have to stick to the rules of the buddy, not the other way around. Why should we add additional overhead to the buddy just because arch XYZ wants to be special? If at all, we should fail hard if an arch doesn't play with the rules and make this a VM_BUG_ON(). > With this patch, we can gurantee a valid buddy no matter what we > have pages for reserved memory or not. > > Fixes: 8170ac4700d26f65 ("mm: wrap __find_buddy_pfn() with a necessary buddy page validation") > Signed-off-by: Xianting Tian > --- > mm/internal.h | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/mm/internal.h b/mm/internal.h > index c0f8fbe0445b..0ec446caeb2e 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -322,7 +322,8 @@ __find_buddy_pfn(unsigned long page_pfn, unsigned int order) > * The found buddy can be a non PageBuddy, out of @page's zone, or its order is > * not the same as @page. The validation is necessary before use it. > * > - * Return: the found buddy page or NULL if not found. > + * Return: the found buddy page or NULL if not found or NULL if buddy pfn is > + * not valid. > */ > static inline struct page *find_buddy_page_pfn(struct page *page, > unsigned long pfn, unsigned int order, unsigned long *buddy_pfn) > @@ -330,6 +331,9 @@ static inline struct page *find_buddy_page_pfn(struct page *page, > unsigned long __buddy_pfn = __find_buddy_pfn(pfn, order); > struct page *buddy; > > + if (!pfn_valid(__buddy_pfn)) > + return NULL; > + > buddy = page + (__buddy_pfn - pfn); > if (buddy_pfn) > *buddy_pfn = __buddy_pfn; -- Thanks, David / dhildenb