From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C7034314AC for ; Thu, 6 Aug 2026 09:22:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786008144; cv=none; b=nVX9cTrjp/e/v/rqDQOvzRLavZeWyXsAgGx9XsZ9I930XcN5Na2BVrpaQhrYC/DiSIYTI+jwqt4S6bHv89N3gHUwMz3sUnUkAEc1EYpHAeAxuM37t7kq37HR36OQeWq1LqC8UgO2X6ZeS2UNVexGfi8oOFKDw80JMXPweU5dA/s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786008144; c=relaxed/simple; bh=eAkOXZtlwNYjPhDGjyZtRke2iyDCQ2QqdzoXZFHQk1s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=peYCzunsIpHhDshU1aF5XVT+lomJrzEhIgdwsnO/Eor2xAAPFseNaM3dlZNUiRYHirpt4JsD9Olr9tbXxw7qo9cbiKqYkqljlTY3XPIaetOVOiueUsa8qSXWueQpVj5N9q4n1Shv6XyJI/MjGUQw/GH6Jnz54qFDWB1MEfO9QGM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=XrnD5ycW; arc=none smtp.client-ip=209.85.221.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="XrnD5ycW" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-47fd66a094eso767796f8f.3 for ; Thu, 06 Aug 2026 02:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1786008140; x=1786612940; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=Pcnhqt0EtUylxXGbjqsf+1Pc4DS5YZiCgI0VutNek2Q=; b=XrnD5ycWprfq6ZXTgx/sPzXa5ZnxABDwcpmPqfn9GG88R1oeKt24y55hESrkuenR00 nCKpfv3AkKfF4BEvNi1Np0lFOrYCUwYWexMxsBnhPOx2mxRlL7ydg2m/kBT+aiUV3Zd3 VESkJ5GGNCSExJTW9D+DzbWi1fVcVr4NwLIFru+84F1HhDvhmChS2J0YqoM0vX1T/1cK iAluYuFr7ppe3xH4njcLfGLfuvucdrfjmvVOh34RYec6puIycELs/LS1OFCHdSinjMYe umcNKcyjctdczgVSItKFxhC6REpSN1RTegig96f/He4KlWghfvQV4c9yOrOSyHOvsfie Z3iQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786008140; x=1786612940; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=Pcnhqt0EtUylxXGbjqsf+1Pc4DS5YZiCgI0VutNek2Q=; b=mPb2v3Dy+0Kv21wEi+HTcqlyfAlUmc2Z7SX4ZzIUr28kxh5rXr2bIfMto2jkkQjeWd E+PpJtjE5OLUf4Fr8MjiKTQ0tXPTuS53qXyAm/lUbZh3PC62ubIt3yxp9clLgDPk5CZC Ve5Vov63TMxx3lfZMN5sdsEX0uOd4hFZptduAREQnfCC7u6HliKdjANFWT392non2Kfr 6WRagZb0lR6L1OhDnwj6wALNm5rdzOrwa3T0YIPlG3wwf3SdzPMoPhDrmADd/3uiUBmI pgu94ROJrMM9/8S7PXbAJ00Q7wivkdv/gJ8mj4EmQpASq2F9m3O2S7StJqLgdm7SiXr0 cktA== X-Forwarded-Encrypted: i=1; AHgh+Rq4uOPhbX4Ub8sJBxl69dr0fzbpfZpJDdq/jFFGkPtBW9aUs4yvzLGVOSPgeJZm5ykKks8xN1+HTDs=@vger.kernel.org X-Gm-Message-State: AOJu0Yz/+Chafvop+d/7J7Zhx9W2OFsPLLcuAyqFmejNfvxqYlakeo4L JxaU4CSGWaSW0gH+kogDS4XpUpkQkRV90Z2aILAn6CvMmPNTuWYXUEZRxDHumumIw5w= X-Gm-Gg: AR+sD1048ypKJDiI6yD4DqFPVm+dzdKphY4BiQt4ynnQr1Vof3HPweDJ2sn+22xTyvS pIlcmr2jSmfJZLUrr2AMZYtT/linl/C/uT/Afwd/ph3L2K5Ny+D9dHpfuMev21L0STrlIekTTbs WW6BfgRFVMhdYL17k8KPfuG02soxYxVEpyqlDiLlbKr9hu3wUR1qDGiJIP9vZVmeQFsw8w5eIkX wTkCGI7guxk8JtOK1+wcbBnc3cGTLJfWCZNZ4thFjlEYSutLqcrP11JK98GKlnbOIR9NneS8vRU 0J0TBYyp39VxqjiVTcGWnwU5ZmxTMYKqiU4ELN44FmAYTXaWbYdvw1JEXjqWlQfi2KqFz/O8ss3 LGS4/+Cs9V2CWVXZmBtp1u1LSJpI5olZphtlLWrUAgjYUbfF62aQhEUv+XoyqYy3nFR/pqRp8ZZ cFhkxAM/cpRXvDFniiYbOvGs105DDLkh5vbi5KynEwCiEGbK5dRQDBS7+pb858Z0Nf X-Received: by 2002:a5d:624a:0:b0:47f:9750:26cc with SMTP id ffacd0b85a97d-47fec630b5cmr16574414f8f.23.1786008139632; Thu, 06 Aug 2026 02:22:19 -0700 (PDT) Received: from localhost.localdomain ([2001:af0:8000:1409:193:86:92:181]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47ff7b31975sm4112794f8f.33.2026.08.06.02.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2026 02:22:18 -0700 (PDT) Date: Thu, 6 Aug 2026 11:22:16 +0200 From: Michal =?utf-8?Q?Koutn=C3=BD?= To: Yu Kuai Cc: Jens Axboe , Tejun Heo , Johannes Weiner , Jonathan Corbet , Yu Kuai , Josef Bacik , Coly Li , Kent Overstreet , Alasdair Kergon , Mike Snitzer , Mikulas Patocka , Benjamin Marzinski , Song Liu , Dan Williams , Vishal Verma , Dave Jiang , Alison Schofield , Pankaj Gupta , Andreas Gruenbacher , Matthew Wilcox , Jan Kara , Andrew Morton , Chris Li , Kairui Song , Christoph Hellwig , Nilay Shroff , Tao Cui , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-bcache@vger.kernel.org, dm-devel@lists.linux.dev, linux-raid@vger.kernel.org, nvdimm@lists.linux.dev, virtualization@lists.linux.dev, gfs2@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH v1 2/3] blk-cgroup: store blkcg in bio instead of blkg Message-ID: References: <20260804065313.2092022-1-yukuai@kernel.org> <20260804065313.2092022-3-yukuai@kernel.org> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ltojthlavrpt3nkl" Content-Disposition: inline In-Reply-To: <20260804065313.2092022-3-yukuai@kernel.org> --ltojthlavrpt3nkl Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC PATCH v1 2/3] blk-cgroup: store blkcg in bio instead of blkg MIME-Version: 1.0 Hi Kuai. On Tue, Aug 04, 2026 at 02:53:12PM +0800, Yu Kuai wrote: > From: Yu Kuai >=20 > A bio currently stores a queue-local blkg reference. This forces bio > association and remap paths to look up or create a blkg even when the bio > will never enter a blkcg policy. >=20 > Store the blkcg css association in the bio instead, and derive the blkg > from the bio's blkcg and current bdev when a policy needs it. The first > successful policy lookup pins the blkg, records the pin with BIO_BLKG_REF, > and drops it from bio_clear_blkcg() or when bio_set_dev() changes the > lookup key. >=20 > Keep lookup-only users from creating missing blkgs by using > bio_blkg_lookup(), and rename the bio cgroup association helpers to match > the stored blkcg state. I assume this should be OK due to limited lifetime of bios -- this would not lead no possibly indefinite accumulation of offlined blkcgs, correct? > -void bio_associate_blkg_from_css(struct bio *bio, > +void bio_associate_blkcg_from_css(struct bio *bio, > struct cgroup_subsys_state *css) > { > - if (bio_blkg(bio)) > - blkg_put(bio_blkg(bio)); > + struct blkcg *blkcg; > =20 > - if (css && css->parent) { > - bio->bi_blkg =3D blkg_tryget_closest(bio, css); > - } else { > - blkg_get(bdev_get_queue(bio->bi_bdev)->root_blkg); > - bio->bi_blkg =3D bdev_get_queue(bio->bi_bdev)->root_blkg; > - } > + if (!css || !css->parent) > + css =3D &blkcg_root.css; > + > + blkcg =3D css_to_blkcg(css); > + if (bio_blkcg(bio) =3D=3D blkcg) > + return; > + > + css_get(css); <--- > + bio_clear_blkcg(bio); > + bio->bi_blkcg =3D blkcg; > } > -EXPORT_SYMBOL_GPL(bio_associate_blkg_from_css); > +EXPORT_SYMBOL_GPL(bio_associate_blkcg_from_css); [skip to next comment below now] And here yet another (any) reference to same css is taken 2nd time. [skip after next comment below :)] > =20 > /** > - * bio_associate_blkg - associate a bio with a blkg > + * bio_associate_blkcg - associate a bio with a blkcg > * @bio: target bio > * > - * Associate @bio with the blkg found from the bio's css and request_que= ue. > - * If one is not found, bio_lookup_blkg() creates the blkg. If a blkg is > - * already associated, the css is reused and association redone as the > - * request_queue may have changed. > + * Associate @bio with the blkcg found from the bio's css. If a blkcg is > + * already associated, keep it as blkcg association is not queue-local. > */ > -void bio_associate_blkg(struct bio *bio) > +void bio_associate_blkcg(struct bio *bio) > { > struct cgroup_subsys_state *css; > =20 > if (blk_op_is_passthrough(bio->bi_opf)) > return; > =20 > - if (bio_blkg(bio)) { > - css =3D bio_blkcg_css(bio); > - bio_associate_blkg_from_css(bio, css); > - } else { > - rcu_read_lock(); > - css =3D blkcg_css(); > - if (!css_tryget_online(css)) > - css =3D NULL; > - rcu_read_unlock(); > + if (bio_blkcg(bio)) > + return; > =20 > - bio_associate_blkg_from_css(bio, css); > - if (css) > - css_put(css); > - } > + rcu_read_lock(); > + css =3D blkcg_css(); > + if (!css_tryget_online(css)) <--- > + css =3D NULL; > + rcu_read_unlock(); > + > + bio_associate_blkcg_from_css(bio, css); > + if (css) > + css_put(css); > } > -EXPORT_SYMBOL_GPL(bio_associate_blkg); > +EXPORT_SYMBOL_GPL(bio_associate_blkcg); next: Here you take (online) reference to the blkcg->css. [return back to previous comment] after: Ideally, no tasks should be in offlined (blk)cgs, so the `current` would not resolve to blkcg_css() returning an offlined blkcgs. OTOH, it's generally good not to do _new_ associations to an offlined blkcg. Which is why I think this logic would better fit to bio_associate_blkcg_from_css() 0.02=E2=82=AC, Michal --ltojthlavrpt3nkl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iJEEABYKADkWIQRCE24Fn/AcRjnLivR+PQLnlNv4CAUCanRSRBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDIACgkQfj0C55Tb+Ahf+gEA5FtU8iXyQA9tlhJdWJEf nyf1IBDUt4tisH7UDE8KiSEBAP5BK6FXkSftml/wn918ol1iwizfBzFhephd2gZc e3UL =GgwG -----END PGP SIGNATURE----- --ltojthlavrpt3nkl--