| 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
| ||
|
Date: Sat, 28 May 2022 16:17:19 +0800
From: Chengming Zhou <zhouchengming@...edance.com>
To: tj@...nel.org, axboe@...nel.dk
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] blk-iocost: fix false positive lagging
On 2022/5/26 21:35, Chengming Zhou wrote:
> I found many false positive lagging during iocost test.
>
> Since iocg->vtime will be advanced to (vnow - margins.target)
> in hweight_after_donation(), which called throw away excess,
> the iocg->done_vtime will also be advanced that much.
>
> period_at_vtime <--period_vtime--> vnow
> | |
> --------------------------------------------------->
> |<--->|
> margins.target
> |->
> vtime, done_vtime
>
> If that iocg has some inflight io when vnow, but its done_vtime
> is before period_at_vtime, ioc_timer_fn() will think it has
> lagging io, even these io maybe issued just before now.
>
> This patch change the condition to check if vdone is before
> (period_at_vtime - margins.target) instead of period_at_vtime.
>
> But there is another problem that this patch doesn't fix.
> Since vtime will be advanced, we can't check if vtime is
> after (vnow - MAX_LAGGING_PERIODS * period_vtime) to tell
> whether this iocg pin lagging for too long.
>
> Maybe we can add lagging_periods in iocg to record how many
> periods this iocg pin lagging, but I don't know when to clean it.
Hello tejun, I add lagging_periods in iocg based on the original patch,
to record how many periods this iocg pin lagging. So we can use it to
avoid letting cmds which take a very long time pin lagging for too long.
Thanks.
diff --git a/block/blk-iocost.c b/block/blk-iocost.c
index 33a11ba971ea..998bb38ffb37 100644
--- a/block/blk-iocost.c
+++ b/block/blk-iocost.c
@@ -541,6 +541,8 @@ struct ioc_gq {
u64 indebt_since;
u64 indelay_since;
+ int lagging_periods;
+
/* this iocg's depth in the hierarchy and ancestors including self */
int level;
struct ioc_gq *ancestors[];
@@ -2257,10 +2259,13 @@ static void ioc_timer_fn(struct timer_list *timer)
if ((ppm_rthr != MILLION || ppm_wthr != MILLION) &&
!atomic_read(&iocg_to_blkg(iocg)->use_delay) &&
time_after64(vtime, vdone) &&
- time_after64(vtime, now.vnow -
- MAX_LAGGING_PERIODS * period_vtime) &&
- time_before64(vdone, now.vnow - period_vtime))
- nr_lagging++;
+ time_before64(vdone, ioc->period_at_vtime - ioc->margins.target)) {
+ if (iocg->lagging_periods < MAX_LAGGING_PERIODS) {
+ nr_lagging++;
+ iocg->lagging_periods++;
+ }
+ } else if (iocg->lagging_periods)
+ iocg->lagging_periods = 0;
/*
* Determine absolute usage factoring in in-flight IOs to avoid
>
> Signed-off-by: Chengming Zhou <zhouchengming@...edance.com>
> ---
> block/blk-iocost.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block/blk-iocost.c b/block/blk-iocost.c
> index 33a11ba971ea..42e301b7527b 100644
> --- a/block/blk-iocost.c
> +++ b/block/blk-iocost.c
> @@ -2259,7 +2259,7 @@ static void ioc_timer_fn(struct timer_list *timer)
> time_after64(vtime, vdone) &&
> time_after64(vtime, now.vnow -
> MAX_LAGGING_PERIODS * period_vtime) &&
> - time_before64(vdone, now.vnow - period_vtime))
> + time_before64(vdone, ioc->period_at_vtime - ioc->margins.target))
> nr_lagging++;
>
> /*
Powered by blists - more mailing lists