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 14:13:54 +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:

> > 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.
> 
> Well I haven't got onto processing these patches in detail yet.  An 
> open questions is why the damn thing was resubmitted from scratch when 
> I've already merged it and fixed various rejects and had to fix 
> several bugs in it.  Do those rejects need to be re-fixed?  Were my 
> bugfixes folded back? I haven't looked yet.  I'll need to generate the 
> incremental diff and see what was done.
> 
> But if what you've merged was against mainline then it isn't terribly 
> useful.

i cross-ported it from the linux-next base to -git base and the conflict 
fallout was minimal, well below 5% or so. I.e. the patches change 
long-existent warnings that have not changed in linux-next either.

About 30% of the changes in this patchset affect subsystems that i 
co-maintain, still tip/core/warn-API did a pure, conflict-free git-merge 
when it was applied ontop of all these subsystem trees:

 commit 99eb83efbe2e3c12d26be22a032495ccddb36a2c
 Merge: de67579... c2e0195...
 Author: Ingo Molnar <mingo@...e.hu>
 Date:   Wed Jul 9 12:14:48 2008 +0200

     Merge branch 'core/warn-API'

Hence my suggestion that this should be maintained and forward ported to 
the end of the merge window, in a separate, standalone tree that is -git 
based.

Anyway, no strong feelings, it's 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/