From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751534AbbICINO (ORCPT <rfc822;w@1wt.eu>);
	Thu, 3 Sep 2015 04:13:14 -0400
Received: from enficsets1.metaswitch.com ([192.91.191.38]:45398 "EHLO
	ENFICSETS1.metaswitch.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750818AbbICINJ convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 3 Sep 2015 04:13:09 -0400
From: Shaun Crampton <Shaun.Crampton@metaswitch.com>
To: Daniel Borkmann <daniel@iogearbox.net>
CC: Eric Dumazet <eric.dumazet@gmail.com>,
        Michael Marineau <michael.marineau@coreos.com>,
        Chuck Ebbert <cebbert.lkml@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Peter White <Peter.White@metaswitch.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: ip_rcv_finish() NULL pointer and possibly related Oopses
Thread-Topic: ip_rcv_finish() NULL pointer and possibly related Oopses
Thread-Index: AQHQ39vEIQicANUMIE+dW4fd3KXwxp4eGjCAgACYJoCAAQ3AgIAJvCgAgABtyoCAAJb2gA==
Date: Thu, 3 Sep 2015 08:13:06 +0000
Message-ID: <D20DBEF2.437A0%Shaun.Crampton@metaswitch.com>
References: <D2033B8F.4133C%Shaun.Crampton@metaswitch.com>
 <20150826074959.48aea34c@as>
 <CAGr1u3twv7KnXug3xZqL3X9NNpWBwGvw1RQpMHyqBmcC2ikamw@mail.gmail.com>
 <1440680401.8932.39.camel@edumazet-glaptop2.roam.corp.google.com>
 <D20CE2AD.43744%Shaun.Crampton@metaswitch.com>
 <55E7907D.9000606@iogearbox.net>
In-Reply-To: <55E7907D.9000606@iogearbox.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [172.18.209.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E2659F5D3B283B4790B8A8A82D785AEA@metaswitch.com>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


>Looking at this one, I am still puzzeled where 0xffffffffa008772b and
>0xffffffffa008772b comes from ... some driver, bridge ...?

Is there anything I can do on a running system to help figure this out?
Some sort of kernel equivalent to pmap to find out what module or device
owns that chunk of memory?