From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DE8FC4332F for ; Mon, 28 Mar 2022 11:38:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241510AbiC1LkC (ORCPT ); Mon, 28 Mar 2022 07:40:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39396 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241534AbiC1Lb7 (ORCPT ); Mon, 28 Mar 2022 07:31:59 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A35A57482; Mon, 28 Mar 2022 04:24:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 61D60B81055; Mon, 28 Mar 2022 11:24:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 377B3C36AE5; Mon, 28 Mar 2022 11:24:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648466673; bh=8eD3NBqN/q0rqhEJ4PrIDbklKcrEr68iBunmR+/7aRM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o4HCxLARALAQ5qrxGM7wBq+Q/ev5ZGW5tSdaut3b+Jwp7ACsjRW97cjsKkVM/M1nA xXh93G8KY2ypyO0CN1j3Yac1KwQU1hDOffFyCPykLCct8+LlI1lWK3grPmV9Ep5HiR JklqngJ+6rjsVX3c08y0Myy2IUo7gvu0G/9qXQe7pCuAIM1aev0LAqh6Z8PAhxmh1+ u4/mvvlEQLE2HbtLxt2jdyYqI5xxN/gEtMv3NAc/ceN+7ud6aFr6cHF8hD0wJ31mMQ Hc52PR2LcacgYEo59CHUPiwJaoDORtwd6kXSKxukqdzKLGZA4OQ35exd3fTDks4Gvy MSYSrYURAgvMA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Paolo Valente , =?UTF-8?q?Holger=20Hoffst=C3=A4tte?= , Jens Axboe , Sasha Levin , linux-block@vger.kernel.org Subject: [PATCH AUTOSEL 4.19 09/12] Revert "Revert "block, bfq: honor already-setup queue merges"" Date: Mon, 28 Mar 2022 07:24:14 -0400 Message-Id: <20220328112417.1556946-9-sashal@kernel.org> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220328112417.1556946-1-sashal@kernel.org> References: <20220328112417.1556946-1-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org From: Paolo Valente [ Upstream commit 15729ff8143f8135b03988a100a19e66d7cb7ecd ] A crash [1] happened to be triggered in conjunction with commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq: honor already-setup queue merges""). Yet, the reverted commit was not the one introducing the bug. In fact, it actually triggered a UAF introduced by a different commit, and now fixed by commit d29bd41428cf ("block, bfq: reset last_bfqq_created on group change"). So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq: honor already-setup queue merges") out. This commit restores it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503 Reported-by: Holger Hoffstätte Signed-off-by: Paolo Valente Link: https://lore.kernel.org/r/20211125181510.15004-1-paolo.valente@linaro.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin --- block/bfq-iosched.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c index dfd55037dc6f..a9f42df92ea3 100644 --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -2155,6 +2155,15 @@ bfq_setup_merge(struct bfq_queue *bfqq, struct bfq_queue *new_bfqq) * are likely to increase the throughput. */ bfqq->new_bfqq = new_bfqq; + /* + * The above assignment schedules the following redirections: + * each time some I/O for bfqq arrives, the process that + * generated that I/O is disassociated from bfqq and + * associated with new_bfqq. Here we increases new_bfqq->ref + * in advance, adding the number of processes that are + * expected to be associated with new_bfqq as they happen to + * issue I/O. + */ new_bfqq->ref += process_refs; return new_bfqq; } @@ -2214,6 +2223,10 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, { struct bfq_queue *in_service_bfqq, *new_bfqq; + /* if a merge has already been setup, then proceed with that first */ + if (bfqq->new_bfqq) + return bfqq->new_bfqq; + /* * Prevent bfqq from being merged if it has been created too * long ago. The idea is that true cooperating processes, and @@ -2228,9 +2241,6 @@ bfq_setup_cooperator(struct bfq_data *bfqd, struct bfq_queue *bfqq, if (bfq_too_late_for_merging(bfqq)) return NULL; - if (bfqq->new_bfqq) - return bfqq->new_bfqq; - if (!io_struct || unlikely(bfqq == &bfqd->oom_bfqq)) return NULL; -- 2.34.1