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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C373DC25B06 for ; Mon, 15 Aug 2022 01:48:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230122AbiHOBsl (ORCPT ); Sun, 14 Aug 2022 21:48:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59360 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230096AbiHOBsi (ORCPT ); Sun, 14 Aug 2022 21:48:38 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D991311A3D for ; Sun, 14 Aug 2022 18:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=HGo0XIO3+DsDYVBd08+wBQXUYY81cjOh3s5tyKuX8Ew=; b=GPxc8nC8lWZ/lo/bc7cKevVkQl unCRB0/xk5GIPpOYjIfnmz6Zfbh5g57noCYsLPWm2IvANFU1mtGm0gjpXAH2FPZmoyrWyZoD+QB3S ef6Uj61oB8Kad7e8tTlwKvq/6frbQUMox+LBM7b0zgjlbroGshoM7qZ6D9AoyZxFCUMtTHYdUvNGf b2eT/UTIg6lp80iLJeaEB3vCW+66v53h32XRzLPkDLS9HNvhwqgnYPe7alOV7hLFHkNa3jf+63g19 A6WeMu1jUBUn/3kfIYjYE4hZ3kWkv8PrAFWpUEspsS2DQaf8/Br7PyCK1lodSvDB4TnGE8JDszfBF M350Ay0g==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1oNPDP-004OGh-5A; Mon, 15 Aug 2022 01:48:27 +0000 Date: Mon, 15 Aug 2022 02:48:27 +0100 From: Al Viro To: Greg Kroah-Hartman Cc: Christian Brauner , Dongliang Mu , Dongliang Mu , Arve =?iso-8859-1?B?SGr4bm5lduVn?= , Todd Kjos , Martijn Coenen , Joel Fernandes , Carlos Llamas , Suren Baghdasaryan , Kees Cook , syzkaller , linux-kernel Subject: Re: [PATCH] drivers: binderfs: fix memory leak in binderfs_fill_super Message-ID: References: <20220812132124.2053673-1-dzm91@hust.edu.cn> <20220812142423.33wnvnjg6v2h2m3y@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 15, 2022 at 02:46:36AM +0100, Al Viro wrote: > On Fri, Aug 12, 2022 at 04:32:28PM +0200, Greg Kroah-Hartman wrote: > > > > It's a bit tricky to follow but d_make_root() always consumes the inode. > > > On success via d_instantiate() and on failure via iput(). So when > > > d_make_root() has been called the inode is off limits. And as soon as > > > d_make_root() has returned successfully we're guaranteed that > > > sb->s_fs_info is cleaned up if a ->put_super() method has been defined. > > > Just fyi. > > > > Ah, thanks, that wasn't obvious at all. > > > > greg k-h > > FWIW, I would rather provide a proper ->kill_sb() and gotten rid of > all that stuff. The thing is, unlike ->put_super(), ->kill_sb() is > called for *anything* that has gotten to foo_fill_super(). Usually > allows to get rid of those "call all of or parts of foo_put_super() > on failure exits" and associated bitrot... > > Like this (completely untested): [snip the patch] PS: that's instead of the patch upstream, not on top of it.