On 25-08-2026 23:24, sashiko-bot@kernel.org wrote:
>> +		for (i = 0; i < num_headers; i++) {
>> +			u32 num_logs = min_t(u32, hdrs[i].counter, XE_RAS_NUM_COUNTERS);
> [Severity: Medium]
> Does capping `num_logs` to `XE_RAS_NUM_COUNTERS` (16) cause desynchronization
> when parsing the raw log stream? If the hardware actually embedded more than
> 16 logs for a specific header, limiting `num_logs` to 16 means `log_offset`
> will only advance by 16. Won't the remaining logs then be incorrectly parsed
> as belonging to the next aggregate header in the stream?

hdrs[i].counter may exceed XE_RAS_NUM_COUNTERS, but the info queue 
contains at most XE_RAS_NUM_COUNTERS log entries.

The cap reflects the amount of log data actually present in the buffer, 
so log_offset remains synchronized with the parsed stream.

Thanks,
Badal