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: Tue, 08 Jul 2008 11:05:16 -0700 From: Mike Travis <travis@....com> To: Vegard Nossum <vegard.nossum@...il.com> CC: Ingo Molnar <mingo@...e.hu>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, mm-commits@...r.kernel.org, Yinghai Lu <yhlu.kernel@...il.com>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/1] x86: Change _node_to_cpumask_ptr to return const ptr Vegard Nossum wrote: > Hi, > > On Tue, Jul 8, 2008 at 7:06 PM, Mike Travis <travis@....com> wrote: >>> (v3 is applied already so Mike please send a delta to v3.) >>> >>> Ingo >> Subject: [PATCH 1/1] x86: Change _node_to_cpumask_ptr to return const ptr >> >> * Strengthen the return type for the _node_to_cpumask_ptr to be >> a const pointer. This adds compiler checking to insure that >> node_to_cpumask_map[] is not changed inadvertently. >> >> Applies to tip/master with the following patch applied: >> >> "[PATCH 1/1] x86: Add check for node passed to node_to_cpumask V3" >> >> Signed-off-by: Mike Travis <travis@....com> >> --- >> Note: I did not change node_to_cpumask_ptr() in include/asm-generic/topology.h >> as node_to_cpumask_ptr_next() does change the cpumask value. > > Hmmm. Does it really? > > #define node_to_cpumask_ptr_next(v, node) \ > _##v = node_to_cpumask(node) > > This doesn't seem to modify it? Well I thought about it. The pointer (*v) does not change but the underlying cpumask variable is updated with the cpumask for the (supposedly) new node number. You can see that in this code snippet from kernel/sched.c: for (i = 1; i < SD_NODES_PER_DOMAIN; i++) { int next_node = find_next_best_node(node, &used_nodes); node_to_cpumask_ptr_next(nodemask, next_node); cpus_or(*span, *span, *nodemask); } In the optimized (x86_64) case, the pointer is simply modified to point to the new node_to_cpumask_map[node] entry. It remains a pointer to a const value. But the non-optimized version replaces the const cpumask value with the new cpumask value. Isn't this breaking the const attribute? > > Also, isn't it unfortunate to have the same function return > const/non-const depending on your arch/config? But isn't that exactly what it does? (And in reality, the real protection happens when there is a node_to_cpumask_map[] present.) But whichever seems more correct is fine with me... ;-) Thanks, Mike -- 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