Date: Tue, 23 Jul 2024 01:50:31 +0300 From: Konstantin Belousov <kib@freebsd.org> To: Michal Meloun <meloun.michal@gmail.com> Cc: Mark Millard <marklmi@yahoo.com>, mmel@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: armv7-on-aarch64 stuck at urdlck Message-ID: <Zp7iN0PmCsdezNOP@kib.kiev.ua> In-Reply-To: <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <B5E2275D-21F0-43C8-AF06-A45DB7448D66@yahoo.com> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <a1b978fe-ff54-4112-860c-b09500d89d0b@freebsd.org> <C0B42CBB-8F12-4597-A04B-26F2107E176E@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 22, 2024 at 09:36:00PM +0200, Michal Meloun wrote: > IMHO, -O2 shouldn't be able to modify function arguments for public > functions, so <guessing> this memory corruption fits perfectly with the > observed behavior</guessing>. > > But , out of curiosity, a quick look at _thr_rwlock_tryrdlock() in > thr_umtx.h:208 makes me wonder: How is the "state" variable inside the loop > guaranteed to be updated? IMHO nothing inside the loop emits a global memory > modification attribute, so the compiler is free to move the assignment to a > "state" variable outside the loop. > I think that you are formally right, because there is only the _acq atomic in the loop body, an evil compiler is allowed to move all loads before the start of the loop iteration. But, since e.g. on arm32 atomic_cmpset_acq implementation contains dmb() which provides the full barrier both for compiler memory accesses, and for hw, it is not the case (for arm32).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Zp7iN0PmCsdezNOP>