Re: vrele vs. syncer deadlock

[Nick Hudson <skrll%netbsd.org@localhost>]

On 12/11/16 21:05, J. Hannken-Illjes wrote:
> > On 11 Dec 2016, at 21:01, David Holland <dholland-tech%netbsd.org@localhost> wrote:
> >
> > On a low-memory machine Nick ran into the following deadlock:
> >
> >   (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> >       no memory in buffer pool -> wait for syncer
> >   (b) syncer waiting for locked parent vnode from the rename
> Do you have full backtrace?

0x980000041097f540:  kernel_text+dc  (0,0,0,0)  ra  ffffffff803ad484  sz  0
0x980000041097f540:  mi_switch+1c4  (0,0,0,0)  ra  ffffffff803a9f20  sz  96
0x980000041097f5a0:  sleepq_block+d8  (0,0,0,0)  ra  ffffffff80377784  sz  64
0x980000041097f5e0:  cv_timedwait+114  (0,0,0,0)  ra  ffffffff8041bdcc  sz  64
0x980000041097f620:  allocbuf+344  (0,0,0,0)  ra  ffffffff8041c504  sz  128
0x980000041097f6a0:  getblk+1d4  (0,0,0,0)  ra  ffffffff80332b40  sz  80
0x980000041097f6f0:  ffs_getblk+48  (0,0,0,0)  ra  ffffffff8032eec4  sz  80
0x980000041097f740:  ffs_indirtrunc+b4  (0,0,539ac0,ffffffffffffffff)  ra  ffffffff8033057c  sz  192
0x980000041097f800:  ffs_truncate+b44  (0,0,539ac0,ffffffffffffffff)  ra  ffffffff8033bd54  sz  320
0x980000041097f940:  ufs_truncate_retry+c4  (0,0,539ac0,ffffffffffffffff)  ra  ffffffff8033bf24  sz  80
0x980000041097f990:  ufs_inactive+184  (0,0,539ac0,ffffffffffffffff)  ra  ffffffff8043fce8  sz  48
0x980000041097f9c0:  VOP_INACTIVE+30  (ffffffff8049d538,980000041097f9f0,539ac0,ffffffffffffffff)  ra  ffffffff804338ec  sz  48
0x980000041097f9f0:  vrelel+534  (ffffffff8049d538,980000041097f9f0,539ac0,ffffffffffffffff)  ra  ffffffff804449a8  sz  96
0x980000041097fa50:  genfs_rename_exit+108  (ffffffff8049d538,980000041097f9f0,539ac0,ffffffffffffffff)  ra  ffffffff80445c3c  sz  48
0x980000041097fa80:  genfs_sane_rename+414  (ffffffff8049d538,980000041097f9f0,539ac0,980000041097fb68)  ra  ffffffff8033da84  sz  192
0x980000041097fb40:  ufs_sane_rename+44  (ffffffff8049d538,980000041097f9f0,539ac0,980000041097fb68)  ra  ffffffff80445600  sz  80
0x980000041097fb90:  genfs_insane_rename+168  (ffffffff8049d538,980000041097f9f0,539ac0,980000041097fb68)  ra  ffffffff8043fa28  sz  96
0x980000041097fbf0:  VOP_RENAME+40  (ffffffff8049d6c8,ffffffff8006d678,980000041097fd08,ffffffff8fd57690)  ra  ffffffff8042b8cc  sz  80
0x980000041097fc40:  do_sys_renameat+454  (ffffffff8049d6c8,ffffffff8006d678,980000041097fd08,ffffffff8fd57690)  ra  ffffffff80243e5c  sz  336
0x980000041097fd90:  netbsd32_rename+24  (ffffffff8049d6c8,ffffffff8006d678,980000041097fd08,ffffffff8fd57690)  ra  ffffffff80234494  sz  32
0x980000041097fdb0:  syscall+114  (ffffffff8049d6c8,ffffffff8006d678,980000041097fd08,785ea604)  ra  ffffffff802289f4  sz  240
0x980000041097fea0:  mips64r2_systemcall+d4  (ffffffff8049d6c8,ffffffff8006d678,980000041097fd08,785ea604)  ra  785ea604  sz  0
PC  0x785ea604:  not  in  kernel  space



> Where is the syncer waiting for the parent?

db>  bt/a  ffffffff8ff28060
pid  0.37  at  0x9800000410960000
0x9800000410961bb0:  kernel_text+dc  (0,0,0,0)  ra  ffffffff803ad484  sz  0
0x9800000410961bb0:  mi_switch+1c4  (0,0,0,0)  ra  ffffffff803a9ef8  sz  96
0x9800000410961c10:  sleepq_block+b0  (0,0,0,0)  ra  ffffffff803b8edc  sz  64
0x9800000410961c50:  turnstile_block+2e4  (0,0,0,0)  ra  ffffffff803a487c  sz  96
0x9800000410961cb0:  rw_enter+17c  (0,0,0,0)  ra  ffffffff8044862c  sz  112
0x9800000410961d20:  genfs_lock+8c  (0,0,0,0)  ra  ffffffff8043fd60  sz  48
0x9800000410961d50:  VOP_LOCK+30  (ffffffff8049d4c8,2,0,0)  ra  ffffffff80436c8c  sz  48
0x9800000410961d80:  vn_lock+94  (ffffffff8049d4c8,2,0,0)  ra  ffffffff803367d8  sz  64
0x9800000410961dc0:  ffs_sync+c8  (ffffffff8049d4c8,2,0,0)  ra  ffffffff80428f4c  sz  112
0x9800000410961e30:  sched_sync+1c4  (ffffffff8049d4c8,2,0,0)  ra  ffffffff80228dd0  sz  112
0x9800000410961ea0:  mips64r2_lwp_trampoline+18  (ffffffff8049d4c8,2,0,0)  ra  0  sz  32



> Which file system?

ffs

> --
> J. Hannken-Illjes - hannken%eis.cs.tu-bs.de@localhost - TU Braunschweig (Germany)

Nick