linux-kernel - Re: [Phishing Risk] [External] Re: [PATCH] blk-iocost: fix very large vtime when iocg activate

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: <YoL0RHmU4tbS2f/F@slm.duckdns.org>
Date:   Mon, 16 May 2022 15:03:00 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Chengming Zhou <zhouchengming@...edance.com>
Cc:     axboe@...nel.dk, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, duanxiongchun@...edance.com,
        songmuchun@...edance.com
Subject: Re: [Phishing Risk] [External] Re: [PATCH] blk-iocost: fix very
 large vtime when iocg activate

On Tue, May 17, 2022 at 08:57:55AM +0800, Chengming Zhou wrote:
> #define time_after64(a,b)	\
> 	(typecheck(__u64, a) &&	\
> 	 typecheck(__u64, b) && \
> 	 ((__s64)((b) - (a)) < 0))
> #define time_before64(a,b)	time_after64(b,a)
> 
> I still don't get why my changes are wrong. :-)

It's a wrapping timestamp where a lower value doesn't necessarily mean
earlier. The before/after relationship is defined only in relation to each
other. Imagine a cirle representing the whole value range and picking two
spots in the circle, if one is in the clockwise half from the other, the
former is said to be earlier than the latter and vice-versa. vtime runs way
faster than nanosecs and wraps regularly, so we can't use absolute values to
compare before/after.

Thanks.

-- 
tejun