linux-kernel - Re: [PATCH V2 0/6] perf: New conditional branch filter

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, 23 Sep 2013 14:45:48 +0530
From:	Anshuman Khandual <khandual@...ux.vnet.ibm.com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Michael Ellerman <michael@...erman.id.au>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux PPC dev <linuxppc-dev@...abs.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Michael Neuling <michael.neuling@....ibm.com>,
	svaidy@...ux.vnet.ibm.com,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>
Subject: Re: [PATCH V2 0/6] perf: New conditional branch filter

On 09/21/2013 12:25 PM, Stephane Eranian wrote:
> On Tue, Sep 10, 2013 at 4:06 AM, Michael Ellerman
> <michael@...erman.id.au> wrote:
>> >
>> > On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
>>> > >       This patchset is the re-spin of the original branch stack sampling
>>> > > patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
>>> > > also enables SW based branch filtering support for PPC64 platforms which have
>>> > > branch stack sampling support. With this new enablement, the branch filter support
>>> > > for PPC64 platforms have been extended to include all these combinations discussed
>>> > > below with a sample test application program.
>> >
>> > ...
>> >
>>> > > Mixed filters
>>> > > -------------
>>> > > (6) perf record -e branch-misses:u -j any_call,any_ret ./cprog
>>> > > Error:
>>> > > The perf.data file has no samples!
>>> > >
>>> > > NOTE: As expected. The HW filters all the branches which are calls and SW tries to find return
>>> > > branches in that given set. Both the filters are mutually exclussive, so obviously no samples
>>> > > found in the end profile.
>> >
>> > The semantics of multiple filters is not clear to me. It could be an OR,
>> > or an AND. You have implemented AND, does that match existing behaviour
>> > on x86 for example?
>> >
> The semantic on the API is OR. AND does not make sense: CALL & RETURN?
> On x86, the HW filter is an OR (default: ALL, set bit to disable a
> type). I suspect
> it is similar on PPC.

Hey Stephane,

In POWER8 BHRB, we have got three HW PMU filters out of which we are trying
to use two of them PERF_SAMPLE_BRANCH_ANY_CALL and PERF_SAMPLE_BRANCH_COND
respectively.

(1) These filters are exclusive of each other and cannot be OR-ed with each other

(2) The SW filters are applied on the branch record set captured with BHRB
    which have the HW filters applied. So the working set is already reduced
    with the HW PMU filters. SW filter goes through the working set and figures
    out which one of them satisfy the SW filter criteria and gets picked up. The
    SW filter cannot find out branches records which matches the criteria outside
    of BHRB captured set. So we cannot OR the filters.

    This makes the combination of HW and SW filter inherently an "AND" not OR.

(3) But once we have captured the BHRB filtered data with HW PMU filter, multiple SW
    filters (if requested) can be applied either in OR or AND manner.

	It should be either like
		(1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2)
	or like
		(2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2)

    NOTE: I admit that the current validate_instruction() function does not do
    either of them correctly. Will fix it in the next iteration.

(4) These combination of filters are not supported right now because

	(a) We are unable to process two HW PMU filters simultaneously
	(b) We have not worked on replacement SW filter for either of the HW filters

	(1) (HW_FILTER_1), (HW_FILTER_2)
	(2) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1)
	(3) (HW_FILTER_1), (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)

   How ever these combination of filters can be supported right now.

	(1) (HW_FILTER_1)
	(2) (HW_FILTER_2)

	(3) (SW_FILTER_1)
	(4) (SW_FILTER_2)
	(5) (SW_FILTER_1), (SW_FILTER_2)

	(6)  (HW_FILTER_1), (SW_FILTER_1)
	(7)  (HW_FILTER_1), (SW_FILTER_2)
	(8)  (HW_FILTER_1), (SW_FILTER_1), (SW_FILTER_2)
	(9)  (HW_FILTER_2), (SW_FILTER_1)
	(10) (HW_FILTER_2), (SW_FILTER_2)
	(11) (HW_FILTER_2), (SW_FILTER_1), (SW_FILTER_2)


Given the situation as explained here, which semantic would be better for single
HW and multiple SW filters. Accordingly validate_instruction() function will have
to be re-implemented. But I believe OR-ing the SW filters will be preferable.

	(1) (HW_FILTER_1) && (SW_FILTER_1) && (SW_FILTER_2)
	or
	(2) (HW_FILTER_1) && (SW_FILTER_1 || SW_FILTER_2)

Please let me know your inputs and suggestions on this. Thank you.

Regards
Anshuman

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