(2013/11/27 2:43), Oleg Nesterov wrote: > On 11/26, Masami Hiramatsu wrote: >> >> (2013/11/26 2:22), Oleg Nesterov wrote: >>> @symbol can't be used to dump the per-cpu variables. The same is >>> true for +offset(something) if "something" results in __percpu >>> pointer. >>> >>> With this patch parse_probe_offset() treats "~" before the numeric >>> offset as "per cpu" mark and stores it in the lowest bit, >>> calc_probe_offset() simply adds per_cpu_offset(smp_processor_id()) >>> if this bit is set. >> >> IMHO, if the symbol is a per-cpu symbol, it is meaningless to >> access the symbol itself. For the symbol(static) percpu, maybe >> we can use is_kernel_percpu_address() to check. > > No, we can't use is_kernel_percpu_address(), this is another thing. > is_kernel_percpu_address(&my_pcpu_var) == F. It is true for > &per_cpu(my_pcpu_var), this is not what we need.
Ah OK. > >> If the symbol is >> percpu, it should be automatically translated to something like >> FETCH_percpu, instead of such additional expression. > > OK. Probably yes, it should be automatically translated, please > see the patches. > > This doesn't allow to read the data from other CPUs, but at least > the changes are simple and this_cpu_ is better than the reading > from the obviously wrong address. Yeah, usually per_cpu variable is used in current cpu context. >> For the dynamic allocated per-cpu things, it is also good to give >> a straight operation, like +10(percpu(%rdi)). > > Probably yes, but this needs more changes and I am still not sure > this is really useful. And if we do this, we probably also need > to allow to read from other CPUs... No, it is enough to provide "percpu(FETCHARG)" which just returns current cpu's percpu variable address. (Note that kprobes handler runs in interrupt) Thank you, -- Masami HIRAMATSU IT Management Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/