linux-kernel - Re: memory-barriers.txt questions

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>] [day] [month] [year] [list]

Message-Id: <20190821143813.GE28441@linux.ibm.com>
Date:   Wed, 21 Aug 2019 07:38:13 -0700
From:   "Paul E. McKenney" <paulmck@...ux.ibm.com>
To:     Björn Töpel <bjorn.topel@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: memory-barriers.txt questions

On Wed, Aug 21, 2019 at 04:24:42PM +0200, Björn Töpel wrote:
> Paul,
> 
> Reaching out directly, hope that's OK!

Adding LKML on CC, hope that's OK!

> >From memory-barriers.txt (what an excellent document. I've read it
> over and over, and never get all the details. :-)):
> --8<--
> MISCELLANEOUS FUNCTIONS
> -----------------------
> 
> Other functions that imply barriers:
> 
>  (*) schedule() and similar imply full memory barriers.
> -->8--
> 
> The "and similar" part puzzles me. IPI is a a full barrier on all
> platforms (I think). Are interrupts in general full barriers? What
> more?

Functions similar to schedule() include schedule_user(),
schedule_preempt_disabled(), preempt_schedule(), preempt_schedule_irq(),
and so on.  Plus any function that calls one of these functions.

Interrupts are quite architecture specific, and on many architectures an
interrupt does not imply any sort of cross-CPU ordering in and of itself.
So you would need to inspect the interrupt-entry/-exit code to see if
the needed full memory-barrier instructions were in place to answer
this question.

But what are you trying to achieve?

							Thanx, Paul