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 8732F339844 for ; Fri, 12 Jun 2026 11:57:28 +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=1781265453; cv=none; b=exaHJQ7yvRazpG4c3EvCtwrqygVVhcF3ywDywoXuo/PY8JCjaCx/b7G8KV4jFPCmOGp7I1PihmGYoQXUnwu8p5jh0boxf3+uvRCg0z1SGiF4bNIPxN1zA7rV/uziesheq8G5RQ5WIIAdLDpS/3OpDIZs7aIo08ZJtxbAG2mMpiE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781265453; c=relaxed/simple; bh=NNOdVSD0C96UsqRXddYuoY497FGeO6FrBJe5ilwO6j0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Kom5euz7i0UeHWDyRuIGjU8KEX6kFt2c2fHOD8Qmedw2QYogqZcYZeHFvYeOAtWbNNqDZOpE5mRCuGqY1j5pKM3EtuYutRV3esAXXMdmiYHVORjQT1A65mH2IVmjyybalg/I2upyCVd24hl12uYWjsa/AvaLQGUXyzR7cx4JAZY= 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=QddhunSb; 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="QddhunSb" 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=eW9tYSWRM+JFfYWM3cisOEdp7zn6Ni4KfLHcXz8CmGM=; b=QddhunSbG4e5NkzuFiBHtpO9jz zhJ21piPLJS0v+4HnxX4yblnhC7jMWj2Fe/zZ3bvre4mpQssMGlrblKWjTYnoZZlrZG1eiPkIBUBk MN4ULUSKz4Xo4C0/S8WpSNt2VRMZHEAwHqYlrOgMOAkc1+oCoufWIhCSlnxVR9GvCzr3GmDNuM4DL PLm3qs2l9QDpwQdmyxqAeih3/nxq+A4t2Fn9UjenVImWy57bFEubAG09TR+q0qLHfJBdAQ5FH1P9l C3qvbc2QvuoK8j9bAU11IVMqR7nkba6E80Ao7t6eGCEgzCd+P5fSNEDEwE6tRC/qpZw1sGn2mgCiT KiwCdKTg==; 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 1wY0Vl-00AiTX-0J; Fri, 12 Jun 2026 11:57:21 +0000 Date: Fri, 12 Jun 2026 04:57:17 -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> <086712c1-18bc-414a-9a7a-723b9498847a@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: <086712c1-18bc-414a-9a7a-723b9498847a@linux.dev> X-Debian-User: leitao On Fri, Jun 12, 2026 at 07:22:38PM +0800, Lance Yang wrote: > > > On 2026/6/12 18:39, Breno Leitao wrote: > > 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? > > It should be race, but possible, that we happen to stop on g/p, > drop RCU, and one of them is gone by the time we come back. ACk, that makes sense, with that, I think this approach might be better than the original one in this patchset. Let me play with it. Thanks for the suggestion, --breno