Shyam Prasad N <nspmangalore@xxxxxxxxx> wrote: > [Mon Jun 19 16:05:49 2023] invalidate_inode_pages2+0x17/0x30 > [Mon Jun 19 16:05:49 2023] cifs_invalidate_mapping+0x57/0x90 [cifs] > [Mon Jun 19 16:05:49 2023] cifs_revalidate_mapping+0xd5/0x130 [cifs] > [Mon Jun 19 16:05:49 2023] cifs_revalidate_dentry+0x32/0x40 [cifs] > [Mon Jun 19 16:05:49 2023] cifs_d_revalidate+0xa3/0x220 [cifs] > [Mon Jun 19 16:05:49 2023] lookup_fast+0xfc/0x1c0 > [Mon Jun 19 16:05:49 2023] walk_component+0x39/0x240 > [Mon Jun 19 16:05:49 2023] path_lookupat+0xb2/0x2f0 > [Mon Jun 19 16:05:49 2023] filename_lookup+0x16f/0x340 You don't have a deadlock between two inode locks, do you? The one on the parent dir and the one on whatever is being invalidated. Or between invalidate and a write. It doesn't seem that it should be that, since in both cases it should take the inode lock first and then PG_lock. There's the possibility that we missed unlocking a page after splitting a read or a write. What's the testcase like? Would it be feasible to trace page activity on smb pages? I have a patch to restrict the page count tracing to just trace the page lock flag that I might be able to adapt. David
