From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 B68353D25C5 for ; Mon, 15 Jun 2026 08:49:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781513386; cv=none; b=bZXA/FcmgQ45gPAAx5uxkhSkrBoTGzupDfWSJNlRaZYdejZx30rvKJZeoxdyzA1ggnTfag+98Mz7c3zy/V/1UKKfrjSSSpDbzlpNGL7Lk/9jZXflucGPRy2Kglfu+S0bFsd7qGiH7CdiIiPMrDALYKaZneym6G5f6hjXJSEcgm0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781513386; c=relaxed/simple; bh=zQDT4vUYXat6HhQQt5iKE+2Xf+K5A0gr7lZQEVzkhUQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=PIMkVKd62VOZ3q/XSYXzBim5O4bgzunKi9ODRUXbpbLCqm9G6dT+3wbYxmy2RKUZfaj9uq+wuHb+ZeF6J7hRvFwzRo1TOIukb+eGqbGQcX58ZN/1jHXEGyjV1HIQ4xg0dGIF6xW1eqIAsIPCsHU6nzB2BNM4/cs0cdaXr1SHTbU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UlDBN9aK; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UlDBN9aK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13CB81F000E9; Mon, 15 Jun 2026 08:49:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1781513380; bh=EcjDrnq43wfyzOlZL8abrsSRl9hrhmFd5MUO9YbOjfQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=UlDBN9aK38JIaZx74VZC4z4fyYqnCbvYoNMCrTDOTUFjJKAjF6etBUtiZ4P6L5mcm VEe45bCmWthZF1TbHLwbKS1vRSvpzs7/DMftHwYIRZ1n0gM2JPklgPpCPTA7vtVRVc N/B7x+tLpwxb8fWTXH/6Eq6PbsuiNLEUjgR57euC3GN1rlTP8uO2rljK8Th0HmIElh ULpg8iuJajEGuPzD+iolnolJbz6zDAsmRXbe0pht+o7sKKW4RjLD+oXlMJrz9ztXjP /srUi5PRanHT+Q3k4yL+BLGqYpybVnHEuyskfZ4KIis4AtBOtyrY7d48JhW0B8zG4a Vu4M99yRuDm2Q== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wZ30j-0000000CrgV-2osN; Mon, 15 Jun 2026 08:49:38 +0000 Date: Mon, 15 Jun 2026 09:52:56 +0100 Message-ID: <87jys089sn.wl-maz@kernel.org> From: Marc Zyngier To: Kemeng Shi Cc: tglx@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc() In-Reply-To: <20260615032910.54735-2-shikemeng@huaweicloud.com> References: <20260615032910.54735-1-shikemeng@huaweicloud.com> <20260615032910.54735-2-shikemeng@huaweicloud.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: shikemeng@huaweicloud.com, tglx@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 15 Jun 2026 04:29:05 +0100, Kemeng Shi wrote: > > Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor Typo. > error handling code to make it a little simpler. No. Please don't mix fixes and (totally pointless) refactoring. > > Signed-off-by: Kemeng Shi > --- > drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------ > 1 file changed, 9 insertions(+), 12 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > index 291d7668cc8d..2b7b546c43c8 100644 > --- a/drivers/irqchip/irq-gic-v3-its.c > +++ b/drivers/irqchip/irq-gic-v3-its.c > @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits) > static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids) > { > unsigned long *bitmap = NULL; > - int err = 0; > > do { > - err = alloc_lpi_range(nr_irqs, base); > + int err = alloc_lpi_range(nr_irqs, base); > if (!err) > break; > > @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids) > } while (nr_irqs > 0); > > if (!nr_irqs) > - err = -ENOSPC; > - > - if (err) > - goto out; > + goto err_out; > > bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC); > if (!bitmap) > - goto out; > + goto err_free_lpi; > > *nr_ids = nr_irqs; > - > -out: > - if (!bitmap) > - *base = *nr_ids = 0; > - > return bitmap; > + > +err_free_lpi: > + free_lpi_range(*base, nr_irqs); > +err_out: > + *base = *nr_ids = 0; > + return NULL; > } > > static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids) Honestly, I question the validity of handling errors this way. You are already unable to allocate a per-device bitmap. And yet you are calling free_lpi_range(), which has the interesting property of *allocating* memory. Which you don't have. Oh wait... M. -- Jazz isn't dead. It just smells funny.