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: <6a23642f-b3bf-4501-8464-f66bb9f1f57f@igalia.com>
Date: Thu, 27 Feb 2025 17:05:54 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Andrea Righi <arighi@...dia.com>
Cc: tj@...nel.org, void@...ifault.com, kernel-dev@...lia.com,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: Add trace point to track sched_ext core events

Hi Andrea,

Thank you for the review!

On 25. 2. 27. 16:38, Andrea Righi wrote:
> Hi Changwoo,
> 
> On Wed, Feb 26, 2025 at 11:33:27PM +0900, Changwoo Min wrote:
>> Add tracing support, which may be useful for debugging sched_ext schedulers
>> that trigger a certain event.
>>
>> Signed-off-by: Changwoo Min <changwoo@...lia.com>
>> ---
>>   include/trace/events/sched_ext.h | 21 +++++++++++++++++++++
>>   kernel/sched/ext.c               |  4 ++++
>>   2 files changed, 25 insertions(+)
>>
>> diff --git a/include/trace/events/sched_ext.h b/include/trace/events/sched_ext.h
>> index fe19da7315a9..88527b9316de 100644
>> --- a/include/trace/events/sched_ext.h
>> +++ b/include/trace/events/sched_ext.h
>> @@ -26,6 +26,27 @@ TRACE_EVENT(sched_ext_dump,
>>   	)
>>   );
>>   
>> +TRACE_EVENT(sched_ext_add_event,
>> +	    TP_PROTO(const char *name, int offset, __u64 added),
>> +	    TP_ARGS(name, offset, added),
>> +
>> +	TP_STRUCT__entry(
>> +		__string(name, name)
>> +		__field(	int,		offset		)
>> +		__field(	__u64,		added		)
>> +	),
>> +
>> +	TP_fast_assign(
>> +		__assign_str(name);
>> +		__entry->offset		= offset;
>> +		__entry->added		= added;
>> +	),
>> +
>> +	TP_printk("name %s offset %d added %llu",
>> +		  __get_str(name), __entry->offset, __entry->added
>> +	)
>> +);
> 
> Isn't the name enough to determine which event has been triggered? What are
> the benefits of reporting also the offset within struct scx_event_stats?
> 

@name and @offset are duplicated information. However, I thought
having two is more convenient from the users' point of view
because they have different pros and cons.

@offset is quick to compare and can be used easily in the BPF
code, but the offset of an event can change across kernel
versions when new events are added. @offset would be good to
write a quick trace hook for debugging.

On the other hand, @name won't change across kernel versions,
which is good. However, it requires more code to acutally read
the string in the BPF code (__data_loc for string is a 32-bit
integer encoding string length and location).

Does it make sense to you?

Regards,
Changwoo Min

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ