On Tue, 29 Jan 2019 07:16:19 +0100 Heiko Carstens <heiko.carstens@xxxxxxxxxx> wrote: > On Mon, Jan 28, 2019 at 10:14:58PM +0100, Jiri Olsa wrote: > > hi, > > we see a problem on s390x when trying to retrieve string > > argument for kprobe, like: > > > > # perf probe 'do_sys_open filename:string' > > # perf record -e probe:do_sys_open -a find / > /dev/null > > ^C[ perf record: Woken up 3 times to write data ] > > [ perf record: Captured and wrote 0.774 MB perf.data (7382 samples) ] > > # perf script > > find 22222 [001] 296517.144464: probe:do_sys_open: (34a7c0) filename_string="" > > find 22222 [001] 296517.144536: probe:do_sys_open: (34a7c0) filename_string="" > > find 22222 [001] 296517.144551: probe:do_sys_open: (34a7c0) filename_string="" > > find 22222 [001] 296517.144580: probe:do_sys_open: (34a7c0) filename_string="" > > ... > > > > we see the same error after enabling the same event via tracefs, like: > > > > # cd /sys/kernel/debug/tracing > > # cat trace > > <...>-18602 [000] d... 288289.847945: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > <...>-18602 [000] d... 288289.848586: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > <...>-18602 [000] d... 288289.852643: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > <...>-18602 [000] d... 288289.853202: do_sys_open: (do_sys_open+0x0/0x238) filename_string=(fault) > > ... > > > > I'm getting this on latest upstream 5.0.0-rc3+ > > > > looks like we call strncpy_from_unsafe -> __get_user, which fails > > in this case.. any idea if this is perhaps some known issue on s390x? > > This looks like the wrong address space is accessed. The "string" type > is supposed to copy a string from _kernel_ space while the filename > argument of do_sys_open() is a user space pointer. Right... since kprobes runs in interrupt(exception) handler, we can not sleep inside it, so accessing user-space can be failed. > This doesn't work on s390 due to the complete distinct address > spaces. At least that's what this looks like at a first glance. Yeah, anyway, accessing user-space variable from kprobe event is not guaranteed. Suppose that if the user-space variable is swapped out, we also can not access it, since kprobe handler is not sleepable. > And if I'm correct it is not easy to "fix". _If_ this functionality is > desired then the kprobes interface must probably be changed so that it > would be possible to specify the address space from where something > should be copied. Or.. maybe the "__user" annotation in the kernel > code can be instrumented(?). No, I don't want to "fix" this. Describing in a document will be OK, but this is a limitation comes from its design. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
