linux-kernel - Re: [PATCH v4 05/14] coresight: get/put module in coresight_build/release

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: <20180607164747.7e4bb30f69a1fb4c160b6ef1@arm.com>
Date:   Thu, 7 Jun 2018 16:47:47 -0500
From:   Kim Phillips <kim.phillips@....com>
To:     Suzuki K Poulose <suzuki.poulose@....com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Howells <dhowells@...hat.com>,
        Eric Auger <eric.auger@...hat.com>,
        Eric Biederman <ebiederm@...ssion.com>,
        Gargi Sharma <gs051095@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Kirill Tkhai <ktkhai@...tuozzo.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Oleg Nesterov <oleg@...hat.com>,
        Pavel Tatashin <pasha.tatashin@...cle.com>,
        Rik van Riel <riel@...hat.com>,
        Robin Murphy <robin.murphy@....com>,
        Russell King <linux@...linux.org.uk>,
        Thierry Reding <treding@...dia.com>,
        Todd Kjos <tkjos@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 05/14] coresight: get/put module in
 coresight_build/release_path

On Thu, 7 Jun 2018 22:10:07 +0100
Suzuki K Poulose <suzuki.poulose@....com> wrote:

> On 06/07/2018 06:13 PM, Kim Phillips wrote:
> > I'm going to assume the series is still valid after this discussion,
> > since technically just this patch can get dropped, and the user is able
> > to shoot themselves in the foot.
> 
> That doesn't mean the kernel can panic() if the user decided to unload 
> the module while the trace session is in progress. It only means that
> the trace session could be stopped in between in the worst case. But
> nothing more harmful to the system.

FWIW, I didn't see the kernel panic in my basic tests; just some bad
accesses: the new remove functions take care of cleaning up most items,
and most drivers still depend on the links and sinks (funnel,
replicator) drivers, so they can't be upset too bad.

> >  This series is for development  purposes, after all.
> 
> Do you mean that this series is for internal development purposes and 
> not upstream ? Making the drivers modular are always helpful, especially 

no, I'm posting them for upstream review because I'd like them upstream.

> for something related to tracing, that allows the module to be unloaded 
> after use. So, it would be good to have this series in, but in a manner 
> which is usable and doesn't cause harm to the overall system usage.
> 
> I think the summary of the discussion is that we need more robust code
> to handle the situation, which also allows unloading the modules without
> any trouble.

Trouble's relative.  My point was since the series is going to be used
mainly by developers testing their code, they already prepare for, and
expect badness to occur anyway.  Greg's point isn't lost here, and in
my interpretation, his review of this patch was that it was in the
wrong direction of safety: it made things unnecessarily too safe, up
front, and that items relative to the perf core should strive to adhere
to the higher standards set in place by the networking subsystem.  So,
this patch doesn't get his ack.

I compiled a new v5 series that omits this patch, and overwrote the v4
series here:

git://linux-arm.org/linux-kp.git, coresight-modules branch

but I'll hold of submitting a v5 for now.

I don't know how the perf core handles AUXTRACE drivers hanging up on
it.  I see intel-pt record support can't be built as a module.  I'm
guessing more testing for actual panics when using perf or sysfs is
what's being sought here?

Kim