From nobody Tue Jul 23 07:41:17 2024 X-Original-To: freebsd-arm@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 4WSpxD6Zk9z5RSFn; Tue, 23 Jul 2024 07:41:20 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSpxD4k5Yz4h2D; Tue, 23 Jul 2024 07:41:20 +0000 (UTC) (envelope-from meloun.michal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2eeec60a324so66766831fa.2; Tue, 23 Jul 2024 00:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721720478; x=1722325278; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:reply-to:user-agent:mime-version:date :message-id:sender:from:to:cc:subject:date:message-id:reply-to; bh=aCJKWokBG/cAa/JgTrEO8G/jLb9adiwgbcWxcuW/Hcs=; b=ekqDvHeZTfBV2NtGU+3DhI9vqyDoXgOyNZrIZbElAr4p92oT1aa6C4Ngp/NuLdz3Ku GVDYOIxJydvymxktHIvFUpATG9t+5p+l1HoOIJrQoQ9P1cbHOE246X1NEwuWAbddsNYc Xb2P5wPRySYv9KERxOhqwtIAtdx8e2xOOIJ+B0X6vBOPFawyorgNpI0gp6lPYH28GQ9d e19kwho5WUkDqpTjuVjZLWM995+ekePp7+8YeUkvsbKKucHK9d9BjOGhPKsdBj2RbgsY rPIpuIXuY4AgjluRZKF/rJV+UCBgxbN0qMKfXETPbtbd2Xker0vK90L02RFUQk2SANNm nxiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721720478; x=1722325278; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:reply-to:user-agent:mime-version:date :message-id:sender:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aCJKWokBG/cAa/JgTrEO8G/jLb9adiwgbcWxcuW/Hcs=; b=eSaGZLeLR+mm+a3/Zb4t6P3yaCXo+rdBS5t+tF3KxJSFZe7JydU+3FKX7QelZgsvkT Eqj2h4xOZ6ZOrDRyUsQgp0M/BpC1g4aNoHjmabcZa74EOx/rUFcpt+F328vTc8YN5OBk fBgeHVVWIzwmTJ8a+iudLTs7M7Uzr/zfKJnqyIlNWvfDuch+42GmnpI192o0eyaV8u81 bp/UXWA18x2AygTaJWsbcjNbMHEQ84nrMPLVslVkg03WQWSwjRVwnNoTvcNFC3h/k+wO qBo2+1bgwsz8vjaArSTq/xRoEzh8QGhimGHZHeDHVT6O7G7DsBOnQYGuoUw0ibOZSDC7 vZXA== X-Forwarded-Encrypted: i=1; AJvYcCVUrJy/cnjAJJECwUdui/BqCC402LnjN537yEyNZ1kaqsQegQmkL4HXNBu05GgXtEEvGrHtU7QSz+VqKbXtATA/yMLOI1Je6pO46Y2xv/ALPGBx/8yJFnkYwrmH/ulHfZUg93ThBkVJiSSxJVRTkp6TOHgEKTuA X-Gm-Message-State: AOJu0Yx6pkTK4FgNEEHVrnG0HJCUAxDa2UAX55BHSyLGyrZTH5mz0Gcz Zl7YZSxffB4xC/O/fjMPqn2Irsqo44054Glj96i3iX3Jwrilk+TdeQNklyHB X-Google-Smtp-Source: AGHT+IEjL+8P6P6tC+JWWTHEx+hsLY0wtEcvQU4tGQn34AixitFC/t8Ict8ugdw0ijr0Rmc9EKX/GA== X-Received: by 2002:a2e:84ca:0:b0:2ee:8f3d:e68d with SMTP id 38308e7fff4ca-2ef1685d099mr84793791fa.44.1721720478325; Tue, 23 Jul 2024 00:41:18 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:55eb:52e:1154:1d18? ([2001:67c:14a0:5fe0:55eb:52e:1154:1d18]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5aa1f02c9fesm154224a12.67.2024.07.23.00.41.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jul 2024 00:41:17 -0700 (PDT) Message-ID: <00b3e6be-648d-44c0-b95b-a31229fb5fde@gmail.com> Date: Tue, 23 Jul 2024 09:41:17 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: meloun.michal@gmail.com Subject: Re: armv7-on-aarch64 stuck at urdlck To: Konstantin Belousov Cc: Mark Millard , mmel@freebsd.org, FreeBSD Current , "freebsd-arm@freebsd.org" References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> <33251aa3-681f-4d17-afe9-953490afeaf0@gmail.com> Content-Language: cs, en-US From: Michal Meloun In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4WSpxD4k5Yz4h2D On 23.07.2024 0:50, Konstantin Belousov wrote: > 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 this memory corruption fits perfectly with the >> observed behavior. >> >> 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). Thank you for the explanation. I didn't check the implementation of atomic_cmpset_acq and completely forgot that it has dmb() inside. My memory really needs a better refresh....