linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

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: <20100322092809.GA20607@elte.hu>
Date:	Mon, 22 Mar 2010 10:28:09 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	yinghai@...nel.org, benh@...nel.crashing.org, tglx@...utronix.de,
	hpa@...or.com, akpm@...ux-foundation.org, jbarnes@...tuousgeek.org,
	ebiederm@...ssion.com, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c
 to fw_memmap.c

( Cc:-ed Andrew and Linus as this is a general design/policy matter wrt. 
  memory management. )

* David Miller <davem@...emloft.net> wrote:

> From: Yinghai Lu <yinghai@...nel.org>
> Date: Sun, 21 Mar 2010 21:28:38 -0700
> 
> >> 
> >> That action means you absolutely don't value our feedback at all.
> > 
> > [PATCH 01/20] x86: add find_e820_area_node
> > is addressing your concern that early_res didn't handle memory cross the nodes problem.
> 
> Now I know that you _REALLY_ aren't listening to us.

[ He has done a bit more than just to simply listen: he seems to have written 
  a patch which he thinks is addressing the concerns you pointed out. It might
  not be the response you wished for (and it might be inadequate) for but it
  sure gives me the impression of him listening to you - unless by 'listening' 
  you mean 'follow my exact opinion without argument'. ]

> We said to use LMB because 1) it already exists 2) many platforms have been 
> using it for years and 3) it doesn't lack the features you're now having to 
> add to e820.

The thing is, lib/lmb.c was librarized two years ago by you (much after 
early_res has been written for x86), but was not properly integrated into the 
core kernel nor into x86. It was first suggested by you in the early_res 
context about ten days ago, when Yinghai started posting Sparc64 patches.

Which is about half a year after the whole very difficult early_res/bootmem 
work was started by Yinghai :-(

I dont mind LMB per se, logically it seems quite similar to the early_res bits 
Yinghai has generalized (to a certain degree), and is quite a bit cleaner as 
you are writing very clean code.

Note the other side of the coin: LMB appears to be deployed on only 4 non-x86 
architectures that muster ~1% of the Linux boxes while early_res is deployed 
on more than 95%.

So there's a very real hardship of testing and conversion here that we cannot 
ignore and an even better path may be to gradually transform the more tested 
and more deployed early_res code to meet the interface details of LMB.

Please also realize the difficulties Yinghai has gone through already: 
converting and generalizing _all_ of the x86 early allocation code to a more 
generic core kernel approach, with essentially zero interest from _any_ 
non-x86 person ...

Those early_res patches were posted all over on lkml, it was literally 
hundreds of difficult patches, and now, months down the line, after we've 
tested and upstreamed it (with many nasty regressions fixed on x86 during the 
development of it) you come with a rigid "do it some other way, convert all of 
x86 over again or else" position.

I really wish non-x86 architectures apprecitated (and helped) the core kernel 
work x86 is doing, because it is subsidizing non-x86 architectures all the 
time.

For example when LMB was plopped into lib/lmb.c in 2008 why was it not ported 
to x86, our most popular architecture? Did you consider posting LMB patches 
for x86 instead of expecting Yinghai to post Sparc64, PowerPC, SH and 
Microblaze patches?

Anyway, i'm sure we can work out an approach, and yes, LMB looks pretty good 
and could be picked up if it can be done gradually - given some mutual 
willingness to work on this as equals.

Thanks,

	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/