Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752480AbWCQBMf (ORCPT ); Thu, 16 Mar 2006 20:12:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752479AbWCQBMf (ORCPT ); Thu, 16 Mar 2006 20:12:35 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]:63265 "EHLO sj-iport-4.cisco.com") by vger.kernel.org with ESMTP id S1752485AbWCQBMc (ORCPT ); Thu, 16 Mar 2006 20:12:32 -0500 X-IronPort-AV: i="4.03,103,1141632000"; d="scan'208"; a="1785708087:sNHT3324945208" To: "Bryan O'Sullivan" Cc: Hugh Dickins , Andrew Morton , torvalds@osdl.org, hch@infradead.org, linux-kernel@vger.kernel.org Subject: Re: Remapping pages mapped to userspace X-Message-Flag: Warning: May contain useful information References: <71644dd19420ddb07a75.1141922823@localhost.localdomain> <1141948516.10693.55.camel@serpentine.pathscale.com> <1141949262.10693.69.camel@serpentine.pathscale.com> <20060309163740.0b589ea4.akpm@osdl.org> <1142470579.6994.78.camel@localhost.localdomain> <1142475069.6994.114.camel@localhost.localdomain> <1142477579.6994.124.camel@localhost.localdomain> <20060315192813.71a5d31a.akpm@osdl.org> <1142485103.25297.13.camel@camp4.serpentine.com> <20060315213813.747b5967.akpm@osdl.org> <1142553361.15045.19.camel@serpentine.pathscale.com> From: Roland Dreier Date: Thu, 16 Mar 2006 17:12:17 -0800 In-Reply-To: <1142553361.15045.19.camel@serpentine.pathscale.com> (Bryan O'Sullivan's message of "Thu, 16 Mar 2006 15:56:01 -0800") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 17 Mar 2006 01:12:17.0312 (UTC) FILETIME=[D521CA00:01C6495F] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 824 Lines: 19 Bryan> Why would you not want accesses to explode? Exploding Bryan> seems like the right behaviour to me, since there's no Bryan> hardware for userspace to talk to any more. Oh yeah... but getting rid of the mapping so userspace gets a segfault might be a good idea too. However, leaving the old PCI mapping there seems rather risky to me: I think it's entirely possible that accesses to that area after the device is gone could trigger machine checks or worse. So what's the right way for a driver to get rid of a remap_pfn_range() mapping into userspace? - R. - 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/