linux-kernel - Re: [PATCH BUGFIX/IMPROVEMENT 5/6] block, bfq: keep shared queues out of the waker mechanism

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: <20210203114806.GC7094@quack2.suse.cz>
Date:   Wed, 3 Feb 2021 12:48:06 +0100
From:   Jan Kara <jack@...e.cz>
To:     Paolo Valente <paolo.valente@...aro.org>
Cc:     Jens Axboe <axboe@...nel.dk>, linux-block@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH BUGFIX/IMPROVEMENT 5/6] block, bfq: keep shared queues
 out of the waker mechanism

On Tue 26-01-21 11:51:01, Paolo Valente wrote:
> Shared queues are likely to receive I/O at a high rate. This may
> deceptively let them be considered as wakers of other queues. But a
> false waker will unjustly steal bandwidth to its supposedly woken
> queue. So considering also shared queues in the waking mechanism may
> cause more control troubles than throughput benefits. This commit
> keeps shared queues out of the waker-detection mechanism.
> 
> Tested-by: Jan Kara <jack@...e.cz>
> Signed-off-by: Paolo Valente <paolo.valente@...aro.org>

Honestly this makes me somewhat nervous. It is just a band aid for a fact
that waker detection is unreliable? There's nothing which prevents
non-shared queue to submit high amounts of IO (e.g. when it uses AIO) as
well as there's nothing which says that shared queues have no wakers (e.g.
jbd2 thread can easily be a waker for a shared queue).

								Honza

> ---
>  block/bfq-iosched.c | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c
> index 0c7e203085f1..23d0dd7bd90f 100644
> --- a/block/bfq-iosched.c
> +++ b/block/bfq-iosched.c
> @@ -5825,7 +5825,17 @@ static void bfq_completed_request(struct bfq_queue *bfqq, struct bfq_data *bfqd)
>  			1UL<<(BFQ_RATE_SHIFT - 10))
>  		bfq_update_rate_reset(bfqd, NULL);
>  	bfqd->last_completion = now_ns;
> -	bfqd->last_completed_rq_bfqq = bfqq;
> +	/*
> +	 * Shared queues are likely to receive I/O at a high
> +	 * rate. This may deceptively let them be considered as wakers
> +	 * of other queues. But a false waker will unjustly steal
> +	 * bandwidth to its supposedly woken queue. So considering
> +	 * also shared queues in the waking mechanism may cause more
> +	 * control troubles than throughput benefits. Then do not set
> +	 * last_completed_rq_bfqq to bfqq if bfqq is a shared queue.
> +	 */
> +	if (!bfq_bfqq_coop(bfqq))
> +		bfqd->last_completed_rq_bfqq = bfqq;
>  
>  	/*
>  	 * If we are waiting to discover whether the request pattern
> -- 
> 2.20.1
> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR