From nobody Wed Jun 12 03:23:53 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VzW9M3V6kz5NZJg; Wed, 12 Jun 2024 03:24:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VzW9K5hHnz43dc; Wed, 12 Jun 2024 03:24:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 45C3NrdC017309; Wed, 12 Jun 2024 06:23:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 45C3NrdC017309 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 45C3NraR017308; Wed, 12 Jun 2024 06:23:53 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 12 Jun 2024 06:23:53 +0300 From: Konstantin Belousov To: Kyle Evans Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 6e824f371301 - main - time: siginfo_recvd needs to be marked volatile Message-ID: References: <202405220537.44M5bugu007292@gitrepo.freebsd.org> <58e93be2-d0bc-403c-8aaf-6d3f5e0dd069@FreeBSD.org> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58e93be2-d0bc-403c-8aaf-6d3f5e0dd069@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.80)[-0.801]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MIME_TRACE(0.00)[0:+]; MISSING_XM_UA(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org,dev-commits-src-main@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_THREE(0.00)[4] X-Rspamd-Queue-Id: 4VzW9K5hHnz43dc On Mon, Jun 10, 2024 at 10:13:45PM -0500, Kyle Evans wrote: > On 5/31/24 14:52, Konstantin Belousov wrote: > > On Wed, May 22, 2024 at 05:37:56AM +0000, Kyle Evans wrote: > > > The branch main has been updated by kevans: > > > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=6e824f3713011f7955a4f88fb16445e8e2cbe72c > > > > > > commit 6e824f3713011f7955a4f88fb16445e8e2cbe72c > > > Author: Kyle Evans > > > AuthorDate: 2024-05-22 05:36:29 +0000 > > > Commit: Kyle Evans > > > CommitDate: 2024-05-22 05:37:41 +0000 > > > > > > time: siginfo_recvd needs to be marked volatile > > I do not think so. It happens to work with the compilers we currently use. > > > > Sorry, I meant to respond but it got lost somewhere in the stack. Can you > expand on this specifically a bit more? I was under the impression that > we'd generally need volatility due to write from SIGINFO handler / read > repeatedly from main(), which serves to demonstrate my ignorance here. Is > it that there are sufficient side-effect-y things between loads in the > wait4() loop that the compiler won't do anything hinky, or more that it's > insufficient and should have been fenced as well? Signal fence is provided by standard explicitly to handle the interaction between signal handler and 'main' code. On the other hand, description of the volatile semantic is vague and references possible side effects caused by something not known to the compiler, like memory-mapped device state. It happens that both gcc and clang effectively implement volatile accesses as relaxed atomics loads and stores. This is enough to ensure that the loop you wrote correctly interacts with the signal handler you wrote. But it is compiler-depended. It might be interesting to read gcc documentation about its implementation- dependent semantic of volaties, 'C implementation defined behavior-> Qualifiers' in the texinfo doc. > > > > sig_atomic_t does not imply volatility, we must do it ourselves to avoid > > > caching of siginfo_recvd loads. > > For this purpose, standard provides atomic_signal_fence(). > > > > You would need to put it before read of siginfo_recvd (after wait4()), and > > after update of siginfo_recvd in the signal handler.