On Wed, 8 May 2019 13:11:43 +0900 Masami Hiramatsu <mhira...@kernel.org> wrote:
> On Mon, 6 May 2019 11:52:26 -0400 > Steven Rostedt <rost...@goodmis.org> wrote: > > > On Mon, 18 Mar 2019 15:43:52 +0900 > > Masami Hiramatsu <mhira...@kernel.org> wrote: > > > > > +.. _user_mem_access: > > > +User Memory Access > > > +------------------ > > > +Kprobe events supports user-space memory access. For that purpose, you > > > can use > > > +either user-space dereference syntax or 'ustring' type. > > > + > > > +The user-space dereference syntax allows you to access a field of a data > > > +structure in user-space. This is done by adding the "u" prefix to the > > > +dereference syntax. For example, +u4(%si) means it will read memory from > > > the > > > +address in the register %si offset by 4, and the mory is expected to be > > > in > > > > ^^^^ > > "memory" > > OK, thanks! > > > > > > +user-space. You can use this for strings too, e.g. +u0(%si):string will > > > read > > > +a string from the address in the register %si that is expected to be in > > > user- > > > +space. 'ustring' is a shortcut way of performing the same task. That is, > > > ++0(%si):ustring is equivalent to +u0(%si):string. > > > + > > > +Note that kprobe-event provides the user-memory access syntax but it > > > doesn't > > > +use it transparently. This means if you use normal dereference or string > > > type > > > +for user memory, it might fail, and always fails on some arch. So user > > > has to > > > > "and may always fail on some archs. The user has to carefully check > > if the target data is in kernel or user space." > > OK. I'll update. > > > > +check if the targe data is in kernel or in user space carefully. > > > > > > Per-Probe Event Filtering > > > ------------------------- > > > diff --git a/Documentation/trace/uprobetracer.rst > > > b/Documentation/trace/uprobetracer.rst > > > index 4346e23e3ae7..de8812c932bc 100644 > > > --- a/Documentation/trace/uprobetracer.rst > > > +++ b/Documentation/trace/uprobetracer.rst > > > @@ -42,16 +42,17 @@ Synopsis of uprobe_tracer > > > @+OFFSET : Fetch memory at OFFSET (OFFSET from same file as PATH) > > > $stackN : Fetch Nth entry of stack (N >= 0) > > > $stack : Fetch stack address. > > > - $retval : Fetch return value.(*) > > > + $retval : Fetch return value.(\*1) > > > $comm : Fetch current task comm. > > > - +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) > > > + +|-[u]OFFS(FETCHARG) : Fetch memory at FETCHARG +|- OFFS > > > address.(\*2)(\*3) > > > NAME=FETCHARG : Set NAME as the argument name of FETCHARG. > > > FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, > > > basic types > > > (u8/u16/u32/u64/s8/s16/s32/s64), hexadecimal types > > > (x8/x16/x32/x64), "string" and bitfield are supported. > > > > Hmm, shouldn't uprobes default to userspace. Isn't the purpose mostly > > to find out what's going on in userspace. Perhaps we should add a 'k' > > annotation to uprobes to denote that it's for kernel space, as that > > should be the exception and not the norm. > > No, uprobe can not access kernel space, because it doesn't have the > current kernel context. Note that all registers, stacks which > can be accessed from uprobe handler are user-space. We can not access > kernel context from that. See below > > > > - (*) only for return probe. > > > - (**) this is useful for fetching a field of data structures. > > > + (\*1) only for return probe. > > > + (\*2) this is useful for fetching a field of data structures. > > > + (\*3) Unlike kprobe event, "u" prefix will just be ignored. > > Thus the 'u' is just ignored on uprobe event. I totally missed the footnote here. Can we stress this point more up in the "User Memory Access" section. Specifically state something like: "Uprobes only access userspace memory, thus the 'u' is not required, and if it is added to a uprobe, it will simply be ignored". Thanks! -- Steve