Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3059266pxb; Fri, 5 Nov 2021 09:06:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxZcZqjG91hz58/rY7ZjD2GFsfcSoWUVzmwN2ydX6ClMFEqS6zMOSP+u0oTJacjwdz/gH+O X-Received: by 2002:a17:907:9487:: with SMTP id dm7mr5464155ejc.95.1636128399263; Fri, 05 Nov 2021 09:06:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636128399; cv=none; d=google.com; s=arc-20160816; b=K/MdN7yhwjJnpNIzPrPKOQONibNr5owquIFTxYWwbF9qhelITcvILqaxizuXngWijo tKAJ1cqwq1pKFt6Xu9dORTNNMpwzYQx+35TWjQ+y3ZGKqd0UhKtOv6OBnyFdonIrolp2 aql8T0+TCHzl+D1d6BlLhcOSluZi2Bg8YN4eJpH2rueavbD59/WNWFmYtMdJ1m+pIyph IdVALrm7rEfeWIOEN8UYrmeqwqzvYgM4eahXam0ZJYaV60VL0KjxbQnJDig7rFccP1Et dLXlx4z8zVRJb9CHCwgqD3/j7LjgWusX0J48CfzZCThdsTygdkvVRf/9IaxvVeD5VRRe A3sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9oHE7tmt1jbLPMHZFo6QaRwbgSgyZn9SpJDvKcWZ46M=; b=IVlR0L7ROPJ36zixvtYvXmZwck81PRWAsT7hoNQAZ7xAzxQhk0Rfx54CpzhugoDHK7 PSeKiNrCjt8E1UqkAfKue8zimWIIWQyVClr89SBv6DOiuRrgqKJGp4TfuJAnQR0g8k7x MkHgdfD4xEXisoV2nj91L98T1SnMOivQNCMxpA66rpow3cfixL02o1jXibC3Kwl0YoC4 yILCQhYGK0m/4LPSjwvFWN2QoLe5Oyy7IVmfs0AJA4DsxxwCMUCUhqXs3KOAPpAlCMhB xuFiz15hAZQVuewce/3q4Yr1oS1KWhRPawkPt24vcFREwqkkJiJGtJXJPy+UaPN0G2MI C/og== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uKknH7Xo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ht11si19920671ejc.95.2021.11.05.09.06.06; Fri, 05 Nov 2021 09:06:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=uKknH7Xo; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232041AbhKELIq (ORCPT + 99 others); Fri, 5 Nov 2021 07:08:46 -0400 Received: from mail.kernel.org ([198.145.29.99]:37048 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231312AbhKELIp (ORCPT ); Fri, 5 Nov 2021 07:08:45 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9EBBF6008E; Fri, 5 Nov 2021 11:06:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1636110366; bh=gJsm1IizLqHIU46nqJ2PCv1weO5m/+2Lhx/GTelVNiA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uKknH7Xo3L4tFaDX1x10uGTlyVBD8Pp4ABE1Nd6UfR4udeBpijbZRzg2e/wl1LBDi oU7vKRK6ylEEkUbz6G2lXztI5Z56Z1/C/jWh2euo0IRIb3z9doWrztVJuejnH4XNmj wp4FYpWDS3vR91479Qi8qBmLwsxkXj7gfKB/NXKB3TxhGj432VRQBMAwsWVifm5OM2 lz8EeR9tRp8idUnHCk47LG7uL5nCfRzH7+qg4g+dUTx9rWnMVGRk57ujHNhiyIRqLI adN/QVDYKJsQ+S1aOJLIsJeEn+hkIu2Bhltdxbjdhm0TYWiCeTGdQgesPgunBPQ3ow zGCcD9kAFT/NQ== Date: Fri, 5 Nov 2021 13:05:58 +0200 From: Mike Rapoport To: Catalin Marinas Cc: Qian Cai , 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 05, 2021 at 10:08:05AM +0000, Catalin Marinas wrote: > 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. > > Or MEMBLOCK_ALLOC_ACCESSIBLE_NOLEAKTRACE to match SLAB_NOLEAKTRACE and > also hint that it's accessible memory. Hmm, I think MEMBLOCK_ALLOC_NOLEAKTRACE is enough. Having a constant instead of end limit already implies there is no limit and when we update the API to use lower bits or a dedicated 'flags' we won't need to change the flag name as well. > > > 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? > > I was talking to Mike on IRC last night and I think you still need a > flag, otherwise you could get a recursive memblock -> kmemleak -> > memblock call (that's why we have SLAB_NOLEAKTRACE). So for the time > being, a new MEMBLOCK_* definition would do. > > I wonder whether we could actually use the bottom bits in the end/limit > as actual flags so one can do (MEMBLOCK_ALLOC_ACCESSIBLE | > MEMBLOCK_NOLEAKTRACE). But that could be for a separate clean-up. We never restricted end/limit to be on a word boundary, but I doubt that in practice we'd ever have the low bits set. I'm not entirely happy with using end limit parameter for this, I'd like to see how much churn it will be to extend some of memblock_*_alloc with an explicit flags parameter. -- Sincerely yours, Mike.