Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1657153pxb; Mon, 11 Oct 2021 10:19:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcuTqsS4iTBNuECaFQSkCUYuDuULIulnx1denHX1QBR9FU+8TKOoTUR+ywwFxiTFmRCZYc X-Received: by 2002:a17:906:369a:: with SMTP id a26mr26273617ejc.539.1633972786410; Mon, 11 Oct 2021 10:19:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633972786; cv=none; d=google.com; s=arc-20160816; b=UQ84MV+eI0J5vMok04zaPLYFm0KcwLk8vk74R/vqmQQHBFpGjNQziSZyS1o062R49t n1UkFneDCT05UtILHVMtH3E7oRlQ7eiGN/PGvH1BhgQ3Nv6ZRpF9Y3CRdlPRptZ1h+FY SeGptw3A+j8jNHsDn0wQGfNKZsuq27D0kjJraGrsaqJQHDyoIuNPylnYl8mrS97+bogW XTAoa/So5RV0Mqudto3Dh5mA/OT8xTcwq5IILugvC8P0Xqte+CeWpbkplhhBu3Ns6cIt 6/tFTy2RlJCSttFeghTsRtTip0GqB6jfZllPSf3NPN8uX2b0vuGFrt0jKX+NxiHqH1YY WL3g== 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=47MxuwjdGXsg6hhuLv8z6fw88ymx9GeX72SLuyGJTok=; b=ySx5eLacWs4DZ5YMJK1oP2g+ZzKr9FTm8nNCCjg39y64thdlyMud1iT2PMG/tAyJio bDR/TsvxHRIiPklWaR65EGMmjvOEym0HuGqENTQyPuTBhlmyhpAN/Noei+1GIuHFfawb M4HhdwKZolpwTKwAEAgMduSBcXzrNxbMXChoDULg7LdyPbPNzLyfwBq4FN3FRNYE0ek0 5Q52EzD5QUHIgVwzmKmFLqbqWg7FasrS/+Jn9dHL7/FrwJHEYWWsCJQa+2rW4n3L+TKB CYBGytPGCheNDqjbKjF0QPuk/jZOwveoJVl8N6MoyFb9aEVfLgSnlItZExRm1hEsoAiP EGQQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=a4RrVVdJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z23si12603557edm.184.2021.10.11.10.19.21; Mon, 11 Oct 2021 10:19:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=a4RrVVdJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S233886AbhJKRTC (ORCPT + 98 others); Mon, 11 Oct 2021 13:19:02 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233713AbhJKRTB (ORCPT ); Mon, 11 Oct 2021 13:19:01 -0400 Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9E2BBC061570; Mon, 11 Oct 2021 10:17:01 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id v11so11418288pgb.8; Mon, 11 Oct 2021 10:17:01 -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=47MxuwjdGXsg6hhuLv8z6fw88ymx9GeX72SLuyGJTok=; b=a4RrVVdJ7cUmlCzggWQlfbsOGdWJ2MPLEG7CalU7wsqMn5r+DmcveNvP/dyXMNR51w JtU8Ih35Ce+uEy4ncY5JylViwvaU0igXgKz2jaopbXllKs4Y/NmCftllt9Er3ysq5hxH VPtWr48EAAqhK7X9th7UFB+LRnFN9m99A2smY07IoxO7ZFdPJ7mXc6Pu3qkj4fBcKTyb 2Iv2hIOIVZVA3TbxCeJx5383kucVuJsrJ2aavndyzcUgCH8omLECpFhzAfSfBEBllQwh 97IPyg91TL5MFJMujwLsnFD+T4IWTukC9iJ8bqhU/7D+IlUe2KDpBVFaOCk696vZlb+a SsYA== 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=47MxuwjdGXsg6hhuLv8z6fw88ymx9GeX72SLuyGJTok=; b=wTJlpTDD5BlXbcIpM5sO91NcjsgMe+tay+GusB4elj5i+pEMKu4cjxGEeamMKs2kbQ xHh/FNxrHvl0NistqwgcxOv8md481QPx6EjgprBHwR2yPlZ9Ldfmyc3kTMo8cZkZIGL/ B3z/J65vkT3Xf/3jOOCoJ0SwiI5ApEQECtq4Bcz0h/zYD0m7dDUd2ivFjgU5XsykRo6i QZdFkx2vok9b1zBTT1ATi1erPMRlFDaJsyzAo/9qYdWV/sOLf1KfDFeU2vL2bkCTc7zx IlipuvKzZ8FQpHSOzl1XXfYbPpzH36jXXZCPEcnC5NBX5BvjP2k8Ot10K5NCW32odYaf XUKA== X-Gm-Message-State: AOAM531WPpmYZtBIA5FpGcWBSoUMPgmZLjx7Enu1Yd57b8f4L2QgM9eC gjrQoKEFZ3BJSV4I0M3c9AAVR9feZ3olzA== X-Received: by 2002:a63:2b8c:: with SMTP id r134mr18907749pgr.420.1633972620892; Mon, 11 Oct 2021 10:17:00 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-e24f-43ff-fee6-449f.res6.spectrum.com. [2603:800c:1a02:1bae:e24f:43ff:fee6:449f]) by smtp.gmail.com with ESMTPSA id u193sm8743444pgc.34.2021.10.11.10.17.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Oct 2021 10:17:00 -0700 (PDT) Sender: Tejun Heo Date: Mon, 11 Oct 2021 07:16:59 -1000 From: Tejun Heo To: Yu Kuai Cc: axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [PATCH] blk-cgroup: check blkcg policy is enabled in blkg_create() Message-ID: References: <20211008072720.797814-1-yukuai3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211008072720.797814-1-yukuai3@huawei.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 08, 2021 at 03:27:20PM +0800, Yu Kuai wrote: > diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c > index eb48090eefce..00e1d97621ea 100644 > --- a/block/blk-cgroup.c > +++ b/block/blk-cgroup.c > @@ -226,6 +226,20 @@ struct blkcg_gq *blkg_lookup_slowpath(struct blkcg *blkcg, > } > EXPORT_SYMBOL_GPL(blkg_lookup_slowpath); > > +static void blkg_check_pd(struct request_queue *q, struct blkcg_gq *blkg) > +{ > + int i; > + > + for (i = 0; i < BLKCG_MAX_POLS; i++) { > + struct blkcg_policy *pol = blkcg_policy[i]; > + > + if (blkg->pd[i] && !blkcg_policy_enabled(q, pol)) { > + pol->pd_free_fn(blkg->pd[i]); > + blkg->pd[i] = NULL; > + } > + } > +} > + > /* > * If @new_blkg is %NULL, this function tries to allocate a new one as > * necessary using %GFP_NOWAIT. @new_blkg is always consumed on return. > @@ -252,6 +266,9 @@ static struct blkcg_gq *blkg_create(struct blkcg *blkcg, > goto err_free_blkg; > } > > + if (new_blkg) > + blkg_check_pd(q, new_blkg); > + Can't this happen the other way around too? ie. Linking a pd which doesn't have an entry for a policy which got enabled inbetween? And what if an existing policy was de-registered and another policy got the policy id inbetween? I think the correct solution here would be synchronizing alloc - create blocks against policy deactivation rather than trying to patch an allocated blkg later. Deactivation being a really slow path, there are plenty of options. The main challenge would making it difficult to make mistakes with, I guess. Thanks. -- tejun