public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox