linux-kernel - Re: [PATCH BUGFIX] block, bfq: lower-bound the estimated peak rate to 1

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] [day] [month] [year] [list]

Message-ID: <5035d1cf-f9ff-013f-87d8-19891d5e8df0@kernel.dk>
Date:   Mon, 26 Mar 2018 10:18:56 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        ulf.hansson@...aro.org, broonie@...nel.org,
        linus.walleij@...aro.org, bfq-iosched@...glegroups.com,
        oleksandr@...alenko.name, khlebnikov@...dex-team.ru
Subject: Re: [PATCH BUGFIX] block, bfq: lower-bound the estimated peak rate to
 1

On 3/26/18 8:06 AM, Paolo Valente wrote:
> If a storage device handled by BFQ happens to be slower than 7.5 KB/s
> for a certain amount of time (in the order of a second), then the
> estimated peak rate of the device, maintained in BFQ, becomes equal to
> 0. The reason is the limited precision with which the rate is
> represented (details on the range of representable values in the
> comments introduced by this commit). This leads to a division-by-zero
> error where the estimated peak rate is used as divisor. Such a type of
> failure has been reported in [1].
> 
> This commit addresses this issue by:
> 1. Lower-bounding the estimated peak rate to 1
> 2. Adding and improving comments on the range of rates representable

Applied for 4.17, thanks.

-- 
Jens Axboe