linux-kernel - Re: [GIT PULL] percpu 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]

Date:	Fri, 19 Jun 2009 07:39:44 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <tj@...nel.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>, kyle@...artin.ca
Subject: Re: [GIT PULL] percpu for 2.6.31

* Tejun Heo <tj@...nel.org> wrote:

> Hello, again.
> 
> Tejun Heo wrote:
> > Oops, my apologies.  I had them as floating series and apparently used
> > different base commit when applying them.  I did grep run and full yes
> > build on the original quilt tree but didn't after quiltimport.  Sorry.
> 
> I digged through git changelogs to find out where it went wrong.  
> I did use the same base commit when quiltimporting but when I 
> updated the patches on top of mainline two days ago, I forgot to 
> quilt add the file and the mce change got committed to the base 
> tree instead of quilt patch.  After pulling the latest master into 
> the quilt branch yesterday, I updated the series for newcomers and 
> everything worked fine (as the base tree change got merged by 
> git).  quiltimporting of course lost the base tree change and 
> thinking the output gotta be identical I didn't test the final git 
> tree.
> 
> Anyways, I'm dropping the for-linus branch from percpu tree, 
> fixing it up, adding patchsets scheduled for .32 release and will 
> try to get it merged into #linux-next.

Please create a -git based bit for the x86 side (as i asked you 
previously) - we can certainly get that upstream sooner after the 
necessary amount of testing.

Condolences for trying to improve a dozen SMP architectures at once, 
you've ended up with:

 - being forced to rebase all the time. (This will happen in the
   cycle to come too: just watch as the conflicts in linux-next
   mount up with the architecture trees. Your tree will become
   crappy quickly due to the combined noise.)

 - the 10x patch logistics end up killing your overall quality, let
   crap creep in and cause breakage even on x86.

You wasted 3 months of your life on that. Now you've learned not to 
do that ever again - i've been there, done that, got the T-shirt.

Just stick your new stuff behind an ARCH_HAS flag, add it to the 
architecture(s) you care about and forget about the rest - let the 
remaining arch maintainers pick things up in their own pace. You'll 
get 90% of the benefits to Linux with just 30% of the work.

( Many wont btw: we still dont have lockdep support in all
  architectures - 3 years and counting. It's a highly useful purely
  sw feature with zero hardware dependencies. Fortunately it's
  well-modularized and the functionality is non-essential. Percpu
  allocation is not so lucky as it's essential functionality. )

	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/