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 B13691BBBC0 for ; Wed, 23 Oct 2024 14:23:42 +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=1729693422; cv=none; b=AAeueIM+oiZJvHu7mUlD31SodbuopB8y3aQNP9DtpnLy5nOJCMyyICYRfJ1V2LI0WaRa0NnaVZOdlb9RZ+4xfvR1943B3VWI/TzbMKnXTrNq6x7KonvqaYBsYkLwsQXFU7TuaV/GX9F2lEyJc4x7UWjruHdd+MZKHdo/eZ/17ww= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729693422; c=relaxed/simple; bh=UZalNqqn9cg9w1aVQzG5s81lrOQsERIxz1Yb5xKvGk0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=GIi6PjgwOWBrpwN1hQLEUwvjvapI0ocJ5rLzZQMtrEVZtEn1vc6XBnxrHmmYELOgnmELxF+XDdCBMoNkLIlabtpXTM/5kjSzhFZPF6bA0KaCd6JH3ROaQ+LDDWclFsMcmLpL/KWC/MqOTG5qIz+Nr8yAqD0fp6aD5vdQrs+5Y5M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j8M+OpB0; 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="j8M+OpB0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49496C4CEC6; Wed, 23 Oct 2024 14:23:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1729693422; bh=UZalNqqn9cg9w1aVQzG5s81lrOQsERIxz1Yb5xKvGk0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=j8M+OpB0N9oMssWJR0CxC8YsgqeWBiwoYuhckZGh0U5d3g9UwO4ZsqksS2fkWt0ol 2lBZpH1QWw1Yb+mtJscZ4KGsDKKjNu3ZVicnykzTsGgE6jhXLCGhRzSAZV/QE94xHx 4twGxTV+GEF6s8IiW/gMstmhhYXLSJuJOeU+vpoMDzyDsLV5uPMFU9WTSXTQOHNAbc sqUZNvGcxA/wnYshf+8dqxnEaw+3WPOL/kDR+TdHAcRvOL40NAhvV7Vu4xxAQ5aBdR Wdm3m4ZQ91KMgGFRM0VJOhusMWnnifIhXmDEugyLLZoUHraz6fUexZa2Lr8Yk9klmf vOET/7dCYOOEQ== 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 1t3cGy-00689F-1x; Wed, 23 Oct 2024 15:23:40 +0100 Date: Wed, 23 Oct 2024 15:23:39 +0100 Message-ID: <8634km5250.wl-maz@kernel.org> From: Marc Zyngier To: Zenghui Yu Cc: , , Thomas Gleixner , Kunkun Jiang Subject: Re: [PATCH] irqchip/gic-v4: Don't allow a VMOVP on a dying VPE In-Reply-To: References: <20241002204959.2051709-1-maz@kernel.org> <87wmhztd9z.wl-maz@kernel.org> 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: yuzenghui@huawei.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, jiangkunkun@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 23 Oct 2024 14:51:40 +0100, Zenghui Yu wrote: > > On 2024/10/23 16:49, Marc Zyngier wrote: > > Hi Zenghui, > > > > On Tue, 22 Oct 2024 08:45:17 +0100, > > Zenghui Yu wrote: > > > > > > Hi Marc, > > > > > > On 2024/10/3 4:49, Marc Zyngier wrote: > > > > Kunkun Jiang reports that there is a small window of opportunity for > > > > userspace to force a change of affinity for a VPE while the VPE has > > > > already been unmapped, but the corresponding doorbell interrupt still > > > > visible in /proc/irq/. > > > > > > > > Plug the race by checking the value of vmapp_count, which tracks whether > > > > the VPE is mapped ot not, and returning an error in this case. > > > > > > > > This involves making vmapp_count common to both GICv4.1 and its v4.0 > > > > ancestor. > > > > > > > > Reported-by: Kunkun Jiang > > > > Signed-off-by: Marc Zyngier > > > > Link: https://lore.kernel.org/r/c182ece6-2ba0-ce4f-3404-dba7a3ab6c52@huawei.com > > > > --- > > > > drivers/irqchip/irq-gic-v3-its.c | 18 ++++++++++++------ > > > > include/linux/irqchip/arm-gic-v4.h | 4 +++- > > > > 2 files changed, 15 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > > > > index fdec478ba5e7..ab597e74ba08 100644 > > > > --- a/drivers/irqchip/irq-gic-v3-its.c > > > > +++ b/drivers/irqchip/irq-gic-v3-its.c > > > > @@ -797,8 +797,8 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, > > > > its_encode_valid(cmd, desc->its_vmapp_cmd.valid); > > > > > > > > if (!desc->its_vmapp_cmd.valid) { > > > > + alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); > > > > if (is_v4_1(its)) { > > > > - alloc = !atomic_dec_return(&desc->its_vmapp_cmd.vpe->vmapp_count); > > > > its_encode_alloc(cmd, alloc); > > > > /* > > > > * Unmapping a VPE is self-synchronizing on GICv4.1, > > > > @@ -817,13 +817,13 @@ static struct its_vpe *its_build_vmapp_cmd(struct its_node *its, > > > > its_encode_vpt_addr(cmd, vpt_addr); > > > > its_encode_vpt_size(cmd, LPI_NRBITS - 1); > > > > > > > > + alloc = !atomic_fetch_inc(&desc->its_vmapp_cmd.vpe->vmapp_count); > > > > + > > > > if (!is_v4_1(its)) > > > > goto out; > > > > > > > > vconf_addr = virt_to_phys(page_address(desc->its_vmapp_cmd.vpe->its_vm->vprop_page)); > > > > > > > > - alloc = !atomic_fetch_inc(&desc->its_vmapp_cmd.vpe->vmapp_count); > > > > - > > > > its_encode_alloc(cmd, alloc); > > > > > > > > /* > > > > @@ -3806,6 +3806,13 @@ static int its_vpe_set_affinity(struct irq_data *d, > > > > struct cpumask *table_mask; > > > > unsigned long flags; > > > > > > > > + /* > > > > + * Check if we're racing against a VPE being destroyed, for > > > > + * which we don't want to allow a VMOVP. > > > > + */ > > > > + if (!atomic_read(&vpe->vmapp_count)) > > > > + return -EINVAL; > > > > > > We lazily map the vPE so that vmapp_count is likely to be 0 on GICv4.0 > > > implementations with the ITSList feature. Seems that that implementation > > > is not affected by the reported race and we don't need to check > > > vmapp_count for that. > > > > Indeed, the ITSList guards the sending of VMOVP in that case, and we > > avoid the original issue in that case. However, this still translates > > in the doorbell being moved for no reason (see its_vpe_db_proxy_move). > > Yup. > > > How about something like this? > > I'm pretty sure that the splat will disappear with that. > > > diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c > > index ab597e74ba08..ac8ed56f1e48 100644 > > --- a/drivers/irqchip/irq-gic-v3-its.c > > +++ b/drivers/irqchip/irq-gic-v3-its.c > > @@ -3810,8 +3810,17 @@ static int its_vpe_set_affinity(struct irq_data *d, > > * Check if we're racing against a VPE being destroyed, for > > * which we don't want to allow a VMOVP. > > */ > > - if (!atomic_read(&vpe->vmapp_count)) > > - return -EINVAL; > > + if (!atomic_read(&vpe->vmapp_count)) { > > + if (gic_requires_eager_mapping()) > > + return -EINVAL; > > Nitpick: why do we treat this as an error? Because at this stage we can't update the affinity anymore, and I see it as basic courtesy to let the caller know. > > > + > > + /* > > + * If we lazily map the VPEs, this isn't an error, and > > + * we exit cleanly. > > + */ > > + irq_data_update_effective_affinity(d, cpumask_of(cpu)); > > @cpu is uninitialized to a sensible value at this point? Ah! As usual, I wrote this on the train this morning, before having had much coffee, and didn't even compile-test it. Here's an amended patch, similarly untested. If that works for you, I'll put that in a proper patch for Thomas to merge. Thanks, M. diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index ab597e74ba08e..52f625e07658c 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -3810,8 +3810,18 @@ static int its_vpe_set_affinity(struct irq_data *d, * Check if we're racing against a VPE being destroyed, for * which we don't want to allow a VMOVP. */ - if (!atomic_read(&vpe->vmapp_count)) - return -EINVAL; + if (!atomic_read(&vpe->vmapp_count)) { + if (gic_requires_eager_mapping()) + return -EINVAL; + + /* + * If we lazily map the VPEs, this isn't an error and + * we can exit cleanly. + */ + cpu = cpumask_first(mask_val); + irq_data_update_effective_affinity(d, cpumask_of(cpu)); + return IRQ_SET_MASK_OK_DONE; + } /* * Changing affinity is mega expensive, so let's be as lazy as -- Without deviation from the norm, progress is not possible.