linux-kernel - Re: [PATCH] ftrace: Avoid potential division by zero in function_stat

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: <20250206085704.1561454-1-kniv@yandex-team.ru>
Date: Thu,  6 Feb 2025 11:57:04 +0300
From: Nikolay Kuratov <kniv@...dex-team.ru>
To: linux-kernel@...r.kernel.org
Cc: linux-trace-kernel@...r.kernel.org,
	Wen Yang <wenyang@...ux.alibaba.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mark Rutland <mark.rutland@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	kniv@...dex-team.ru
Subject: Re: [PATCH] ftrace: Avoid potential division by zero in function_stat_show()

I would suggest just fixing zerodiv for now because IMO the patch
fixing overflows properly on stddev path may or may not use macroconstants
at all. Also ns^2 overflow will always happen first. I don't know in advance
how this patch will look at the end and even not sure it's viable.
Steps to consider:
0) Infer some assumptions from the rest of tracing code like `nanoseconds
are stored in unsigned long, so on 32-bit machine function should not
execute more than ~ 2 s anyway`
1) unsigned long -> u64 conversion
2) ns^2 -> us^2 if possible, inevitable precision loss (how much?)
3) Compute stddev using some numerical trick. Now comment about Welford's
method is a bit misleading because its a plain variance formula. But maybe
it's a hint that we should convert to that method and problems are gone? ;)

I'll send the patch fixing zero division and simplifying code a bit as a
follow-up. It's up to you to choose what to apply. I'm Ok with any patch
fixing zerodiv and will look into overflow problem.

Again, thank you very much for the review and your time.