Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030562AbVIOSJT (ORCPT ); Thu, 15 Sep 2005 14:09:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030563AbVIOSJT (ORCPT ); Thu, 15 Sep 2005 14:09:19 -0400 Received: from ppp-217-133-42-200.cust-adsl.tiscali.it ([217.133.42.200]:28506 "EHLO opteron.random") by vger.kernel.org with ESMTP id S1030562AbVIOSJT (ORCPT ); Thu, 15 Sep 2005 14:09:19 -0400 Date: Thu, 15 Sep 2005 20:09:28 +0200 From: Andrea Arcangeli To: Linus Torvalds Cc: Hugh Dickins , Nick Piggin , linux-kernel@vger.kernel.org, Andrew Morton , Roland McGrath Subject: Re: ptrace can't be transparent on readonly MAP_SHARED Message-ID: <20050915180928.GI4122@opteron.random> References: <20050914212405.GD4966@opteron.random> <20050915154702.GA4122@opteron.random> <20050915162347.GC4122@opteron.random> <20050915165117.GE4122@opteron.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1354 Lines: 28 On Thu, Sep 15, 2005 at 10:52:14AM -0700, Linus Torvalds wrote: > And the PTRACE_POKE is _exactly_ the same thing. There's _zero_ > difference. The fact that PTRACE_POKE _changes_ the data instead of just > reading it doesn't change anything at all - the fact that data got changed > in NO WAY invalidates the fact that processes might still depend on > getting a SIGSEGV. And this process may as well depend to see the on-disk changes that other threads are doing on the shared memory, and that will break regardless of what Linus changes in the kernel. You also didn't make up any useful example where _writing_ (not reading like in your example) was involved. Your example is totally offtopic, since it only involved reading as far as I can tell. I can't imagine where writing to a PROT_NONE is actually useful. > Now, if you have a technical reason why "maybe_mkwrite()" needs to go > away, then that's a different thing. BUT IT HAS NOTHING TO DO WITH THE > FACT THAT WE LOOKED AT OR CHANGED THE DATA! It just looks unnecessary cruft, but I'll stick with kernel crashing bugs for my own safety. - 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/