linux-kernel - RE: [PATCH 2/2] perf record: Replace 'overwrite' by 'flightrecorder' for better naming

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: <37D7C6CF3E00A74B8858931C1DB2F077537DC3B1@SHSMSX103.ccr.corp.intel.com>
Date:   Wed, 1 Nov 2017 16:13:43 +0000
From:   "Liang, Kan" <kan.liang@...el.com>
To:     "Wangnan (F)" <wangnan0@...wei.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "acme@...nel.org" <acme@...nel.org>,
        "jolsa@...hat.com" <jolsa@...hat.com>,
        "namhyung@...nel.org" <namhyung@...nel.org>
Subject: RE: [PATCH 2/2] perf record: Replace 'overwrite' by
 'flightrecorder' for better naming

 > On 2017/11/1 23:04, Liang, Kan wrote:
> >> On 2017/11/1 22:22, Liang, Kan wrote:
> >>>> On 2017/11/1 21:26, Liang, Kan wrote:
> >>>>>> The meaning of perf record's "overwrite" option and many
> "overwrite"
> >>>>>> in source code are not clear. In perf's code, the 'overwrite' has
> >>>>>> 2
> >> meanings:
> >>>>>>     1. Make ringbuffer readonly (perf_evlist__mmap_ex's argument).
> >>>>>>     2. Set evsel's "backward" attribute (in apply_config_terms).
> >>>>>>
> >>>>>> perf record doesn't use meaning 1 at all, but have a overwrite
> >>>>>> option, its real meaning is setting backward.
> >>>>>>
> >>>>> I don't understand here.
> >>>>> 'overwrite' has 2 meanings. perf record only support 1.
> >>>>> It should be a bug, and need to be fixed.
> >>>> Not a bug, but ambiguous.
> >>>>
> >>>> Perf record doesn't need overwrite main channel (we have two
> channels:
> >>>> evlist->mmap is main channel and evlist->backward_mmap is backward
> >>>> evlist->channel),
> >>>> but some testcases require it, and your new patchset may require it.
> >>>> 'perf record --overwrite' doesn't set main channel overwrite. What
> >>>> it does
> >> is
> >>>> moving all evsels to backward channel, and we can move some evsels
> >> back to
> >>>> the main channel by /no-overwrite/ setting. This behavior is hard
> >>>> to understand.
> >>>>
> >>> As my understanding, the 'main channel' should depends on what user
> sets.
> >>> If --overwrite is applied, then evlist->backward_mmap should be the
> >>> 'main channel'. evlist->overwrite should be set to true as well.
> >> Then it introduces a main channel switching mechanism, and we need
> >> checking evlist->overwrite and another factor to determine which one
> >> is the main channel. Make things more complex.
> > We should check the evlist->overwrite.
> > Now, all perf tools force evlist->overwrite = false. I think it doesn’t make
> sense.
> >
> > What is another factor?
> 
> If we support mixed channel as well as forward overwrite ring buffer,
> evlist->overwrite is not enough.

I think you have a detailed analysis regarding to the weakness of 'forward overwrite'.
commit ID 9ecda41acb97 ("perf/core: Add ::write_backward attribute to perf event").

There is no perf tools use 'forward overwrite' mode.

The only users are three perf test cases. We can change them to 'backward overwrite'

I think it's OK to discard the 'forward overwrite' mode

> 
> > I don't think it will be too complex.
> >
> > In perf_evlist__mmap_ex, we just need to add a check.
> > If (!overwrite)
> > 	evlist->mmap = perf_evlist__alloc_mmap(evlist); else
> > 	evlist->backward_mmap = perf_evlist__alloc_mmap(evlist);
> >
> > In perf_evlist__mmap_per_evsel, we already handle per-event overwrite.
> > It just need to add some similar codes to handler per-event nonoverwrite.
> 
> Then the logic becomes:
> 
>   if (check write_backward) {
>      maps = evlist->backward_mmap;
>      if (!maps) {
>        maps = perf_evlist__alloc_mmap(...);
>        if (!maps) {
>            /* error processing */
>        }
>        evlist->backward_mmap = maps;
>        if (evlist->bkw_mmap_state == BKW_MMAP_NOTREADY)
>          perf_evlist__toggle_bkw_mmap(evlist, BKW_MMAP_RUNNING);
>      }
>   } else {
>      maps = evlist->mmap;
>      if (!maps) {
>        maps = perf_evlist__alloc_mmap(...);
>        if (!maps) {
>            /* error processing */
>        }
>        evlist->mmap = maps;
>        ....
>      }
>   }
> 

Thanks.
It looks good to me.

Kan

> > For other codes, they should already check evlist->mmap and evlist-
> >backward_mmap.
> > So they probably don't need to change.
> >
> >
> > Thanks,
> > Kan
> >
> >
>