linux-kernel - Re: [Q] Frequency & duty cycle measurement?

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: <0c74dd96-2978-46ab-a399-9c94c9529b2e@prolan.hu>
Date: Wed, 5 Feb 2025 10:30:26 +0100
From: Csókás Bence <csokas.bence@...lan.hu>
To: William Breathitt Gray <wbg@...nel.org>
CC: <linux-iio@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<timestamp@...ts.linux.dev>, Jonathan Cameron <jic23@...nel.org>, "Lars-Peter
 Clausen" <lars@...afoo.de>, Daniel Lezcano <daniel.lezcano@...aro.org>,
	"Thomas Gleixner" <tglx@...utronix.de>, Dipen Patel <dipenp@...dia.com>,
	<dlechner@...libre.com>
Subject: Re: [Q] Frequency & duty cycle measurement?

Hi,

On 2025. 02. 05. 0:37, William Breathitt Gray wrote:
> Are you still having trouble with this? Is "X" the
> capture{0,1}_component_id value?

X is 0/1 from `/sys/bus/counter/devices/counter0/count0/capture{0,1}`, 
which is also equal to the respective `capture{0,1}_component_id`, since 
I don't have any other counters. I checked that beforehand.

> I apologize, the Generic Counter character device interface is
> underdocumented so it can be a bit confusing at first; I'll submit a
> patch improving the documentation later this cycle when I get a chance.
> For now, let's walk through how to create an appropriate Counter watch
> for the capture extension components you have.

After much tinkering and reading of the `counter-chrdev.c` code, I now 
see *something*, although it's much slower to make a measurement than 
the sysfs `reopen()` hack.

> The first step is to decide which event we'll monitor and on which
> channel: we want to monitor Capture events so that's
> COUNTER_EVENT_CAPTURE, and we want event channel 0 (n.b. 0 because
> that's the channel parameter value passed to counter_push_event() in the
> driver).
> 
> The next step is to choose the components you wish to watch: Count 0's
> capture0 and capture1 extensions. So type is COUNTER_COMPONENT_EXTENSION
> because we want to watch extensions, scope is COUNTER_SCOPE_COUNT
> because we want Count extensions, and parent is 0 because we want
> Count 0's Count extensions.
> 
> Finally, we need to set the component id for each extension. You get a
> particular component's id by reading the respective *_component_id sysfs
> attribute: so for capture{0,1} you would read capture{0,1}_component_id
> respectively. These component id values potentially can change with
> future driver updates, so for robustness your userspace application
> should read the respective *_component_id sysfs attribute itself rather
> than hardcoding the component id in the Counter watch.
> 
> However, for the sake of simplicity in this example, I'll assume the
> component ids are 42 and 43 respectively for capture0 and capture1. That
> gives us the following two watches:
> 
>          {
>                  .component.type = COUNTER_COMPONENT_EXTENSION,
>                  .component.scope = COUNTER_SCOPE_COUNT,
>                  .component.parent = 0,
>                  .component.id = 42,
>                  .event = COUNTER_EVENT_CAPTURE,
>                  .channel = 0,
>          },
>          {
>                  .component.type = COUNTER_COMPONENT_EXTENSION,
>                  .component.scope = COUNTER_SCOPE_COUNT,
>                  .component.parent = 0,
>                  .component.id = 43,
>                  .event = COUNTER_EVENT_CAPTURE,
>                  .channel = 0,
>          },
> 
> Does this resolve your chardev read issue? If you're still having
> troubling, just let me know and we can troubleshoot further to figure
> out what's going on.

I had no success using `channel = 0`, only data from `capture0` comes 
back. If I set both `channel` AND `component.id` to X, then I start to 
see similar values than what I get from reading sysfs. (For now I 
hard-coded all values; I agree that the correct way would be to read 
component IDs from sysfs, but this is still a PoC...)

Did I do something wrong in implementing the driver maybe? (See the 
submitted patches.) And any idea as to why I might be seeing the slowdown?

Bence