[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180110090305.hx5b7lo3qnd4ko7j@arbeitstier>
Date: Wed, 10 Jan 2018 10:03:05 +0100
From: Tobias Hommel <netdev-list@...oetigt.de>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: netdev@...r.kernel.org
Subject: Re: BUG: 4.14.11 unable to handle kernel NULL pointer dereference in
xfrm_lookup
On Wed, Jan 10, 2018 at 08:30:38AM +0100, Steffen Klassert wrote:
> On Tue, Jan 09, 2018 at 03:49:21PM +0100, Tobias Hommel wrote:
> >
> > I copied the config from my 4.14.12 sources to a fresh 4.13.16 source tree, ran
> > `make olddefconfig` and built a new kernel.
> > The kernel config is attached as kernel-4.13.16.config.
> > The panic*.log files are kernel logs from different crashes of this 4.13.16
> > kernel, but all from the same scenario as before.
> > I also enabled CONFIG_DEBUG_INFO, so if any disassemblies are required, I'd be
> > happy to provide them.
> >
> > So, the system still crashes, but the traces are completely different from
> > those with 4.14.12. This time there are also WARNINGs and "refcnt: -1" messages
> > sometimes before the actual panic, so not sure if there is maybe some other
> > problem. Still, the crashes all seem to be related to ip routing somehow.
>
> Strange, you must do something that other people don't do.
> Do you have some uncommon netfiler rules, namespaces, etc?
No, no namespaces yet.
However, the box uses marks and routing based on marks. Firewall marks are a
bit strange sometimes, so I'll try to clean up everything and see if it is
possible to reproduce the bug without marks.
>
> Please try to build your kernels with
>
> CONFIG_ORC_UNWINDER (v4.14 and above)
>
> and
>
> CONFIG_KASAN
>
> This can give some better debug informations (depends on the compiler
> version).
I'll also try that. I'm currently using GCC 5.4.0.
>
> There are some things we can do now:
>
> - Try v4.15-rc7, just to be sure that we don't search for
> something that is already fixed.
And that one, too. All this will probably take some time though. ;-)
I'll keep you informed.
>
> - Find a working kernel version and try to bisect.
>
> - Minimalize the configuration with that the bug happens,
> so that I can try to reproduce it here.
>
Powered by blists - more mailing lists