* [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction
@ 2022-12-20 11:13 fdmanana
2022-12-20 16:38 ` Sweet Tea Dorminy
2022-12-20 18:35 ` David Sterba
0 siblings, 2 replies; 3+ messages in thread
From: fdmanana @ 2022-12-20 11:13 UTC (permalink / raw)
To: linux-btrfs
From: Filipe Manana <fdmanana@suse.com>
When logging a new name, we don't expect to fail joining a log transaction
since we know at least one of the inodes was logged before in the current
transaction. However if we fail for some unexpected reason, we end up not
freeing the fscrypt name we previously allocated. So fix that by freeing
the name in case we failed to join a log transaction.
Fixes: ab3c5c18e8fa ("btrfs: setup qstr from dentrys using fscrypt helper")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
fs/btrfs/tree-log.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index a3c43f0b1c95..fb52aa060093 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -7459,8 +7459,11 @@ void btrfs_log_new_name(struct btrfs_trans_handle *trans,
* not fail, but if it does, it's not serious, just bail out and
* mark the log for a full commit.
*/
- if (WARN_ON_ONCE(ret < 0))
+ if (WARN_ON_ONCE(ret < 0)) {
+ fscrypt_free_filename(&fname);
goto out;
+ }
+
log_pinned = true;
path = btrfs_alloc_path();
--
2.35.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction
2022-12-20 11:13 [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction fdmanana
@ 2022-12-20 16:38 ` Sweet Tea Dorminy
2022-12-20 18:35 ` David Sterba
1 sibling, 0 replies; 3+ messages in thread
From: Sweet Tea Dorminy @ 2022-12-20 16:38 UTC (permalink / raw)
To: fdmanana, linux-btrfs
On 12/20/22 06:13, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> When logging a new name, we don't expect to fail joining a log transaction
> since we know at least one of the inodes was logged before in the current
> transaction. However if we fail for some unexpected reason, we end up not
> freeing the fscrypt name we previously allocated. So fix that by freeing
> the name in case we failed to join a log transaction.
>
> Fixes: ab3c5c18e8fa ("btrfs: setup qstr from dentrys using fscrypt helper")
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
I keep reexamining that change and still keep failing at finding missing
frees until they're pointed out, so particular thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction
2022-12-20 11:13 [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction fdmanana
2022-12-20 16:38 ` Sweet Tea Dorminy
@ 2022-12-20 18:35 ` David Sterba
1 sibling, 0 replies; 3+ messages in thread
From: David Sterba @ 2022-12-20 18:35 UTC (permalink / raw)
To: fdmanana; +Cc: linux-btrfs
On Tue, Dec 20, 2022 at 11:13:33AM +0000, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> When logging a new name, we don't expect to fail joining a log transaction
> since we know at least one of the inodes was logged before in the current
> transaction. However if we fail for some unexpected reason, we end up not
> freeing the fscrypt name we previously allocated. So fix that by freeing
> the name in case we failed to join a log transaction.
>
> Fixes: ab3c5c18e8fa ("btrfs: setup qstr from dentrys using fscrypt helper")
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Added to misc-next, thanks.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2022-12-20 18:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-20 11:13 [PATCH] btrfs: fix fscrypt name leak after failure to join log transaction fdmanana
2022-12-20 16:38 ` Sweet Tea Dorminy
2022-12-20 18:35 ` David Sterba
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).