Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757816AbZDTXMZ (ORCPT ); Mon, 20 Apr 2009 19:12:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756387AbZDTXMK (ORCPT ); Mon, 20 Apr 2009 19:12:10 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:37012 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755959AbZDTXMI (ORCPT ); Mon, 20 Apr 2009 19:12:08 -0400 Date: Tue, 21 Apr 2009 00:08:03 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.anvils To: Chris Friesen cc: Linus Torvalds , "Rafael J. Wysocki" , Linux Kernel Mailing List , Adrian Bunk , Andrew Morton , Natalie Protasevich , Kernel Testers List , Network Development , Linux ACPI , Linux PM List , Linux SCSI List , Trenton Adams Subject: Re: 2.6.29-git13: Reported regressions from 2.6.28 In-Reply-To: <49ECE783.5050704@nortel.com> Message-ID: References: <200904070035.00784.rjw@sisk.pl> <49E79E58.9000606@nortel.com> <49ECE783.5050704@nortel.com> 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: 2578 Lines: 56 On Mon, 20 Apr 2009, Chris Friesen wrote: > Linus Torvalds wrote: > > On Thu, 16 Apr 2009, Chris Friesen wrote: > > > I'm okay with that. The problem causes some backwards compatibility > > > problems > > > with existing apps that get confused by the large "offset" number. The > > > fix is > > > going to cause problems too, but in a different way. > > > > > > We'll work around it. > > > > If you have actual apps that care, that's a different issue. Yes, that's what I told Chris too. But asked for more info, suspecting his app was already broken. > > > > We do try to bend over backwards on ABI issues if it really is noticeable > > for applications. Now, in this case, if you can just fix your app to not > > care (because it really was badly written in the first place to even > > notice), then that is the _much_ superior solution. > > Yep, we can fix the app to ignore that field for anonymous mappings. > > > Although I don't really even see what we can sanely do except for the 0 > > case. We could put the virtual address in there instead of zero (I forget > > what old kernels used to do - whatever magic value the anonymous mappings > > got, it wasn't really designed as an important value in its own right, it > > was designed to trigger the "we can merge these vma's" logic. > > For anonymous mappings, the older kernels put the starting address of the VMA > (from the point of view of the app) as the offset. Until the recent change, > new kernels still did this for most VMAs, but the stack offset was a 64-bit > value with no obvious relation to the VMA start address. No, what they put there was something that in most cases matched the starting address of the VMA; but try moving that VMA with mremap (and an old /proc//maps!) and you'll see that the "offset" remained unchanged even when the starting address of the VMA was changed. (The offset remaining constant so that rmap can locate the VMA's pages and unmap them, despite their being mapped at different virtual addresses in parent and child after a move in one of them.) ... so I think your app was indeed already broken, wasn't it? It's also unclear why you'd want to use the offset field for the starting address of the VMA, when /proc//maps already shows the starting address of the VMA. I think you've more to tell us! Hugh -- 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/