Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3696591imw; Mon, 18 Jul 2022 12:50:40 -0700 (PDT) X-Google-Smtp-Source: AGRyM1trybSTzzBs9NAB1oNThnGeK0QvObAGZWmeJTusfOw1cnf0KX3E9/qAPuMru8uXYZqGkT9H X-Received: by 2002:a17:907:2d25:b0:72b:83c2:ab90 with SMTP id gs37-20020a1709072d2500b0072b83c2ab90mr27110201ejc.373.1658173839781; Mon, 18 Jul 2022 12:50:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658173839; cv=none; d=google.com; s=arc-20160816; b=jRyzyfyukc0Gz2E7kund2oDicPOeqwTBoJVUY6rHLmvSLI9j3xLD2baFLRV60WNWF4 lYnXp+7OtTObKoPxSi6OzRTRDHCHtpsr153JJqFFRiOEuG7Jz21R5JSXqRqihgkOpzi1 8ZVJHJPd4vhougXLEHdMnAUIiUBdpZDBWUE6+ajt8OWLnsoFAM53RLQ3dmxxg6SegjS4 N94sUYAW/XovjvYHLtyyT6esHVtTUC3bwSR2IwLXjwA3uK3PnhVb5iO/JQq2KnuPwN1D oJwQYghRsqPM1BdPCEojmFXaSexyEikfvDRB4ToPlMBRWZ4CLh2RwVCazokQN6kWYkJS 6toA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=L49cEqnvIqcH6kuvpQrqn6Zje6ktkAbRLUeIUPxx/7E=; b=gbytTZ2WGptk1p08FB23CKmG/EbknDJH8j4eGe6u8tb9rfoVqQ1T1QkwfJSsPRk+n2 UC0LYYCWDNYfEWwJOWfLNjM6uVJOt82i5wgggMy0/mpgMTEAzRcKsgjCc1SR7QxTCvVL eOKA6y773/rB0rcSad9qIaOqzM9nBBJR8HKMO5GrEcHKrTbghGHmgZzt4PPDV0dwZ5nn B8blWkX1cYdfhIpAoOa0GgCJl3TQ9Wbkj/1QzSF9hg50hO/VILisy6vQzdC/qPXk/j3H OVzpUvdmKE/pzghG5qMGPPF7/sp5CwqMdFpUZBSa9Rxn2VVA1Xv+QT1ZoHD5Psh+XO1D tw0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=AOJiH+SX; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y7-20020aa7c247000000b0043ab049687esi14551412edo.236.2022.07.18.12.50.15; Mon, 18 Jul 2022 12:50:39 -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=@gmail.com header.s=20210112 header.b=AOJiH+SX; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235719AbiGRTWz (ORCPT + 99 others); Mon, 18 Jul 2022 15:22:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41980 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235704AbiGRTWw (ORCPT ); Mon, 18 Jul 2022 15:22:52 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A31AF2F67D; Mon, 18 Jul 2022 12:22:51 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id v4-20020a17090abb8400b001ef966652a3so19138500pjr.4; Mon, 18 Jul 2022 12:22:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=L49cEqnvIqcH6kuvpQrqn6Zje6ktkAbRLUeIUPxx/7E=; b=AOJiH+SXnVmQJ+bGNsZclRXLODxNSpRAvPfO/VxS7r8q2g5X+8Xlta47Sl1pGHzkV+ FwVS6nFN35kueD5zFoeT2Vv3mlbHyBS2eLHAXHY+HA81SCyD7KP1t86n3llHw0BDRhTg 7ch/aSQGS5uqNET+mWyGr9MIsDr6aTo1b+6izOguOwAcCZPuG46lc3d9yq3pl2ncn2vD Viw2Q0xjJXJVjT2AMQBZ1fIMD63Tief5fi+JCPArIrudaYNEp/+tca6nW5kzvPHK8EvX OrRROGhSWJzS0qyYOUQQX6nlYAPRZP8RFAaRlfraANgBC65PrFNL+zLE+OpIUFOPlbpB kS5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=L49cEqnvIqcH6kuvpQrqn6Zje6ktkAbRLUeIUPxx/7E=; b=hiZlLRGpZBgPitM7gSsX/2JZbHyPCZ/DtY93s4gPByhpAloBBUdCjAg/Go1iK3cF9r qeCaPDyRWEHIktgfxyNSlBKrkLU6f1mb7GNz35XbE3HrBppGAhkh3KJGimx4iEl+cW7E EkdUVyanO/4HhmNdkoGiLT6+ojicMPhVlagt0EomAmAq1+dQ5lqizTTVGhxr7VOx4zHx P+T9z+cEOUT2xx1N2XflOsNNgK2uMcJapg1rviOQiRtaafjJggg84aQthIevtUyOGRBc m2PKCQ92CRPPafLeORnRn50pIq86a9Uz2x/QrCeLwurG3txGYhUvNMuYsDc0tRgZp3a+ VPlw== X-Gm-Message-State: AJIora8CL1WilHca2HYj51N36fT09dMkairTf7krh9OY+F2fe1NvwvPP K8L94F9uc5kHYeuEgI0yISopTII1864= X-Received: by 2002:a17:902:f708:b0:153:839f:bf2c with SMTP id h8-20020a170902f70800b00153839fbf2cmr28645338plo.113.1658172170867; Mon, 18 Jul 2022 12:22:50 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id e15-20020a056a0000cf00b005255489187fsm9620296pfj.135.2022.07.18.12.22.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 12:22:49 -0700 (PDT) Sender: Tejun Heo Date: Mon, 18 Jul 2022 09:22:47 -1000 From: Tejun Heo To: Jinke Han Cc: axboe@kernel.dk, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH] block: don't allow the same type rq_qos add more than once Message-ID: References: <20220718083646.67601-1-hanjinke.666@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220718083646.67601-1-hanjinke.666@bytedance.com> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no 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 Hello, On Mon, Jul 18, 2022 at 04:36:46PM +0800, Jinke Han wrote: > When the io.cost.qos file is written by two cpu concurrently, rq_qos may > be added to one disk twice. In that case, there will be two iocs enabled > and running on one disk. They own different iocgs on their active list. > In the ioc_timer_fn function, because of the iocgs from two ioc have the > same root iocg, the root iocg's walk_list may be overwritten by each > other and this lead to list add/del corrutions in building or destorying > the inner_walk list. > > And so far, the blk-rq-qos framework works in case that one instance for > one type rq_qos per queue by default. This patch make this explicit and > also fix the crash above. Ah, good catch. Looks great. Just a few nits below. > Signed-off-by: hanjinke Can you please use your full name in FIRST LAST form on the SOB line? > --- a/block/blk-iocost.c > +++ b/block/blk-iocost.c > @@ -2886,7 +2886,12 @@ static int blk_iocost_init(struct request_queue *q) > * called before policy activation completion, can't assume that the > * target bio has an iocg associated and need to test for NULL iocg. > */ > - rq_qos_add(q, rqos); > + ret = rq_qos_add(q, rqos); > + if (ret) { > + free_percpu(ioc->pcpu_stat); > + kfree(ioc); > + return ret; Given that these get repeated for policy activation failure, it'd prolly be better to factor them out at the end and use gotos and make all of the users use the same pattern. > +static inline int rq_qos_add(struct request_queue *q, struct rq_qos *rqos) > { > /* > * No IO can be in-flight when adding rqos, so freeze queue, which > @@ -98,6 +98,8 @@ static inline void rq_qos_add(struct request_queue *q, struct rq_qos *rqos) > blk_mq_freeze_queue(q); > > spin_lock_irq(&q->queue_lock); > + if (rq_qos_id(q, rqos->id)) > + goto out; Maybe rename the goto label to ebusy so that it's `goto ebusy`? Other than the nits, please feel free to add Acked-by: Tejun Heo Thanks. -- tejun