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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 6463AC433ED for ; Fri, 21 May 2021 08:24:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 44E2860FD8 for ; Fri, 21 May 2021 08:24:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231484AbhEUIZW (ORCPT ); Fri, 21 May 2021 04:25:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231307AbhEUIZW (ORCPT ); Fri, 21 May 2021 04:25:22 -0400 Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4FB0DC061574 for ; Fri, 21 May 2021 01:23:59 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id c6so5867628uat.0 for ; Fri, 21 May 2021 01:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b2Yr50BYJU/SZ0Vl8VXunqJwvs9CbxD4iLGD7Ur9faE=; b=oYxq7lybSyekzx5UKNcYJQmHIzn5CtgBTPN8lrpzcb5zWZ0SnQeuIYxp56u/5DPupU EuaXc/H+qQETT5Z8crVwhjTbt20vCWbLWNTW/tTMiUfxPI1fiHYaoJzXvdzJ5fOxlP8m 8RWhkrwEIlfB+TcgNGR+6cj9wV6l2OiKJBKos= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b2Yr50BYJU/SZ0Vl8VXunqJwvs9CbxD4iLGD7Ur9faE=; b=e8d1bfMOV8NUffKRKjs8bdQV+mcls2eJwAtICvKe0jHa6uipoajzHBqYu9UHKGBRkn V6VWGRAdhu+MWCf6DbtwdZpt9X70MTeW3b59qkmqZnnvqGZXXNVjMayHLG63o2Lebj+I FzgjthhwVicuAQC1cLkuN1eWFg8q+DBM6bNLy1ioE7UK9zTwbJshZDzK6ye61jZ1+0c0 V5Jf1LtZMJigSttAkFVYoC0R6oZT/2lPif3cyLulwnIBTR24Y1yfJCkzCV2trj0rjEdz ws5PhzDGM1iu6JO6oIw6WV/6UbPJ5i0dCS9PyH+RXmuuVT3gv+VDfhhetXfakMgrd5h0 XTCA== X-Gm-Message-State: AOAM5324Ejq4+jUDtncF7619sVDoq1ZHQsCUwKhVM10SO8w/cYQZnJUi nuc9blYS+Zx+czT3eIW7iGTfMBFWzfVu078JkcMLKg== X-Google-Smtp-Source: ABdhPJzG3Kds4iA86PMJ9Guob8EEfcQ6yIocoDa8h42Of1c3IqeZ7+jjIj681zBzrv1pMSCio+Dk1zfQ96NWNsCehPM= X-Received: by 2002:ab0:596f:: with SMTP id o44mr9157215uad.8.1621585438503; Fri, 21 May 2021 01:23:58 -0700 (PDT) MIME-Version: 1.0 References: <20210520154654.1791183-1-groug@kaod.org> <20210520154654.1791183-2-groug@kaod.org> <20210521101523.4f276dac@bahia.lan> In-Reply-To: <20210521101523.4f276dac@bahia.lan> From: Miklos Szeredi Date: Fri, 21 May 2021 10:23:47 +0200 Message-ID: Subject: Re: [PATCH v4 1/5] fuse: Fix leak in fuse_dentry_automount() error path To: Greg Kurz 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Fri, 21 May 2021 at 10:15, Greg Kurz wrote: > > 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. Agreed. Thanks for verifying. Miklos