Guenter found that this looks to be nearly the same as b/118366217.  

It appears that me turning on extra debug flags is what started making this show up.  I left my machine up all vacation and it never hit this error.  I'm not sure exactly what flags I was running during that time, but I believe it was

  USE="lockdebug kgdb vtconsole"

Thus some combination of "debugobjects", "kasan" and "kmemleak" seem to be what triggered this for me.

In case it helps, reproduced this with:

  "kasan lockdebug kgdb vtconsole"

I gave this another 30 minutes of debugging today.
...and noticed something a bit suspicious...

Just to have something concrete to talk about, in the case I debugged today, the crash looked like this:

---

[11675.286800] INFO: task crash_sender:15228 blocked for more than 120 seconds.
[11675.295414]       Tainted: G        W         4.19.15 #75
[11675.317365] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[11675.335628] crash_sender    D    0 15228  15227 0x00400000
[11675.348488] Call trace:
[11675.351606]  __switch_to+0x174/0x1c4
[11675.356233]  __schedule+0x124c/0x1bbc
[11675.362541]  schedule+0x160/0x1a0
[11675.366828]  schedule_timeout+0xc0/0xc9c
[11675.372103]  do_wait_for_common+0x2c8/0x4d4
[11675.378271]  wait_for_common+0x58/0x78
[11675.385044]  wait_for_completion+0x24/0x30
[11675.390982]  __wait_rcu_gp+0x1dc/0x204
[11675.395495]  synchronize_rcu+0xd8/0x100
[11675.401937]  namespace_unlock+0x10c/0x11c
[11675.406220]  ksys_umount+0x7b0/0x7e0
[11675.409971]  __arm64_sys_umount+0x48/0x5c
[11675.414328]  el0_svc_common+0x124/0x1c4
[11675.418380]  el0_svc_compat_handler+0x64/0x8c
[11675.422968]  el0_svc_compat+0x8/0x18
[11675.426740]
[11675.426740] Showing all locks held in the system:
[11675.433221] 1 lock held by khungtaskd/58:
[11675.437411]  #0: 0000000015c459a1 (rcu_read_lock){....}, at: rcu_lock_acquire+0x8/0x38
[11675.445715] 1 lock held by in:imklog/611:
[11675.449906]  #0: 00000000f7ee42e9 (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x7c/0xb0
[11675.457970] 2 locks held by bash/6607:
[11675.461911]  #0: 00000000be9ee2a5 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x3c/0x48
[11675.470346]  #1: 0000000020d55df2 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0x1f4/0xf74

---

...the same as all the previous ones.  


So something is fishy in the above.  Specifically it claims that at the time of the printout that khungtaskd is holding the rcu lock.  Huh?  That's weird because in check_hung_uninterruptible_tasks() you can see that the code specifically calls rcu_read_unlock() before calling debug_show_all_locks().  So why would it still show as holding the lock?

===

Another interesting thing I noticed is this patch upstream:

--

commit 304ae42739b108305f8d7b3eb3c1aec7c2b643a9
Author:     Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
AuthorDate: Thu Jan 3 15:26:31 2019 -0800
Commit:     Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Fri Jan 4 13:13:45 2019 -0800

    kernel/hung_task.c: break RCU locks based on jiffies
    
    check_hung_uninterruptible_tasks() is currently calling rcu_lock_break()
    for every 1024 threads.  But check_hung_task() is very slow if printk()
    was called, and is very fast otherwise.
    
    If many threads within some 1024 threads called printk(), the RCU grace
    period might be extended enough to trigger RCU stall warnings.
    Therefore, calling rcu_lock_break() for every some fixed jiffies will be
    safer.
    
    Link: http://lkml.kernel.org/r/1544800658-11423-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
    Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
    Cc: Dmitry Vyukov <dvyukov@google.com>
    Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
    Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

--

I'm not convinced that's what we're seeing here, but I at least did add some debug prints to check...