Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1225625iob; Wed, 4 May 2022 18:01:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJybP6/AgZ6/4HeF7eJ3GZLASIiHAyQcmojL2ej50orXaH3UQSHeqhktwruBxU49oLUHGlh/ X-Received: by 2002:aa7:c5c9:0:b0:425:ca31:4e35 with SMTP id h9-20020aa7c5c9000000b00425ca314e35mr27304714eds.315.1651712500771; Wed, 04 May 2022 18:01:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651712500; cv=none; d=google.com; s=arc-20160816; b=UpbZ1wxv9Qkl6nsXvxKB/xGXdOokprY70p1H4ghZ/5fYQ/XYGxNd8FU81iu/2SXYnd CpxCfovbpneqL0q+e/RqjeBB9zCqdxZiblN5v4wrZy5MELVJHTyxL8oX9Z8GIStFlInM kyufJHpEyf/hVtbw1v68Fgx0YPI5NfR43WF/D8NSCHFGKIB5Ovh4TXlJ+lB9PkJSVtGf 6HFjQdWqsgH8qR3byLIxuICXaDGBAqBiULivX/qLJJQbIBFU9+9EL/mb1fGKrdVqPaf4 WWeF/nrlA5nC/k3QWY9RqQtqCsD6QuNOl1vZqwENM8chNE2Bq+5nDzL15L0RmvXpwUns Hx1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=4FG/Eq63FwbMeko0IoYzy1G5BUQ4r7w8dRevykcJiNo=; b=MtP/IS3U5XSeWT+U72k99hICkSl+ux/I4AXPWpb28OEXt7xGZuG7dWo+Agz90wJ6+P QQNo/d6Gs3sT5tXcjfVvy2Kj/eYnU6Mm4WHpdtuxuUO+VvSsCkVL7Iuhe0flVSFkLwSK hKyQay3f4oy4hsKxpDZMuLYfdAOdD6c3zmKfe/dUBfYW1x0Mpf9SAlgz5nblc6qeEVLh hOVkovrOk25RggYQ2Ft6wP5EWOUSg79h9Khg3MrDTo9Yqn1aSb7z48yPFLGSEGeewYUN dQBLrsOlNAI7SQFfTkrIbvL07X7XWwU2oklkTzvmkckkX5yhEjbmFgaF1EUHUgSMx6UH PmGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=K6vzjX4N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id o4-20020a170906860400b006ef57f5e94esi386275ejx.1006.2022.05.04.18.01.15; Wed, 04 May 2022 18:01:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=K6vzjX4N; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352508AbiEDRwO (ORCPT + 99 others); Wed, 4 May 2022 13:52:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1357455AbiEDRPC (ORCPT ); Wed, 4 May 2022 13:15:02 -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 4B63954BFB; Wed, 4 May 2022 09:58:36 -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 C94B4B82416; Wed, 4 May 2022 16:58:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79736C385A4; Wed, 4 May 2022 16:58:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651683514; bh=L7DYpejEYREcuXWD29M7l9A1VyzsjUx/u8M06UpSmMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K6vzjX4N2rSPw2BOzd2qwbGHwi6wBU/P54hKntcLFXd3jYRZP0PotnFfA/xGM0JJO HGi/MyfrDTWQIDMiLHh1/bC+C0w+mpS7/KTL/LuKQuLy6TBAo1YGurOCCHwrXWStF8 ZrKJaBrf+akiuFZK6woCm315TCE6GeW0BKLy+SjA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chris Murphy , "yukuai (C)" , Jan Kara , Jens Axboe Subject: [PATCH 5.17 177/225] bfq: Fix warning in bfqq_request_over_limit() Date: Wed, 4 May 2022 18:46:55 +0200 Message-Id: <20220504153126.156084152@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220504153110.096069935@linuxfoundation.org> References: <20220504153110.096069935@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jan Kara commit 09df6a75fffa68169c5ef9bef990cd7ba94f3eef upstream. People are occasionally reporting a warning bfqq_request_over_limit() triggering reporting that BFQ's idea of cgroup hierarchy (and its depth) does not match what generic blkcg code thinks. This can actually happen when bfqq gets moved between BFQ groups while bfqq_request_over_limit() is running. Make sure the code is safe against BFQ queue being moved to a different BFQ group. Fixes: 76f1df88bbc2 ("bfq: Limit number of requests consumed by each cgroup") CC: stable@vger.kernel.org Link: https://lore.kernel.org/all/CAJCQCtTw_2C7ZSz7as5Gvq=OmnDiio=HRkQekqWpKot84sQhFA@mail.gmail.com/ Reported-by: Chris Murphy Reported-by: "yukuai (C)" Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20220407140738.9723-1-jack@suse.cz Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- block/bfq-iosched.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) --- a/block/bfq-iosched.c +++ b/block/bfq-iosched.c @@ -569,7 +569,7 @@ static bool bfqq_request_over_limit(stru struct bfq_entity *entity = &bfqq->entity; struct bfq_entity *inline_entities[BFQ_LIMIT_INLINE_DEPTH]; struct bfq_entity **entities = inline_entities; - int depth, level; + int depth, level, alloc_depth = BFQ_LIMIT_INLINE_DEPTH; int class_idx = bfqq->ioprio_class - 1; struct bfq_sched_data *sched_data; unsigned long wsum; @@ -578,15 +578,21 @@ static bool bfqq_request_over_limit(stru if (!entity->on_st_or_in_serv) return false; +retry: + spin_lock_irq(&bfqd->lock); /* +1 for bfqq entity, root cgroup not included */ depth = bfqg_to_blkg(bfqq_group(bfqq))->blkcg->css.cgroup->level + 1; - if (depth > BFQ_LIMIT_INLINE_DEPTH) { + if (depth > alloc_depth) { + spin_unlock_irq(&bfqd->lock); + if (entities != inline_entities) + kfree(entities); entities = kmalloc_array(depth, sizeof(*entities), GFP_NOIO); if (!entities) return false; + alloc_depth = depth; + goto retry; } - spin_lock_irq(&bfqd->lock); sched_data = entity->sched_data; /* Gather our ancestors as we need to traverse them in reverse order */ level = 0;