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 AE6C2371D0A for ; Fri, 12 Jun 2026 10:39:40 +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=1781260782; cv=none; b=mp/I36DRdHFsE4BD0k47Xj+GPQUNKpofwwLIVM2AsU1gZTPZUNqvL5fr7uHHvk1NiYzBpW3if4GLuFCF2InK0WiM8zjtTNLtR8pGhyqrCKrUkhlxTUgr3vJNcGh8XH/JQ+1kyhDhZd8/p1d5mfK2TYLPPuKanzUryAsLoF2gLas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781260782; c=relaxed/simple; bh=Pf+ahb3iiyICerX/p4we3rLw39dDAS87sBkdbOcQcWg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AC/ohPy2iRQAQrmWEh1lRu58lNgljVd8BpTCPA+3qaSAE0TAAtdm4PZ53c877O/h2ljqWDtoVH4SFrcPdvtyYihSk17tU2b3yA46rXK3AiekOSWOFYE9HnGmfz5NcEVGCX+B46dbPTeSgI1f77Cg2t+zVIoQ0Q3U95U5+7Ld2yI= 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=fnIsnV3y; 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="fnIsnV3y" 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=NqiV790zEvyRLcm0gWc4S1J3hXlHamb1bPXX4CuLsi0=; b=fnIsnV3ykoZi4mVYkoDyye/INV 69lBYsqLq4UvFK/wovjBpHDMpmShA07v4bUpP/6v5MsdeIURTcSEqlszMi2nFvIY+mhh9b3gGwa9V ZAqMizSnfSFpceDt7iP64/fqx760xE57JK8SqanRX6YUopv/kM5izoaXQpf2YUZSGnMPYkGvT8N88 svc62gzydJuJCmdbot+kGqCIHaWwY0ckWAUhcyhTWyE0B1H4lXR7E1XVaeDDJ0kDFEqrkGFfT7g9p pL1oPL88zgydPiJH/txPJlE6WlUyEld6mGM3sqhFsIeDGEgMVMrbB7ea7uSLXutVvFjci0vrAuJ/q nQcma7eQ==; 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 1wXzIQ-00Ag0Y-1W; Fri, 12 Jun 2026 10:39:30 +0000 Date: Fri, 12 Jun 2026 03:39:26 -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> <6bc446b7-8e25-4add-9d72-a3c9e9191533@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: <6bc446b7-8e25-4add-9d72-a3c9e9191533@linux.dev> X-Debian-User: leitao On Fri, Jun 12, 2026 at 05:57:12PM +0800, Lance Yang wrote: > > 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; > > } > > I'd expect the normal case to just drop RCU, cond_resched(), take RCU > again, see both cursors still alive, and keep walking :) > > > ... > > if (scan_should_stop() || aborted) > > return; > > And yeah, you're right. If we do lost a cursor, bailing out and > skipping reporting fot that incomplete root scan should be the > right thing, I guess :D Thanks! Under what circumstances would the cursor actually be lost?