From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 8BC0B4D9F6 for ; Mon, 1 Apr 2024 16:53:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711990405; cv=none; b=Kjz7R/krDT9qN58l5xRiEn+eQFEmhqCEmpKdYd6yAM33K2TnwQiYaZerh3SUPnrLGjkPJMtCGwI6xuX6++fogWWL8FRrXXRfMM6TlXRiPOkCuAridsFNXORGlRDkSyz31dqfCt9YEE0wyto3ZCm/m9ZLlMKZ64CtREf6wUy+X/k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711990405; c=relaxed/simple; bh=Px+t/pqhTaHvvnpiM1qu0pSyT6V6ck36oVwB2RElRkc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N0HerwfyS/AFCOh3pXRGPAoHmZAtnl+uccXuxu/FFtAPtUm81Y7mx2i4LGG32gBMfRtGI55YAjdA7FQ/sVIxuQGwJRnth8DLY9Pm+YE2Eh/+ISJn7k3ec23dEvorzJDPGY6Xf56/lRYv36w+U8h2hsTn9d2GuEKBaTruKkjSd+w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=R5llBlNI; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="R5llBlNI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1711990402; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1LAUA7bfueGfw+ooJ+w3kZbmsPcMAiHJ2zm/1a2ap/M=; b=R5llBlNI65qlrqxnAw8XmTgK58In7OCInG1lcwDo3iV57J2PZfC0GfbyaH8nzp4CIYp6Jt 7vn5AK3X/YHlErQPVkC7hBI5LDzxtM2G94idLLRJ9tZZ7z5KtHkek5hxDz3ybbx+4fulkd en/q18vU3nr4Y7EE/JBqgzpk5NlhSps= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-473-fxJd7GLEMdC7vaKcTG2cTg-1; Mon, 01 Apr 2024 12:53:16 -0400 X-MC-Unique: fxJd7GLEMdC7vaKcTG2cTg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E414E811E81; Mon, 1 Apr 2024 16:53:15 +0000 (UTC) Received: from omen.home.shazbot.org (unknown [10.22.34.212]) by smtp.corp.redhat.com (Postfix) with ESMTP id F3CA23C21; Mon, 1 Apr 2024 16:53:14 +0000 (UTC) From: Alex Williamson To: stable@vger.kernel.org Cc: Alex Williamson , sashal@kernel.org, gregkh@linuxfoundation.org, eric.auger@redhat.com, Diana Craciun , Kevin Tian Subject: [PATCH 5.10.y 6/6] vfio/fsl-mc: Block calling interrupt handler without trigger Date: Mon, 1 Apr 2024 10:53:00 -0600 Message-ID: <20240401165302.3699643-7-alex.williamson@redhat.com> In-Reply-To: <20240401165302.3699643-1-alex.williamson@redhat.com> References: <20240401165302.3699643-1-alex.williamson@redhat.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 [ Upstream commit 7447d911af699a15f8d050dfcb7c680a86f87012 ] The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is initially NULL and may become NULL if the user sets the trigger eventfd to -1. The interrupt handler itself is guaranteed that trigger is always valid between request_irq() and free_irq(), but the loopback testing mechanisms to invoke the handler function need to test the trigger. The triggering and setting ioctl paths both make use of igate and are therefore mutually exclusive. The vfio-fsl-mc driver does not make use of irqfds, nor does it support any sort of masking operations, therefore unlike vfio-pci and vfio-platform, the flow can remain essentially unchanged. Cc: Diana Craciun Cc: Fixes: cc0ee20bd969 ("vfio/fsl-mc: trigger an interrupt via eventfd") Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Link: https://lore.kernel.org/r/20240308230557.805580-8-alex.williamson@redhat.com Signed-off-by: Alex Williamson --- drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c b/drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c index 0d9f3002df7f..86f770e6d0f8 100644 --- a/drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c @@ -142,13 +142,14 @@ static int vfio_fsl_mc_set_irq_trigger(struct vfio_fsl_mc_device *vdev, irq = &vdev->mc_irqs[index]; if (flags & VFIO_IRQ_SET_DATA_NONE) { - vfio_fsl_mc_irq_handler(hwirq, irq); + if (irq->trigger) + eventfd_signal(irq->trigger, 1); } else if (flags & VFIO_IRQ_SET_DATA_BOOL) { u8 trigger = *(u8 *)data; - if (trigger) - vfio_fsl_mc_irq_handler(hwirq, irq); + if (trigger && irq->trigger) + eventfd_signal(irq->trigger, 1); } return 0; -- 2.44.0