linux-kernel - Re: [PATCH] softlockup: show irqtrace

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, 25 Jun 2008 19:11:11 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Ingo Molnar" <mingo@...e.hu>
Cc:	"Johannes Weiner" <hannes@...urebad.de>,
	"Arjan van de Ven" <arjan@...ux.intel.com>,
	"Peter Zijlstra" <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] softlockup: show irqtrace

On 6/25/08, Ingo Molnar <mingo@...e.hu> wrote:
> > (Compile tested on allyesconfig, allnoconfig, allnoconfig + softlockup
> > debugging.)
>
> hm, that must have taken quite some time to do on your desktop, right?

Hm, no. I admit to having improved the process of compilation
somewhat; I compiled only the affected files, or in case a CONFIG
prevents a file from being built, the complete parent directory. I
find that this works well in practice; the compiler usually warns
about implicit declarations (which would otherwise show up as linker
errors), so there is no need to link everything. (Sadly, this is not
true when declarations are provided regardless of definition -- I
think this is actually a case against putting declarations outside
#ifdefs.)

> FYI, there's no mandatory need to go through that buerocratic testing
> hassle with patches submitted to -tip - especially with small patches
> that look obvious and have a high chance of being right. We do non-stop
> allyes/allno/allmod+randconfig 64-bit/32-bit build and boot testing for
> every single patch added to the repository.
>
> Building, booting and testing it in the environment where you expect it
> to be used primarily should be more than enough.

Well, it's still somewhat emberassing to submit patches that don't compile :-)

This patch was also a typical error scenario; I introduce the call of
a function which requires the inclusion of a new header, one which
seemingly depends on a particular config option (lockdep). So I simply
wanted to be sure myself -- and then I might as well put it in the
e-mail. That also implicitly means that I did not boot test it at all.
(Because, yeah, what it actually DOES should be fairly obvious.)

Thanks, though! It's really nice to know the world's not coming to an
end because of a broken patch ;-)

Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/