From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: Re: BUG: unable to handle kernel NULL pointer dereference at 000000000000002c Date: Mon, 30 Jan 2012 16:48:28 -0500 (EST) Message-ID: <20120130.164828.1695146432151008554.davem@davemloft.net> References: <20120130171215.GA11508@kroah.com> <20120130.130717.348683183628737352.davem@davemloft.net> <4F26E72E.2020007@profihost.ag> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: greg@kroah.com, eric.dumazet@gmail.com, jwboyer@gmail.com, hch@infradead.org, netdev@vger.kernel.org, david@fromorbit.com, stable@vger.kernel.org, gregkh@suse.de To: s.priebe@profihost.ag Return-path: Received: from shards.monkeyblade.net ([198.137.202.13]:42426 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753387Ab2A3Vt7 (ORCPT ); Mon, 30 Jan 2012 16:49:59 -0500 In-Reply-To: <4F26E72E.2020007@profihost.ag> Sender: netdev-owner@vger.kernel.org List-ID: From: Stefan Priebe Date: Mon, 30 Jan 2012 19:53:34 +0100 > So we're talking AT LEAST about these ones: >>Linus tree : >> >>commit 580da35a31f91a594f3090b7a2c39b85cb051a12 >>IB: Fix RCU lockdep splats Doesn't even come close to applying to v3.0.18 That patch would only apply properly if the IB code is using the dst_get_neighbour() interface, which doesn't even exist in v3.0.18 >>David tree : >> >>commit 218fa90f072e4aeff9003d57e390857f4f35513e >>ipv4: fix lockdep splat in rt_cache_seq_show Patch also does not apply, and for the same reason as the IB patch. dst_get_neighbour() doesn't exist in v3.0.18, and therefore this code being patched doesn't make use of it. >>commit f7e57044eeb1841847c24aa06766c8290c202583 >>sch_teql: fix lockdep splat I'm not even going to try applying this one, it's going to have the same issue as the previous two. The patch mentioned by commit 218fa90f072e4aeff9003d57e390857f4f35513e ("ipv4: fix lockdep splat in rt_cache_seq_show") is not in the v3.0.x tree, and it's a prerequisite for the rt_cache_seq_show() change being even necessary. In all, I think this request is invalid. You're asking me to submit patches to -stable which don't apply even remotely, and whose dependencies haven't even been applied to the tree.