From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42C7D408008 for ; Mon, 24 Aug 2026 10:56:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787569007; cv=none; b=tzdhYduM83xNv7oEbbcrLIMzfAlxPCG61IMzEKK9ekUpSQcqI95zseNF7GKnuTIXlvzvLq9N/yrTPDGB/iap+FsKjIVUL93ujgYkoTt+7C7Ol3am2edkQCOIH2O5sUVCmsfWLllPF/eXyXepfSlL90Nzp2UpnbcBOpmvHQUXcxY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787569007; c=relaxed/simple; bh=HAVhEo41ftBXk2eGrSZviX7ckEMXwirfUSQXIvaJGVw=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=EmcZoz1ZSVVNvxHQ7IGBSqkcUliIC91fcO4DNPf05gVehUE6jClm2v5EyCKeMXXzRlZ/rBgJuOmm4QdIzvllpKk/jPOsbAqmCgvOXMl7Pm4sUv0c6C5BvRaaxSJzBZNP+32S4uvhxoySjsy5TF2z339TmuWZjI9cpL9MFxfgD8w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PM2XTxns; arc=none smtp.client-ip=209.85.210.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PM2XTxns" Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-84faf87d19dso3245762b3a.3 for ; Mon, 24 Aug 2026 03:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787569006; x=1788173806; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=HAVhEo41ftBXk2eGrSZviX7ckEMXwirfUSQXIvaJGVw=; b=PM2XTxnsESdIsfjOTRga8vtAz3QPD2NeF9gStLX2lj+Svxb5Av8yKMWpoA8z2WVr+/ EjbLC5ZHr1h/56WCAi3HXuovn+n7cBNFoAIJj/FPXB4RmkJhgo0o9DLM0CYGzE86VHnI w7nlM/ZkmfphsO0GPWBBskDSWgWuwnXf4zRh881W23d5FQsehkZMeUL32qUJVfaLp6U7 b6tDhnU1zDZNxbsQSeMg3mg5Tg3PEqJzwjHjx9N2KvcQAuFPa2L547Gfd6nmH4QXFZx8 S+6i3lvt1vl86hN4s/i4TxS3bmnb7CH0Hp/pIYs0m4oduTanBSimT4sf0tXP4cp76plT j+qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787569006; x=1788173806; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=HAVhEo41ftBXk2eGrSZviX7ckEMXwirfUSQXIvaJGVw=; b=tKnsjiexWXkl/gCYEQ9kz7alcNqnZ0q02kGoXo4KUW1c2zE1wAmncHjD70bK0H2CQ6 Q1ZLTtxy2r6/iRRmM2oiybKYG1dG9lv6Z2O7vJX3YBGu8YVG5QWEqZJNLD2USTF4nwE4 D+dgURVn+xfJ9c3Pf0Y/cfAghnQuMX95bDVw55rcP0+POCqh3WagInByEIOlpFcTJKhP an1rlupoUwtjtKLemSEG7jVDRIbAye+pCK64A8a6c4PYvfVYI/MBHNzER6hgoj4N+81G FXUNwr4eNQmt/i5T5doO0T1JdY3u5C5nNcTFPlNH9RiuGX0anwPDPe4fIAI3PtKo4HGH c0fQ== X-Forwarded-Encrypted: i=1; AHgh+Rq+tfKiAn1/i6eFH+2dj0n7RacMDFCd5ffaXDmi8uiF0x0Z+6owZ1kKisVmSqBK5k7FkSEH8O+WmZ1TfmE=@vger.kernel.org X-Gm-Message-State: AFuF++nUvr/WDvQNH7ORJ+8MrKYoaZwSxVSJTFVcuCJZJ9/tGZ/QTxc1 ey+1azKLeM4lbiqfZa9/LOiv19zkvTk4zO5xqwgMZrE7/B114FFNRDGQ X-Gm-Gg: AR+sD12V6tq9OLiHZTIGtFn4t73hxPceD+ZsUJHa//Y1LKG0DTWBar6BZqPr4N2+nqW b8+zXTE16snMpeuXLPVqhd/wxvP7Ql4kJc3zJPGIuMjCX5a8RsZ/zf7BYUBe4254I2tlPmsdYkX TBCLLnVwYkVsZlcSWucoiK2peA7gfLu+/51C+K7IGNTFCgQQzgEWSvUKWVEI8T5TPvXKy+imrYb EPDXZBHtH6P0Qh10izEtsnjGzcxlJSvvMV3P9pFQBJishcz7FOCF0uuszUBLZ2aEb6L5/Z/S35F vuH6t12ktro/uEaa0jN8NpqbVH3l8s+QiuT6RMqdEvCdDewwvEBjGe3YE9EB+xPbscRrihMC+yt 9w0QiAOK2MGu1kLQ8PVrjO5c82RmZxSINjgTZru47/uh5LrpYDtLcPgfR1SIlLqaGpJlvsoAh8j IyIhEAuwWZl0fn1/WKW79WM+hh23o70U1Y8kXIG9Osuf4RAtN5a02TcULoDOlLOaqKHoD/zp+hn fHgw7tI4m+BixiEFg== X-Received: by 2002:a05:6a00:300c:b0:848:4859:a45 with SMTP id d2e1a72fcca58-8520b96630dmr32205642b3a.2.1787569005520; Mon, 24 Aug 2026 03:56:45 -0700 (PDT) Received: from shpark-MS-7E27.tailee9dcb.ts.net ([218.49.81.87]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-cc199daed9asm913911a12.5.2026.08.24.03.56.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Aug 2026 03:56:45 -0700 (PDT) From: Sunho Park To: rcu@vger.kernel.org Cc: paulmck@kernel.org, qiang.zhang@linux.dev, linux-kernel@vger.kernel.org, Sunho Park , syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com Subject: [BUG] srcu: false-positive WARN in cleanup_srcu_struct() after 78a38cbf6f20 Date: Mon, 24 Aug 2026 19:56:25 +0900 Message-ID: <20260824105625.3725157-1-shpark061104@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit The main crash report [1] which is tested on non-merged commit 6b8c8af514d7 is caused by the single-condition WARN_ON(timer_delete_sync(&sdp->delay_work)) in cleanup_srcu_struct(&kvm->irq_srcu). As discussed in [2], it is a false positive because irq_srcu does not use call_srcu(). However, the merged WARN_ON(timer_delete_sync(&sdp->delay_work) && rcu_segcblist_n_cbs(&sdp->srcu_cblist)) is also triggered in cleanup_srcu_struct(&kvm->srcu) which is called after srcu_barrier() properly. Although my syz test command [3] failed to reproduce, it was reproducible in my QEMU environment built with the .config of the report. I found out that the return value of rcu_segcblist_n_cbs can be nonzero even after srcu_barrier() because of the srcu_barrier_cb() that srcu_barrier() inserts at the end of the queue. The length of cblist is decreased after srcu_invoke_callbacks() finishes invoking all callbacks in a batch. But srcu_barrier() may return when all the srcu_barrier_cb() are called, bringing the counter to zero, even if srcu_invoke_callbacks() has not yet decremented the length. So checking cblist length before flush_work() is inaccurate. By the comment of srcu_barrier(), it guarantees that all the previously registered call_srcu() callbacks are completed. Therefore srcu_barrier() did what it said, only the length of cblist was not updated. I think there are two options: 1) Not to check the length of cblist before flush_work() 2) Make srcu_barrier() guarantee the length of cblist is adjusted when it returns [1] https://lore.kernel.org/all/6a78d191.b50370da.49fe0.0042.GAE@google.com/T [2] https://lore.kernel.org/rcu/01484cd339ea024dd7c01f02a9781f00e67cb52d@linux.dev/T [3] https://lore.kernel.org/all/6a8bc111.91706f20.16b6e3.02cd.GAE@google.com Reported-by: syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com