On Tue, Jan 29, 2019 at 05:32:49PM +0900, Masami Hiramatsu wrote: > > > # 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. Well, this didn't fail because a user space page was not mapped, but because a wrong address space with a different page table was used. If the kernel address space would have something mapped at the same address like user space, then garbage would have been returned instead. Still, this is a usage error. > > 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. It could be fixed if e.g. a new ustring fetcharg type would be supported, where we don't switch to KERNEL_DS. It would still fault when the page isn't mapped, but would access the correct address space. I don't know if it is really worth to implement this.. since I'm afraid this will cause "some" problems ;)
