[PATCH AUTOSEL 6.19-5.10] jfs: Add missing set_freezable() for freezable kthread

[Sasha Levin <sashal@kernel.org>]

From: Haotian Zhang <vulab@iscas.ac.cn>

[ Upstream commit eb0cfcf265714b419cc3549895a00632e76732ae ]

The jfsIOWait() thread calls try_to_freeze() but lacks set_freezable(),
causing it to remain non-freezable by default. This prevents proper
freezing during system suspend.

Add set_freezable() to make the thread freezable as intended.

Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms the bug pattern clearly:

- **`jfs_txnmgr.c`** has TWO kthreads (`jfs_lazycommit` and `jfs_sync`)
  that both correctly call `set_freezable()` before their loops and then
  use `freezing(current)` + `try_to_freeze()`.
- **`jfs_logmgr.c`** (`jfsIOWait`) has the same `freezing(current)` +
  `try_to_freeze()` pattern but was **missing** the `set_freezable()`
  call. This is clearly a bug — the thread was intended to be freezable
  (it checks for freeze and tries to freeze) but never marked itself as
  such.

### 3. CLASSIFICATION

This is a **real bug fix**:
- The thread is intended to participate in the kernel's freeze mechanism
  (for suspend/hibernate), evidenced by the `freezing()` check and
  `try_to_freeze()` call.
- Without `set_freezable()`, the thread has `PF_NOFREEZE` set by
  default, so `freezing(current)` always returns false and
  `try_to_freeze()` is a no-op.
- This means the jfsIOWait thread **never freezes during suspend**,
  which can cause suspend failures or issues with filesystem consistency
  during suspend/resume cycles.

### 4. SCOPE AND RISK ASSESSMENT

- **Size**: Single line addition — minimal risk.
- **Scope**: Only affects the jfsIOWait kernel thread in the JFS
  filesystem.
- **Risk**: Extremely low. This is adding the exact same pattern used by
  the other two JFS kthreads. The only behavioral change is that the
  thread will now actually freeze during suspend, which was the original
  design intent.
- **Subsystem**: JFS filesystem — mature and stable. While not as widely
  used as ext4/xfs, it has real users.

### 5. USER IMPACT

Users running JFS filesystems who suspend/hibernate their systems could
be affected by the non-freezable kthread. The impact includes:
- Potential suspend/hibernate failures (the freezer may timeout waiting
  for this thread)
- Possible filesystem consistency issues if the thread continues I/O
  during suspend

### 6. STABILITY INDICATORS

- The fix follows the exact same pattern as the other two JFS kthreads
  in jfs_txnmgr.c
- Signed off by the JFS maintainer (Dave Kleikamp)
- Trivial one-line addition with clear correctness

### 7. DEPENDENCY CHECK

No dependencies. The `set_freezable()` API and the freeze framework have
existed for many kernel versions. This patch applies to any kernel that
has the JFS filesystem with the jfsIOWait thread.

### 8. CONCLUSION

This is a textbook stable backport candidate:
- **Obviously correct**: Adds the same `set_freezable()` call used by
  the other two JFS kthreads
- **Fixes a real bug**: The thread never actually freezes during suspend
  despite being designed to do so
- **Small and contained**: Single line addition
- **No new features**: Just makes existing freeze support work correctly
- **Low risk**: Cannot introduce regressions — it only enables the
  freeze behavior that was already coded but never activated
- **Affects real users**: Anyone using JFS with suspend/hibernate

**YES**

 fs/jfs/jfs_logmgr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/jfs/jfs_logmgr.c b/fs/jfs/jfs_logmgr.c
index b343c5ea11592..5b1c5da041630 100644
--- a/fs/jfs/jfs_logmgr.c
+++ b/fs/jfs/jfs_logmgr.c
@@ -2311,6 +2311,7 @@ int jfsIOWait(void *arg)
 {
 	struct lbuf *bp;
 
+	set_freezable();
 	do {
 		spin_lock_irq(&log_redrive_lock);
 		while ((bp = log_redrive_list)) {
-- 
2.51.0