linux-kernel - Re: [PATCH 11/17] coresight etr: Handle driver mode specific ETR buffers

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: <c0a55562-77f5-35cb-6db9-4452ebef34f2@arm.com>
Date:   Fri, 3 Nov 2017 10:08:07 +0000
From:   Suzuki K Poulose <Suzuki.Poulose@....com>
To:     Mathieu Poirier <mathieu.poirier@...aro.org>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        robert.walker@....com, mike.leach@...aro.org,
        coresight@...ts.linaro.org
Subject: Re: [PATCH 11/17] coresight etr: Handle driver mode specific ETR
 buffers

On 02/11/17 20:26, Mathieu Poirier wrote:
> On Thu, Oct 19, 2017 at 06:15:47PM +0100, Suzuki K Poulose wrote:
>> Since the ETR could be driven either by SYSFS or by perf, it
>> becomes complicated how we deal with the buffers used for each
>> of these modes. The ETR driver cannot simply free the current
>> attached buffer without knowing the provider (i.e, sysfs vs perf).
>>
>> To solve this issue, we provide:
>> 1) the driver-mode specific etr buffer to be retained in the drvdata
>> 2) the etr_buf for a session should be passed on when enabling the
>>     hardware, which will be stored in drvdata->etr_buf. This will be
>>     replaced (not free'd) as soon as the hardware is disabled, after
>>     necessary sync operation.
> 
> If I get you right the problem you're trying to solve is what to do with a sysFS
> buffer that hasn't been read (and freed) when a perf session is requested.  In
> my opinion it should simply be freed.  Indeed the user probably doesn't care
> much about that sysFS buffer, if it did the data would have been harvested.

Not only that. If we simply use the drvdata->etr_buf, we cannot track the mode
which uses it. If we keep the etr_buf around, how do the new mode user decide
how to free the existing one ? (e.g, the perf etr_buf could be associated with
other perf data structures). This change would allow us to leave the handling
of the etr_buf to its respective modes.

And whether to keep the sysfs etr_buf around is a separate decision from the
above.


Cheers
Suzuki