On Sun, 2024-07-21 at 14:03 +0300, Dan Aloni wrote: > On 2024-07-16 16:09:54, Trond Myklebust wrote: > > [..] > > gdb -batch -quiet -ex 'list > > *(nfs_folio_find_private_request+0x3c)' -ex quit nfs.ko > > > > > > I suspect this will show that the problem is occurring inside the > > function folio_get_private(), but I'd like to be sure that is the > > case. > > I would suspect that `->private_data` gets corrupted somehow. Maybe > the folio_test_private() call needs to be protected by either the > &mapping->i_private_lock, or folio lock? > If the problem is indeed happening in "folio_get_private()", then the dereferenced address value of 00000000000003a6 would seem to indicate that the pointer value of 'folio' itself is screwed up, doesn't it? Since the value of 'folio' is being passed directly from write_cache_pages() as an argument to all the subsequent functions in the stack trace, then I'm somewhat confused. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
