linux-kernel - Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48F84DAB.4060002@nttdata.co.jp>
Date:	Fri, 17 Oct 2008 17:32:43 +0900
From:	Kentaro Takeda <takedakn@...data.co.jp>
To:	paulmck@...ux.vnet.ibm.com
CC:	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	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, haradats@...data.co.jp,
	akpm@...ux-foundation.org
Subject: Re: [TOMOYO #10 (linux-next) 7/8] File operation restriction part.

Quoting from http://lkml.org/lkml/2008/2/2/255
> Similarly, the smp_read_barrier_depends() is only for initialization
> of something that is about to enter the list.  As with the smp_wmb()
> primitive, smp_read_barrier_depends() also is not to protect against
> freeing.  Instead, it is rcu_read_lock() and rcu_read_unlock() that
> protect against freeing.
We don't need to use rcu_read_lock() and rcu_read_unlock() because 
we don't free elements in a list. I see.

However, to ensure the reader gets up-to-date value, we need to use 
smp_read_barrier_depends() (which is expanded to "mb()" for SMP on 
Alpha, "read_barrier_depends()" for SMP on H8300, "((void)0)" for SMP 
on M68K-nommu, "((void)0)" for M68K, "do { } while (0)" otherwise) 
whenever the reader fetches an element in a list.

Paul E. McKenney wrote:
> But fair enough.  How about the following?
> 
> 	#define worm_dereference()	rcu_dereference()
> 	#define worm_assign_pointer()	rcu_assign_pointer()
> 
So, I understood that the rcu_dereference() and rcu_assign_pointer() 
are not only for RCU. They are needed to ensure the reader gets 
up-to-date value. Then, their names should be var_dereference() and 
var_assign_pointer() or something, shouldn't they? The "rcu_" prefix 
and comments on rcu_dereference in include/linux/rcupdate.h sound for 
me that they are used for variables protected by RCU locking 
mechanism only...

You are suggesting to explicitly call rcu_assign_pointer() (which 
will call smp_wmb()) and rcu_dereference() (which will call 
smp_read_barrier_depends()). But I think that the various cache 
invalidations driven by the workload will call rcu_assign_pointer() 
and rcu_dereference() sooner or later. So, if the reader can tolerate 
reading non-up-to-date value (in fact, TOMOYO can), isn't there a 
choice to omit rcu_assign_pointer() and rcu_dereference() (which will 
cost "mb()" for SMP on Alpha)?

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/