linux-kernel - Re: [PATCH 2/3] perf lock contention: Add -o/--lock-owner option

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:   Tue, 7 Feb 2023 14:20:26 -0800
From:   Namhyung Kim <namhyung@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ian Rogers <irogers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-perf-users@...r.kernel.org, Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Davidlohr Bueso <dave@...olabs.net>,
        Song Liu <song@...nel.org>, Hao Luo <haoluo@...gle.com>,
        bpf@...r.kernel.org
Subject: Re: [PATCH 2/3] perf lock contention: Add -o/--lock-owner option

Hi Arnaldo,

On Tue, Feb 7, 2023 at 7:11 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
>
> Em Mon, Feb 06, 2023 at 04:24:02PM -0800, Namhyung Kim escreveu:
> > When there're many lock contentions in the system, people sometimes
> > want to know who caused the contention, IOW who's the owner of the
> > locks.
> >
> > The -o/--lock-owner option tries to follow the lock owners for the
> > contended mutexes and rwsems from BPF, and then attributes the
> > contention time to the owner instead of the waiter.  It's a best
> > effort approach to get the owner info at the time of the contention
> > and doesn't guarantee to have the precise tracking of owners if it's
> > changing over time.
>
> Having this in the documentation as limitations of the approach helps,
> but I'm not seeing this on this specific patch, where I think it should
> be.
>
> Furthermore probably its a good idea to have this as a warning on the
> actual output of the tool, no?
>
> Generally having cool commit log messages, as this one has, is great,
> but people have difficulty looking at docs, imagine expecting them to
> read commit log messages... :-)

I see.  I'll add this limitation to the doc and tool output.

Thanks,
Namhyung