linux-kernel - Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch methods (v6)

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:	Fri, 8 Nov 2013 17:52:33 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Namhyung Kim <namhyung.kim@....com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hyeoncheol Lee <cheol.lee@....com>,
	Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [PATCHSET 00/13] tracing/uprobes: Add support for more fetch
	methods (v6)

Hi Namhyung,

sorry for delay.

On 11/07, Namhyung Kim wrote:
>
> >> > As for "-= tu->offset"... Can't we avoid it? User-space needs to calculate
> >> > the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Hmm.. it makes sense too. :)
> >
> > I am no longer sure ;)
> >
> > This way the "@" argument will look more confusing, it will depend on the
> > address/offset of the probed insn. But again, I do not know, this is up
> > to you.
>
> That said, I'd prefer the original "-= -tu->offset" approach.  It'll
> make debugging easier IMHO.

I do not really mind, and probably you are right. Actually it seems
that I was confused, if user-space does "-= -tu->offset" itself then
the "@" argument will look more consistent (contrary to what I said
above).

In any case we should make the calculation of "@" argument (in user
space) as simple/clear as possible, it is very easy to add the
additional hacks in kernel if necessary.

And this is very (if not most) important part, we can change the kernel
later, but it is not easy to change the already working semantics, so I'd
like to know what other reviewers think.

Oleg.

--
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/