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
| ||
|
Date: Mon, 30 May 2011 10:12:27 +0900 From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> To: torvalds@...ux-foundation.org CC: mingo@...e.hu, akpm@...ux-foundation.org, tglx@...utronix.de, linux-kernel@...r.kernel.org, a.p.zijlstra@...llo.nl, linux-mm@...ck.org Subject: Re: [PATCH] mm: Fix boot crash in mm_alloc() (2011/05/30 3:43), Linus Torvalds wrote: > On Sun, May 29, 2011 at 10:19 AM, Linus Torvalds > <torvalds@...ux-foundation.org> wrote: >> >> STILL TOTALLY UNTESTED! The fixes were just from eyeballing it a bit >> more, not from any actual testing. > > Ok, I eyeballed it some more, and tested both the OFFSTACK and ONSTACK > case, and decided that I had better commit it now rather than wait any > later since I'll do the -rc1 later today, and will be on an airplane > most of tomorrow. > > The exact placement of the cpu_vm_mask_var is up for grabs. For > example, I started thinking that it might be better to put it *after* > the mm_context_t, since for the non-OFFSTACK case it's generally > touched at the beginning rather than the end. > > And the actual change to make the mm_cachep kmem_cache_create() use a > variable-sized allocation for the OFFSTACK case is similarly left as > an exercise for the the reader. So effectively, this reverts a lot of > de03c72cfce5, but does so in a way that should make very it easy to > get back to where KOSAKI was aiming for. > > Whatever. I was hoping to get comments on it, but I think I need to > rather push it out to get tested and public than wait any longer. The > patch *looks* fine, tests ok on my machine, and removes more lines > than it adds despite the new big comment. Hi Thank you Linus and I'm sorry for bother you and guys. So, if I understand this thread correctly, rest my homework is 1) make cpumask_allocation variable size 2) remove NR_CPUS bit fill/copy from fork/exec path. Right? I think (2) is big matter than (1). NR_CPUS(=4096) bits copy easily screw up cache behavior. Anyway, will do. Thank you! -- 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