[PATCH AUTOSEL 6.19-5.10] wifi: iwlegacy: add missing mutex protection in il3945_store_measurement()

[Sasha Levin <sashal@kernel.org>]

From: Ziyi Guo <n7l8m4@u.northwestern.edu>

[ Upstream commit 4dd1dda65265ecbc9f43ffc08e333684cf715152 ]

il3945_store_measurement() calls il3945_get_measurement() which internally
calls il_send_cmd_sync() without holding il->mutex. However,
il_send_cmd_sync() has lockdep_assert_held(&il->mutex) indicating that
callers must hold this lock.

Other sysfs store functions in the same file properly acquire the mutex:
- il3945_store_flags() acquires mutex at 3945-mac.c:3110
- il3945_store_filter_flags() acquires mutex at 3945-mac.c:3144

Add mutex_lock()/mutex_unlock() around the il3945_get_measurement() call
in the sysfs store function to fix the missing lock protection.

Signed-off-by: Ziyi Guo <n7l8m4@u.northwestern.edu>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
Link: https://patch.msgid.link/20260125193005.1090429-1-n7l8m4@u.northwestern.edu
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Analysis

### Commit Message Analysis

The commit message is clear and well-documented. It identifies:
- **The bug**: `il3945_store_measurement()` calls
  `il3945_get_measurement()` → `il_send_cmd_sync()` without holding
  `il->mutex`
- **The evidence**: `il_send_cmd_sync()` has
  `lockdep_assert_held(&il->mutex)`, meaning this will trigger a lockdep
  warning at runtime
- **The pattern**: Other sysfs store functions in the same file
  (`il3945_store_flags()`, `il3945_store_filter_flags()`) already
  properly acquire the mutex
- **The fix**: Add `mutex_lock()`/`mutex_unlock()` around the call

### Code Change Analysis

The diff is minimal — only 2 lines added:
```c
mutex_lock(&il->mutex);
il3945_get_measurement(il, &params, type);
mutex_unlock(&il->mutex);
```

This is a textbook missing-lock fix. The function is a sysfs store
handler (called from userspace via writing to a sysfs file), which calls
into the driver's command submission path without the required
synchronization.

**Bug mechanism**: Without the mutex, concurrent access to
`il_send_cmd_sync()` from this sysfs path and other paths (e.g., normal
driver operation, other sysfs handlers) can result in:
1. **Data races** on shared driver state
2. **Lockdep warnings** at runtime (guaranteed to fire)
3. Potential **corruption of command submission state** leading to
   firmware communication errors or crashes

### Classification

This is a **synchronization bug fix** — a missing lock acquisition. It
falls squarely into the "race conditions" category of stable-worthy
fixes.

### Scope and Risk Assessment

- **Lines changed**: 2 (extremely minimal)
- **Files touched**: 1
- **Risk**: Very low — adding lock acquisition around a single function
  call, following the exact same pattern as sibling functions in the
  same file
- **Subsystem**: iwlegacy wireless driver (older Intel WiFi),
  mature/stable code
- **Could this break something?**: The mutex is already used throughout
  the driver. The only concern would be deadlock if
  `il3945_get_measurement()` were called with the mutex already held,
  but since this is a sysfs entry point (userspace-initiated), it's a
  fresh call path — no lock is held on entry.

### User Impact

- Users with Intel 3945 WiFi hardware who trigger this sysfs interface
  will hit the lockdep warning
- More critically, the lack of synchronization could lead to corruption
  of the driver's command channel, potentially causing firmware hangs or
  crashes
- The iwlegacy driver, while old, still has active users on older
  hardware

### Stability Indicators

- **Acked-by**: Stanislaw Gruszka (former iwlegacy maintainer)
- **Committed by**: Johannes Berg (WiFi subsystem maintainer)
- The fix follows an existing, well-established pattern in the same file

### Dependency Check

- No dependencies on other commits
- The `il->mutex` and the function being called have existed in the
  driver since its inception
- This code exists in all stable trees that include the iwlegacy driver

### Verdict

This is a small, obviously correct, well-reviewed fix for a real
synchronization bug. It:
- Fixes a lockdep assertion violation (guaranteed to trigger)
- Prevents potential race conditions in command submission
- Is only 2 lines, touching 1 file
- Follows the exact same pattern as adjacent code
- Has maintainer acks
- Has zero risk of regression

This meets all stable kernel criteria perfectly.

**YES**

 drivers/net/wireless/intel/iwlegacy/3945-mac.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index 104748fcdc33e..54991f31c52c5 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -3224,7 +3224,9 @@ il3945_store_measurement(struct device *d, struct device_attribute *attr,
 
 	D_INFO("Invoking measurement of type %d on " "channel %d (for '%s')\n",
 	       type, params.channel, buf);
+	mutex_lock(&il->mutex);
 	il3945_get_measurement(il, &params, type);
+	mutex_unlock(&il->mutex);
 
 	return count;
 }
-- 
2.51.0