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 12:33:42 -0600 From: Matt Mackall <mpm@...enic.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Ingo Molnar <mingo@...e.hu>, "Rafael J. Wysocki" <rjw@...k.pl>, LKML <linux-kernel@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.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, Dec 08, 2007 at 09:54:06AM -0800, Linus Torvalds 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*. But what about: (c) stop passing GFP_ZERO to kmalloc allocators stop fiddling with flags inside allocators remove ugly if (unlikely(gfp & GFP_ZERO)) from kmalloc allocators make kzalloc and kcalloc non-inline functions that do the memset That should: - make both kmalloc and kzalloc/kcalloc faster (one less branch) - reduce kernel size GFP_ZERO is a bit of an abuse here, given that we don't even intend to pass it to the underlying "GFP". -- Mathematics is the supreme nostalgia of our time. -- 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