linux-kernel - Re: [PATCH v6 00/14] uprobes: Add uprobes support for ARM

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:	Mon, 03 Mar 2014 05:08:06 -0500
From:	David Long <dave.long@...aro.org>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
CC:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Oleg Nesterov <oleg@...hat.com>,
	linux-arm-kernel@...ts.infradead.org, Rabin Vincent <rabin@....in>,
	"Jon Medhurst (Tixy)" <tixy@...aro.org>,
	Ingo Molnar <mingo@...hat.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
	davem@...emloft.net, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 00/14] uprobes: Add uprobes support for ARM

On 03/03/14 01:23, Srikar Dronamraju wrote:

> It should be me who should take the blame for this and not Oleg.  This
> was discussed more than couple of times.  I can recollect couple of
> discussions here.
> http://article.gmane.org/gmane.linux.kernel/1017186
> http://article.gmane.org/gmane.linux.kernel/1001605

I wasn't trying to assign blame to anyone, I was just soliciting an 
opinion from the last uprobes maintainer I had a conversation with. 
Thanks for the links.

> I know there were more discussions on this, but I cant dig them out at
> this time.  Finally it was decided that
> 1. Users shouldnt have to select more than one config to select Uprobes.
> 2. There was no point in selecting Uprobes and not having Uprobe_event
> and vice versa.
>
>  From the above, If a user chose UPROBE_EVENT, (which is the interface
> for uprobes), we would automatically assume that he wants to use Uprobes
> framework.
>
>> like "select" is used in part maybe just to avoid the recursive
>> dependency error that would be generated if "depends on" were used
>> in both places.
>
> We did "Select Uprobes" not because of avoiding recursive dependency but
> as told above, to select the framework, given that user has chosen the
> framework. We dont want to give a choice to user to choose uprobe_event
> but not choose Uprobes or vice versa.

I suppose that's more to the point.

>> However I don't think UPROBES should be dependent on
>> UPROBE_EVENT, only the other way around.  As RK noted in previous
>
> Whats the point of having the framework(Uprobes) without an interface?
>

My comment was based only in the fact it built successfully that way on 
both x86 and ARM.  If there's no way to access the functionality without 
both selected then I suppose it does make sense to not allow that 
configuration.  Maybe it's time to remove one of these config symbols. 
I didn't see anything in the email history on this that says that would 
be a bad idea.  I'll try and come up with a patch.

-dl

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