LKML Archive on
 help / color / Atom feed
From: Al Viro <>
To: Casey Schaufler <>
Subject: Re: [PATCH] Version 8 (2.6.23) Smack: Simplified Mandatory Access Control Kernel
Date: Thu, 18 Oct 2007 21:26:27 +0100
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Oct 18, 2007 at 01:13:02PM -0700, Casey Schaufler wrote:

> CPU1 sets smk_next to smack_known. 
> CPU1 fills in the rest of the entry.
> CPU1 sets smack_known to skp (the entry).
> CPU2 will either see the old value for smack_known,
> in which case this entry isn't actually on the list yet,
> or it will see the new value in smack_known. Since smk_next
> is set before the entry is added to the list, it seems that
> the scenario you've outlined shouldn't happen.

Why?  Writes from CPU1 don't have to be seen in the same order on CPU2.
Compiler has every right to turn that into
	load from smack_known
	store to ->smk_next
	store to smack_known
and there's no reason whatsoever why these two stores won't be seen
out of order on CPU2 - there's no barrier and all we have is a bunch
of assignments from registers to various (nonrepeating) addresses in
memory.  On out-of-order architectures they can be reordered just fine
by CPU itself...

You need at least a barrier, assuming that you want to keep that kind
of lockless access in readers (actually, I wonder if that list is a
good choice of data structure here - you are using it as a symbol table
and depending on the expected use pattern there might be better choices
for that).

  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-17  4:17 Casey Schaufler
2007-10-18  4:57 ` Al Viro
2007-10-18  5:10   ` Al Viro
2007-10-19 12:39     ` Ahmed S. Darwish
2007-10-18 20:13   ` Casey Schaufler
2007-10-18 20:26     ` Al Viro [this message]
2007-10-21  1:40 ` [PATCH] Smackv8: Omit non-cipso labels in cipso_seq_start Ahmed S. Darwish
2007-10-21  2:25   ` [PATCH] Smackv8: Safe lockless {cipso,load} read operation Ahmed S. Darwish

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git
	git clone --mirror lkml/git/9.git
	git clone --mirror lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone