From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 43AF229ACF6 for ; Wed, 22 Apr 2026 18:19:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776881957; cv=none; b=cdKSApKRkAKR82OXFKQJUspgEEck2uvZGTR3nBAIepHFTFrNBEtvSTb/b3k3ky88dYUNruA/bUCINsyjpwMXL1F/phJnSSVxLKxuU/DClkt4nJP9iDkw99skpfC10SViDQ6HYklde6WQ7qH0kFe3XZGxQjm5tPQG6rOmO9tCBok= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776881957; c=relaxed/simple; bh=yg0aZU4ZgB3Ms/fU0AljMIkWk9fNOyv4/FX4qzwrF/E=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=RFOHjaCLsd1u8VLReaweHS+N+0Ov8w7itoWe+/YFauwLHMU/x9gKD2quJOglOmO/YIfahqTew4qWB2Da89+HidCj0aw/LSqkEuYTbYJ1sj9soUlKLtaafu6qiKPpKpV88i/6fd+NdezjaCxmwZ05ZlPUP/L8X7wj51XUiw8Gm8I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BJb+DI1L; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=giwJ05CT; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="BJb+DI1L"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="giwJ05CT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1776881955; 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=wwU+V0ShYDgZN9VQw7mFGwyGa9GtIvXJwbt6oc94MqI=; b=BJb+DI1L1lr/sKC3NFLfVse3en1nrEzITGi778YN9VC6uw9WDRGSQ2CfkEQh5TSLhKI7Zq Nfbfm54It39EEYiAfBY3f18i8P5Ztaw0Gky0XtYSZcwaUHZGhdEVanx8gSK+Pt/AYtWVYK XuttdUNZeP4DUZJK4CsQbzUwkeQrzCE= Received: from mail-ot1-f71.google.com (mail-ot1-f71.google.com [209.85.210.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-443-D1NlkpwrN-uqCvHiG2K_Iw-1; Wed, 22 Apr 2026 14:19:14 -0400 X-MC-Unique: D1NlkpwrN-uqCvHiG2K_Iw-1 X-Mimecast-MFC-AGG-ID: D1NlkpwrN-uqCvHiG2K_Iw_1776881953 Received: by mail-ot1-f71.google.com with SMTP id 46e09a7af769-7dbc09d4e43so12923628a34.1 for ; Wed, 22 Apr 2026 11:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1776881953; x=1777486753; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=wwU+V0ShYDgZN9VQw7mFGwyGa9GtIvXJwbt6oc94MqI=; b=giwJ05CTXeQ+6Lvdoj0jCKRZ6g8SoL1Kw2LVsiJ2cBgvl5iPD4jW0MPATx4dgFKxBH 1DUz//xxEKU93zODQGO8QlIBpsjyy/tSXYh5gL4FTOC+roRFFwblIFDqoAXsBSm4u1dQ /sOZdDZEYZwrcB3A8+lM/o9u2MviNRuvCys3QC7Q1QjjVRN+1YwRHDQ86vP6sE++H6dg 3PfX2LyIMdvWTy+knzCKMKpuC0dudNm/MxEtvvL6wuE3scUXOV9jbM5dmtibM830uIDq MLJO1vFHf++Gk/E08FJiIZy3F9Fuw1QTijeKUO9jiBxU2r9w4YyH5yCv5IvhmTwA5ygI v09w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776881953; x=1777486753; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wwU+V0ShYDgZN9VQw7mFGwyGa9GtIvXJwbt6oc94MqI=; b=NKjWef4oiWJXceRUqt/SwLUvmqJhiQKQTyjD+DE7ANYjV6FJHEssjtP2JJZBg2PQzP UtX3Ya/CKrqS1KBUnwblFlp/SSomKW5o634a7LqJcTcbz6HLVVT0VdTu2wNcBbH1ii2N +qDmEKERe7FH58XHCHk7VXcLhyU6/O4WyUS7LjueZ9SgcBwOFwTNKSTs/U4KOqgDzgcS /8d1xdURTWJ+5sdeLCgycDf6iqBnOuDH5pfERpsKqJAst1J2A0htY0j5mZvoX+cRR5D3 fAOGzjoOz62w/gEBL4mxf2FfBz4n83afz4YG/TII51fW9mX/aUrhzFqab8gUKmujXYWG UQcQ== X-Forwarded-Encrypted: i=1; AFNElJ8klc47aE7eNsSwRRC9st9w6nEOscmO81KRTwLryExdJavpR30N/RguSGa9F9ZVDu9LpgHDVw3A9MMboRc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw1YDSOUrCv2MMtWLkyfjzLxO0X0KTEiajwBpsCs7cLKs1JVx1T GPko8CU4g5P/N+kxooWR3hiq7/B/S2Q3zamjGVgsjSe/CA4qpESvOCm3WWuHoplv6Y08iSUXf3m CJpVCRT5sJKzHExr8Axd+GO14gvVNWO7aHP0rc50/vvbqXh82Jr2kgFGhi1HKKVe3N09zVbHlTw == X-Gm-Gg: AeBDiev7ueHxWj1U8MDyZ1Yk7Z7D3a6neHix7ThKwBSSCQMcSqMSNucgukSkjqx5Agl dl0c9hnpBIZ+VUr8P5YLFUSX1SwzEv1JD2VxH3ttYG6VM8sQXzKb+2qMYcktVfCxUQRNKicikFU p/oZf+erGfsR+ifAYlxpQMtXNx1YHsHhNsFwijpaHohU1dos5DTQjFlVdHTWEvwebyb99shIAto Nxpmyw37FbaNH+KC5agQGKV6zmFeJJ3Yi9R+IwFCnae+zMkUbIv8k58p9ErNmYXB7KKtwAxYAg1 Gtkq1ZSGoB4zT8D7VeDwC4/W6A1KRCKRu+9Kq5BJdrwaE5dT62BOYiVwm5G6383C/3VMaEhXE4U Azo8u1qZZUO96hsx7LFc1eDevRkKGNEFRCaof7gQVmNn4+UTUp6pBrWuWOre+fVc= X-Received: by 2002:a9d:7155:0:b0:7dc:e43f:4b31 with SMTP id 46e09a7af769-7dce43f602fmr2227420a34.12.1776881953026; Wed, 22 Apr 2026 11:19:13 -0700 (PDT) X-Received: by 2002:a9d:7155:0:b0:7dc:e43f:4b31 with SMTP id 46e09a7af769-7dce43f602fmr2227400a34.12.1776881952535; Wed, 22 Apr 2026 11:19:12 -0700 (PDT) Received: from li-4c4c4544-0032-4210-804c-c3c04f423534.ibm.com ([2600:1700:6476:1430::29]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7dc975b0591sm14423408a34.19.2026.04.22.11.19.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Apr 2026 11:19:12 -0700 (PDT) Message-ID: <39b283f4e3fe75a8b9ee324e5906c6635aafed40.camel@redhat.com> Subject: Re: [PATCH] hfsplus: Supports freeing newly created tree head From: Viacheslav Dubeyko To: Edward Adam Davis Cc: frank.li@vivo.com, glaubitz@physik.fu-berlin.de, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, slava@dubeyko.com, syzbot+98547b0428b6a6a3467c@syzkaller.appspotmail.com, syzkaller-bugs@googlegroups.com Date: Wed, 22 Apr 2026 11:19:10 -0700 In-Reply-To: References: <60605973b66496b04c6847ceb6fa46dfada6a628.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43app2) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Sat, 2026-04-18 at 17:37 +0800, Edward Adam Davis wrote: > On Fri, 17 Apr 2026 15:03:17 -0700, Viacheslav Dubeyko wrote: > > > hfs_bnode_put() does not support deallocating a newly created btree > > > head node; therefore, regardless of whether hfsplus_bnode_find() succ= eeds > > > or fails, it cannot effectively reclaim the memory allocated for a ne= wly > > > created head node. > > >=20 > > > When finding a head node, if the node is a newly created one, we can = use > > > hfs_bnode_free() to reclaim its memory. > > >=20 > > > [1] > > > BUG: memory leak > > > unreferenced object 0xffff88811cabc840 (size 96): > > > backtrace (crc 3e2dadb7): > > > __hfs_bnode_create+0x59/0x310 fs/hfsplus/bnode.c:469 > > > hfsplus_bnode_find+0x13e/0x580 fs/hfsplus/bnode.c:547 > > > hfsplus_btree_open+0x2fa/0x6d0 fs/hfsplus/btree.c:382 > > > hfsplus_fill_super+0x272/0x880 fs/hfsplus/super.c:548 > >=20 > > I need slightly more detailed and clear explanation how the issue has b= een > > happened and why we need to fix it in a such way. Currently, I don't ha= ve the > > complete picture how this happened. I am sure that you have the complet= e > > picture. :) Could you please share what you have in your mind? :) Don't= hide the > > wisdom. ;) > fc_mount() > vfs_get_tree() > get_tree_bdev_flags() > hfsplus_fill_super()=20 We have multiple calls of hfsplus_btree_open(). Which particular b-tree do = you mean here? > hfsplus_btree_open()=20 I assume that you mean hfs_btree_open(). > hfsplus_bnode_find(tree, HFSPLUS_TREE_HEAD) >=20 We call hfs_bnode_find() here. > =20 > __hfs_bnode_create() > ... > node->this =3D cnid; // cnid is HFSPLUS_TREE_HEAD, it is 0 > ... > ... > desc =3D (struct hfs_bnode_desc *)(kmap_local_page(node->page[0]) > node->type =3D desc->type; > switch (node->type) { > ... > default: // because node->type is 127, so run here > goto node_error; I think, maybe, we need to add some error message(s) when some error is happened. What do you think? > ... > hfs_bnode_put() > ... > if (test_bit(HFS_BNODE_DELETED, &node->flags)) { /* head node not set= HFS_BNODE_DELETED flag > * so, the node will never be freed. > * Furthermore, even if the node were marked > * with the HFS_BNODE_DELETED flag, hfs_bmap_free() > * would still trigger BUG_ON(!node->this). > */ node_error: set_bit(HFS_BNODE_ERROR, &node->flags); - clear_bit(HFS_BNODE_NEW, &node->flags); - wake_up(&node->lock_wq); + if (num !=3D HFSPLUS_TREE_HEAD) { Why do we need to distinguish is it HFSPLUS_TREE_HEAD or not? I don't see a= ny difference in node processing. + clear_bit(HFS_BNODE_NEW, &node->flags); I think that we don't need to clear the HFS_BNODE_NEW. Because, we need to analyze HFS_BNODE_ERROR in hfs_bnode_put(). + wake_up(&node->lock_wq); I assume that wake_up() should be called anyway. Why have you removed this = call for HFSPLUS_TREE_HEAD case? + } hfs_bnode_put(node); return ERR_PTR(-EIO); @@ -694,6 +698,10 @@ void hfs_bnode_put(struct hfs_bnode *node) hfs_bnode_free(node); return; } + if (test_bit(HFS_BNODE_NEW, &node->flags)) { I suggest to analyze HFS_BNODE_ERROR here. + hfs_bnode_unhash(node); + hfs_bnode_free(node); + } @@ -598,14 +598,18 @@ struct hfs_bnode *hfs_bnode_find(struct hfs_btree *tr= ee, u32 num) if (key_size >=3D entry_size || key_size & 1) goto node_error; } - clear_bit(HFS_BNODE_NEW, &node->flags); - wake_up(&node->lock_wq); + if (num !=3D HFSPLUS_TREE_HEAD) { + clear_bit(HFS_BNODE_NEW, &node->flags); + wake_up(&node->lock_wq); What the point in this code? Why have you change the logic here? + } return node; And, could you please add these new details into the commit message? Thanks, Slava.