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 DF0124CA261
	for <linux-kernel@vger.kernel.org>; Wed, 19 Aug 2026 19:34:06 +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=1787168053; cv=none; b=Tex83hsA4ZseBMCKBqkf2h5Dv89XqOW/1VeegWUMOykUb8XvU13hiDr9ZuRMd3B8x2vCkBo2D4lkOukG4MSfBZGxWo64lcEqJbois13FgOlX23uw1/YNF5hj/KarNbuXQu9hnUSd9A+0rpp8aHmvlxJwhD7lVolh/xd3s1xilXM=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1787168053; c=relaxed/simple;
	bh=3wziTbU9MsDHD9TP6ico+HGukQM0nSysUmQc0/7R3ms=;
	h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID:
	 MIME-Version:Content-Type; b=R4YF6PHx1Gw5qLYmDsb9tZIenpk6GOA3MoSI1YOIJj9HkE80UHtaxLaoarm2q2ro7oJ0qVuiTsRRmxQ6HbLB5e/VXvQ1mR877md5+dZKPy4InC37rnQSNvAwsJjCu6oRDThyofZv9qbvNK3R1Um6kSPwOM9LaDGeSxOd8v+NmOM=
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=UWGTfmXS; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zOcUGeNI; 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="UWGTfmXS";
	dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zOcUGeNI"
From: Thomas Gleixner <tglx@linutronix.de>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020; t=1787168044;
	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=3wziTbU9MsDHD9TP6ico+HGukQM0nSysUmQc0/7R3ms=;
	b=UWGTfmXSHqnDaeXXo9pphlnD2DMvofpgO8sRF3hZVQIiTCp5raloJ+PrpfTfd8pcvwlsGu
	JOJQ8gcwQ0vdRcrNJTr0boD5SU26xVafYHe+E917pLaqCbSXNcs8XED5dJuurE7sP4bLOX
	DkwERDkXs3OUtcMPCTLnbmAEUm2Ec9SlLW1pNc1aLr3FqfgcEdSpL9TGKRZwnN454CBkZe
	DPPdqd7BRyBlwaeHAVmVCTB2zz8+VnLdC33+/GvHE0hWNEFCNRZEzurl+rSxrbJwAW9IhH
	MwYl6VF1+egl+7JOsXHMSgK5tHEhsPqbwEB4DHNuz4bISr9MyaxaKp1QhA4kdQ==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de;
	s=2020e; t=1787168044;
	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=3wziTbU9MsDHD9TP6ico+HGukQM0nSysUmQc0/7R3ms=;
	b=zOcUGeNIkfZjXBj6tcCLyymhlHO2ImuITlqZUIxDRMksyCahlBcAP6N8eIVGL0Moj16vSM
	yCLxNi6hAj0dFtCA==
To: Haotian Zhang <vulab@iscas.ac.cn>
Cc: linux-kernel@vger.kernel.org, Haotian Zhang <vulab@iscas.ac.cn>
Subject: Re: [PATCH] irqchip/ingenic-tcu: free generic chips on error path
In-Reply-To: <20260818030206.4420-1-vulab@iscas.ac.cn>
References: <20260818030206.4420-1-vulab@iscas.ac.cn>
Date: Wed, 19 Aug 2026 21:34:04 +0200
Message-ID: <87fr09kiqb.ffs@fw13>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain

On Tue, Aug 18 2026 at 11:02, Haotian Zhang wrote:
> irq_alloc_domain_generic_chips() stores the allocated generic chip
> data in domain->gc. On the error path taken when irq_of_parse_and_map()
> fails, ingenic_tcu_irq_init() calls irq_domain_remove() without first
> calling irq_domain_remove_generic_chips(). As the domain was created
> with irq_domain_add_linear(), which does not set
> IRQ_DOMAIN_FLAG_DESTROY_GC, irq_domain_remove() never frees the generic
> chips and the allocation leaks.
>
> Call irq_domain_remove_generic_chips() before irq_domain_remove() so
> that the generic chip data is released on the error path.

No. Set the stupid flag on the domain and let the core code do it.