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]
Message-ID: <20131128163148.GA15985@redhat.com>
Date:	Thu, 28 Nov 2013 17:31:48 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hyeoncheol Lee <cheol.lee@....com>,
	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@...wei.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Hemant Kumar <hkshaw@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Namhyung Kim <namhyung.kim@....com>
Subject: Re: [PATCH/RFC 17/17] tracing/uprobes: Add @+file_offset fetch
	method

On 11/28, Namhyung Kim wrote:
>
> I thought we need a fetch_param anyway if we will add support for
> cross-fetch later.  But I won't insist it strongly, I can delay it to
> later work and make current code simpler if you want. :)

OK, great,

> >>  static int uprobe_dispatcher(struct uprobe_consumer *con, struct pt_regs *regs)
> >>  {
> >>  	struct trace_uprobe *tu;
> >> +	struct uprobe_task *utask;
> >>  	int ret = 0;
> >>
> >>  	tu = container_of(con, struct trace_uprobe, consumer);
> >>  	tu->nhit++;
> >>
> >> +	utask = current->utask;
> >> +	if (utask == NULL)
> >> +		return UPROBE_HANDLER_REMOVE;
> >
> > Hmm, why? The previous change ensures ->utask is not NULL? If we hit
> > NULL we have a bug, we should not remove this uprobe.
>
> Yes, I just want to be defensive. :)
>
> So do you suggest to add BUG_ON()?

We are going to crash with the same effect if it is NULL ;)

> And can I convert or remove a
> similar check in uprobes.c:pre_ssout() too?

Well, yes, we _can_ do this. But unless you have the strong opinion
I'd suggest to not do this. At least right now.

To remind, perhaps we can revert the previous patch later if we find
a better solution (placeholder).

And. Note that we will change this code in any case. I suggested to
use ->vaddr to avoid the other (potentially conflicting) changes in
uprobes.h. Even if we use current->utask, we should add another member
into the union. But again, it would be better to do this later, and
the change will be trivial.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ