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] [day] [month] [year] [list]
Message-ID: <9008f2e6-d2de-4765-b824-cdd6a1175794@linaro.org>
Date: Wed, 12 Nov 2025 09:21:28 +0000
From: James Clark <james.clark@...aro.org>
To: Ian Rogers <irogers@...gle.com>, Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Arnaldo Carvalho de Melo <acme@...nel.org>,
 Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
 Jiri Olsa <jolsa@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
 John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
 Mike Leach <mike.leach@...aro.org>, Leo Yan <leo.yan@...ux.dev>,
 Suzuki K Poulose <suzuki.poulose@....com>,
 Yicong Yang <yangyicong@...ilicon.com>,
 Jonathan Cameron <jonathan.cameron@...wei.com>,
 Thomas Gleixner <tglx@...utronix.de>, Darren Hart <dvhart@...radead.org>,
 Davidlohr Bueso <dave@...olabs.net>, André Almeida
 <andrealmeid@...lia.com>, Tomas Glozar <tglozar@...hat.com>,
 Quentin Monnet <qmo@...nel.org>, Yuzhuo Jing <yuzhuo@...gle.com>,
 Blake Jones <blakejones@...gle.com>, Charlie Jenkins <charlie@...osinc.com>,
 Yeoreum Yun <yeoreum.yun@....com>, Athira Rajeev <atrajeev@...ux.ibm.com>,
 Ravi Bangoria <ravi.bangoria@....com>, Collin Funk <collin.funk1@...il.com>,
 Dapeng Mi <dapeng1.mi@...ux.intel.com>,
 Thomas Richter <tmricht@...ux.ibm.com>, Dmitry Vyukov <dvyukov@...gle.com>,
 Andi Kleen <ak@...ux.intel.com>, Howard Chu <howardchu95@...il.com>,
 Zecheng Li <zecheng@...gle.com>, tanze <tanze@...inos.cn>,
 Gabriele Monaco <gmonaco@...hat.com>, GuoHan Zhao <zhaoguohan@...inos.cn>,
 Markus Elfring <Markus.Elfring@....de>,
 Colin Ian King <colin.i.king@...il.com>,
 Kan Liang <kan.liang@...ux.intel.com>,
 "Dr. David Alan Gilbert" <linux@...blig.org>,
 Jean-Philippe Romain <jean-philippe.romain@...s.st.com>,
 Yang Li <yang.lee@...ux.alibaba.com>, linux-kernel@...r.kernel.org,
 linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v1 0/5] Remove NO_AUXTRACE build option



On 11/11/2025 6:01 pm, Ian Rogers wrote:
> On Mon, Nov 10, 2025 at 10:21 PM Namhyung Kim <namhyung@...nel.org> wrote:
>>
>> Hi Ian,
>>
>> On Sun, Nov 09, 2025 at 05:31:47PM -0800, Ian Rogers wrote:
>>> Switch the __get_cpuid feature for intel-pt to use the provided cpuid
>>> function in perf, this removes the need for NO_AUXTRACE when the
>>> feature detection fails. Remove the now unnecessary feature
>>> detection. Remove NO_AUXTRACE as it just builds a more broken version
>>
>> Can you please elaborate what the broken part is?
> 
> Sure. I'll summarize what alters in patch 4. NO_AUXTRACE is
> controlling 3 main things:
>   * set up of aux options for PMUs (code in the arch directory)
>     * ARM: coresight and SPE
>     * Intel: BTS and PT
>     * PowerPC: VPA DTL
>     * S390: cpumsf
>   * support for decoding aux events (common code that can be
> cross-compiled assuming other library dependencies are available)
>     * ARM: coresight
>     * HiSi: PTT decoder
>     * Intel: BTS and PT
>     * PowerPC: VPA DTL
>     * S390: cpumsf
>   * Tool support for aux buffers (common shared builtin code):
>    * perf record: aux options for events, snapshot, aux-sample
>    * perf inject: aux events will fail the entire perf inject command
> 
> So somebody with a NO_AUXTRACE build would generally experience a very
> sad perf command. Having the option made sense when there were feature
> tests that could fail, but possibly that should have just controlled
> not compiling intel-pt. Having the option is extra burden on
> developers/maintainers, as shown in my comment:
> 
>> This was prompted by needing to make a v2 patch set of:
>> https://lore.kernel.org/lkml/20251107170712.2302714-1-irogers@google.com/
>> due to a broken NO_AUXTRACE configuration.
> 
> Somebody may have been using NO_AUXTRACE as a proxy for not having
> some library, but I don't see that in the code. If this is the case we
> should add the appropriate feature test, ..
> Not having NO_AUXTRACE may have been a bug work around for someone, in
> which case we should work to fix the bug. Again, I don't know of this
> case and don't see it in the code.
> 
> Thanks,
> Ian
> 
>> Thanks,
>> Namhyung

Seems like a nice simplification even if nothing was badly broken.

Reviewed-by: James Clark <james.clark@...aro.org>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ