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 A402C31ED93 for ; Mon, 6 Jul 2026 14:02:16 +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=1783346538; cv=none; b=nyLPOkhDxy0Eyhu/Rx/uKwqWhOnF257TVfs928QuGOE+lgYnD242CMKRdy9lzn8JkxMFTT3DUTPJakOT3ABXjrxMKTqj635uKUDce5e6RtspPnNkTgpHdNO48UhDrq/TO3AaXYJstmNmnI4NE/2rIc950LjqzxTt/eoFM4aj5jM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783346538; c=relaxed/simple; bh=+JqLFX616JDwKbMQz43fj2DNhDNXcrBgecFC751sJ8Q=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=eYB3cNyC4v4q5fPGt90DhLzXVXdAd9fAtZNFKkZzckQAS1VscDhlmJPomIrgVr+Hxc9QJc+dTcyknZMKgzKVEkc+uS5oC0pkLPgfM/ThlOu6Lp/IzV/rLMOk6+sxO3XPwjOk/XTLvP8qsEdJri7PE3Lpet3fnL7v3PB+y7rYk4M= 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=bGXPKMat; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=Ehsvkm1f; 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="bGXPKMat"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="Ehsvkm1f" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1783346535; 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:autocrypt:autocrypt; bh=+JqLFX616JDwKbMQz43fj2DNhDNXcrBgecFC751sJ8Q=; b=bGXPKMatzyDXtnMiUvk1MwnFYZNsk/s4kBe/m9hEb5gxaxR/U6NDG36XZ3zY4XJzoYKM6h XE4Uuh2gaNMPSnqEbyi+gBZ/KXcntBsrq7691i13WH+iET1RORAHj5vu1UOo4uVmpmkHyn JwCmXIFh50DDNQKjF+BIUsyPCcskDLE= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-107-3sfg7KpJMOmiUlEJM1cezQ-1; Mon, 06 Jul 2026 10:02:14 -0400 X-MC-Unique: 3sfg7KpJMOmiUlEJM1cezQ-1 X-Mimecast-MFC-AGG-ID: 3sfg7KpJMOmiUlEJM1cezQ_1783346532 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-493bd52dae6so19973285e9.0 for ; Mon, 06 Jul 2026 07:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1783346532; x=1783951332; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=+JqLFX616JDwKbMQz43fj2DNhDNXcrBgecFC751sJ8Q=; b=Ehsvkm1f7guLUyS0/KLAbquN20jjTMtAaQTXUi31C73dxD0qlR4NWKC8GMLH+jycws 5Cggp4L9flCkYCJxWFG09ok1KEYFdnfYmcpN93gKLyZhIrXJV+izEohIqAhDt8iK9gNY Xilu+BBjWfHQItQLlWAEom/eTW/oDCe9yfgtiIrEvyZ6iHFrd5T1mWQ1IbhyiSSn68Wx 4ax78V1+1uIpRIVkfLOi3PiQrd/gthaYDPsNATZkAZBFeC+hLDMluLoY7rzGZ3Ss6Blu 39BGI/+tmAiwKbG6RYi+LgGL/hPlYe7DRzWuKxwVV+7U/JgxFDPTIX1Y5KZcQHuMz/hy hoDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783346532; x=1783951332; h=mime-version:user-agent:content-transfer-encoding:autocrypt :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+JqLFX616JDwKbMQz43fj2DNhDNXcrBgecFC751sJ8Q=; b=DWgYkSCziHhv14DdXHWztpr0r5GRDIxC18sC6a9/cNse4Iv6e5gX41cxRtuXhszbV+ RiCl8D5fcG9chnWjqVGajHL/XUzMUSVFj/Pn3rLrXZ+mymUXDg2aiQ7jPeTSeWklA8fp l4Yws5kl4E1+1ru5oAWXA1DqAZvsxHNhzF8dcCOAGKuQRHPWu4pWDQZnn+FiJVXBTxBQ 6wyOXYb+oAMRiFAh1w+CSywwxY/Yduo04klnqw+UYhpBmnKGcPpKVXj9m/ub5rVUqrv8 HiynH/LWqg4+6zjrya+cOAY4oDRLMa7zp6N/aF5pM13g807rT/tx3ucvsmTRBDFIJ8A7 W/cg== X-Forwarded-Encrypted: i=1; AHgh+RrwEScQedRZwWLW6zRSN2Q4Av5A6ad/Ul2vPxLB4FZd3dHZFlXJyARnIIN1SWrIYUEB5SrowKltFN9PkYI=@vger.kernel.org X-Gm-Message-State: AOJu0YxMTTxfPZiw1BRj3Z6YT6YVqfGvOZ4lWwhrm8Kij9YM/ufSM8sP 6xAjUIbmRBs79mBvnTGisxp3Foxkw7stG5luQ/GcCzxQBq1h8TjA+si15HBwev9BCVDp13ZKtOM iTe3zMZ8rgrRiQ5TG+R+Xh8WyQDuErAeJfSEuOPIvL4RNOBhVBI5Mz7V1ZdfEodwe5A== X-Gm-Gg: AfdE7clATUrqrnap9XZUpbcM1ATiAFSGyeU1DkPGOel4wgUERwKi2//qJ3Q7IhnZMGy lH8hcdVdi4nyRzPAniSD57qVE+U9gR8mroEkowwWX8n8q3pkd33WXO5sTF/DtrQ/jr99ggDQ8xa LpmSYQIxXcbOkzxvMTg9qJORyYdh3dKKIcfIX1BjWRsumu+X8i+4IzIsOzl1Nvji2pHvEG7JDgX euqzsJh0eqoaD2emUFOkM18jkWcjzC7iTzENX20GAqvChtJvPo/TO4WUg6ngu9wNi9f2DhuXVQL NvZvTSS3e2zlK7Nu1sNkf5komishv+173Q7wzQYhO1dM8QVqv/HPOlbH8mys29YQYgA7pXlguEk G0Q3DbP5voO/hINsRWZEYFPWwBzWEPQRGybEHuqa6aWSeATdjlQDf8HwJXP40zapTo6/2IKYbK5 oAlasn X-Received: by 2002:a05:600c:8108:b0:492:6f9b:572e with SMTP id 5b1f17b1804b1-493df083a4amr7477225e9.37.1783346532040; Mon, 06 Jul 2026 07:02:12 -0700 (PDT) X-Received: by 2002:a05:600c:8108:b0:492:6f9b:572e with SMTP id 5b1f17b1804b1-493df083a4amr7476565e9.37.1783346531415; Mon, 06 Jul 2026 07:02:11 -0700 (PDT) Received: from gmonaco-thinkpadt14gen3.rmtit.csb (212-8-243-115.hosted-by-worldstream.net. [212.8.243.115]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47a9e4d83bdsm25576171f8f.13.2026.07.06.07.02.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jul 2026 07:02:10 -0700 (PDT) Message-ID: <3c53f741559f834986e976b524c5ded90bbd5627.camel@redhat.com> Subject: Re: [PATCH 1/3] rv/reactors: fix lockdep "Invalid wait context" in rv_react() From: Gabriele Monaco To: Thomas =?ISO-8859-1?Q?Wei=DFschuh?= , wen.yang@linux.dev Cc: Nam Cao , linux-trace-kernel@vger.kernel.org, linux-kernel@vger.kernel.org Date: Mon, 06 Jul 2026 16:02:08 +0200 In-Reply-To: <20260623112942-4943fc6a-c1d5-4eed-a91f-66b3a034caa7@linutronix.de> References: <20260623112942-4943fc6a-c1d5-4eed-a91f-66b3a034caa7@linutronix.de> Autocrypt: addr=gmonaco@redhat.com; prefer-encrypt=mutual; keydata=mDMEZuK5YxYJKwYBBAHaRw8BAQdAmJ3dM9Sz6/Hodu33Qrf8QH2bNeNbOikqYtxWFLVm0 1a0JEdhYnJpZWxlIE1vbmFjbyA8Z21vbmFjb0BrZXJuZWwub3JnPoiZBBMWCgBBFiEEysoR+AuB3R Zwp6j270psSVh4TfIFAmjKX2MCGwMFCQWjmoAFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgk Q70psSVh4TfIQuAD+JulczTN6l7oJjyroySU55Fbjdvo52xiYYlMjPG7dCTsBAMFI7dSL5zg98I+8 cXY1J7kyNsY6/dcipqBM4RMaxXsOtCRHYWJyaWVsZSBNb25hY28gPGdtb25hY29AcmVkaGF0LmNvb T6InAQTFgoARAIbAwUJBaOagAULCQgHAgIiAgYVCgkICwIEFgIDAQIeBwIXgBYhBMrKEfgLgd0WcK eo9u9KbElYeE3yBQJoymCyAhkBAAoJEO9KbElYeE3yjX4BAJ/ETNnlHn8OjZPT77xGmal9kbT1bC1 7DfrYVISWV2Y1AP9HdAMhWNAvtCtN2S1beYjNybuK6IzWYcFfeOV+OBWRDQ== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.2 (3.60.2-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-06-23 at 11:38 +0200, Thomas Wei=C3=9Fschuh wrote: > This now allows reactors to take (raw) spinlocks. The original idea was > to not allow that as a reactor can be called from LD_WAIT_FREE context. > So I am not sure this is the right fix. Not that I have a better one > available right now. As far as I understand it, LD_WAIT_FREE is fairly impossible to apply on preemptible code (here we see it hit by an interrupt). Since we kind of have to allow raw spinlock to avoid this (even if we don't= take them explicitly), why wouldn't a reactor ever be allowed to take raw spinlo= cks? Technically it wouldn't be wrong to take locks from RV monitors, although m= ost monitors don't do it explicitly. If we ever happen to take the wrong lock explicitly from a reactor triggere= d by a nasty event (e.g. sched_switch), I believe lockdep would still be complai= ning down that path, so we probably don't need to be too strict in rv_react(). Obviously we don't want to disable interrutps for LD_WAIT_FREE to hold eith= er. Am I missing something? Thanks, Gabriele