linux-kernel - Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

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: <CAKMK7uEnECWMC-EhEhNYiMH4+om6vLTmNw3jTwx0MY5m-Ksc8A@mail.gmail.com>
Date:   Fri, 13 Sep 2019 19:19:24 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Alexander Kapshuk <alexander.kapshuk@...il.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Linux-Next <linux-next@...r.kernel.org>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Sean Paul <sean@...rly.run>, Dave Airlie <airlied@...ux.ie>
Subject: Re: Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

On Mon, Sep 9, 2019 at 12:25 PM Alexander Kapshuk
<alexander.kapshuk@...il.com> wrote:
>
> On Mon, Sep 9, 2019 at 1:21 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >
> > Hi,
> >
> > On Mon, 9 Sep 2019 20:11:59 +1000 Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > >
> > > If you are bisecting linux-next, I will suggest bisecting between the
> > > stable branch on linux-next (which is just Linus' tree when I started
> > > that day) and the top of the first linux-next that fails.  (Assuming
> > > that the stable branch is good).
> >
> > Actually (since you won't be bisecting the latest linux-next), you
> > probably want to use
> >
> > git merge-base stable next-20190903
> >         (or whatever linux-next you are bisecting)
> >
> > as your first good commit (assuming it id good :-)).
> >
> > --
> > Cheers,
> > Stephen Rothwell
>
> Hi Stephen,
>
> Thanks very much for the tips.
> I'll go ahead and give those a try.

Yeah this should help, but in general, due to our non-linear history,
git bisect can jump around quite a bit. Especially if you only look at
dates. Also due to our non-linear history, it sometimes needs to test
you a merge-base, to figure out which part of the history it needs to
chase for the bad commit. So all normal, but the hint above should
help.

Also, you don't need to restart git bisect, you can just tell it about
any good/bad commit you tested with

$ git bisect good|bad $sha1

The more git knows, the quicker it should find the bad commit.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch