linux-kernel - Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on x86

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: <20170205102703.5c128c46@canb.auug.org.au>
Date:   Sun, 5 Feb 2017 10:27:03 +1100
From:   Stephen Rothwell <sfr@...b.auug.org.au>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        Guenter Roeck <linux@...ck-us.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...capital.net>,
        Borislav Petkov <bp@...en8.de>
Subject: Re: Regression on next-20170203 spi/for-next 3f87493930a0f qemu on
 x86_64

Hi all,

On Sun, 5 Feb 2017 10:17:29 +1100 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> On Sat, 4 Feb 2017 12:05:42 -0800 "Luis R. Rodriguez" <mcgrof@...nel.org> wrote:
> >
> > though so it seems something with my configuration and boot. I
> > bisected next-20170203 between its latest commit and v4.10-rc6 and
> > ended up with this bad commit:
> > 
> > 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62
> > 
> > $ git show 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62
> > commit 104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62
> > Merge: 7c3b1edeee66 3f87493930a0
> > Author: Stephen Rothwell <sfr@...b.auug.org.au>
> > Date:   Fri Feb 3 12:30:38 2017 +1100
> > 
> >     Merge remote-tracking branch 'spi/for-next'
> > 
> > I have checked Next/SHA1s and it shows:
> > 
> > mcgrof@...gy ~/linux-next (git::original)$ grep spi Next/SHA1s
> > spi-nor        dc12bcccadafb5441170e6b7c8a438c91d4f385b
> > spi        3f87493930a0f934549b04e100ecc2110e4f1efd
> > hwspinlock    bd5717a4632cdecafe82d03de7dcb3b1876e2828
> > 
> > The commit 3f87493930a0f934549b04e100ecc2110e4f1efd then seems to be
> > what I need to test. I have cloned Mark's spi tree and just tried to
> > boot the for-next branch (on v4.10-rc1) on
> > 3f87493930a0f934549b04e100ecc2110e4f1efd, and it boots successfully.
> > This would lead me to believe this issue might be related to the merge
> > conflict resolution done by Stephen, but wanted to check and ask.
> > Perhaps there might be some specific tests I can run.  
> 
> OK, it is possible that the merge is actually incorrect.  I did *not*
> do any manual resolution of that merge and git only reported an
> automatic resolution in file drivers/spi/spi-bcm-qspi.c (which looks ok
> from a quick glance).
> 
> It is always possible that there is some semantic conflict that git
> won't see and didn;t also involve a syntactic conflict or a build
> failure.  e.g. the internal semantics of a function changes on one side
> of the merge but a new usage expecting the old semantics is introduced
> on the other side.

Just to mention, there was no change to the spi tree between
next-20170202 and next-20170203.  I assume that next-20170202 is fine?
If so, you could try bisecting with next-20170202 as good and
104a519fe1732b4e503ebc7b4ac71b6f0b8a0b62 as bad.  I have no idea if
that sort of bisec will even work, though.

Or if commit 8cfb3801a57a (the merge of the spi tree in next-20170202)
is fine, then you could try using that as your starting good (that will
remove a lot of next-20170202).

-- 
Cheers,
Stephen Rothwell