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 X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2A99CC433B4 for ; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 07435613B6 for ; Fri, 21 May 2021 08:15:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230320AbhEUIRD convert rfc822-to-8bit (ORCPT ); Fri, 21 May 2021 04:17:03 -0400 Received: from us-smtp-delivery-44.mimecast.com ([205.139.111.44]:32655 "EHLO us-smtp-delivery-44.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbhEUIRC (ORCPT ); Fri, 21 May 2021 04:17:02 -0400 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-134-P7MMZ4skNEasB_Ci5O7ioQ-1; Fri, 21 May 2021 04:15:35 -0400 X-MC-Unique: P7MMZ4skNEasB_Ci5O7ioQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9FD3F107ACCD; Fri, 21 May 2021 08:15:34 +0000 (UTC) Received: from bahia.lan (ovpn-112-49.ams2.redhat.com [10.36.112.49]) by smtp.corp.redhat.com (Postfix) with ESMTP id B74C65C8A8; Fri, 21 May 2021 08:15:24 +0000 (UTC) Date: Fri, 21 May 2021 10:15:23 +0200 From: Greg Kurz To: Miklos Szeredi Cc: Al Viro , virtualization@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, virtio-fs-list , Stefan Hajnoczi , Max Reitz , Vivek Goyal Subject: Re: [PATCH v4 1/5] fuse: Fix leak in fuse_dentry_automount() error path Message-ID: <20210521101523.4f276dac@bahia.lan> In-Reply-To: References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-2-groug@kaod.org> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=groug@kaod.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kaod.org Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 21 May 2021 09:54:19 +0200 Miklos Szeredi wrote: > On Thu, 20 May 2021 at 21:45, Al Viro wrote: > > > > On Thu, May 20, 2021 at 05:46:50PM +0200, Greg Kurz wrote: > > > Some rollback was forgotten during the addition of crossmounts. > > > > Have you actually tested that? Because I strongly suspect that > > by that point the ownership of fc and fm is with sb and those > > should be taken care of by deactivate_locked_super(). > > Not quite. Patch looks correct because destruction of fm is done in > fuse_put_super(), which only gets called if the sb initialization gets > as far as setting up sb->s_root, which only happens after the > successful fuse_fill_super_submount() call in this case. > > Doing the destruction from the various ->kill_sb() instances instead > of from ->put_super() would also fix this, but I'm not quite sure that > that would be any cleaner. > As saying in the answer I've just posted, a failure in fuse_fill_super_submount() causes an actual crash because fuse_mount_remove() logically assumes fm to already be in fc->mounts, which isn't the case at this point. In the root mount case, this is handled by taking back the ownership on fm, i.e. do the rollback *and* clear sb->s_fs_info. It seems that the same should be done for submounts. > Thanks, > Miklos