https://bugs.kde.org/show_bug.cgi?id=528116

            Bug ID: 528116
           Summary: TrashDirNotify blocks Wi-Fi connection after resume
                    when a mounted CIFS share is unavailable
    Classification: Frameworks and Libraries
           Product: frameworks-kio
      Version First 6.31.0
       Reported In:
          Platform: Fedora RPMs
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: Trash
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
  Target Milestone: ---

Summary

After waking the computer from sleep, Wi-Fi sometimes fails to reconnect with
“No secrets were provided”.

The saved password is available in KWallet. The problem is that trashdirnotify
blocks the main thread of kded6 while checking a mounted CIFS share before the
network is available. The NetworkManager secret agent runs in the same process
and cannot answer the password request.

System
- Fedora 44
- KDE Plasma 6.7.5
- KDE Frameworks / KIO 6.31.0
- NetworkManager 1.56.1
- Kernel 7.2.11-200.fc44.x86_64
- CIFS mount using SMB 3.1.1
- Wi-Fi password stored in KWallet (psk-flags=1, agent-owned)
Steps to reproduce
1. Mount an SMB share using the kernel CIFS client.
2. Configure Wi-Fi to reconnect automatically, with its password stored in
KWallet.
3. Suspend the computer while keeping the share mounted.
4. Resume without another active network connection.
5. Wait for Wi-Fi to reconnect.
The problem is intermittent.

Actual result

Wi-Fi remains in the authentication stage. After 120 seconds, NetworkManager
reports:
GetSecrets: completed with failure: Timeout was reached
no secrets: No agents were available for this request.
KWallet remains open and its Secret Service collection is unlocked.

During the failure, even a simple loadedModules D-Bus request to kded6 receives
no immediate reply.

Technical findings

An automatically captured stack shows the main thread of kded6 executing:
fstatat64
TrashImpl::trashForMountPoint
TrashImpl::scanTrashDirectories
TrashDirNotify::updateWatchedTrashDirectories
Solid::DeviceNotifier::deviceAdded
Solid::Backends::UPower::UPowerManager::onDeviceAdded
Other snapshots show the same thread blocked in the kernel:
wait_for_response [cifs]
compound_send_recv [cifs]
smb2_query_path_info [cifs]
cifs_lookup [cifs]
vfs_statx
__do_sys_newfstatat
This creates a circular dependency: the trash scan waits for network access,
while Wi-Fi waits for the secret agent in the blocked kded6 process.

Expected result

Checking trash directories on an unavailable network filesystem should not
block the main thread of kded6 or prevent the Wi-Fi secret agent from
responding.


Related report: Bug 525116 describes blocking CIFS requests during trash
scanning. This report adds the effect on kded6 and Wi-Fi authentication after
resume.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to