Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp704649pxf; Thu, 1 Apr 2021 11:19:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJydK0uzRmqAwN2+moIEzJQB9rQ5siAu4moVAq/QUSM9EiEzBWOTb7R3SDZro1fQ2SMTtHZp X-Received: by 2002:a17:906:71d3:: with SMTP id i19mr10661416ejk.347.1617301183509; Thu, 01 Apr 2021 11:19:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617301183; cv=none; d=google.com; s=arc-20160816; b=0o1BZF8tUmjL90m3pR7YnGKVuI/cVF5CSyTHZ8eboM+v9BlWTcTharh3n5Q0XOtFpS PZ8L/ZnBBsms+3Y/JLkfbZiSEdo3dUWygDWCPOtzhQQ6qQ//zQe6tXR5gVYh7f4MPGs7 7aARHT5FXSUWJQOAZIkJB82cVkX56aJ6AE7D44yiFS8QYur3sSxsU980C8TxSW8f334W K3t8RzZy8CIIusQci4GwbN0CIeQmd0X4MjnXoJMqnU5tWYvHCYRS06AIQGTrpGs/Uquq eCVmM5v7is6DEq156rq3LQHMNatFkd4u4J5Gl9VuT3XfL0fNUFmAqaj9d0fjE5ks2kuu kd1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=DZ5o8xyhoYGjZMwbZbuoSG15PY6aGXxwCTwzusxwEpc=; b=MR6ZnWCQ7FPj0kjon4hY29RZ6gPtJWcDAOQGG7vsQax38tO3I3xy5r9keNVRmzpBP4 Cszm6XHBQxJlbF79ZkfuCH2U6LhFNqs5Rjn16l7GX3cG6M+ADCjFwLgtxTVU7SCKQdrL r0o453lIc0xCCm0zF+MeSGlzcodZKYaaqR/RZkHyiYTlWoaZTl9oo0pwac8R6Arz8oM6 zGOhDrYHUa5aavggOeiE3TJ5R5pLUS10A4lREyLexwalT4X/yfU97s4HleLppEMNT6P7 Mw+zdTryguBSeumIOPDRdNyu7KcPmwnXSnIbBguejJm3Lo0m18HX6niYw/esCvJLe1c9 jFfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QGxIDx0w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z25si4924664ejw.647.2021.04.01.11.19.20; Thu, 01 Apr 2021 11:19:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=QGxIDx0w; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237009AbhDASSy (ORCPT + 99 others); Thu, 1 Apr 2021 14:18:54 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:23268 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237519AbhDASAR (ORCPT ); Thu, 1 Apr 2021 14:00:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617300016; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DZ5o8xyhoYGjZMwbZbuoSG15PY6aGXxwCTwzusxwEpc=; b=QGxIDx0wO+uOYhYaGHD1ebbtraUSs30PE3EzB+JeubT4+AxrqqiTzBvRuBhsLupMlbuxHm oUHVJhZX71h+dKDyno7Ot2/FI+EYbdXRixh6mU4QbocMk9HvWIkwBTadJy77WL19bUPjea 2fu4PIQRC1j/uyXpmQKZM42PGxIU5Zw= 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-61-YVQssqzYNSmnqpfwZ9mZUA-1; Thu, 01 Apr 2021 11:58:19 -0400 X-MC-Unique: YVQssqzYNSmnqpfwZ9mZUA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5909C1966324; Thu, 1 Apr 2021 15:58:15 +0000 (UTC) Received: from horse.redhat.com (ovpn-113-97.rdu2.redhat.com [10.10.113.97]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4687B5DDAD; Thu, 1 Apr 2021 15:58:14 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id D9BD222054F; Thu, 1 Apr 2021 11:58:13 -0400 (EDT) Date: Thu, 1 Apr 2021 11:58:13 -0400 From: Vivek Goyal To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-unionfs@vger.kernel.org, Amir Goldstein , stable@vger.kernel.org, syzbot , =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= Subject: Re: [PATCH v1] ovl: Fix leaked dentry Message-ID: <20210401155813.GA801967@redhat.com> References: <20210329164907.2133175-1-mic@digikod.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210329164907.2133175-1-mic@digikod.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 29, 2021 at 06:49:07PM +0200, Micka?l Sala?n wrote: > From: Micka?l Sala?n > > Since commit 6815f479ca90 ("ovl: use only uppermetacopy state in > ovl_lookup()"), overlayfs doesn't put temporary dentry when there is a > metacopy error, which leads to dentry leaks when shutting down the > related superblock: > Hi, Thanks for finding and fixing this bug. Patch looks correct to me. We need to drop that reference to this. I am not able to trigger this warning on umount of overlayfs. I copied up a file with metacopy enabled and then remounted overlay again with metacopy disabled. That does hit this code and I see the warning. refusing to follow metacopy origin for (/foo.txt) This should have lead to leak of dentry pointed by "this". But after that I unmounted, overlay and that succeeds. Is there any additional step to be done to trigger this VFS warning. Vivek > overlayfs: refusing to follow metacopy origin for (/file0) > ... > BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] > ... > WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d > CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 > ... > RIP: 0010:umount_check.cold+0x107/0x14d > ... > Call Trace: > d_walk+0x28c/0x950 > ? dentry_lru_isolate+0x2b0/0x2b0 > ? __kasan_slab_free+0x12/0x20 > do_one_tree+0x33/0x60 > shrink_dcache_for_umount+0x78/0x1d0 > generic_shutdown_super+0x70/0x440 > kill_anon_super+0x3e/0x70 > deactivate_locked_super+0xc4/0x160 > deactivate_super+0xfa/0x140 > cleanup_mnt+0x22e/0x370 > __cleanup_mnt+0x1a/0x30 > task_work_run+0x139/0x210 > do_exit+0xb0c/0x2820 > ? __kasan_check_read+0x1d/0x30 > ? find_held_lock+0x35/0x160 > ? lock_release+0x1b6/0x660 > ? mm_update_next_owner+0xa20/0xa20 > ? reacquire_held_locks+0x3f0/0x3f0 > ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 > do_group_exit+0x135/0x380 > __do_sys_exit_group.isra.0+0x20/0x20 > __x64_sys_exit_group+0x3c/0x50 > do_syscall_64+0x45/0x70 > entry_SYSCALL_64_after_hwframe+0x44/0xae > ... > VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day... > > This fix has been tested with a syzkaller reproducer. > > Cc: Amir Goldstein > Cc: Miklos Szeredi > Cc: Vivek Goyal > Cc: # v5.7+ > Reported-by: syzbot > Fixes: 6815f479ca90 ("ovl: use only uppermetacopy state in ovl_lookup()") > Signed-off-by: Micka?l Sala?n > Link: https://lore.kernel.org/r/20210329164907.2133175-1-mic@digikod.net > --- > fs/overlayfs/namei.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/overlayfs/namei.c b/fs/overlayfs/namei.c > index 3fe05fb5d145..424c594afd79 100644 > --- a/fs/overlayfs/namei.c > +++ b/fs/overlayfs/namei.c > @@ -921,6 +921,7 @@ struct dentry *ovl_lookup(struct inode *dir, struct dentry *dentry, > if ((uppermetacopy || d.metacopy) && !ofs->config.metacopy) { > err = -EPERM; > pr_warn_ratelimited("refusing to follow metacopy origin for (%pd2)\n", dentry); > + dput(this); > goto out_put; > } > > > base-commit: a5e13c6df0e41702d2b2c77c8ad41677ebb065b3 > -- > 2.30.2 >