From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 07A815588B for ; Tue, 10 Sep 2024 07:50:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725954634; cv=none; b=P5rpLeDW6xXwSqetozk0+fM7mOXEOsqvxEVDCunho1wSYAhgJAH3T7a0aNxqFbki6/aM7al1VEbl83rSU/Uy7pfa8Ls4pO/jd4nADKT3UdxYkMmgdPgog57rY1b6x7yK7gJ8sIpWDv0oG7txO9YNA2+BnG3oEWL3WWpLdb8J0LA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725954634; c=relaxed/simple; bh=vswE4xEmJQOfA6+wzXWKCkfpVFKdHaZzmFjzfjPBSrM=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=YQaee4+4BFkbSyE/Ei9cXRtXFWusBwdV0CrHfwpaqKFu01LiHUGMwbxYyeJ+aiOQljzVC0dhG3wlZkbXxh59c5kUUKntO34AQfZ0I/bgZRbZO7sz+lRiPLvRVJmdCVvOfJxOc7gXQadYdKuZpBIh8HDZOi1+5OSO9U3s3veMOtg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iNM2M95T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iNM2M95T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D80F3C4CEC6; Tue, 10 Sep 2024 07:50:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725954633; bh=vswE4xEmJQOfA6+wzXWKCkfpVFKdHaZzmFjzfjPBSrM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=iNM2M95TL/Sk6Qzjc5rDyQk6v/WTCQWeHB89NpvjAnD21uEyIwBiycKtIYkOx6gbY AWEZzrr3yqUBJXCVYA/jdVJcEu02SpMaYYgvZku8jIBaTcNDKIm/45SjlwFMblB+RP qQ7FoLiJYkpQoSCIkp1+H0JvBab/sYW2Jb/mceh79EBAUkoA8QJYQuM7aJYmPJ92Fa R9840lZ5yjie/4gT1lYpK50dMEqjU1Y9jOtNnwZR/yQ2Xeqgr5EuRB6q5Uh/KE4hNH o7qFoC/Zb6FLQAOX/C3KCUz2arCN9/p0I6jWiplZNhnJDPhBiAbxwBTdbt/2XvUzLa Eb61E0bN8gIEA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1snvdv-00BeUN-T9; Tue, 10 Sep 2024 08:50:32 +0100 Date: Tue, 10 Sep 2024 08:50:30 +0100 Message-ID: <86y1406j7d.wl-maz@kernel.org> From: Marc Zyngier To: Sergey Shtylyov Cc: Thomas Gleixner , , Subject: Re: [PATCH] irqchip/gic: prevent buffer overflow in gic_ipi_send_mask() In-Reply-To: References: <048ff3bb-09d1-2e60-4f3b-611e2bfde7aa@omp.ru> <87cyli5zj7.ffs@tglx> 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/29.4 (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: s.shtylyov@omp.ru, tglx@linutronix.de, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.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, 09 Sep 2024 20:23:21 +0100, Sergey Shtylyov wrote: > > On 9/5/24 10:29 AM, Thomas Gleixner wrote: > [...] > > >> ARM GIC arch v2 spec claims support for just 8 CPU interfaces. However, > >> looking at the GIC driver's irq_set_affinity() method, it seems that the > >> passed CPU mask may contain the logical CPU #s beyond 8, and that method > > s/8/7/, of course... :-< > > >> filters them out before reading gic_cpu_map[], bailing out with > >> -EINVAL. > > > > The reasoning is correct in theory, but in reality it's a non problem. > > Frankly, before finalizing this patch I had tried to ascertain whether > cpumask could contain CPUs with the logical #s higher than 8 but that was > taking way too much time and I gave up... :-) You can't really work it out form the source code. The trick is that the integration requirements prevent you from doing so. It is as simple as that. People have built GICv2-like interrupt controllers with more than 8 CPUs, but it is a different beast (see the hip04 driver for a good laugh). Another possible hack is to have 2 GICs side by side, and connect up to 8 CPUs to each. But then you cannot IPI one cluster from another, and you end-up with the hilarious situation that plagued the Axxia SoC, which Linux never really supported, because this is utter nonsense. > > > Simply because processors which use this GIC version cannot have more > > than 8 cores. > > And big.LITTLE not involved? In what sense? Asymmetric configurations don't impact the number of CPU interfaces that can be connected to a single GIC. > > > That means num_possible_cpus() <= 8 so the cpumask handed in cannot have > > bits >= 8 set. Ergo for_each_cpu() can't return a bit which is >= 8. > > Perhaps adding WARN_ON() would make some sense though? :-) But why? If someone builds something that cannot work, they have bigger problems than an extra bit in a bitmap, and the kernel is not a validation suite for idiotic integration (though I wonder at times). M. -- Without deviation from the norm, progress is not possible.