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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 30 Sep 2015 08:05:09 +0000
From:	平松雅巳 / HIRAMATU,MASAMI 
	<masami.hiramatsu.pt@...achi.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...nel.org>,
	Wang Nan <wangnan0@...wei.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: RE: [perf probe] How to ask what variables can be collected at
 function return?

From: Arnaldo Carvalho de Melo [mailto:acme@...nel.org]
>
>How to figure out which variables can I collect at function return?
>None?

At first, it seems the below pattern failed to get the probe point itself,
because you're specifying the return point of an inlined function, which
is nowhere.

If you give a function which has actual instance, perf-probe may show
the variables which will be accessable in the entry of the function as below.

$ sudo ./perf probe -V "vfs_read%return"
Available variables at vfs_read%return
        @<vfs_read+0>
                char*   buf
                loff_t* pos
                size_t  count
                struct file*    file

However, this may not work on the arguments passed by registers,
since those may be already broken by the operations in the function.

So, to get correct accessible variables at return, you must give an actual
line number in the function currently.

$ sudo ./perf probe -L vfs_read
<vfs_read@...me/mhiramat/ksrc/linux-3/fs/read_write.c:0>
      0  ssize_t vfs_read(struct file *file, char __user *buf, size_t count, lof
      1  {
                ssize_t ret;

      4         if (!(file->f_mode & FMODE_READ))
      5                 return -EBADF;
      6         if (!(file->f_mode & FMODE_CAN_READ))
      7                 return -EINVAL;
      8         if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
      9                 return -EFAULT;

     11         ret = rw_verify_area(READ, file, pos, count);
     12         if (ret >= 0) {
                        count = ret;
     14                 ret = __vfs_read(file, buf, count, pos);
     15                 if (ret > 0) {
     16                         fsnotify_access(file);
     17                         add_rchar(current, ret);
                        }
     19                 inc_syscr(current);
                }

                return ret;
     23  }

$ sudo ./perf probe -V vfs_read:23
Available variables at vfs_read:23
        @<vfs_read+214>
                char*   buf
                loff_t* pos
                size_t  count
                struct file*    file


>
>I think we need a better error message :-)
>
>[root@zoo ~]# perf probe -V getname_flags%return Return probe must be on the head of a real function.

It seems that perf probe said " Return probe must be on the head of a real function."
So this means it can not find the given probe point because the %return is not 
put on the entry of the function which has actual instance.

Thanks.


>Debuginfo analysis failed.
>  Error: Failed to show vars.
>[root@zoo ~]#
>
>
>- Arnaldo
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ