[PATCH AUTOSEL 6.18] btrfs: do not free data reservation in fallback from inline due to -ENOSPC

[PATCH AUTOSEL 6.18] btrfs: do not free data reservation in fallback from inline due to -ENOSPC

[Sasha Levin]

From: Filipe Manana <fdmanana@suse.com>

[ Upstream commit f8da41de0bff9eb1d774a7253da0c9f637c4470a ]

If we fail to create an inline extent due to -ENOSPC, we will attempt to
go through the normal COW path, reserve an extent, create an ordered
extent, etc. However we were always freeing the reserved qgroup data,
which is wrong since we will use data. Fix this by freeing the reserved
qgroup data in __cow_file_range_inline() only if we are not doing the
fallback (ret is <= 0).

Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: btrfs qgroup data reservation fix

### 1. COMMIT MESSAGE ANALYSIS

The commit message clearly describes a **bug fix** for btrfs qgroup
handling:
- When inline extent creation fails due to -ENOSPC, btrfs falls back to
  the normal COW (copy-on-write) path
- The bug: qgroup data reservation was being freed unconditionally
  before return
- This is incorrect because in the fallback case (ret == 1), the data
  will still be used through the COW path
- Fix: only free the reservation when NOT doing fallback (`ret <= 0`)

The commit has strong review credentials:
- Reviewed-by: Qu Wenruo (btrfs developer)
- Reviewed-by: David Sterba (btrfs maintainer)
- Author: Filipe Manana (prolific btrfs developer)

### 2. CODE CHANGE ANALYSIS

The change is extremely minimal:

```c
- btrfs_qgroup_free_data(inode, NULL, 0, fs_info->sectorsize, NULL);
+       if (ret <= 0)
+               btrfs_qgroup_free_data(inode, NULL, 0,
fs_info->sectorsize, NULL);
```

**Technical mechanism of the bug:**
1. `__cow_file_range_inline()` attempts to create an inline extent
2. If this fails with -ENOSPC, `ret` is set to 1 (signaling fallback to
   normal COW)
3. Before the fix, `btrfs_qgroup_free_data()` was called unconditionally
   at the `out:` label
4. The COW path then executes expecting to use the reserved qgroup data
5. **Problem:** The reservation was prematurely freed, causing incorrect
   qgroup accounting

**The fix logic:**
- `ret == 0`: Success → free the reservation (inline extent doesn't
  count as data extent)
- `ret < 0`: Real error → free the reservation (operation failed)
- `ret == 1`: Fallback to COW → **preserve** the reservation (data will
  be written)

### 3. CLASSIFICATION

- **Bug fix:** YES - fixes incorrect resource accounting
- **Feature addition:** NO
- **Security:** Not directly, but could affect quota enforcement
  integrity

### 4. SCOPE AND RISK ASSESSMENT

- **Lines changed:** ~3 lines effective change
- **Files touched:** 1 (fs/btrfs/inode.c)
- **Complexity:** Very low - simple conditional addition
- **Risk:** LOW - surgical fix, doesn't change any logic paths, just
  prevents premature resource freeing

### 5. USER IMPACT

**Affected users:**
- Anyone using btrfs with qgroups enabled
- Qgroups are widely used for container quota management (e.g., Docker,
  LXC) and enterprise storage

**Consequences of the bug:**
- Incorrect qgroup space accounting
- Potential quota enforcement failures
- Possible qgroup-related warnings or errors

**Trigger condition:**
- Inline extent creation fails with ENOSPC and falls back to COW
- Not uncommon when filesystems are near capacity

### 6. STABILITY INDICATORS

- Reviewed by two btrfs developers including the maintainer
- Author (Filipe Manana) is highly experienced in btrfs
- The fix is logically straightforward and obviously correct

### 7. DEPENDENCY CHECK

The fix is self-contained. Looking at the context:
```c
} else if (ret == -ENOSPC) {
    ret = 1;
    goto out;
}
```

The return value semantics (`ret == 1` for ENOSPC fallback) already
exist in the code. This fix should apply cleanly to any stable tree
containing this function.

## STABLE KERNEL CRITERIA EVALUATION

| Criterion | Assessment |
|-----------|------------|
| Obviously correct | ✅ Logic is clear and well-documented in comment |
| Fixes real bug | ✅ Incorrect qgroup accounting |
| Important issue | ✅ Affects quota management, data integrity |
| Small and contained | ✅ 3-line change, single file |
| No new features | ✅ Just a conditional guard |
| Applies cleanly | ✅ Self-contained, no dependencies |

## CONCLUSION

This commit is an excellent candidate for stable backporting. It fixes a
real bug in btrfs qgroup data reservation handling with a minimal,
surgical change. The bug causes incorrect resource accounting when
inline extent creation fails and falls back to COW - a scenario that can
happen in normal operation when filesystems approach capacity. The fix
is obviously correct, well-reviewed by btrfs maintainers, and has zero
risk of regression.

**YES**

 fs/btrfs/inode.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 51401d586a7b6..9e8be59ea3deb 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -670,8 +670,12 @@ static noinline int __cow_file_range_inline(struct btrfs_inode *inode,
 	 * it won't count as data extent, free them directly here.
 	 * And at reserve time, it's always aligned to page size, so
 	 * just free one page here.
+	 *
+	 * If we fallback to non-inline (ret == 1) due to -ENOSPC, then we need
+	 * to keep the data reservation.
 	 */
-	btrfs_qgroup_free_data(inode, NULL, 0, fs_info->sectorsize, NULL);
+	if (ret <= 0)
+		btrfs_qgroup_free_data(inode, NULL, 0, fs_info->sectorsize, NULL);
 	btrfs_free_path(path);
 	btrfs_end_transaction(trans);
 	return ret;
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] btrfs: fix deadlock in wait_current_trans() due to ignored transaction type

[Sasha Levin]

From: Robbie Ko <robbieko@synology.com>

[ Upstream commit 5037b342825df7094a4906d1e2a9674baab50cb2 ]

When wait_current_trans() is called during start_transaction(), it
currently waits for a blocked transaction without considering whether
the given transaction type actually needs to wait for that particular
transaction state. The btrfs_blocked_trans_types[] array already defines
which transaction types should wait for which transaction states, but
this check was missing in wait_current_trans().

This can lead to a deadlock scenario involving two transactions and
pending ordered extents:

  1. Transaction A is in TRANS_STATE_COMMIT_DOING state

  2. A worker processing an ordered extent calls start_transaction()
     with TRANS_JOIN

  3. join_transaction() returns -EBUSY because Transaction A is in
     TRANS_STATE_COMMIT_DOING

  4. Transaction A moves to TRANS_STATE_UNBLOCKED and completes

  5. A new Transaction B is created (TRANS_STATE_RUNNING)

  6. The ordered extent from step 2 is added to Transaction B's
     pending ordered extents

  7. Transaction B immediately starts commit by another task and
     enters TRANS_STATE_COMMIT_START

  8. The worker finally reaches wait_current_trans(), sees Transaction B
     in TRANS_STATE_COMMIT_START (a blocked state), and waits
     unconditionally

  9. However, TRANS_JOIN should NOT wait for TRANS_STATE_COMMIT_START
     according to btrfs_blocked_trans_types[]

  10. Transaction B is waiting for pending ordered extents to complete

  11. Deadlock: Transaction B waits for ordered extent, ordered extent
      waits for Transaction B

This can be illustrated by the following call stacks:
  CPU0                              CPU1
                                    btrfs_finish_ordered_io()
                                      start_transaction(TRANS_JOIN)
                                        join_transaction()
                                          # -EBUSY (Transaction A is
                                          # TRANS_STATE_COMMIT_DOING)
  # Transaction A completes
  # Transaction B created
  # ordered extent added to
  # Transaction B's pending list
  btrfs_commit_transaction()
    # Transaction B enters
    # TRANS_STATE_COMMIT_START
    # waiting for pending ordered
    # extents
                                        wait_current_trans()
                                          # waits for Transaction B
                                          # (should not wait!)

Task bstore_kv_sync in btrfs_commit_transaction waiting for ordered
extents:

  __schedule+0x2e7/0x8a0
  schedule+0x64/0xe0
  btrfs_commit_transaction+0xbf7/0xda0 [btrfs]
  btrfs_sync_file+0x342/0x4d0 [btrfs]
  __x64_sys_fdatasync+0x4b/0x80
  do_syscall_64+0x33/0x40
  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Task kworker in wait_current_trans waiting for transaction commit:

  Workqueue: btrfs-syno_nocow btrfs_work_helper [btrfs]
  __schedule+0x2e7/0x8a0
  schedule+0x64/0xe0
  wait_current_trans+0xb0/0x110 [btrfs]
  start_transaction+0x346/0x5b0 [btrfs]
  btrfs_finish_ordered_io.isra.0+0x49b/0x9c0 [btrfs]
  btrfs_work_helper+0xe8/0x350 [btrfs]
  process_one_work+0x1d3/0x3c0
  worker_thread+0x4d/0x3e0
  kthread+0x12d/0x150
  ret_from_fork+0x1f/0x30

Fix this by passing the transaction type to wait_current_trans() and
checking btrfs_blocked_trans_types[cur_trans->state] against the given
type before deciding to wait. This ensures that transaction types which
are allowed to join during certain blocked states will not unnecessarily
wait and cause deadlocks.

Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## COMPREHENSIVE ANALYSIS

### What the Bug Is

The deadlock occurs because `wait_current_trans()` ignores the
transaction type when deciding whether to wait:

1. `join_transaction()` correctly uses
   `btrfs_blocked_trans_types[cur_trans->state] & type` to return
   `-EBUSY`
2. But `wait_current_trans()` waits **unconditionally** whenever a
   transaction is blocked

Looking at `btrfs_blocked_trans_types[]`:
- `TRANS_STATE_COMMIT_START` only blocks `__TRANS_START |
  __TRANS_ATTACH`
- `__TRANS_JOIN` is NOT blocked during `TRANS_STATE_COMMIT_START`

The deadlock: `TRANS_JOIN` from ordered extent processing waits for a
transaction in `COMMIT_START` state (which it shouldn't), while that
transaction waits for the ordered extent to complete.

### Technical Assessment

**The Fix:**
- Adds `type` parameter to `wait_current_trans()`
- Adds check: `btrfs_blocked_trans_types[cur_trans->state] & type`
- Updates 3 call sites to pass the type

**Lines of actual change**: ~6 lines of logic change
**Files changed**: 1 (fs/btrfs/transaction.c)
**Risk level**: LOW - the fix makes behavior *more restrictive* about
when to wait, aligning with already-defined semantics

### Stable Kernel Criteria Assessment

| Criterion | Assessment |
|-----------|------------|
| Obviously correct? | ✅ Yes - aligns `wait_current_trans()` with
existing `btrfs_blocked_trans_types[]` semantics |
| Fixes real bug? | ✅ Yes - deadlock with real call stacks provided |
| Important issue? | ✅ Yes - deadlock is severe (system hang, potential
data loss) |
| Small and contained? | ✅ Yes - ~6 lines logic change in one file |
| No new features? | ✅ Correct - pure bug fix |
| Dependencies in stable? | ✅ Yes - `btrfs_blocked_trans_types[]` exists
since 2013 |

### Review Quality

- Reviewed-by: Filipe Manana (btrfs maintainer)
- Reviewed-by: David Sterba (btrfs maintainer)
- Signed-off-by: David Sterba (merged by maintainer)

### User Impact

- **Severity**: HIGH - deadlock causes complete hang
- **Affected users**: btrfs users with ordered extent workloads (common
  during fsync)
- **Evidence**: Real production call stacks provided from Synology
  system

### Risk vs Benefit

**Benefits:**
- Fixes a critical deadlock in filesystem code
- Small, surgical change with minimal risk
- Uses existing, well-tested infrastructure

**Risks:**
- Very low - the change only affects waiting behavior and aligns it with
  already-existing type-specific blocking rules
- The fix is conservative: it makes the code wait *less* (only when it
  should), not more

### Conclusion

This commit fixes a **real deadlock** in btrfs transaction handling. The
fix is:
- Small and surgical
- Obviously correct (makes `wait_current_trans()` respect existing type-
  specific blocking rules)
- Well-reviewed by btrfs maintainers
- Low risk with high benefit

The `btrfs_blocked_trans_types[]` array has existed since 2013, ensuring
clean backporting to all stable kernels. This is exactly the type of
commit that should be backported - a critical deadlock fix with minimal
risk.

**YES**

 fs/btrfs/transaction.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 89ae0c7a610aa..c457316c2788b 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -518,13 +518,14 @@ static inline int is_transaction_blocked(struct btrfs_transaction *trans)
  * when this is done, it is safe to start a new transaction, but the current
  * transaction might not be fully on disk.
  */
-static void wait_current_trans(struct btrfs_fs_info *fs_info)
+static void wait_current_trans(struct btrfs_fs_info *fs_info, unsigned int type)
 {
 	struct btrfs_transaction *cur_trans;
 
 	spin_lock(&fs_info->trans_lock);
 	cur_trans = fs_info->running_transaction;
-	if (cur_trans && is_transaction_blocked(cur_trans)) {
+	if (cur_trans && is_transaction_blocked(cur_trans) &&
+	    (btrfs_blocked_trans_types[cur_trans->state] & type)) {
 		refcount_inc(&cur_trans->use_count);
 		spin_unlock(&fs_info->trans_lock);
 
@@ -699,12 +700,12 @@ start_transaction(struct btrfs_root *root, unsigned int num_items,
 		sb_start_intwrite(fs_info->sb);
 
 	if (may_wait_transaction(fs_info, type))
-		wait_current_trans(fs_info);
+		wait_current_trans(fs_info, type);
 
 	do {
 		ret = join_transaction(fs_info, type);
 		if (ret == -EBUSY) {
-			wait_current_trans(fs_info);
+			wait_current_trans(fs_info, type);
 			if (unlikely(type == TRANS_ATTACH ||
 				     type == TRANS_JOIN_NOSTART))
 				ret = -ENOENT;
@@ -1001,7 +1002,7 @@ int btrfs_wait_for_commit(struct btrfs_fs_info *fs_info, u64 transid)
 
 void btrfs_throttle(struct btrfs_fs_info *fs_info)
 {
-	wait_current_trans(fs_info);
+	wait_current_trans(fs_info, TRANS_START);
 }
 
 bool btrfs_should_end_transaction(struct btrfs_trans_handle *trans)
-- 
2.51.0

[PATCH AUTOSEL 6.18-6.1] btrfs: fix reservation leak in some error paths when inserting inline extent

[Sasha Levin]

From: Filipe Manana <fdmanana@suse.com>

[ Upstream commit c1c050f92d8f6aac4e17f7f2230160794fceef0c ]

If we fail to allocate a path or join a transaction, we return from
__cow_file_range_inline() without freeing the reserved qgroup data,
resulting in a leak. Fix this by ensuring we call btrfs_qgroup_free_data()
in such cases.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Commit Analysis: btrfs: fix reservation leak in some error paths when
inserting inline extent

### 1. COMMIT MESSAGE ANALYSIS

The subject clearly indicates a **bug fix** for a "reservation leak" in
error paths. The body explains:
- When `btrfs_alloc_path()` fails or `btrfs_join_transaction()` fails,
  the function returned early
- The reserved qgroup data was never freed in these error paths
- This results in a resource leak

**Tags**: Reviewed-by and Signed-off-by from David Sterba (btrfs
maintainer), authored by Filipe Manana (experienced btrfs developer).
Excellent review coverage.

### 2. CODE CHANGE ANALYSIS

**The Bug (Before):**
```c
path = btrfs_alloc_path();
if (!path)
    return -ENOMEM;  // Early return - leaks qgroup reservation

trans = btrfs_join_transaction(root);
if (IS_ERR(trans)) {
    btrfs_free_path(path);
    return PTR_ERR(trans);  // Early return - leaks qgroup reservation
}
```

**The Fix (After):**
```c
path = btrfs_alloc_path();
if (!path) {
    ret = -ENOMEM;
    goto out;  // Goes to cleanup that calls btrfs_qgroup_free_data()
}

trans = btrfs_join_transaction(root);
if (IS_ERR(trans)) {
    ret = PTR_ERR(trans);
    trans = NULL;
    goto out;  // Goes to cleanup that calls btrfs_qgroup_free_data()
}
```

Additional changes:
- Initialize `trans = NULL` at declaration
- Add NULL check before `btrfs_end_transaction(trans)` in cleanup

**Root cause**: Early returns bypassed the `out` label where
`btrfs_qgroup_free_data()` is called for error cases (`ret <= 0`).

**Why the fix works**: Redirects error paths to use `goto out`, ensuring
all exits pass through existing cleanup logic.

### 3. CLASSIFICATION

- **Type**: Bug fix (resource leak)
- **Category**: Error handling fix in filesystem code
- **Not a feature addition**: Pure cleanup path fix

### 4. SCOPE AND RISK ASSESSMENT

- **Size**: ~20 lines changed in a single file (`fs/btrfs/inode.c`)
- **Scope**: Single function `__cow_file_range_inline()`
- **Complexity**: Very low - simple control flow change (early return →
  goto)
- **Risk**: Very low
  - Uses existing cleanup logic already tested for other error paths
  - The NULL check on `trans` is a proper safeguard
  - No algorithm changes, no new logic

### 5. USER IMPACT

- **Affected users**: btrfs users with qgroups enabled
- **Trigger conditions**: ENOMEM or transaction join failure during
  inline extent insertion
- **Severity**: Resource leak that accumulates over time, can cause
  incorrect qgroup accounting
- **Frequency**: Error conditions are rare, but when they occur, the
  leak is guaranteed

### 6. STABILITY INDICATORS

- Authored by Filipe Manana (prolific btrfs contributor)
- Reviewed by David Sterba (btrfs maintainer)
- Signed-off by David Sterba

### 7. DEPENDENCY CHECK

- Self-contained fix
- No dependencies on other commits
- The affected function and `btrfs_qgroup_free_data()` exist in stable
  trees
- The code structure is stable and not recently added

## Conclusion

This commit is an **ideal stable candidate**:

1. **Obviously correct**: Simple redirection of error paths to existing
   cleanup code
2. **Fixes a real bug**: Qgroup data reservation leak that can
   accumulate over time
3. **Small and contained**: ~20 lines, one file, one function
4. **No new features**: Pure bug fix
5. **Well-reviewed**: By btrfs maintainers
6. **Low risk**: Uses existing cleanup logic, minimal code change
7. **Important for users**: Btrfs with qgroups is a common configuration

The fix is surgical, low-risk, and addresses a genuine resource leak in
the btrfs filesystem. It meets all stable kernel criteria.

**YES**

 fs/btrfs/inode.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 9e8be59ea3deb..0d61e0ee2f86f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -614,19 +614,22 @@ static noinline int __cow_file_range_inline(struct btrfs_inode *inode,
 	struct btrfs_drop_extents_args drop_args = { 0 };
 	struct btrfs_root *root = inode->root;
 	struct btrfs_fs_info *fs_info = root->fs_info;
-	struct btrfs_trans_handle *trans;
+	struct btrfs_trans_handle *trans = NULL;
 	u64 data_len = (compressed_size ?: size);
 	int ret;
 	struct btrfs_path *path;
 
 	path = btrfs_alloc_path();
-	if (!path)
-		return -ENOMEM;
+	if (!path) {
+		ret = -ENOMEM;
+		goto out;
+	}
 
 	trans = btrfs_join_transaction(root);
 	if (IS_ERR(trans)) {
-		btrfs_free_path(path);
-		return PTR_ERR(trans);
+		ret = PTR_ERR(trans);
+		trans = NULL;
+		goto out;
 	}
 	trans->block_rsv = &inode->block_rsv;
 
@@ -677,7 +680,8 @@ static noinline int __cow_file_range_inline(struct btrfs_inode *inode,
 	if (ret <= 0)
 		btrfs_qgroup_free_data(inode, NULL, 0, fs_info->sectorsize, NULL);
 	btrfs_free_path(path);
-	btrfs_end_transaction(trans);
+	if (trans)
+		btrfs_end_transaction(trans);
 	return ret;
 }
 
-- 
2.51.0

[PATCH AUTOSEL 6.18-5.10] btrfs: fix deadlock in wait_current_trans() due to ignored transaction type

[Motiejus Jakštys]

Dear stable maintainers,

I was about to submit to stable@, but found this earlier email autosel.
However, I don't see it in the queue. What's the right process to get it
included to stable?

This specific patch fixes a production issue: we saw this happening at
least 3 times (across a few thousand servers over the past 4 months
we've moved to btrfs); the last time I was able to capture a kernel
stack trace, which was identical to the one in the patch.

Thanks,
Motiejus

Re: [PATCH AUTOSEL 6.18-5.10] btrfs: fix deadlock in wait_current_trans() due to ignored transaction type

[Greg KH]

On Mon, Jan 19, 2026 at 01:46:26PM +0200, Motiejus Jakštys wrote:
> Dear stable maintainers,
> 
> I was about to submit to stable@, but found this earlier email autosel.
> However, I don't see it in the queue. What's the right process to get it
> included to stable?

You can submit it now if you wish to see it merged at this point in
time.

thanks,

greg k-h