From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752777AbYIXFp5 (ORCPT ); Wed, 24 Sep 2008 01:45:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751097AbYIXFps (ORCPT ); Wed, 24 Sep 2008 01:45:48 -0400 Received: from rn-out-0910.google.com ([64.233.170.191]:20343 "EHLO rn-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750844AbYIXFpr (ORCPT ); Wed, 24 Sep 2008 01:45:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=b8LeM/GtriKptc0FYEbbc5i9euKTpaoc85GckZPzerC/Kw5BQg6TK4y2UJW2WOXBPr FFM2L7ofZckmu20Oix+dnzxmTtqqvL5S102ZSVo5NcvFmF+jTR4+0QahsnzU3iAc9i28 HTZvQbb5ZiNpFyS4clm7BAaSPP9BQ/ydc7jws= Message-ID: <21d7e9970809232245x6a91c6e2l552ff039d07e2017@mail.gmail.com> Date: Wed, 24 Sep 2008 15:45:46 +1000 From: "Dave Airlie" To: "David Miller" Subject: Re: [Bug #11382] e1000e: 2.6.27-rc1 corrupts EEPROM/NVM Cc: jkosina@suse.cz, jeffrey.t.kirsher@intel.com, david.vrabel@csr.com, rjw@sisk.pl, linux-kernel@vger.kernel.org, kernel-testers@vger.kernel.org, chrisl@vmware.com In-Reply-To: <20080923.211215.193696086.davem@davemloft.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080923.150722.141587696.davem@davemloft.net> <9929d2390809231512w160d221axa2923a6b293a041@mail.gmail.com> <20080923.211215.193696086.davem@davemloft.net> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 24, 2008 at 2:12 PM, David Miller wrote: > From: Jiri Kosina > Date: Wed, 24 Sep 2008 00:19:00 +0200 (CEST) > >> On Tue, 23 Sep 2008, Jeff Kirsher wrote: >> >> > >> I don't think OpenSUSE was shipping any of the GEM bits. >> > > Good data point, can someone confirm this? Also, what X server version >> > > is the effected OpenSUSE shipping? >> > OpenSuSE 11 ships x server version 7.3. >> >> Opensuse 11 is fine. >> >> The problem can be reproduced [not only] on opensuse 11.1 beta1, which has >> >> xorg-x11-7.4-1.6.x86_64.rpm > > I did some snooping around, and while doing so I noticed that the PCI > mmap code for x86 doesn't do one bit of range checking on the size, or > any other aspect of the request, wrt. the MMIO regions actually mapped > in the BARs of the PCI device. > > Yikes! > > It just does a reserve_memtype() on the address range, and says "ok". > > So if, for example, the X server tries to mmap() more than an MMIO bar > actually maps, the kernel lets the user do this. > > It would be very interesting to add the appropriate checks to > pci_mmap_page_range() in arch/x86/pci/i386.c, anyone who wants to do > this can use the code in arch/sparc64/kernel/pci.c: > __pci_mmap_make_offset() as a guide, and see what happens. > > If the MMIO space regions of the video cards sit right before the > E1000E ones on the effected systems, that would pretty much > convince me that this is the kind of problem we are having here. > > This also reminds me that there was that whole set of issues that > had to get worked out wrt. write-caching of mappings on x86. > I'm still dubious about this, wouldn't we see other wierdass side effects if X was trashing the BARs on other devices? I think tglx is on the right path, same problem as e1000, code is stupid, it can reenter the nvram read/write code from irq context, and pwn itself. Dave.