[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6d313c8a-0d3e-40bd-a3f4-86b2ebc5f59a@suse.com>
Date: Mon, 9 Oct 2023 12:58:24 +0200
From: Juergen Gross <jgross@...e.com>
To: Viresh Kumar <viresh.kumar@...aro.org>,
Alex Bennée <alex.bennee@...aro.org>
Cc: Stefano Stabellini <sstabellini@...nel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
stratos-dev@...lists.linaro.org,
Erik Schilling <erik.schilling@...aro.org>,
Manos Pitsidianakis <manos.pitsidianakis@...aro.org>,
Mathieu Poirier <mathieu.poirier@...aro.org>,
linux-kernel@...r.kernel.org, xen-devel@...ts.xenproject.org
Subject: Re: [PATCH 2/2] xen: privcmd: Add support for ioeventfd
On 09.10.23 12:53, Viresh Kumar wrote:
> On 09-10-23, 10:40, Alex Bennée wrote:
>> I thought generally sync points act as full barriers. Doing a bunch of
>> grepping I think ends at:
>>
>> static __always_inline bool __mutex_unlock_fast(struct mutex *lock)
>> {
>> unsigned long curr = (unsigned long)current;
>>
>> return atomic_long_try_cmpxchg_release(&lock->owner, &curr, 0UL);
>> }
>>
>> so you should already have completed your writes by that point.
>
> I am not sure if depending on such indirect mechanisms to implement
> barriers for you is a good idea.
>
> The situation here probably requires explicit barriers to make sure it
> doesn't break in future ?
>
Depending on lock implementations to include the needed barriers is fine IMO.
That is one central objective locks must ensure: to make sure any updates in
a locked region are operating on consistent data and being observable by
others after leaving the locked region.
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3099 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists