[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1191422117.1553.8.camel@moss-terrapins.epoch.ncsc.mil>
Date: Wed, 03 Oct 2007 10:35:17 -0400
From: "David P. Quigley" <dpquigl@...ho.nsa.gov>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: a.p.zijlstra@...llo.nl, jmorris@...ei.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, chrisw@...s-sol.org
Subject: Re: [TOMOYO 05/15](repost) Domain transition handler functions.
On Wed, 2007-10-03 at 23:19 +0900, Tetsuo Handa wrote:
> Hello.
>
> Thank you for pointing out.
>
> Peter Zijlstra wrote:
> > > Currently, TOMOYO Linux avoids read_lock, on the assumption that
> > > (1) First, ptr->next is initialized with NULL.
> > > (2) Later, ptr->next is assigned non-NULL address.
> > > (3) Assigning to ptr->next is done atomically.
> > (4) wmb after asigning ptr->next
> > (5) rmb before reading ptr->next
> Excuse me, but I didn't understand why (4) and (5) are needed.
>
> append_function() {
>
> down(semaphore_for_write_protect);
> ...
> ptr = head;
> while (ptr->next) ptr = ptr->next;
> ptr->next = new_entry;
> ...
> up(semaphore_for_write_protect);
>
> }
It seems to me that this function alone is a reason to argue against
using a singly linked list. I know your patch doesn't actually contain
this as a function but it does use the same logic to append to your
lists. Does the overhead of the second pointer that the regular list
head uses outweigh the O(1) insertion and deletion it provides
(especially in your case)? I know domain transitions are rare but why
use something with O(N) insertion? This could be one reason why there
isn't an slist already in list.h
Dave Quigley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists