From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 0294137C91E for ; Fri, 12 Jun 2026 11:22:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781263373; cv=none; b=QA+SpVNKNPVoGhSE+IRAXi7J7l5iiNLpTtZPD/c3ACldWqzi1lNctfrHpsW6VMHbtScdCFkp0xKBZSsI0rsh/uR9fUpnFqukD+btpbOyvaLdAKv7i0gepL5bKuKF40fW5yPeHSSSHEc6O5C6cZoVF+vCEzKQv+FnBGLP1jWRb4s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781263373; c=relaxed/simple; bh=+1/hR8MFy8vJHA3pw7YsoHEqknbdVs3lUVsYBSqdjho=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=tpJu+vHNGMgBtPWrPCSgW31uz6ZP3AF2kN0IOg3qZF+gf3NRbuPEfmu2cnSAZ5J/6xdnNmO9ZYPzkJn+anC/pY7Mf7jG1MfWgaVXyM4w5fyhtBPWsZjtoKNMkqOvwG15VcDkbGpXyX3deVItDQ5Em2R+1rTSSGVMoUg91UcI56M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=rK/4qiQ+; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="rK/4qiQ+" Message-ID: <086712c1-18bc-414a-9a7a-723b9498847a@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781263366; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S9H34KM0CzvAdGWJO94iGmMoL4Jxl0Cg8wXuvqWR/cE=; b=rK/4qiQ+XLdBkl7Okeesu87wgP7Mgh4oBmRzUCGOvu9pPnd/ic3ah3cJ1CMoHgTrwmpFB0 6y/jI8vDt5GSR3cvaWWyDuMzebjA53ulL17K67G2IctToNkmbf54/mk/DoFVTbWYGFzsd7 +2xGjRK/NZ3gtwU2fM9n44tcvY8FWXg= Date: Fri, 12 Jun 2026 19:22:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH RFC] mm/kmemleak: avoid soft lockup when scanning task stacks Content-Language: en-US To: Breno Leitao 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 References: <20260611-kmemleak-stack-resched-v1-1-d6248ade5f4a@debian.org> <20260612031605.58235-1-lance.yang@linux.dev> <6bc446b7-8e25-4add-9d72-a3c9e9191533@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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.