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 5C7ABC433F5 for ; Wed, 23 Mar 2022 23:07:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB33D8D000B; Wed, 23 Mar 2022 19:07:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E620C6B0083; Wed, 23 Mar 2022 19:07:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D29EB8D000B; Wed, 23 Mar 2022 19:07:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id C55806B0082 for ; Wed, 23 Mar 2022 19:07:22 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 9071A8249980 for ; Wed, 23 Mar 2022 23:07:22 +0000 (UTC) X-FDA: 79277189124.28.B8466F1 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id C532E100032 for ; Wed, 23 Mar 2022 23:07:21 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C236FB82184; Wed, 23 Mar 2022 23:07:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5168EC340EE; Wed, 23 Mar 2022 23:07:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1648076839; bh=tl3Vpw1b/ZTsG2DUIPp96zuks4WVQhE/4KiH9Q+hMRs=; h=Date:To:From:In-Reply-To:Subject:From; b=yrBEw+g9HCY6Iwe57esN4w0xMOSqPTExvHUTm23tNESs9BU6mscjhDTkOrzkyqOsR ClIqVCC0noIAWdVvwKpnkmJWNuownN+XhuAOQ2BjcKEe8i89HvtnRbe2qdS+d9qJnk SRGIH/9+vENJn6U8YB/ZzEyqTv7U05NoOWfM3zp4= Date: Wed, 23 Mar 2022 16:07:18 -0700 To: david@redhat.com,dan.j.williams@intel.com,apopple@nvidia.com,linmiaohe@huawei.com,akpm@linux-foundation.org,patches@lists.linux.dev,linux-mm@kvack.org,mm-commits@vger.kernel.org,torvalds@linux-foundation.org,akpm@linux-foundation.org From: Andrew Morton In-Reply-To: <20220323160453.65922ced539cbf445b191555@linux-foundation.org> Subject: [patch 40/41] kernel/resource: fix kfree() of bootmem memory again Message-Id: <20220323230719.5168EC340EE@smtp.kernel.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: C532E100032 X-Stat-Signature: h8koa3diwhkz9z16nwe6mfngkjjrfzq9 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=yrBEw+g9; dmarc=none; spf=pass (imf14.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org X-Rspam-User: X-HE-Tag: 1648076841-924864 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: From: Miaohe Lin Subject: kernel/resource: fix kfree() of bootmem memory again Since commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory"), we could get a resource allocated during boot via alloc_resource(). And it's required to release the resource using free_resource(). Howerver, many people use kfree directly which will result in kernel BUG. In order to fix this without fixing every call site, just leak a couple of bytes in such corner case. Link: https://lkml.kernel.org/r/20220217083619.19305-1-linmiaohe@huawei.com Fixes: ebff7d8f270d ("mem hotunplug: fix kfree() of bootmem memory") Signed-off-by: Miaohe Lin Suggested-by: David Hildenbrand Cc: Dan Williams Cc: Alistair Popple Signed-off-by: Andrew Morton --- kernel/resource.c | 41 ++++++++--------------------------------- 1 file changed, 8 insertions(+), 33 deletions(-) --- a/kernel/resource.c~kernel-resource-fix-kfree-of-bootmem-memory-again +++ a/kernel/resource.c @@ -56,14 +56,6 @@ struct resource_constraint { static DEFINE_RWLOCK(resource_lock); -/* - * For memory hotplug, there is no way to free resource entries allocated - * by boot mem after the system is up. So for reusing the resource entry - * we need to remember the resource. - */ -static struct resource *bootmem_resource_free; -static DEFINE_SPINLOCK(bootmem_resource_lock); - static struct resource *next_resource(struct resource *p) { if (p->child) @@ -160,36 +152,19 @@ __initcall(ioresources_init); static void free_resource(struct resource *res) { - if (!res) - return; - - if (!PageSlab(virt_to_head_page(res))) { - spin_lock(&bootmem_resource_lock); - res->sibling = bootmem_resource_free; - bootmem_resource_free = res; - spin_unlock(&bootmem_resource_lock); - } else { + /** + * If the resource was allocated using memblock early during boot + * we'll leak it here: we can only return full pages back to the + * buddy and trying to be smart and reusing them eventually in + * alloc_resource() overcomplicates resource handling. + */ + if (res && PageSlab(virt_to_head_page(res))) kfree(res); - } } static struct resource *alloc_resource(gfp_t flags) { - struct resource *res = NULL; - - spin_lock(&bootmem_resource_lock); - if (bootmem_resource_free) { - res = bootmem_resource_free; - bootmem_resource_free = res->sibling; - } - spin_unlock(&bootmem_resource_lock); - - if (res) - memset(res, 0, sizeof(struct resource)); - else - res = kzalloc(sizeof(struct resource), flags); - - return res; + return kzalloc(sizeof(struct resource), flags); } /* Return the conflict entry if you can't request it */ _