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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5EFCEC433EF for ; Fri, 5 Nov 2021 10:49:57 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E4E156124A for ; Fri, 5 Nov 2021 10:49:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E4E156124A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 525B26B006C; Fri, 5 Nov 2021 06:49:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AF2A6B0071; Fri, 5 Nov 2021 06:49:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39D0B6B0073; Fri, 5 Nov 2021 06:49:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0081.hostedemail.com [216.40.44.81]) by kanga.kvack.org (Postfix) with ESMTP id 280A26B006C for ; Fri, 5 Nov 2021 06:49:56 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D4C471846CA31 for ; Fri, 5 Nov 2021 10:49:55 +0000 (UTC) X-FDA: 78774556350.06.1D8C721 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf07.hostedemail.com (Postfix) with ESMTP id 7D98610004C1 for ; Fri, 5 Nov 2021 10:49:55 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 160CF610A8; Fri, 5 Nov 2021 10:49:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636109394; bh=flL52suMqN/frqIhABji+kP/KZLf7M9LOU0RKHo6DLY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UHIkVgQ6n5Zyxz0A4kkUqNx//vww03JEjx7BVRVBn8g1SzYXC5XpSbyPhTc/6CQp4 7VvwqDdzpzd5lnQZuG1gkrjKQUw/axAdmhmkty0yFl7yf4j5fZ1+WDyQbYBQ+CR5iL uKM5GooAJ9Dk/qzcZ2aGLEpvAzSxszQO3tKsKlusWO6SZ9ay3dcZVq7BZ6YAxjKpBt Loq6f+itdJBPQRJ3z2TK7BwsVXHVaHayAVENKVzqG8b3o/UxRLB5xDvAuuRvJOlwQv OSBPYK6iOpIBiL9CWWeclndyZnEpXH7fodmG5ZzSqos+qgsxd46iR9l4dybgF4jTyU GRhROeEeCPH3g== Date: Fri, 5 Nov 2021 12:49:47 +0200 From: Mike Rapoport To: Qian Cai Cc: Catalin Marinas , Will Deacon , Andrew Morton , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: Track no early_pgtable_alloc() for kmemleak Message-ID: References: <20211104155623.11158-1-quic_qiancai@quicinc.com> <9bb6fe11-c10a-a373-9288-d44a5ba976fa@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bb6fe11-c10a-a373-9288-d44a5ba976fa@quicinc.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 7D98610004C1 X-Stat-Signature: mahqey3dndxo3z3t96q1qw133es4b1up Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UHIkVgQ6; spf=pass (imf07.hostedemail.com: domain of rppt@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1636109395-774140 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 Thu, Nov 04, 2021 at 01:57:03PM -0400, Qian Cai wrote: > > > On 11/4/21 1:06 PM, Mike Rapoport wrote: > > I think I'll be better to rename MEMBLOCK_ALLOC_KASAN to, say, > > MEMBLOCK_ALLOC_NOKMEMLEAK and use that for both KASAN and page table cases. > > Okay, that would look a bit nicer. > > > But more generally, we are going to hit this again and again. > > Couldn't we add a memblock allocation as a mean to get more memory to > > kmemleak::mem_pool_alloc()? > > For the last 5 years, this is the second time I am ware of this kind of > issue just because of the 64KB->4KB switch on those servers, although I > agree it could happen again in the future due to some new debugging > features etc. I don't feel a strong need to rewrite it now though. Not > sure if Catalin saw things differently. Anyway, Mike, do you agree that > we could rewrite that separately in the future? Yeah, the rework can definitely go on top. -- Sincerely yours, Mike.