linux-kernel - Re: [patch 0/17] Series to introduce WARN()... a WARN

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, 9 Jul 2008 13:37:03 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 0/17] Series to introduce WARN()... a WARN_ON() variant
	that takes printk arguments

* Andrew Morton <akpm@...ux-foundation.org> wrote:

> > > The first few patches have been in -mm for a long time; the later 
> > > ones are newer and introduce more users of WARN().
> > 
> > i've created a new -git based topic branch in tip/core/warn-API and 
> > picked up your patches:
> 
> um, why?
> 
> If you merge this into linux-next then it will trash already-merged 
> patches in -mm and, more particularly, it will trash other trees which 
> you aren't looking at, causing Stephen problems.

no, i didnt plan to push this towards linux-next - given the broad 
consensus and given the wide spread of the changes.

I wanted to wait with this until the end of the merge window and keep it 
tested and merged up nicely. I.e. zero maintenance overhead to 
subsystems.

> The way to merge this code is to get the base patches into mainline 
> and then trickle the dependent patches into subsystem trees, or direct 
> into mainline after the subsystem trees have merged, and with suitable 
> acks.
> 
> You aren't set up to do that?

i think it's better to just go through the merge window i believe, and 
then do this atomically in one correct and tested step, when all 
subsystem trees are at their minimum size and there's virtually no 
collisions.

Note that this situation is special: this is a patchset that has 
virtually no functionality side-effects, and hence can be done 100% 
correctly, i thought the atomic step was the right approach.

For anything semantically meaningful i too would do the spread-out 
gradual approach (and i'm presently doing that for a number of topics).

But if you'd like to do this the spread-out way then sure, and i will 
drop this tree. ( if you do that then please import the commits from 
tip/core/warn-API, i fixed a couple of of typos in the commit messages 
and did some merging and extensions as well. The tree also passed a fair 
amount of testing meanwhile as well. )

Anyway, your call.

	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/