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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 19 Oct 2008 21:17:37 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp> Cc: serue@...ibm.com, sds@...ho.nsa.gov, jmorris@...ei.org, chrisw@...s-sol.org, dhowells@...hat.com, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org, takedakn@...data.co.jp, haradats@...data.co.jp Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part. 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@...ux.vnet.ibm.com> > Signed-off-by: Tetsuo Handa <penguin-kernel@...ove.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. -- 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