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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6EECBC433FE for ; Wed, 30 Nov 2022 15:16:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B5E306B0072; Wed, 30 Nov 2022 10:16:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0DC56B0073; Wed, 30 Nov 2022 10:16:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FC816B0074; Wed, 30 Nov 2022 10:16:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 90FB76B0072 for ; Wed, 30 Nov 2022 10:16:44 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 60E1DC0863 for ; Wed, 30 Nov 2022 15:16:44 +0000 (UTC) X-FDA: 80190460728.07.D7178B6 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf13.hostedemail.com (Postfix) with ESMTP id AEDDF2000B for ; Wed, 30 Nov 2022 15:16:42 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 1D5C0218DF; Wed, 30 Nov 2022 15:16:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669821401; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ATM8wuEZO4F8LmfuabnM5oV4K3RnnbDMeyDmwCZSpdY=; b=j6xq7JSq+Wr3SnG8eqNE+ECS5hPr743xQ5eo4n+UP7l3stds48QDvKwIiUHdHLnjAe5FLh i3ipUvJUniXllps7G5UVsQKq8e4auYqUEEFMQ/03zLcVsv9A4c4d2v2B6rezUF+XYnSfwU 8/nlKl2px4rsGu4yjPnAuTS9c0Ex8fE= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id C987F1331F; Wed, 30 Nov 2022 15:16:40 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id tYxQMNhzh2MWGwAAMHmgww (envelope-from ); Wed, 30 Nov 2022 15:16:40 +0000 Date: Wed, 30 Nov 2022 16:16:39 +0100 From: Michal =?iso-8859-1?Q?Koutn=FD?= To: Waiman Long Cc: Jens Axboe , Tejun Heo , cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ming Lei , Andy Shevchenko , Andrew Morton , Hillf Danton , Chaitanya Kulkarni , Bart Van Assche , Josef Bacik , Yi Zhang Subject: Re: [PATCH-block v2] bdi, blk-cgroup: Fix potential UAF of blkcg Message-ID: <20221130151639.GE27838@blackbody.suse.cz> References: <20221129203400.1456100-1-longman@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="T6xhMxlHU34Bk0ad" Content-Disposition: inline In-Reply-To: <20221129203400.1456100-1-longman@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=j6xq7JSq; spf=pass (imf13.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669821403; a=rsa-sha256; cv=none; b=mBCGosXocquc2Qw0ESGakDXt4g3dGf+f0fkySGi9nsGtm/1HhXS8q337V2pf/5xqboKqjE mU/8RZD8TWv5W99NfCgzR3qe68xKoGhCDiPa6TgJi4FRJajfxPx5zmLwyNImLHtDIk93Zp qS9mTp3Ei8CcirKPhp2Siq5ksnfceX4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669821403; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ATM8wuEZO4F8LmfuabnM5oV4K3RnnbDMeyDmwCZSpdY=; b=ZSs1CQ31Qf24MHR/9ra7dh2wOXDkxREYD7LcySeAMB6CL9SixhoSBfyvcW/wGsa81brcK7 nspQa8w3t/+ZrthzM9LJKXA18/bICoDjeByC6qFqxZJSDo6UiiaxL/Y7h3ek1MfAcELCNW eEviMI6tV+Bedo+ZTFqKPYKMbCpkRcU= Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=j6xq7JSq; spf=pass (imf13.hostedemail.com: domain of mkoutny@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mkoutny@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam01 X-Stat-Signature: mxpn3be3cniuzmibzmkiyhk6xbex4hp7 X-Rspamd-Queue-Id: AEDDF2000B X-Rspam-User: X-HE-Tag: 1669821402-614715 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: --T6xhMxlHU34Bk0ad Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 29, 2022 at 03:34:00PM -0500, Waiman Long = wrote: > The reproducing system can no longer produce a warning with this patch. > All the runnable block/0* tests including block/027 were run successfully > without failure. Thanks for the test! > @@ -1088,7 +1088,15 @@ static void blkcg_destroy_blkgs(struct blkcg *blkc= g) > =20 > might_sleep(); > =20 > - css_get(&blkcg->css); > + /* > + * blkcg_destroy_blkgs() shouldn't be called with all the blkcg > + * references gone and rcu_read_lock not held. > + */ > + if (!css_tryget(&blkcg->css)) { > + WARN_ON_ONCE(!rcu_read_lock_held()); > + return; > + } As I followed the previous discussion, the principle is that obtaining a reference or being inside an RCU read section is sufficient. Consequently, I'd expect the two situations handled equally but here the no-ref but RCU bails out. (Which is OK because blkg_list must be empty?) However, the might_sleep() in (non-sleepable) RCU reader section combo makes me wary anyway (not with the early return but tools would likely complain). All in all, can't the contract of blkcg_destroy_blkgs() declare that a caller must pass blkcg with a valid reference? (The body of blkcg_destroy_blkgs then wouldn't need to get neither put the inner reference). HTH, Michal --T6xhMxlHU34Bk0ad Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTrXXag4J0QvXXBmkMkDQmsBEOquQUCY4dzxgAKCRAkDQmsBEOq ua6MAQCYfYVZAsH1NgOid00l0b52FcccC2/s0ITlu8jm7ZQs6wEAhKRvdwKu6lsC VQgfYht9U8f+lQdK562Fh/ONyn6DzQw= =M1ug -----END PGP SIGNATURE----- --T6xhMxlHU34Bk0ad--