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: Fri, 18 Mar 2011 20:58:38 -0700 (PDT) From: Hugh Dickins <hughd@...gle.com> To: Christoph Lameter <cl@...ux.com> cc: Pekka Enberg <penberg@...nel.org>, Lai Jiangshan <laijs@...fujitsu.com>, Ingo Molnar <mingo@...e.hu>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Eric Dumazet <eric.dumazet@...il.com>, "David S. Miller" <davem@...emloft.net>, Matt Mackall <mpm@...enic.com>, linux-mm@...ck.org, linux-kernel@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH 2/4] slub,rcu: don't assume the size of struct rcu_head On Thu, 17 Mar 2011, Christoph Lameter wrote: > On Sun, 6 Mar 2011, Hugh Dickins wrote: > > > >> That was so for a long time, but I stopped it just over a year ago > > >> with commit a70caa8ba48f21f46d3b4e71b6b8d14080bbd57a, stop ptlock > > >> enlarging struct page. > > > > > > Strange. I just played around with in in January and the page struct size > > > changes when I build kernels with full debugging. I have some > > > cmpxchg_double patches here that depend on certain alignment in the page > > > struct. Debugging causes all that stuff to get out of whack so that I had > > > to do some special patches to make sure fields following the spinlock are > > > properly aligned when the sizes change. > > > > That puzzles me, it's not my experience and I don't have an > > explanation: do you have time to investigate? > > > > Uh oh, you're going to tell me you're working on an out-of-tree > > architecture with a million cpus ;) In that case, yes, I'm afraid > > I'll have to update the SPLIT_PTLOCK_CPUS defaulting (for a million - > > 1 even). > > No I am not working on any out of tree structure. Just regular dual socket > server boxes with 24 processors (which is a normal business machine > configuration these days). > > But then there is also CONFIG_GENERIC_LOCKBREAK. That does not affect > things? CONFIG_GENERIC_LOCKBREAK adds an unsigned int break_lock after the int-sized arch_spinlock_t: which would make no difference on 64-bit anyway (the two ints fitting into one long), and makes no difference on 32-bit because we have put struct { unsigned long private; struct address_space *mapping; }; into the union with spinlock_t ptl - the arch_spinlock_t then overlays private and the break_lock overlays mapping. I'd much rather have had simple elements in that union, but it's precisely because of 32-bit CONFIG_GENERIC_LOCKBREAK that we need that structure in there. (It is important to the KSM assumption about page->mapping that what goes into break_lock is either 0 or 1: in neither case could page->mapping look like a kmem address + 3.) Hugh -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists