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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 8 Dec 2007 10:09:50 -0800 From: Andrew Morton <akpm@...ux-foundation.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Matt Mackall <mpm@...enic.com>, Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>, LKML <linux-kernel@...r.kernel.org>, Christoph Lameter <clameter@....com> Subject: Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23] On Sat, 8 Dec 2007 09:54:06 -0800 (PST) Linus Torvalds <torvalds@...ux-foundation.org> wrote: > On Sat, 8 Dec 2007, Linus Torvalds wrote: > > > > But I'll apply it anyway, because it looks "obviously correct" from the > > standpoint that the _other___slob user already clears the end result > > explicitly later on, and we simply should never pass down __GFP_ZERO to > > the actual page allocator. > > Actually, I take that back. The other slob users are different. They share > pages, this codepath does not. > > So I think a more proper solution would be: > (a) Something like this patch (which includes my previous mm/slub.c > change) > (b) don't warn about atomic GFP_ZERO's - unless they have GFP_HIGHMEM set > *too*. > > So which warning is it that triggers the bogus error? It's a kmap_atomic() debugging patch which I wrote ages ago and whcih Ingo sucked into his tree. I don't _think_ this warning is present in your tree at all. http://lkml.org/lkml/2007/11/29/157 is where it starts. I had a lenghty back-and-forth with Christoph on this within the past couple of months and I cannot locate the thread and I don't recall what the upshot was and Christoph is still offline. Knocking out __GFP_ZERO at the point where the slab allocator(s) call the page allocator seems like a good approach to me. But I don't think we need to do anything for 2.6.24.. -- 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/
Powered by blists - more mailing lists