From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-94.mta0.migadu.com [91.218.175.94]) (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 0C7E1432E80 for ; Tue, 25 Aug 2026 12:33:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.94 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787661187; cv=none; b=tRT4aYn9qHx0uxkuLjMt8ts9vTM6fx+qgCVXu5WyEJElGXIEWaaiZ3M4EGCW6k4I53ulIImCKisVf71BC2mNkdZ1eGHOGgvc4+hRn9GGGx3KiSGuUCUcblQxxA6wbygSrdYu0oaX9A4N0VMfoSxsofslWZ3dMroqfTys2BNpfbw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787661187; c=relaxed/simple; bh=/wnW7DbYIJvddAqh3pqpM7I09WXnxpDrlHu1DS0K5pQ=; h=MIME-Version:Date:Content-Type:From:Message-ID:Subject:To:Cc: In-Reply-To:References; b=bJqzxsv1+VaBmlRl7WVKzvLUBulsDbni7e7NVlNFEi/upxw8sOIQd+JSLwlhJCbB/xi2lbQpizZAEY7YhV42pMo18PniOlYl492UhcmsrOLVMGtCyv3iclCnWI7cH5F4f++qrl4S61MT2zAzSeRF1OVM8922u/Nt+1KiGCmZ4GE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=N/skSKzp; arc=none smtp.client-ip=91.218.175.94 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="N/skSKzp" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=/wnW7DbYIJvddAqh3pqpM7I09WXnxpDrlHu1DS0K5pQ=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1787661184; v=1; x=1788265984; b=N/skSKzpcipCQnkoPUqjbTxihUxkbfoijIkO+yG2ZHePb7bjBqL3hbTgk9VuR5iqxRWsrzVk 2rx2cIdAqrgzUCUzu7kDukdDO2LJBer9WZZgzYmq0ONRX1o8wsgFCz07zPO56jt3JbR4J0xtYvF ZxIhCgJaBgl3/aiAMO6ESEz8= X-Envelope-To: linux-kernel@vger.kernel.org Received: from webmail.migadu.com (2001:41d0:303:fc7a::) by smtp.migadu.com with ESMTPS id 1d302fce12a8bbff; Tue, 25 Aug 2026 12:33:03 +0000 X-Mizu-Trace-ID: 1d302fce12a8bbff X-Migadu-Flow: FLOW_OUT Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Tue, 25 Aug 2026 12:33:03 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Zqiang" Message-ID: <494f3e0cdb3692bf13690f4cddd3b40098b51627@linux.dev> TLS-Required: No Subject: Re: [BUG] srcu: false-positive WARN in cleanup_srcu_struct() after 78a38cbf6f20 To: "Sunho Park" , rcu@vger.kernel.org Cc: paulmck@kernel.org, linux-kernel@vger.kernel.org, "Sunho Park" , syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com In-Reply-To: <20260824105625.3725157-1-shpark061104@gmail.com> References: <20260824105625.3725157-1-shpark061104@gmail.com> >=20 >=20The main crash report [1] which is tested on non-merged commit 6b8c8a= f514d7 > 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 fa= lse > positive because irq_srcu does not use call_srcu(). >=20 >=20However, 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() pr= operly. > Although my syz test command [3] failed to reproduce, it was reproducib= le > in my QEMU environment built with the .config of the report. >=20 >=20I found out that the return value of rcu_segcblist_n_cbs can be nonze= ro > even after srcu_barrier() because of the srcu_barrier_cb() that srcu_ba= rrier() > inserts at the end of the queue. The length of cblist is decreased afte= r > srcu_invoke_callbacks() finishes invoking all callbacks in a batch. But > srcu_barrier() may return when all the srcu_barrier_cb() are called, br= inging > the counter to zero, even if srcu_invoke_callbacks() has not yet decrem= ented > the length. So checking cblist length before flush_work() is inaccurate= . If srcu_barrier() be invoke before srcu_cleanup(), and after srcu_barrier= () completion, there are no concurrent srcu grace period start again (e.g. c= all_srcu() calls),=20 the=20timer_delete_sync() should return false, the rcu_segcblist_n_cbs() will not be check. Or did I miss something? Thanks Zqiang >=20 >=20By the comment of srcu_barrier(), it guarantees that all the previous= ly > registered call_srcu() callbacks are completed. Therefore srcu_barrier(= ) > did what it said, only the length of cblist was not updated. I think th= ere > are two options: >=20 >=201) Not to check the length of cblist before flush_work() > 2) Make srcu_barrier() guarantee the length of cblist is adjusted when = it returns >=20 >=20[1] https://lore.kernel.org/all/6a78d191.b50370da.49fe0.0042.GAE@goog= le.com/T > [2] https://lore.kernel.org/rcu/01484cd339ea024dd7c01f02a9781f00e67cb52= d@linux.dev/T > [3] https://lore.kernel.org/all/6a8bc111.91706f20.16b6e3.02cd.GAE@googl= e.com >=20 >=20Reported-by: syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com >