From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B825364935 for ; Tue, 16 Jun 2026 12:46:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781614012; cv=none; b=G3Z25+Q82eehAtQ6P6/zNKdIPHKzIDjA0Q3hepVwonDIf3VXbmJQ4ZKPjSza3MarbsoZmu98UsCbXXFv0vbkvUflbgyYn7Yw2A3L2H4/P/gOXdoKq4pdAAkNuTtJ4jFOxRPUojmOYC3pdQUPVoMO4dJygpmY7/rFkPgBfOcge/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781614012; c=relaxed/simple; bh=02dLRa21YOxkCl50eSWkr2PmWWkuPtYf0QpFs7ehCHk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=exqh7A2nawQyvuK8Ad7wr7e4CmDy1VRavPfLquqbCDNTOHLQ8oO+WBoFpgRtk+2tuJu84fWnYBJNhUIGh/3ea5/r/LrzVkHzQtEl6PMh7IZZlEJCm2ApQ68T+0stmPwC1VY8y4NlfLkC1gZMoP9iG5HjjSVFG4TwN3JN45kxRGc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org; spf=pass smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=gFj/tZku; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="gFj/tZku" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vUobB4c4LuSlDSioRinvR60+XHgnr1Axh4buGNM4lE4=; b=gFj/tZkuGLBn1RILXXmCVhMFjH M3zu0i8Gn5A3u1DPTAx0sw2gnbGi9sw+zpW9z5APVS1bmnW1v37pCezwYv6bl+PErKGwbscrfAuYK G/ylKYgMfru/o5MmPUGJfdTu7Ln7kZ+y4gvU2QlquAY9kYsrxhcmIIa5rgRd2mmbxvfrtMc7hC+Mu DFu8FJ4ZenO+EY64gJu++eP5g7slEI/6mtT57SBI2aF7Wv9avHrfQ2/hbq4AMRAbMbzR1DErgtBTp mfuBGf7ZAFtafgWRnIy+DYuYl/T11StYZ9j9nOw/Q0fsaRboCdvQIdRymk925QF3t46ZsVesNfkHG 5ybDsu5A==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from ) id 1wZTBW-00Dr8c-0l; Tue, 16 Jun 2026 12:46:30 +0000 Date: Tue, 16 Jun 2026 05:46:25 -0700 From: Breno Leitao To: Oleg Nesterov Cc: Catalin Marinas , Andrew Morton , lance.yang@linux.dev, Davidlohr Bueso , Qian Cai , sj@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v3 3/3] mm/kmemleak: stop the per-cpu and struct page scans early too Message-ID: References: <20260615-kmemleak-stack-resched-v3-0-acecd7d7fd92@debian.org> <20260615-kmemleak-stack-resched-v3-3-acecd7d7fd92@debian.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Debian-User: leitao Hello Oleg, On Tue, Jun 16, 2026 at 12:07:04PM +0200, Oleg Nesterov wrote: > On 06/15, Breno Leitao wrote: > > > > #ifdef CONFIG_SMP > > /* per-cpu sections scanning */ > > - for_each_possible_cpu(i) > > - scan_large_block(__per_cpu_start + per_cpu_offset(i), > > - __per_cpu_end + per_cpu_offset(i)); > > + for_each_possible_cpu(i) { > > + if (scan_large_block(__per_cpu_start + per_cpu_offset(i), > > + __per_cpu_end + per_cpu_offset(i))) > > + break; > > + } > > #endif > > The patch looks correct, but... > > if scan_large_block() returns true, then > > > @@ -1902,6 +1908,7 @@ static void kmemleak_scan(void) > > unsigned long start_pfn = zone->zone_start_pfn; > > unsigned long end_pfn = zone_end_pfn(zone); > > unsigned long pfn; > > + int stop = 0; > > > > for (pfn = start_pfn; pfn < end_pfn; pfn++) { > > struct page *page = pfn_to_online_page(pfn); > > @@ -1918,8 +1925,12 @@ static void kmemleak_scan(void) > > /* only scan if page is in use */ > > if (page_count(page) == 0) > > continue; > > - scan_block(page, page + 1, NULL); > > + stop = scan_block(page, page + 1, NULL); > > it is pointless to enter this for_each_populated_zone() loop and call > kmemleak_scan_task_stacks() after that? Upon further review, your semll is right, once a phase trips scan_should_stop() the later phases are still entered and each just bails on its first scan_block(). That can be optimized away, e.g. by lifting 'stop' to function scope and guarding the remaining phases so they aren't entered at all. It is not a regression, though -- the pointless work is pre-existing. Before this series none of these loops broke out on scan_should_stop(): the scan ground through every CPU, every pfn and every thread, relying only on scan_block() returning early on each call. This series already removes the bulk of that; the bit you spotted (entering the next phase only to bail) is the small leftover. So I'd rather keep this series as-is and do that optimization as a follow-up once it lands, instead of growing a patch that's already been reviewed. Are you OK with that? Thanks, --breno