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] [day] [month] [year] [list]
Date:	Mon, 25 Apr 2011 15:21:27 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	paulmck@...ux.vnet.ibm.com, "H. Peter Anvin" <hpa@...ux.intel.com>,
	Michal Marek <mmarek@...e.cz>,
	Jan Beulich <JBeulich@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	David Howells <dhowells@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET

On 04/22/2011 04:10 PM, Peter Zijlstra wrote:
> On Fri, 2011-04-22 at 15:19 +0800, Lai Jiangshan wrote:
>>
>> What is the solution you prefer to?
>>
>> I insist on the solution which split rcupdate.h into 2 parts,
>> the first part is rcupdate_defs.h which only contains:
>> 1) struct rcu_head
>> 2) MACRO rcu_dereference*
>> 3) MACRO rcu_access_pointer rcu_access_index rcu_assign_pointer RCU_INIT_POINTER
>> 4) rcu_*_lock_held() which is required by 2)
>>
>> All of these is required by sched.h, it is all about 450 lines of code.
>>
>> It does not just separate struct rcu_head out only, because rcu_dereference*()
>> and APIs in rculist.h are required by in sched.h or headers included by sched.h.
> 
> The only usage of rculist.h in the whole of sched.h is that _one_
> list_entry_rcu, of which we already have a macro user, so why not make
> that one a macro too and safe ourselves a ton of grief?
> 
> You're just making stuff harder than it needs to be.
> 

No, opposite.
the more things(except rcu_read_[un]lock*()) are moved to rcupdate_defs.h the more easy.
the less things are moved to rcupdate_defs.h the more hard.

example, if rcu_dereference* is not moved to rcupdate_defs.h,
I have to do 2 more things:
1) convert inline functions next_thread() to macro.
2) find all .c which uses next_thread()/next_task() and ensure they all have rcupdate.h included.
3?) handle the complaints from LKML and told them should convert their new APIs to macro
    and should also do the same work like 2)

I'm just expressing my thinking, I will accept your requirement and make things progress.

Thanks,
Lai
--
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