Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758113AbYJEQVe (ORCPT ); Sun, 5 Oct 2008 12:21:34 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758138AbYJEQRn (ORCPT ); Sun, 5 Oct 2008 12:17:43 -0400 Received: from www.tglx.de ([62.245.132.106]:59438 "EHLO www.tglx.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758123AbYJEQRl (ORCPT ); Sun, 5 Oct 2008 12:17:41 -0400 Date: Sun, 5 Oct 2008 18:16:29 +0200 (CEST) From: Thomas Gleixner To: Arjan van de Ven cc: Jesse Brandeburg , Jiri Kosina , Jesse Barnes , David Miller , jesse.brandeburg@intel.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kkeil@suse.de, agospoda@redhat.com, david.graham@intel.com, bruce.w.allan@intel.com, john.ronciak@intel.com, chris.jones@canonical.com, tim.gardner@canonical.com, airlied@gmail.com, Olaf Kirch , Linus Torvalds Subject: Re: [RFC PATCH 02/12] On Tue, 23 Sep 2008, David Miller wrote: In-Reply-To: <20081005090226.1e9eaae6@linux.intel.com> Message-ID: References: <20080930030825.22950.18891.stgit@jbrandeb-bw.jf.intel.com> <200810021523.45884.jbarnes@virtuousgeek.org> <20081003.134634.240211201.davem@davemloft.net> <200810031429.22598.jbarnes@virtuousgeek.org> <4807377b0810031628x43f79eferdbb9c9c264a5816e@mail.gmail.com> <4807377b0810041824u5ea472d1q4cf5ff606bd23a11@mail.gmail.com> <48E8D7A5.7060508@linux.intel.com> <20081005090226.1e9eaae6@linux.intel.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1916 Lines: 47 On Sun, 5 Oct 2008, Arjan van de Ven wrote: > On Sun, 5 Oct 2008 17:55:14 +0200 (CEST) > Thomas Gleixner wrote: > > > On Sun, 5 Oct 2008, Arjan van de Ven wrote: > > > Thomas Gleixner wrote: > > > > On Sat, 4 Oct 2008, Jesse Brandeburg wrote: > > > > > > Exactly. The access to a ro region results in a fault. I have > > > > > > nowhere seen that trigger, but I can reproduce the trylock() > > > > > > WARN_ON, which confirms that there is concurrent access to > > > > > > the NVRAM registers. The backtrace pattern is similar to the > > > > > > one you have seen. > > > > > are you still getting WARN_ON *with* all the mutex based fixes > > > > > already applied? > > > > > > > > The WARN_ON triggers with current mainline. Is there any fixlet in > > > > Linus tree missing ? > > > > > > > > > with the mutex patches in place (without protection patch) we > > > > > are still reproducing the issue, until we apply the > > > > > set_memory_ro patch. > > > > > > > > That does not make sense to me. If the memory_ro patch is > > > > providing _real_ protection then you _must_ run into an access > > > > violation. If not, then the patch just papers over the real > > > > problem in some mysterious way. > > > > > > > > > > not if the bad code is doing copy_to_user .... (or similar) > > > > You mean: copy_from_user :) This would require that the e1000e > > nvram region is writable via copy_from_user by an e1000e user space > > interface. A quick grep does not reviel such a horrible interface. > > I meant a "copy_to_user" to a duff pointer, somewhere in the kernel. Hmm, don't we check the *to address on copy_to_user ? Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/