From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: serue@us.ibm.com, sds@tycho.nsa.gov, jmorris@namei.org,
chrisw@sous-sol.org, dhowells@redhat.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
takedakn@nttdata.co.jp, haradats@nttdata.co.jp
Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.
Date: Sun, 19 Oct 2008 21:17:37 -0700 [thread overview]
Message-ID: <20081020041736.GA6929@linux.vnet.ibm.com> (raw)
In-Reply-To: <200810192210.FAG26590.MLtOVOFJHQFOSF@I-love.SAKURA.ne.jp>
On Sun, Oct 19, 2008 at 10:10:23PM +0900, Tetsuo Handa wrote:
> Hello.
>
> Paul E. McKenney wrote:
> > > Maybe I'm misunderstanding what "mb()" can do.
> >
> > The problem is that while wmb() and mb() do in fact order writes, they
> > cannot order the other task's reads.
> >
> I expected that "mb()" can order the other task's reads.
So did I, a long time ago. It took an Alpha architect more than
an hour face-to-face to convince me otherwise. ;-)
> Now, I understood that there is no room for optimizing the reader process
> by omitting smp_read_barrier_depends() on read side.
>
> OK, let's return to http://lkml.org/lkml/2008/10/14/406 .
> Below is the updated version of list1 operations.
> As I now use rcu_assign_pointer() and rcu_dereference() which depend on
> include/linux/rcupdate.h , I separated the code from include/linux/list.h .
> Did I update correctly?
>
> ---
> Subject: Singly linked list implementation.
Looks good to me!
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> include/linux/list1.h | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 81 insertions(+)
>
> --- /dev/null
> +++ linux-next/include/linux/list1.h
> @@ -0,0 +1,81 @@
> +#ifndef _LINUX_LIST1_H
> +#define _LINUX_LIST1_H
> +
> +#include <linux/list.h>
> +#include <linux/rcupdate.h>
> +
> +/*
> + * Singly linked list implementation.
> + *
> + * This list supports only two operations.
> + * (1) Append an entry to the tail of the list.
> + * (2) Read all entries starting from the head of the list.
> + *
> + * This list is designed for holding "write once, read many" entries.
> + * This list requires no locks for read operation.
> + * This list doesn't support "remove an entry from the list" operation.
> + */
> +
> +/* To reduce memory usage, this list doesn't use "->prev" pointer. */
> +struct list1_head {
> + struct list1_head *next;
> +};
> +
> +#define LIST1_HEAD_INIT(name) { &(name) }
> +#define LIST1_HEAD(name) struct list1_head name = LIST1_HEAD_INIT(name)
> +
> +static inline void INIT_LIST1_HEAD(struct list1_head *list)
> +{
> + list->next = list;
> +}
> +
> +/* Reuse list_entry because it doesn't use "->prev" pointer. */
> +#define list1_entry list_entry
> +
> +/* Reuse list_for_each_rcu because it doesn't use "->prev" pointer. */
> +#define list1_for_each list_for_each_rcu
> +/* Reuse list_for_each_entry_rcu because it doesn't use "->prev" pointer. */
> +#define list1_for_each_entry list_for_each_entry_rcu
> +
> +/**
> + * list1_for_each_cookie - iterate over a list with cookie.
> + * @pos: the &struct list1_head to use as a loop cursor.
> + * @cookie: the &struct list1_head to use as a cookie.
> + * @head: the head for your list.
> + *
> + * Same with list_for_each_rcu() except that this primitive uses @cookie
> + * so that we can continue iteration.
> + * @cookie must be NULL when iteration starts, and @cookie will become
> + * NULL when iteration finishes.
> + *
> + * Since list elements are never removed, we don't need to get a lock
> + * or a reference count.
> + */
> +#define list1_for_each_cookie(pos, cookie, head) \
> + for (({ if (!cookie) \
> + cookie = head; }), \
> + pos = rcu_dereference((cookie)->next); \
> + prefetch(pos->next), pos != (head) || ((cookie) = NULL); \
> + (cookie) = pos, pos = rcu_dereference(pos->next))
> +
> +/**
> + * list1_add_tail - add a new entry to list1 list.
> + * @new: new entry to be added.
> + * @head: list head to add it before.
> + *
> + * Same with list_add_tail_rcu() without "->prev" pointer.
> + *
> + * Caller must hold a lock for protecting @head.
> + */
> +static inline void list1_add_tail(struct list1_head *new,
> + struct list1_head *head)
> +{
> + struct list1_head *prev = head;
> +
> + new->next = head;
> + while (prev->next != head)
> + prev = prev->next;
> + rcu_assign_pointer(prev->next, new);
> +}
> +
> +#endif
> ---
>
> By the way, quoting from ordering.2007.09.19a.pdf :
>
> | One could place an smp_rmb() primitive between the pointer fetch and
> | dereference. However, this imposes unneeded overhead on systems (such as
> | i386, IA64, PPC, and SPARC) that respect data dependencies on the read side.
> | A smp_read_barrier_depends() primitive has been added to the Linux 2.6 kernel
> | to eliminate overhead on these systems.
>
> In 2.4 kernels, to support Alpha architecture, people use smp_rmb() which
> imposes unneeded overhead on non Alpha architecture.
> In 2.6 kernels, to support Alpha architecture, people use
> smp_read_barrier_depends() which does not impose unneeded overhead on
> non Alpha architecture.
> That's nice.
>
> | Alpha is the only CPU where smp_read_barrier_depends() is an smp_mb() rather
> | than a no-op.
>
> I found
>
> #define smp_read_barrier_depends() read_barrier_depends()
>
> in arch/h8300/include/asm/system.h but couldn't find the definition of
> read_barrier_depends() within that file.
> I hope read_barrier_depends() is defined as a no-op by some other header files.
>
> Regards.
next prev parent reply other threads:[~2008-10-20 4:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 4:28 [TOMOYO #10 (linux-next) 0/8] TOMOYO Linux Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 1/8] Introduce new LSM hooks where vfsmount is available Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 2/8] Add in_execve flag into task_struct Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 3/8] LSM adapter functions Kentaro Takeda
2008-10-09 6:10 ` KAMEZAWA Hiroyuki
2008-10-09 6:57 ` Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 4/8] Memory and pathname management functions Kentaro Takeda
2008-10-09 6:18 ` KAMEZAWA Hiroyuki
2008-10-09 7:17 ` Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 5/8] Common functions for TOMOYO Linux Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 6/8] Domain transition handler Kentaro Takeda
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 7/8] File operation restriction part Kentaro Takeda
2008-10-09 16:48 ` Serge E. Hallyn
2008-10-12 0:09 ` Tetsuo Handa
2008-10-15 1:29 ` Paul E. McKenney
2008-10-16 4:05 ` Kentaro Takeda
2008-10-16 15:10 ` Paul E. McKenney
2008-10-17 8:32 ` Kentaro Takeda
2008-10-17 14:56 ` Paul E. McKenney
2008-10-18 14:04 ` Tetsuo Handa
2008-10-18 15:18 ` Paul E. McKenney
2008-10-19 13:10 ` Tetsuo Handa
2008-10-20 4:17 ` Paul E. McKenney [this message]
2008-10-15 15:24 ` Serge E. Hallyn
2008-10-09 4:28 ` [TOMOYO #10 (linux-next) 8/8] Kconfig and Makefile Kentaro Takeda
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081020041736.GA6929@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=chrisw@sous-sol.org \
--cc=dhowells@redhat.com \
--cc=haradats@nttdata.co.jp \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=sds@tycho.nsa.gov \
--cc=serue@us.ibm.com \
--cc=takedakn@nttdata.co.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.