linux-kernel - Re: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803 do_one

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] [day] [month] [year] [list]

Message-ID: <20141123050617.GA9218@wfg-t540p.sh.intel.com>
Date:	Sat, 22 Nov 2014 21:06:17 -0800
From:	Fengguang Wu <fengguang.wu@...el.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	LKP <lkp@...org>, linux-kernel@...r.kernel.org
Subject: Re: [ftrace/x86/extable] WARNING: CPU: 0 PID: 1 at init/main.c:803
 do_one_initcall()

On Sat, Nov 22, 2014 at 04:53:02PM -0500, Steven Rostedt wrote:
> On Sat, 22 Nov 2014 11:59:26 -0800
> Fengguang Wu <fengguang.wu@...el.com> wrote:
> 
> >
> > > Is it possible for your tests to see if a branch was rebased before
> > > posting bug reports to LKML? This gave me a scare that my new code had
> > > the same brain fart in it.
> > 
> > Sure and good idea! I'll implement it right now.
> > 
> 
> It should also make sure that the rebase does not include the offending
> commit before not sending out the email. A rebase alone may still have
> the bug.
> 
> And if you really want to be fancy, you can check to see if the code
> itself changed. The attached script takes two git releases (SHA1s,
> tags, etc) or one git release and uses HEAD, and finds where the two
> are different. Not just by commit id, but also by code. I use this
> because I'll modify a branch to add an acked-by and not change the code,
> but still want to know the last commit that I tested. It may not have
> the same commit id.

I definitely would like to be fancy. I think I'll not only check if
the branch has been rebased, but also test the rebased branch out to
make sure the problem is still there. I've been doing this check for
the build bisects. When doing so, it no longer matters how the rebased
branch differs from the original branch in source code level. For
example, even the simple rebase to a new RC base might make a problem
disappear.

Thanks,
Fengguang
--
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/