linux-kernel - [PATCH 1/2] include: trace: Add SCMI header with trace events

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20191216161650.21844-1-lukasz.luba@arm.com>
Date:   Mon, 16 Dec 2019 17:15:54 -0500
From:   Jim Quinlan <james.quinlan@...adcom.com>
To:     lukasz.luba@....com
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        mingo@...hat.com, rostedt@...dmis.org, sudeep.holla@....com
Subject: [PATCH 1/2] include: trace: Add SCMI header with trace events

From: Lukasz Luba <lukasz.luba@....com>

+
+TRACE_EVENT(scmi_xfer_begin,
+	TP_PROTO(u8 id, u8 protocol_id, u16 seq, bool poll),
+	TP_ARGS(id, protocol_id, seq, poll),
+
+	TP_STRUCT__entry(
+		__field(u8, id)
+		__field(u8, protocol_id)
+		__field(u16, seq)
+		__field(bool, poll)
+	),
+
+	TP_fast_assign(
+		__entry->id = id;
+		__entry->protocol_id = protocol_id;
+		__entry->seq = seq;
+		__entry->poll = poll;
+	),
+
+	TP_printk("id=%u protocol_id=%u seq=%u poll=%u", __entry->id,
+		__entry->protocol_id, __entry->seq, __entry->poll)
+);
+
+TRACE_EVENT(scmi_xfer_end,
+	TP_PROTO(u8 id, u8 protocol_id, u16 seq, u32 status),
+	TP_ARGS(id, protocol_id, seq, status),
+
+	TP_STRUCT__entry(
+		__field(u8, id)
+		__field(u8, protocol_id)
+		__field(u16, seq)
+		__field(u32, status)
+	),
+
+	TP_fast_assign(
+		__entry->id = id;
+		__entry->protocol_id = protocol_id;
+		__entry->seq = seq;
+		__entry->status = status;
+	),
+
+	TP_printk("id=%u protocol_id=%u seq=%u status=%u", __entry->id,
+		__entry->protocol_id, __entry->seq, __entry->status)
+);

Hello,

When there are multiple messages in the mbox queue, I've found it
a chore matching up the 'begin' event with the 'end' event for each
SCMI msg.  The id (command) may not be unique, the proto_id may not be
unique, and the seq may not be unique.  The combination of the three
may not be unique.  Would it make sense to assign a monotonically
increasing ID to each msg so that one can easily match the two events
for each msg?  This id could be the result of an atomic increment and
could be stored in the xfer structure.  Of course, it would be one of
the values printed out in the events.

Also, would you consider a third event, right after the
scmi_fetch_response() invocation in scmi_rx_callback()?  I've found
this to be insightful in situations where we were debugging a timeout.

I'm fine if you elect not to do the above; I just wanted to post
this for your consideration.

Thanks,
Jim Quinlan
Broadcom