linux-kernel - Re: [bug] build failure in net/netfilter/nf_conntrack

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: <20080421193147.GA8770@elte.hu>
Date:	Mon, 21 Apr 2008 21:31:47 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Patrick McHardy <kaber@...sh.net>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org
Subject: Re: [bug] build failure in net/netfilter/nf_conntrack_sip.c, on
	latest -git


* Patrick McHardy <kaber@...sh.net> wrote:

>> for the last 3 days my own automated bug finding capacity is at 10% 
>> of its normal throughput (it booted only 200 kernels, instead of 2000 
>> kernels) - which is OK in early phases of the merge window, but you 
>> seem to deny that i have any standing to argue development process 
>> issues.
>
> In my perception networking is not doing worse than other subsystems, 
> this (small) accumulation of build-bugs seems more like an unfortunate 
> coincidence caused by two people being sloppy during testing (me and 
> the LED guys).

nah, it's not doing worse at all and my comment was not really about the 
bug itself (bugs happen), but about the most efficient way to report 
that bug - which in hindsight is not an argument i should have gotten 
into. arch/x86 has at least this proportion of build bugs if not more. 
[and the scheduler is a 50 times smaller piece of code so it's not 
really comparable.]

btw., managed to test 755 random kernels today:

  #define UTS_VERSION "#755 SMP PREEMPT Mon Apr 21 21:12:52 CEST 2008"

with no runtime (or build) failure anywhere. [other than in freshly 
added x86.git or scheduler patches that is.]

	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/