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 929223839A5 for ; Mon, 1 Jun 2026 07:15:12 +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=1780298114; cv=none; b=D0QPBlKStmJJqiXyAuG6vOBgpF76SljBV5GW4vsL5fpTisDKAivLTYFW/NiX8eaBkrNrY05C6dYNxi0nzNNYYLaKKsL7LENo3oP9K4Q64oy5byGc+QzCIpME7p6dkyDEGf8VBwHb/zLmWMJMOMUWSuJHluayK4qTdSf26wrSL48= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780298114; c=relaxed/simple; bh=D/r2HHFw1ttDeZs3wCOHPdORv/hVYFs4XvwSToWdU1g=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=OsNq+iChupfP0eden1DpqXKIezgulkLvnHhe64E6LZ9ehGPlWBci/YGT9RCcswC9JLIGTITdOMApBoaPUaR8P80x2Bu9+wNEhAbk/YWgSHO/FU3AZ7KqQGhvvT30dIBM1/Hus2/rCYtfEqClkrXzBZfY4VDIPkYW3BQpxv4Qoy0= 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=D0V1bXIA; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=tB1yRUI3; 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="D0V1bXIA"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="tB1yRUI3" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780298111; 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=1fvBsMVKeDZrNyh5hX3nwapbF4YMBNws5zjlgVw0ARU=; b=D0V1bXIAOr71Td559D2lxe9havmaj2d7w/6nz3hOmbrboL+USVYjrwQpd3mAKbnkRC+ZVr Pne/Si9COndcu2GxpEr5E8gvtiMk+Zg8viYEz8xrRdrdExs7eBz/35eMdVoHEB/mY3diS+ TEnLMQEoN2k1qD2U+RBRXeQUnzQeuJo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-391-lgYKCLDBOAK4D2RLWkeDoA-1; Mon, 01 Jun 2026 03:15:10 -0400 X-MC-Unique: lgYKCLDBOAK4D2RLWkeDoA-1 X-Mimecast-MFC-AGG-ID: lgYKCLDBOAK4D2RLWkeDoA_1780298109 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-45ef2bd566bso1511543f8f.0 for ; Mon, 01 Jun 2026 00:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1780298109; x=1780902909; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=1fvBsMVKeDZrNyh5hX3nwapbF4YMBNws5zjlgVw0ARU=; b=tB1yRUI3w2M5g1KbLamWXuqOfg3cYA7WBa3AoBwAraeg420HU12y/9BIK2AN11ySgY 7OGp7YvnsmVibImhSZRUjEjU6aPFYytzQAp5j39AIw7x97iwkMjidKN6lJ494RARx/A9 IPdbaoLpGXnNA7SxMEkdypSzortFSri+pxxY+M2O6P8wG4ebdbyUdsR1Cpmi4L3BnBDz IaIRx92vJZg44m/lYNyaATaCOw56BvEt3NwU6ns3x4+v6smS2rh3jlTJX8eGJUekgQGX zRsJXL+1iRNXjG9vCzlYvJN0ZeZRgd4m1I8BYZiKieoCkywnO0MkTMAtK55wnrKjclQE Lfeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780298109; x=1780902909; h=mime-version:user-agent:content-transfer-encoding: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=1fvBsMVKeDZrNyh5hX3nwapbF4YMBNws5zjlgVw0ARU=; b=eb6R6MBfZuTdtCS5fgVnBjU9GGHkW6wXj2kwfCmWmaYy+ICZ/q3kdH7h802t5/+g5B DJIRGftpYKpdvjhyOLMz/awGTjeoLoaDqUto/6zAgsgU4pQUpbqlg/UQyK2V4vzrjyhf NUWoVetGp8j0GPqCospoyHbp6SMNA0MiRZm1LfHOmUv32dytyt0fVskTVjtqTiyVfZMp TAX0doWXIWzFRXlnreHhqAsksa8p6EE3iXOZ2A7B2OWgWokVHC6mxRxRloPXEvrVWAjh +7AnMC0wOcxkQHbS1shbevOsYPmu41FTjqyTFOGO3UCwnpP22/wZj01z1CPAbYcgHNBn rmVg== X-Gm-Message-State: AOJu0Yz7YAEFemvSW8UYhOxvlyYUXeXey5ZgLdeGN9FdnjhibtFEDfxx e47h6AQLeZFGT1JK8tI053D8sOx11mx5CYo5rgjjJXQxC4b9HvGzgVzKmB6VBDVlSTAiNsLQbhl f/BIOY+zHYxMo+MfKL0H7Kk1ZpHw5U8FeFie/15BBToKZf58knspGIogjp9JPT8ohzmiuRZf5Zw == X-Gm-Gg: Acq92OGpIKUqz2G+qRRrsKJcVYvoCBzgmE/NCPejWkR/9K/NZS3kJ7pmkS7bwva5MFM k9JiSLljdM2o5F1DRv/ltiyMbEU6M6ABQ9QBpaRZNTo80SNfEwiBFhMGWq4yTyD62ogfimFmio3 bN2TZpzI9b4g8YxL/g7obckAl7XExpj1uHKcuZT+saxl1efmi96cdexX+3xfwyxSX3zTmbS1g8W EzD36bFIu6FCTeWEjWg3qCIh9RRckAENpCERoj5zYWs/459f37OEDRvc/E21FBV9Pal4mEsun04 MJcnHQvJ5vj7s4Ey9tPPnO2sAWFV15lL60zwtG7rL7Dm9EwLnsjbLKfSH1nJrauBAFA+zYz4EZn VRiwWU0UF4cGF2DpDlS/WUghn0pu3umPjlY7g X-Received: by 2002:a05:6000:2812:b0:45e:73b3:4515 with SMTP id ffacd0b85a97d-45ef6b8c2e1mr13618013f8f.35.1780298109110; Mon, 01 Jun 2026 00:15:09 -0700 (PDT) X-Received: by 2002:a05:6000:2812:b0:45e:73b3:4515 with SMTP id ffacd0b85a97d-45ef6b8c2e1mr13617975f8f.35.1780298108710; Mon, 01 Jun 2026 00:15:08 -0700 (PDT) Received: from [192.168.1.167] ([185.168.96.228]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef356b129sm28983761f8f.32.2026.06.01.00.15.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jun 2026 00:15:08 -0700 (PDT) Message-ID: <76628c68336037b0d652456cf2033d3b51399a09.camel@redhat.com> Subject: Re: [PATCH v3 05/13] rv: Fix monitor start ordering and memory ordering for monitoring flag From: Gabriele Monaco To: Nam Cao , Wen Yang Cc: linux-kernel@vger.kernel.org, Steven Rostedt , linux-trace-kernel@vger.kernel.org Date: Mon, 01 Jun 2026 09:15:06 +0200 In-Reply-To: <87ik82ycl3.fsf@yellow.woof> References: <20260530141652.58084-1-gmonaco@redhat.com> <20260530141652.58084-6-gmonaco@redhat.com> <87ik82ycl3.fsf@yellow.woof> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.1 (3.60.1-1.fc44) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Mon, 2026-06-01 at 08:55 +0200, Nam Cao wrote: > > diff --git a/include/rv/da_monitor.h b/include/rv/da_monitor.h > > index a7e103654..60dc39f26 100644 > > --- a/include/rv/da_monitor.h > > +++ b/include/rv/da_monitor.h > > @@ -82,7 +82,7 @@ static void react(enum states curr_state, enum > > events event) > > =C2=A0static inline void da_monitor_reset(struct da_monitor *da_mon) > > =C2=A0{ > > =C2=A0 da_monitor_reset_hook(da_mon); > > - da_mon->monitoring =3D 0; > > + WRITE_ONCE(da_mon->monitoring, 0); > > =C2=A0 da_mon->curr_state =3D model_get_initial_state(); > > =C2=A0} >=20 > Looking at this again, do you need to change it to >=20 > static inline void da_monitor_reset(struct da_monitor *da_mon) > { > WRITE_ONCE(da_mon->monitoring, 0); > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 smp_mb(); > da_monitor_reset_hook(da_mon); > da_mon->curr_state =3D model_get_initial_state(); > } >=20 This order won't work. Monitor reset relies on monitoring to be true to stop the timer. The same function is called also on monitor start and there the timer may not have been initialised yet, we use monitoring to discriminate the two. > To prevent another task from seeing monitoring=3D1 while the timer is > already cancelled? I'm not sure what could go wrong in this scenario. Perhaps another event that could start the monitor would miss the chance because it doesn't see a reaction occurred (monitor looks like still running)? Or a concurring event would run on top of a reaction, potentially moving the state machine further or causing another reaction. Those aren't really disasters and I think could happen also without enforcing an order with the timer, nothing checks the timer's status. Following events don't even need to know whether the timer was armed at all, in the worst case we may be stopping twice. Am I missing something here? Thanks, Gabriele