Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp696103pxf; Thu, 1 Apr 2021 11:07:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXcAXoWK2kI8LVLzrMAmjtGeHdqJkDruf3Zb7e1cTdHdYDQWBS5NeVYWMxGHRMOvdpMhZy X-Received: by 2002:a50:82c5:: with SMTP id 63mr11131551edg.97.1617300470366; Thu, 01 Apr 2021 11:07:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1617300470; cv=none; d=google.com; s=arc-20160816; b=tShHH/kJqHEHD9qj8OOYQdq3kP+9+5foJcd04FmydvyFq14a9L876mbROAD56Bofo5 YG/0b9FQYdXDy5zd1ZQLgpo0uMaOwV/wv6JWFBZD0naYFG3GBMQx3J3SIC2O06cZHX4e 6RALpZLOw0etN5eap2JArlB3qLXwlJV24P9W9dIRd3wfSyijQQ8B+dwl7jusH92C6b3d RsEVWVqD0MkCzaCZWD+aGjyiHTv+4Oix0y0gTmw7tUfT4BIc7Y02hzi9bEnqjWJjk8F8 BzoN1RPBX8Iuub2Tp97GH3R5xbgw2qmcl3AjleE1XahYM741ZQMBEOpsFxykKfv0Mm3A cPjA== 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=GXWPtffsDMR9QZWl6Ce2ebcQcVpDYm8f+5vNo4wn+Z8=; b=BBDQRz1ZuP9E3n26IGDY5kr57vdhOmumYzoO7N/6nBCS02YbcWmXgC99WtvYUNVaxo 25kOfadrrGLDtE/2DTPd+BR1LMqPVVXjJLCnFE+yPgAb30a4Il+rmyNI9TEpg54rq+ax XnwTaxmfuqPcxidjhaczbFJE0QZ/2iTRyzTBMpFHLXDR1HjNjTo3uGPnXHnXeZ84F/2a gApdW86jDag2J4pkWrYx866pltsjD4ZuiQNoUzJrZyAKONNQNVdpFEbTbH66srNZiSmT ty4xawzB0rMbjFEkBtj3UMgd3f2qQT/hoBVv1Sc0bK+/ShdfafIXVoiwailiPvRyS1as BgPA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=caVGPMXD; 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 b15si4653374edz.247.2021.04.01.11.07.26; Thu, 01 Apr 2021 11:07:50 -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=caVGPMXD; 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 S234521AbhDASGg (ORCPT + 99 others); Thu, 1 Apr 2021 14:06:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:43857 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237199AbhDARvB (ORCPT ); Thu, 1 Apr 2021 13:51:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617299461; 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=GXWPtffsDMR9QZWl6Ce2ebcQcVpDYm8f+5vNo4wn+Z8=; b=caVGPMXDmYWuYM5hSrjUji+pXrwlKnH4igvZkHl+5eIrK9ssMsj+vKzljhC57Rw98JwsFQ d28XfwRcJUs7Cxyvnl2ijoFJp3Q7r/5Ul0T0gUUY3Y9MCOXILSHwN9j3lsEaQaoSl2EM4P unug7Ssq+iN4p9eqODI5jExC+FwJhzA= 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-184-QwU6G8GQPR-20xv5hW3C5w-1; Thu, 01 Apr 2021 12:50:28 -0400 X-MC-Unique: QwU6G8GQPR-20xv5hW3C5w-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7070187A826; Thu, 1 Apr 2021 16:50:27 +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 C30F85D6D1; Thu, 1 Apr 2021 16:50:25 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id 683EA22054F; Thu, 1 Apr 2021 12:50:24 -0400 (EDT) Date: Thu, 1 Apr 2021 12:50:24 -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: <20210401165024.GB801967@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.15 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: > > 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. > Looks good to me. I realized that dentry leak will happen on underlying filesystem so unmount of underlying filesystem will give this warning. I created nested overlayfs configuration and could reproduce this error and tested that this patch fixes it. Reviewed-by: Vivek Goyal Vivek > 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 >