linux-kernel - Re: [PATCH v3 0/7] perf: Add ioctl for PMU driver configuration

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: <20180815102820.3520d0c3875d2fd82300cdef@arm.com>
Date:   Wed, 15 Aug 2018 10:28:20 -0500
From:   Kim Phillips <kim.phillips@....com>
To:     Will Deacon <will.deacon@....com>
Cc:     Mathieu Poirier <mathieu.poirier@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        <schwidefsky@...ibm.com>, <heiko.carstens@...ibm.com>,
        Mark Rutland <mark.rutland@....com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>, <ast@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "H. Peter Anvin" <hpa@...or.com>, <suzuki.poulosi@....com>,
        <linux-s390@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 0/7] perf: Add ioctl for PMU driver configuration

On Wed, 15 Aug 2018 10:39:13 +0100
Will Deacon <will.deacon@....com> wrote:

> On Tue, Aug 14, 2018 at 01:42:27PM -0600, Mathieu Poirier wrote:
> > On Tue, 14 Aug 2018 at 11:09, Kim Phillips <kim.phillips@....com> wrote:
> > > The other thing that's going on here is that I'm becoming numb to the
> > > loathsome "failed to mmap with 12 (Cannot allocate memory)" being
> > > returned no matter what the error is/was. E.g., an error that would
> > > indicate a sense of non-implementation would be much better
> > > appreciated than presumably what the above is doing, i.e., returning
> > > -ENOMEM.  That, backed up with specific details in the form of human
> > > readable text in dmesg would be *most* welcome.
> > 
> > As part of the refactoring of the code to support CPU-wide scenarios I
> > intend to emit better diagnostic messages from the driver.  Modifying
> > rb_alloc_aux() to propagate the error message generated by the
> > architecture specific PMUs doesn't look hard either and I _may_ get to
> > it as part of this work.
> 
> For the record, I will continue to oppose PMU drivers that dump diagnostics
> about user-controlled input into dmesg, but the coresight drivers are yours
> so it's up to you and I won't get in the way!

That sounds technically self-contradicting to me.  Why shouldn't
coresight share the same policies as those used for PMU drivers?  Or
why not allow the individual vendor PMU driver authors control the
level of user-friendliness of their own drivers?

That being said, Matheiu, would you accept patches that make coresight
more verbose in dmesg?

Kim