linux-kernel - Re: Reporting bugs and bisection

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:	Mon, 14 Apr 2008 11:58:08 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Willy Tarreau <w@....eu>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Tilman Schmidt <tilman@...p.cc>,
	Valdis.Kletnieks@...edu, Mark Lord <lkml@....ca>,
	David Miller <davem@...emloft.net>, jesper.juhl@...il.com,
	yoshfuji@...ux-ipv6.org, jeff@...zik.org,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Reporting bugs and bisection

Willy Tarreau <w@....eu> writes:

> Linux is the *only* product which requires
> the bug reporter to find the fault change (yes, I know, it's scalable).

It's a pretty common procedure for compilers (gcc, llvm) too, although
they have the advantage that given a test case usually someone else
can run the bisect procedure because they do not depend on the underlying
hardware 

That's unfortunately not the case for most kernel bugs, although
sometimes it is possible given a hardware independent test case. And
while most of the kernel code is drivers and arch, a lot of it is
still pretty hardware independent, so at least in some cases it is
possible to submit test cases and then let someone else (like a bug
master) do the bisect.

Of course it is unclear if producing a submittable test case will be
actually any faster than just running bisect for the user.

That said I agree it's a big burden to run bisect for everything
because it can take very long (especially if the problem
is not trivially reproducable) 

It would be fair at least if maintainers always gave some candidate
commit ids when asking for bisect for likely changes that could
have matched the bug.  Then those could be checked quickly first
before doing the full run.

While that will not always work it would be still a useful short cut
and save a lot of time for the reporter.

-Andi
--
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/