linux-kernel - Re: [PATCH 1/2] blk-throttle: remove THROTL_TG_HAS_IOPS

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]

Date:   Fri, 23 Sep 2022 17:31:57 -1000
From:   Tejun Heo <tj@...nel.org>
To:     Yu Kuai <yukuai1@...weicloud.com>
Cc:     axboe@...nel.dk, cgroups@...r.kernel.org,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        yukuai3@...wei.com, yi.zhang@...wei.com
Subject: Re: [PATCH 1/2] blk-throttle: remove THROTL_TG_HAS_IOPS_LIMIT

On Wed, Sep 21, 2022 at 05:53:08PM +0800, Yu Kuai wrote:
> From: Yu Kuai <yukuai3@...wei.com>
> 
> Currently, "tg->has_rules" and "tg->flags & THROTL_TG_HAS_IOPS_LIMIT"
> both try to bypass bios that don't need to be throttled, however, they are
> a little redundant and both not perfect:
> 
> 1) "tg->has_rules" only distinguish read and write, but not iops and bps
>    limit.
> 2) "tg->flags & THROTL_TG_HAS_IOPS_LIMIT" only check if iops limit
>    exist, read and write is not distinguished, and bps limit is not
>    checked.
> 
> tg->has_rules will extended to distinguish bps and iops in the following
> patch. There is no need to keep the flag.
> 
> Signed-off-by: Yu Kuai <yukuai3@...wei.com>

Acked-by: Tejun Heo <tj@...nel.org>

> @@ -183,11 +182,6 @@ static inline bool blk_throtl_bio(struct bio *bio)
>  {
>  	struct throtl_grp *tg = blkg_to_tg(bio->bi_blkg);
>  
> -	/* no need to throttle bps any more if the bio has been throttled */
> -	if (bio_flagged(bio, BIO_BPS_THROTTLED) &&
> -	    !(tg->flags & THROTL_TG_HAS_IOPS_LIMIT))
> -		return false;
> -

This temporary removal would break the double accounting until the next
patch, right? That might be worth noting but this looks like an okay way to
go about it.

Thanks.

-- 
tejun