linux-kernel - Re: 2.6.29-git13: Reported regressions from 2.6.28

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <49ECE783.5050704@nortel.com>
Date:	Mon, 20 Apr 2009 15:22:11 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Adrian Bunk <bunk@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Network Development <netdev@...r.kernel.org>,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	Linux PM List <linux-pm@...ts.linux-foundation.org>,
	Linux SCSI List <linux-scsi@...r.kernel.org>,
	Trenton Adams <trenton.d.adams@...il.com>
Subject: Re: 2.6.29-git13: Reported regressions from 2.6.28

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.
> 
> 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.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/