linux-kernel - Re: [GIT PULL] Early boot SLAB for 2.6.31

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: <20090611005411.GB24065@elte.hu>
Date:	Thu, 11 Jun 2009 02:54:11 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	cl@...ux-foundation.org, hannes@...xchg.org, mpm@...enic.com,
	npiggin@...e.de, yinghai@...nel.org
Subject: Re: [GIT PULL] Early boot SLAB for 2.6.31


* Pekka Enberg <penberg@...helsinki.fi> wrote:

> Hi Ingo,
>
> Ingo Molnar wrote:
>>>>> What kind of conflicts are there against -tip? The diffstat  
>>>>> suggests it's mostly in-SLAB code, right? There shouldnt be much 
>>>>> to conflict, except kmemcheck - which has more or less trivial 
>>>>> callbacks there.
>>>> The conflicting bits are the patches that remove bootmem allocator 
>>>> uses in arch/x86 and kernel/sched.c.
>>> Give me an hour and i'll get some minimal testing done.
>>
>> This tree doesnt conflict (not even with kmecheck) - and the older  
>> bits you sent against the scheduler and against x86 doesnt apply  
>> anymore - but they do look scary.
>
> Btw, yeah, it doesn't conflict because I dropped the problematic patches  
> and did the bootmem fallback instead.
>
> But now you know why I tried to push all this to -tip. Your tree 
> is moving so fast that it's difficult to generate patches that 
> apply to both, -tip and mainline, in this particular area :-).

Hey, i'd agree normally, but the scheduler tree was very quiet in 
this cycle, for a change :-)

The main "problem" here really is the multi-tree impact of such 
broad changes. Those are best kept in a tree like -mm, which goes on 
top of all other trees and is thus basically the only tree that can 
do tree-wide changes.

Anyway, if you rebase to latest -git it should be fine - Linus 
pulled the scheduler and x86 bits.

	Ingo
--
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/