lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231009105320.scljokj4ies2s5r4@vireshk-i7>
Date:   Mon, 9 Oct 2023 16:23:20 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Alex Bennée <alex.bennee@...aro.org>
Cc:     Juergen Gross <jgross@...e.com>,
        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, 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 ?

-- 
viresh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ