linux-kernel - 回复: [PATCH 1/3] btrfs: get rid of path allocation in btrfs_del_inode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <SEZPR06MB5269D8348566FC049107053FE8BC2@SEZPR06MB5269.apcprd06.prod.outlook.com>
Date: Thu, 17 Apr 2025 14:15:17 +0000
From: 李扬韬 <frank.li@...o.com>
To: Filipe Manana <fdmanana@...nel.org>, "dsterba@...e.cz" <dsterba@...e.cz>
CC: Sun YangKai <sunk67188@...il.com>, "clm@...com" <clm@...com>,
	"dsterba@...e.com" <dsterba@...e.com>, "josef@...icpanda.com"
	<josef@...icpanda.com>, "linux-btrfs@...r.kernel.org"
	<linux-btrfs@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "neelx@...e.com" <neelx@...e.com>
Subject:
 回复: [PATCH 1/3] btrfs: get rid of path allocation in btrfs_del_inode_extref()

> Honestly I don't like adding yet another function to do such "reset" thing.
>
> Leaving path->skip_release_on_error is perfectly fine in this scenario.
> If that bothers anyone so much, just set path->skip_release_on_error to 0 after calling btrfs_release_path() and before passing the path to btrfs_insert_inode_extref().
>
> This is the sort of optimization that is not worth spending this much time and adding new APIs - freeing and allocating a path shortly after is almost always fast as we're using a slab, plus this is a rarely hit use case - having to use extrefs, meaning we have a very large number of inode refs.

I am fine to add btrfs_reset_path or just clear path->skip_release_on_error.

David, what do you think?

Thx,
Yangtao