linux-kernel - Re: [RFC PATCH 4/5] RCU: Add TASK_RCU

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]

Date:	Wed, 30 Mar 2011 13:25:30 +0800
From:	Lai Jiangshan <laijs@...fujitsu.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
CC:	paulmck@...ux.vnet.ibm.com, Jan Beulich <JBeulich@...ell.com>,
	Ingo Molnar <mingo@...e.hu>,
	Alexander van Heukelum <heukelum@...tmail.fm>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	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>,
	Serge Hallyn <serue@...ibm.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 03/30/2011 08:47 AM, Paul E. McKenney wrote:
> On Tue, Mar 29, 2011 at 03:01:19PM -0700, H. Peter Anvin wrote:
>> On 03/29/2011 02:47 PM, Paul E. McKenney wrote:
>>> On Tue, Mar 29, 2011 at 02:32:30PM -0700, H. Peter Anvin wrote:
>>>> On 03/29/2011 02:31 PM, Paul E. McKenney wrote:
>>>>>>
>>>>>> I have to say that if we have to use hardcoded offsets in C then we have
>>>>>> bigger problems.
>>>>>
>>>>> In this case, the offsets are mechanically generated from the structure
>>>>> definitions.
>>>>>
>>>>> Or am I missing your point?
>>>>
>>>> Yes.  The point is if we have to pull out these kinds of hacks in *C*
>>>> code, we are doing it wrong.  Not just a little wrong, but completely
>>>> and totally bonkers wrong.
>>>
>>> OK, maybe we are doing it wrong.
>>>
>>> But in that case, how do you suggest restructuring include/linux/sched.h
>>> so that struct task_struct can be safely included everywhere
>>> rcu_read_lock() and friends are invoked?  Or, on the other hand,
>>> what should we be doing so that we don't need to include task_struct
>>> everywhere?
>>
>> Lai's text doesn't give any hint as to the specific nature of the
>> conflict, which makes it hard to come up with a better alternative
>> without having to rediscover the problem from first principles.
>> However, a somewhat logical assumption is that the problem is that
>> struct task_struct includes struct rcu_head, in which case the easiest
>> thing to do is almost certainly to move the definition of struct
>> rcu_head to its own header file, <linux/rcuhead.h>, and include that in
>> <linux/sched.h>, which should make it possible to include
>> <linux/sched.h> in <linux/rcupdate.h>.
> 
> I believe that there are other circular dependencies -- there certainly
> were a few years back -- but I will defer to Lai.
> 
> 							Thanx, Paul
> 

Yes, there are other circular dependencies, <linux/sched.h> includes
many files which include or indirectly include <linux/rcupdate.h>
for struct rcu_head or RCU apis. There are too many to be split all.

Even we just create a <linux/task_struct_def.h>, it also needs to include
many files which have included or indirectly included <linux/rcupdate.h>
for struct rcu_head already. It is still not a easy work to split them,
it still requires many subsystem maintainers to participate in.

RCU is one of the most import subsystem,
I think it is worth to do such "wrong" way.

Thanks,
Lai

P.S.

Circular dependencies is one of the original sins of C language.
If it is a good change for lots of linux hackers participating in
to split all un-split kernel headers, I'd like to do so too.
--
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/