From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 439DA1C3BFC for ; Mon, 19 Jan 2026 07:48:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768808897; cv=none; b=WuFWwd36AJlBv6VMq/RN7sHW181VlugJi4pAOUcBGF53xAsIZ/WNJAWjH7T/pKJXW8ApNYOmVJkIxHlFSgEsP1aneh4S3IC6fyHJ++De/TkvC8DE0lK9vP8IFEwLFDcoV7K678/N21Ke6d4DuIFa787uPntAgnXipbm2KsjhtBE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768808897; c=relaxed/simple; bh=jb1gJokCYYx9XGOH6pPs1TFuXLDyesZrVvOQUR0f2ZQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZhBPJyAxiwMAxOReBJIaQYm9FZkvuQTy9Pif/qD2AKO8ndPtaJAsjEcNDmEJOa0ekUglVFa6FSOyF0JDn9T5BSqEJ0wjreuQFPFueoQayPXhqvkfTdTOdHeKpd/xr0zf1dRcx/DW5qS1+yegl0gj5BCEtCi/KUwFN0jV6BUKGLw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Bv81rIR2; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=IcfOFdBp; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Bv81rIR2"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="IcfOFdBp" Date: Mon, 19 Jan 2026 08:48:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1768808894; 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: in-reply-to:in-reply-to:references:references; bh=4nyquV9IFp9+ZLI3g6GqUmUmB328l0PHMKo2ZocZs3c=; b=Bv81rIR2pZAs9TIDBF5rKWZpxsY2yA2hAbXgEtGAvpbo5L/SPxv6BhexP4iJINZ9sQmYAN swmNZZ3CGwNadUiIWH2Q67pgjJEUCV9cX5VHqSAo5gYpROW3FWuUDTVjFiwY1T/wnOCgTt anW/W2g7/klFNi5o9lWe9dAHQVh4a0dkhxsj0aAhwkaO4Czo/RFqdoG/m++l7ZPQmMlvY8 bANc11dV035+QQ4rl75p+zVXWwdoLME3FbZi0/9PD/otzWlIaBhOTUd2SNZRZSIo0ULQRY sCWyyVT5TwIXO9RbhCnLaGrxl98j5bMZ8oWhNfwHhUx4yB5+HpCxBxurQFl3lg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1768808894; 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: in-reply-to:in-reply-to:references:references; bh=4nyquV9IFp9+ZLI3g6GqUmUmB328l0PHMKo2ZocZs3c=; b=IcfOFdBpzy2Qqgay8Es8uS0xjVyqhcHbAtbnCTUV+AFwM9H1b/gUzNWrpqm9+kBEU5HKg0 4m50jDF9QZb0qaDg== From: Sebastian Andrzej Siewior To: Dennis Zhou Cc: Andrew Morton , Tejun Heo , Christoph Lameter , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] percpu: add basic double free check Message-ID: <20260119074813.ecAFsGaT@linutronix.de> References: <20260116023216.14515-1-dennis@kernel.org> <20260116191548.7df814c2a9eea1a9fa3c4cb5@linux-foundation.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=utf-8 Content-Disposition: inline In-Reply-To: On 2026-01-16 21:15:33 [-0800], Dennis Zhou wrote: > > The patch does appear to do that which it set out to do. But do we > > want to do it? Is there a history of callers double-freeing percpu > > memory? Was there some bug which would have been more rapidly and > > easily solved had this change been in place? > > > > Originally, Sebastian posted he ran into the issue where he double freed > in [1] (linked in patch). Maybe he can elaborate how that bug was > introduced. > > Wrt do we want to do it - I think it doesn't hurt and makes it more > explicit that something very wrong occurred. Percpu memory really > expects users to be good samaritans. If you do happen to accidentally > double free without the warning, in a contrived case you could > experience unexplained behavior for some time before crashing in a spot > that would leave your head scratching. If anything I think there could > be an argument to fail louder. I did write some code and there was a free path I did not expect to happen. While it was rare to happen, it did not always crash right away. Once I had the pattern I was wondering why none of the memory debug switches did something. Adding this does not look expensive, allocating per-CPU is hardly done in a hot path so I did not add anything but I don't mind hiding it behind a config switch similar to SLAB_DEBUG. While we do have way less per-CPU allocations compared to SLAB, I think it is important to have some kind of sanity checks for it to ensure it is used properly. I would go with a WARN_ON_ONCE but if there is a desire for rate limited multiple warnings, fine. > [1] https://lore.kernel.org/linux-mm/20250904143514.Yk6Ap-jy@linutronix.de/ > > Thanks, > Dennis Sebastian