From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [62.89.141.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEC5219BBA for ; Thu, 9 Jan 2025 06:22:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.89.141.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736403743; cv=none; b=du1duvRlo7ZykKYjVSHFSSlqHtdLrurG7RS+vIiyODCmhNSbVUivtrWPcOjs4MOsVfvikeLt618rnpDi3PRysBaIAjX2Mw0ElOQf/Ab8g62Yv1bHbDGetFz3Dp0xhs7Ot/KgalVu9lkAz3CTWYhSuCqcb4HxQ1yeaFnZYGjxm2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736403743; c=relaxed/simple; bh=Ac3j+nn3ylhmWG6TVKNzSNO8b0MP0M9lql1bY4L0rCo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=awPdLQ6lCTus66n/McXM+hkWKOehT7pWlAKMCRvbCM57a99uS0FXwCX+z/gtBRT0UzmEK4LYksBnxlapKSx4q8Dzm/QcUEqGzVaBczQCQ57xnwy9DvBOKEhWhzDFB841yFZ3rONdxnlBV4FyXXEwGlSfLRQHS81AR9EHGkK3t7I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk; spf=none smtp.mailfrom=ftp.linux.org.uk; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b=PPz9GDgn; arc=none smtp.client-ip=62.89.141.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=ftp.linux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linux.org.uk header.i=@linux.org.uk header.b="PPz9GDgn" 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=836AVmqdf+LDF83ptPKnmYJ+oI663ZXSEv887hmJ7ik=; b=PPz9GDgn2RdvL/bzGoUL1gRZGD vVEfhf1fst6rUZKF4VLaDNTjjUdJX9UfN/BowUjGvKcwICd+nvi9DP7YifkJ/Dq6DeHoj48ufCKsO xhSAtp1434TLQyJ1jhcwDbq9QlYZ1+g3tjSFC1+tqDnKYdvE29M0I72ger3BBkKT9TKpBlla8GjO7 LPqelygjYe8ukSnPHjr+YkV2IHOoxoQyvkgz7NnzBk+qOJd2kGghMXPhX/Fplg/1vUFj7YnESTSLG bieuBcjxIqioyfieR1RcDJQ+OF/6/FZeRTovxt2qtPLAPie93rlingZ/gZLqK+E3uNNCHvvHOHDvU BQ+KCEug==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.98 #2 (Red Hat Linux)) id 1tVlvs-0000000H8ah-2AoR; Thu, 09 Jan 2025 06:22:16 +0000 Date: Thu, 9 Jan 2025 06:22:16 +0000 From: Al Viro To: Lizhi Xu Cc: syzbot+80e60df48923e1b7691d@syzkaller.appspotmail.com, aivazian.tigran@gmail.com, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com Subject: Re: [PATCH] bfs: put a inode if link count is 0 Message-ID: <20250109062216.GQ1977892@ZenIV> References: <6776b5fb.050a0220.3a8527.0043.GAE@google.com> <20250109034946.1386748-1-lizhi.xu@windriver.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250109034946.1386748-1-lizhi.xu@windriver.com> Sender: Al Viro On Thu, Jan 09, 2025 at 11:49:46AM +0800, Lizhi Xu wrote: > > The reproducer performs the rename operation on the file twice in succession > and changes the file to the same file name. After the first rename operation, > the number of links in the inode is set to 0. In the second execution, the > same inode is used, resulting in a 0 value warning for i_nlink. > > To avoid this issue, put the target inode before exiting the bfs_rename. This is completely insane - you get an extra drop of in-core inode refcount, which *will* end up with dangling pointer and memory corruption. Besides, there is a perfectly legitimate case when you open a file and rename something on top of it. It MUST remain open and alive until the last in-core reference to inode goes away, which must not happen before close(). Frankly, if you do not understand why that is wrong, you should not mess with anything filesystem-related until you learn the area enough. NAK.