[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180727135528.GA3618@redhat.com>
Date: Fri, 27 Jul 2018 15:55:29 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
Cc: srikar@...ux.vnet.ibm.com, rostedt@...dmis.org,
mhiramat@...nel.org, peterz@...radead.org, mingo@...hat.com,
acme@...nel.org, alexander.shishkin@...ux.intel.com,
jolsa@...hat.com, namhyung@...nel.org,
linux-kernel@...r.kernel.org, ananth@...ux.vnet.ibm.com,
alexis.berlemont@...il.com, naveen.n.rao@...ux.vnet.ibm.com,
linux-arm-kernel@...ts.infradead.org, linux-mips@...ux-mips.org,
linux@...linux.org.uk, ralf@...ux-mips.org, paul.burton@...s.com
Subject: Re: [PATCH v6 5/6] Uprobes/sdt: Prevent multiple reference counter
for same uprobe
Hi Ravi,
On 07/27, Ravi Bangoria wrote:
>
> > I simply can't understand this "bool installed"....
>
>
> That boolean is needed because consumer_filter() returns false when this
> function gets called first time from uprobe_register().
Ah yes, I forgot about the (ugly) 2-stage TRACE_REG_PERF_REGISTER +
TRACE_REG_PERF_OPEN logic...
But then I think the whole idea of REF_CTR_OFF_RELOADED is even more broken.
Nevermind.
> I have a solution for this. Idea is, if reference counter is reloaded, save
> of all mms for which consumer_filter() denied to updated when being called
> from register_for_each_vma(). Use this list of mms as checklist next time
> onwards. I don't know if it's good to do that or not.
Sounds horrible ;) and I bet this is not enough.
> Please let me know if you have any better approach.
Just drop this patch.
If we can't make it per consumer, let it be global like it was in first version.
Oleg.
Powered by blists - more mailing lists