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 008B43385AB for ; Wed, 21 Jan 2026 18:13:54 +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=1769019236; cv=none; b=S6FxQdn0lCD7yVzs1RNXNq2/0XJicL2vaoUB1WtKvGqmZ3jQWOWg9YqzB8AEh7ltRmnFOG/oJRVSvc53OUTNsDvJ3mByWr9oeoVfHnlDoNu+qxFMtZv8j+KFOQycQpPWRIXAt/RzdCjAwpchseMdAsw41fYIXnzNoGuzIcigHCs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769019236; c=relaxed/simple; bh=C28c/EW5CuQsoDdUsx8dGqG9K8fs0K81D2a2muNH+l8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=u+XDr1xngho6yoB277BV6hGTqxP7bz8pSnabtBRbl2JXi0MYcN9hetpftIdbasBX+q+MFubeOK2CBaQ6naexnud4LSnZrGtdiROQ6B2ZKseA4WU2qfUP5tPqu6tyvCckM1uTT7xDnDaep2qaWdNa94gJvDLH8JZRJZJnDqmA26Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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=euHzJOwv; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=jho8CDq+; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine 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="euHzJOwv"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="jho8CDq+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769019234; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ynpg/cJ+vd3nqyV8BLe/SIqtaIrKy7cylnYrcUttxQg=; b=euHzJOwvNR8mzI4yeHSqnHqjyMroC1jphtvHlKNZ8G/SrQNoBwC2xIDHzkOfli4HUiZ9I7 +Zv1Dnd7rmYKDDsCkWH122bL8dqg0V3iYh8hx2elkCTnTnMj3D8YAwovOtQNWce0hV5GfA H2vNvkD5c1LJxvACqLo6wRpaoGGFofk= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-211-2otNlcrHPy-CXPc_TWds1Q-1; Wed, 21 Jan 2026 13:13:52 -0500 X-MC-Unique: 2otNlcrHPy-CXPc_TWds1Q-1 X-Mimecast-MFC-AGG-ID: 2otNlcrHPy-CXPc_TWds1Q_1769019231 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-435a11575ecso56279f8f.2 for ; Wed, 21 Jan 2026 10:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1769019231; x=1769624031; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=Ynpg/cJ+vd3nqyV8BLe/SIqtaIrKy7cylnYrcUttxQg=; b=jho8CDq+PeZcjS/nSY9XrSc5iVXaebdV6mQPtnJrFRnrhgOAuMr/arUsuVWGO0o8By byNQas67i5oic58YInoEFtrbi2kmBT4AxIGatxkC3SswNwwe7DuOgrj+hfkmJOYvUtfY SdZUk+UNQAnZ5U8bQHx5GGf0I9mxO5aR1174tUJNECQQZJmC53I5YDrN0eyYNtEKQVaY R8XDBY3Q3PrDmQ6pDU2zlEWltNy9HZJ/x4uwD0NBhivdTs6cepzJnJbLDaHiTRXNA2LJ EEuLMDP+A4nL8mZ9G7hIEsGkHj97o+ijCR0EdbXDgni5C3oZmjqYTjziZGUBBtLpuxKY L4rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769019231; x=1769624031; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ynpg/cJ+vd3nqyV8BLe/SIqtaIrKy7cylnYrcUttxQg=; b=B5riKDGU0H007VCtqaU16DhXsVs+3xCXO+Wu0dVYOpDiWxG2cXFvMklN0slrkzensV 2qfvun5GLv6bpbt0EuenV1gn1em8pHpLJhDqADUBfaWaq/iJVaiZwNa7sQfOfsVPVEVF MyNAfTLVWHLrCuSD9m9R4LHb9vrgPL3bMWC0MEMyLVZ84YVnwqMelzGJuOfclmbxFsRa 6VzJoSgscze1CvX+gzI+8k1RiB/J9r5WACkEMk43qkN3evFEHqSwbfTGl1cf7S5tEYqi odOlUutH3DxTFjzWoWPd1RhXO2xYUFo2DYCbfRKSGxHcI0LieMRE3yYkjfL4Iqn1T7LG ZEKg== X-Forwarded-Encrypted: i=1; AJvYcCUBVTO4CLNfcx/sXL8tqYfzbOVces5B2JTFM0WYADI5q7XP94IA62j1ZS08EB6IXPZ5XuC93SGXc4jVa2Y=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0rSywSAKyrfDEXyKNrMepkU+gigkz5NI12RgwY/+erT/Rmj8c HspkRHfHIo7dWmKZ83XKzq7HslwQO4IRwiM+QYGzKqhF3JUTabb0uAefdpVIBVk4YGmiFEkcEtc HMwdJaiuJhVmYVB2ytuSUDsrIYS9dCsVXd/6CWZCr4N35s6F/xPNygDScSXtol0jPqA== X-Gm-Gg: AZuq6aK3df72DEh/uSEZqvcQIx8/nRO4O1G4VHmcnXQa50Z+UifadTMdba9+GC1aBXV JmY2G7HprbITj2Y/QsLrdtjSHyHV/Uskaei7bTAFcY71663cdn/iGy/Jvnpdg/6rZAc/ea8H4dl C/+YiutE4I2+MgHzu6+f00av50dKaNGuBJWeASfVo8mjjsdzKfK74J2L3C76NJ74jAOm2Ls0r9p 4T0CPDobO9hfbP+fgJUxDYilCLypRlZIJQjEhcdOyUWjh89oFIJRis0phw9GbZgP+0DKIZ3PqBo h0NqDMvvvu0/BaxM6B5wMIoT3LPJpBd7LonkplBDGONoi77N5sZtjHGVeMJihdu/RbyNSXhLU1/ Slt3ov2EEWPAXHp2zBzG+0nnpwOS19ks+OZvl3tQsqzzmlgrysvOvJAW1wzCG7vdWlCBFh5KH8C k0I7Ip4OycujT8Dw== X-Received: by 2002:a5d:4688:0:b0:435:95c9:6891 with SMTP id ffacd0b85a97d-43595c96bcamr7351154f8f.42.1769019231267; Wed, 21 Jan 2026 10:13:51 -0800 (PST) X-Received: by 2002:a5d:4688:0:b0:435:95c9:6891 with SMTP id ffacd0b85a97d-43595c96bcamr7351114f8f.42.1769019230831; Wed, 21 Jan 2026 10:13:50 -0800 (PST) Received: from [192.168.10.48] ([151.61.26.160]) by smtp.googlemail.com with ESMTPSA id ffacd0b85a97d-43569921da2sm38550536f8f.1.2026.01.21.10.13.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jan 2026 10:13:49 -0800 (PST) Message-ID: <5bea843b-dec8-4f15-bb7c-1d0550542034@redhat.com> Date: Wed, 21 Jan 2026 19:13:43 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: possible deadlock due to irq_set_thread_affinity() calling into the scheduler (was Re: [PATCH v3 38/62] KVM: SVM: Take and hold ir_list_lock across IRTE updates in IOMMU) To: Thomas Gleixner , Ankit Soni , Sean Christopherson , Marc Zyngier Cc: Oliver Upton , Joerg Roedel , David Woodhouse , Lu Baolu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, kvm@vger.kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org, Sairaj Kodilkar , Vasant Hegde , Maxim Levitsky , Joao Martins , Francesco Lavra , David Matlack , Naveen Rao , Crystal Wood References: <20250611224604.313496-2-seanjc@google.com> <20250611224604.313496-40-seanjc@google.com> <42513cb3-3c2e-4aa8-b748-23b6656a5096@redhat.com> <874iovu742.ffs@tglx> <87pl7jsrdg.ffs@tglx> From: Paolo Bonzini Content-Language: en-US In-Reply-To: <87pl7jsrdg.ffs@tglx> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sorry, not sure how the previous email ended up encrypted. On 1/8/26 22:53, Thomas Gleixner wrote: > On Thu, Jan 08 2026 at 22:28, Thomas Gleixner wrote: >> On Mon, Dec 22 2025 at 15:09, Paolo Bonzini wrote: >>> Of the three, the most sketchy is (a); notably, __setup_irq() calls >>> wake_up_process outside desc->lock. Therefore I'd like so much to treat >>> it as a kernel/irq/ bug; and the simplest (perhaps too simple...) fix is >> >> It's not more sketchy than VIRT assuming that it can do what it wants >> under rq->lock. 🙂 > > And just for the record, that's not the only place in the irq core which > has that lock chain. > > irq_set_affinity_locked() // invoked with desc::lock held > if (desc->affinity_notify) > schedule_work() // Ends up taking rq::lock > > and that's the case since cd7eab44e994 ("genirq: Add IRQ affinity > notifiers"), which was added 15 years ago. > > Are you still claiming that this is a kernel/irq bug? Not really, I did say I'd like to treat it as a kernel/irq bug... but certainly didn't have hopes high enough to "claim" that. I do think that it's ugly to have locks that are internal, non-leaf and held around callbacks; but people smarter than me have thought about it and you can't call it a bug anyway. For x86/AMD we have a way to fix it, so that part is not a problem. For the call(*) to irq_set_affinity() in arch/arm64/kvm/'s vgic_v4_load() I think it can be solved as well. kvm_make_request(KVM_REQ_RELOAD_GICv4) will delay vgic_v4_load() to a safe spot, so just cache the previous smp_processor_id() and, if it is different, do the kvm_make_request() and return instead of calling irq_set_affinity(). vgic_v3_load() is the only place that calls it from the preempt notifier, so this behavior can be tied to a "bool delay_set_affinity" argument to vgic_v4_load() or placed in a different function. Marc/Oliver, does that sound doable? Paolo (*) kvm_sched_in() preempt notifier -> kvm_arch_vcpu_load() -> kvm_vgic_load() -> vgic_v3_load() -> vgic_v4_load()