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
| ||
|
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 > > > > >
Powered by blists - more mailing lists