On Thu, Apr 9, 2020 at 2:51 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > 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? Yes indeed the renames were on NFS. I'll take a look at the network trace (it didn't look like there was an unanswered renamed that would have been holding a VFS lock). Thanks for reply so far.
