On Mon, Dec 26, 2022 at 04:58:58PM +0800, Yu Kuai wrote:
> From: Li Nan <linan122@xxxxxxxxxx>
>
> echo max of u64 to cost.model can cause divide by 0 error.
>
> # echo 8:0 rbps=18446744073709551615 > /sys/fs/cgroup/io.cost.model
>
> divide error: 0000 [#1] PREEMPT SMP
> RIP: 0010:calc_lcoefs+0x4c/0xc0
> Call Trace:
> <TASK>
> ioc_refresh_params+0x2b3/0x4f0
> ioc_cost_model_write+0x3cb/0x4c0
> ? _copy_from_iter+0x6d/0x6c0
> ? kernfs_fop_write_iter+0xfc/0x270
> cgroup_file_write+0xa0/0x200
> kernfs_fop_write_iter+0x17d/0x270
> vfs_write+0x414/0x620
> ksys_write+0x73/0x160
> __x64_sys_write+0x1e/0x30
> do_syscall_64+0x35/0x80
> entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> calc_lcoefs() uses the input value of cost.model in DIV_ROUND_UP_ULL,
> overflow would happen if bps plus IOC_PAGE_SIZE is greater than
> ULLONG_MAX, it can cause divide by 0 error.
>
> Fix the problem by setting basecost
>
> Signed-off-by: Li Nan <linan122@xxxxxxxxxx>
> Signed-off-by: Yu Kuai <yukuai3@xxxxxxxxxx>
> ---
> block/blk-iocost.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/block/blk-iocost.c b/block/blk-iocost.c
> index f8726e20da20..c6b39024117b 100644
> --- a/block/blk-iocost.c
> +++ b/block/blk-iocost.c
> @@ -866,9 +866,13 @@ static void calc_lcoefs(u64 bps, u64 seqiops, u64 randiops,
>
> *page = *seqio = *randio = 0;
>
> - if (bps)
> - *page = DIV64_U64_ROUND_UP(VTIME_PER_SEC,
> - DIV_ROUND_UP_ULL(bps, IOC_PAGE_SIZE));
> + if (bps) {
> + if (bps >= U64_MAX - IOC_PAGE_SIZE)
> + *page = 1;
> + else
> + *page = DIV64_U64_ROUND_UP(VTIME_PER_SEC,
> + DIV_ROUND_UP_ULL(bps, IOC_PAGE_SIZE));
> + }
This is a nitpick but wouldn't something like the following be easier to
understand?
if (bps) {
u64 bps_pages = DIV_ROUND_UP_ULL(bps, IOC_PAGE_SIZE);
if (bps_pages)
*pages = DIV64_U64_ROUND_UP(VTIME_PER_SEC, bps_pages);
else
*pages = 1;
}
Out of scope but this seems more like a bug in the DIV macros. The fact that
it returns 0 is an implementation artifact more than anything and a
surprising one at that as it ends up returning 0 for an input that a regular
division would handle just fine and the rounded up result fits well within
the result type.
Thanks.
--
tejun
