From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 67952A0519; Mon, 22 Jun 2020 17:17:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C2C501D734; Mon, 22 Jun 2020 17:17:51 +0200 (CEST) Received: from inbox.dpdk.org (xvm-172-178.dc0.ghst.net [95.142.172.178]) by dpdk.org (Postfix) with ESMTP id F12431D732 for ; Mon, 22 Jun 2020 17:17:50 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id B5557A051C; Mon, 22 Jun 2020 17:17:50 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Mon, 22 Jun 2020 15:17:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: other X-Bugzilla-Version: 19.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: davidajackson2013@gmail.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 491] Timers synchronously resetting or stopping other timers as part of their callback can cause hangs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" https://bugs.dpdk.org/show_bug.cgi?id=3D491 Bug ID: 491 Summary: Timers synchronously resetting or stopping other timers as part of their callback can cause hangs Product: DPDK Version: 19.11 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: other Assignee: dev@dpdk.org Reporter: davidajackson2013@gmail.com Target Milestone: --- Created attachment 108 --> https://bugs.dpdk.org/attachment.cgi?id=3D108&action=3Dedit Patch for test_timer.c to reproduce single lcore issue If a timer's callback function calls rte_timer_reset_sync() or rte_timer_stop_sync() on another timer that is about to expire (during the = same call to rte_timer_manage()) on the same lcore, the call to rte_timer_*_sync= () will loop indefinitely, causing a hang. rte_timer_manage() works out which timers are going to be expired in a given iteration, and then sets them all to state RUNNING. When a timer is in runn= ing state, it can only be changed to CONFIG state (in order to reset or stop it= ) by the owning lcore if it is the timer that is currently running/popping. Any timers that attempt to reset other timers synchronously when they are in RUNNING state will wait indefinitely for that timer to have been run by rte_timer_manage(), which is itself then waiting for this call to have completed. I've attached a patch file for test_timer.c which adds an extra timer to reproduce this. It might take a few runs to trigger the test to hang, and adding a log to rte_timer_reset_sync() aided seeing that this was the cause. I have reproduced this on 19.11, although I believe this reproduces on both earlier and later versions. There is a second part to this bug where this can also happen between lcore= s, although I have not managed to get a test to reproduce this. If two lcores = (A and B, say) run rte_timer_manage() such that two timers (say A1 and B1) are being run at the same time and A2 and B2 are two timers about to be run on their respective lcores as part of the same rte_timer_manage() calls, if A1= 's callback tries to (synchronously) reset B2 and B1's callback tries to (synchronously) reset A2, this causes both lcores A and B to hang for the s= ame reason as in the single lcore case. --=20 You are receiving this mail because: You are the assignee for the bug.=