On Thu, Apr 09, 2020 at 12:44:25PM -0400, Olga Kornievskaia wrote: > Hi folks, > > Getting this hang on a 5.5 kernel, is this a known issue? Thank you. I haven't seen it reported. > Apr 7 13:34:53 scspr1865142002 kernel: Not tainted 5.5.7 #1 > Apr 7 13:34:53 scspr1865142002 kernel: "echo 0 > > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > Apr 7 13:34:53 scspr1865142002 kernel: dt D 0 24788 > 24323 0x00000080 > Apr 7 13:34:53 scspr1865142002 kernel: Call Trace: > Apr 7 13:34:53 scspr1865142002 kernel: ? __schedule+0x2ca/0x6e0 > Apr 7 13:34:53 scspr1865142002 kernel: schedule+0x4a/0xb0 > Apr 7 13:34:53 scspr1865142002 kernel: schedule_preempt_disabled+0xa/0x10 > Apr 7 13:34:53 scspr1865142002 kernel: __mutex_lock.isra.11+0x233/0x4e0 > Apr 7 13:34:53 scspr1865142002 kernel: ? strncpy_from_user+0x47/0x160 > Apr 7 13:34:53 scspr1865142002 kernel: lock_rename+0x28/0xd0 This task is doing a cross-directory rename() operation. We only allow one of those in progress per filesystem at any given time (because they're quite rare and rearranging the tree like that plays merry havoc with the locking, which you need to prevent a directory becoming its own ancestor). So the question is, who else is in the middle of a rename operation and has blocked for a long time while holding the s_vfs_rename_mutex? As I recall, you work on NFS, so has something weird been going on with your network?
