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 B905D1DF748 for ; Fri, 12 Jun 2026 09:09:38 +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=1781255380; cv=none; b=cwa81ogGO0GZbSvYoUhTebhV1R9i7A9hE03Dk1wRPvnrBy2Xij5yHIOAuUVAPcGD7hKvBPXmiwE4lvWs8ZgJeGr7y4thzI6k6pPP77FNvahtufOoMDA1vN8kR6L5Za7FVkh6xBRFSvaLNYlzqDtBJftCTswt+euteJ7P9qxIQoU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781255380; c=relaxed/simple; bh=EMvQy4+9JADYTf3p5wc+2FSDI+VajEIso52Q0F6lpCI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M0ZV+UvKKfVqKeShwddxZQKMwsbUc6Fcwp5bFthtDKCabaKLDSWiaCZ25POUj/KoSFmAOA9T+L04VNEPE9QUO2UqvI+LTf6lBWQ3s9WxyaDX1b/pFcCjcEHUjEXlc8+QsT8j1mieAjnJzO7lvH5Y/sKcwTE+1sG/+q0Yiuoww9Q= 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=Zb2BqOhx; 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="Zb2BqOhx" 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=ov4AVDFRF37D/+G11b2iCMEU1PIeF4rFLNtUdtH3Z3A=; b=Zb2BqOhxIN4tIQojHy3lR9eOto cC/wZDHAnH2v5rs3qReuPzaRaYDBpz77V+2NVG+q7tPa8DKdY2/45mpgCudFob3QLViDtpJk/QaUJ 4kkkvgSLXr8GD2R50aZgOR3EZC1H+FniE+5HtNxXH9VWvQnKRg+CSOrbIbyIRqH6MArtnjJO/P8iG dhhBdOcqEGWZab0qG/hDUamNVbUv2syb29BDAh36QaoOMbqWugggQLjlUkueSPprrUR6BG2V+840W iz2cdg3VMLT4HJLAbAxNuYstr6wN5bQU3ylkO2Nlnu2/of0Oh3S5FHT7zcmdxnesyz5N4lDDp5sDB gueAJOAA==; 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 1wXxtH-00Acrr-2J; Fri, 12 Jun 2026 09:09:28 +0000 Date: Fri, 12 Jun 2026 02:09:23 -0700 From: Breno Leitao To: Lance Yang Cc: catalin.marinas@arm.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com, sj@kernel.org Subject: Re: [PATCH RFC] mm/kmemleak: avoid soft lockup when scanning task stacks Message-ID: References: <20260611-kmemleak-stack-resched-v1-1-d6248ade5f4a@debian.org> <20260612031605.58235-1-lance.yang@linux.dev> 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: <20260612031605.58235-1-lance.yang@linux.dev> X-Debian-User: leitao Hello Lance, First of all, thanks for ther review, really awesome! On Fri, Jun 12, 2026 at 11:16:05AM +0800, Lance Yang wrote: > On Thu, Jun 11, 2026 at 05:45:00AM -0700, Breno Leitao wrote: > >kmemleak_scan() walks every thread and scans its kernel stack under a > >single rcu_read_lock() with no reschedule point. On a host with very > >many threads -- amplified by KASAN/lockdep in debug builds -- this loop > >can hog a CPU long enough to trip the soft lockup watchdog: > > > > watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537] > > scan_block > > kmemleak_scan > > kmemleak_scan_thread > > kthread > > Neat, good catch! > > >A cond_resched() cannot be added directly: the loop runs inside an RCU > >read-side critical section. > > > >Split the scan in two parts: > > > >1) get the list of tasks (with RCU read lock) in an array > >2) run scan_block() for the tasks (with cond_reschd()). > > > >Is it a sane approach? > > Why not use the kernel/hung_task.c pattern here? Seems simpler, with no > extra task-array allocation ;) I've looked at it, but I am not sure we want to break the loop mid-air, that seems to increase the false positives, given we did a half-baked scan, right? > Could break RCU only when resched is needed. Pin the current cursors, > drop RCU, cond_resched(), take RCU again, and continue only if the > cursors are still alive ;) > > If either cursor died while RCU was droped, stopping this scan round > should be fine, IMHO. I am not sure, this is not the same as the existing kmemleak_cond_resched() raciness in the object_list loops. Those iterate the marked set, where a miss only means "this object isn't reported until the next scan" -- under-reporting, self-healing, and the in-tree comment says exactly that. Dropping a *root* mid-scan is the opposite: it makes *other* objects get falsely reported. So the "it's already racy, bailing is fine" reasoning doesn't carry over from the object loop to the stack loop. If we go this route, the aborted round has to suppress reporting, reusing kmemleak's existing "scan was interrupted -> don't report" path: if (need_resched() && !kmemleak_stack_scan_break(g, p)) { aborted = true; goto unlock; } ... if (scan_should_stop() || aborted) return; Then an abort means "this round reports nothing; the next full scan reports the real leaks" instead of a false-positive flood. On boxes with very many threads, where the stack walk is long and need_resched() fires constantly, so the break helper runs a lot -- which makes aborts (and thus fully-suppressed, non-reporting rounds) plausibly more than "rare". Since each round restarts from the head, the tail of the thread list is the most likely to be perpetually skipped, on exactly the workload this is meant to fix. The snapshot avoids that by scanning a complete, similar to what we have today. Anyway, I would love to get rid of the array, but, I am not convinced that dropping the scan mid-air will not cause false positives. Thanks for the review, --breno