linux-kernel - Re: [PATCH] dcookies: Make dcookies depend on CONFIG

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:   Wed, 28 Oct 2020 19:01:37 +0100
From:   Arnd Bergmann <arnd@...nel.org>
To:     William Cohen <wcohen@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Christoph Hellwig <hch@...radead.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Anmar Oueja <anmar.oueja@...aro.org>,
        Arnd Bergmann <arnd@...db.de>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] dcookies: Make dcookies depend on CONFIG_OPROFILE

On Wed, Oct 28, 2020 at 5:34 PM William Cohen <wcohen@...hat.com> wrote:
>
> On 10/27/20 12:54 PM, Linus Torvalds wrote:
> > On Tue, Oct 27, 2020 at 1:52 AM Christoph Hellwig <hch@...radead.org> wrote:
> >>
> >> Is it time to deprecate and eventually remove oprofile while we're at
> >> it?
> >
> > I think it's well past time.
> >
> > I think the user-space "oprofile" program doesn't actually use the
> > legacy kernel code any more, and hasn't for a long time.
> >
> > But I might be wrong. Adding William Cohen to the cc, since he seems
> > to still maintain it to make sure it builds etc.
>
> Yes, current OProfile code uses the existing linux perf infrastructure and
> doesn't use the old oprofile kernel code.  I have thought about removing
> that old oprofile driver code from kernel, but have not submitted patches
> for it. I would be fine with eliminating that code from the kernel.

I notice that arch/ia64/ supports oprofile but not perf. I suppose this just
means that ia64 people no longer care enough about profiling to
add perf support, but it wouldn't stop us from dropping it, right?

There is also a stub implementation of oprofile for microblaze
and no perf code, not sure if it would make any difference for them.

Everything else that has oprofile kernel code also supports perf.

       Arnd