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:	Fri, 21 Mar 2008 15:38:38 -0400
From:	Valdis.Kletnieks@...edu
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.25-rc3-mm1 - BUG at system shutdown time

On Fri, 21 Mar 2008 14:41:28 BST, Ingo Molnar said:
> 
> * Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> 
> > I may have to try again to figure out how to bisect the git-x86 tree - 
> > Ingo send me a pointer to his git-x86 cheat sheet, I looked at it but 
> > I couldn't figure out how to tell 'git bisect' that the starting good 
> > spot was "whatever corresponded to the git-x86 patch in 24-rc8-mm1" 
> > and bad was "25-rc3-mm1". I tried using the first commit ID listed in 
> > the patch, but that gave me this:
> 
> the best way to bisect the x86.git-only commits is to do:
> 
>   git-bisect bad x86/latest
>   git-bisect good x86/base

OK, *that* got the bisect running.  However, after a few bisections, things
are getting weird...

(Note - I haven't done a git pull or update for a week and a bit, so the tree is
as of 03/14 or so...)

'git bisect log' reports:

git-bisect start
# bad: [21a418440c44b6a2cdf38fea2533a5398d6fd939] Move mp_bus_id_to_node to numa.c
git-bisect bad 21a418440c44b6a2cdf38fea2533a5398d6fd939
# good: [dba92d3bc49c036056a48661d2d8fefe4c78375a] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband
git-bisect good dba92d3bc49c036056a48661d2d8fefe4c78375a
# good: [53f0f2bc547fd13a70a6adb86592301ec83b9fc7] x86 mmiotrace: comment about user space ABI
git-bisect good 53f0f2bc547fd13a70a6adb86592301ec83b9fc7
# good: [53f0f2bc547fd13a70a6adb86592301ec83b9fc7] x86 mmiotrace: comment about user space ABI
git-bisect good 53f0f2bc547fd13a70a6adb86592301ec83b9fc7
# good: [53f0f2bc547fd13a70a6adb86592301ec83b9fc7] x86 mmiotrace: comment about user space ABI
git-bisect good 53f0f2bc547fd13a70a6adb86592301ec83b9fc7
# good: [2702dd1be087ac7307b731d884ee48db6e1cdff6] x86: create smpcommon.c
git-bisect good 2702dd1be087ac7307b731d884ee48db6e1cdff6
# good: [ad42b55d36238ebb9fa4d7a538ef691a76397c46] x86: add KERN_INFO to show_unhandled_signals printout
git-bisect good ad42b55d36238ebb9fa4d7a538ef691a76397c46
# good: [56b412e63863ea82a5720315076c7dbd1d9888cd] x86: change x86 to use generic find_next_bit
git-bisect good 56b412e63863ea82a5720315076c7dbd1d9888cd
# good: [42de918f25dc9a49fb9688e22c2a3f2b156cc1bf] x86: prevent unconditional writes to DebugCtl MSR
git-bisect good 42de918f25dc9a49fb9688e22c2a3f2b156cc1bf

At this point, 'git bisect visualize' shows 9 commits left to bisect through,
and all are dated 03/10 or later.  However, since 25-rc3-mm1 had the problem,
it had to be something in-tree as of 03/05.

Is it possible that the problem code was in the git-x86 tree when Andrew
pulled for -rc3-mm1 and -rc5-mm1, but had been reverted by the time I grabbed
the tree, so the /x86/base' was in fact *good* by that point?


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ