Quoting Jeremie Courreges-Anglas <j...@wxcvbn.org>:
On Tue, Jul 10 2018, Vijay Sankar <vsan...@foretell.ca> wrote:
Quoting Jeremie Courreges-Anglas <j...@wxcvbn.org>:
On Tue, Jul 10 2018, Ian McWilliam
<i.mcwill...@westernsydney.edu.au> wrote:
Ouch, that's a new lock order problem. The one I encountered with
4.8.2 was with the vfs/acl_tdb module.
They are not the same thing: you hit a locking problem in samba code,
the log from Vijay shows a lock ordering problem in the OpenBSD kernel.
[...]
2) When samba 4.8.3 starts, the following is logged
lock order reversal:
1st 0xffffff07811695c0 vmmaplk (&map->lock) @
/usr/src/sys/uvm/uvm_map.c:4433
2nd 0xffffff087c37bf80 inode (&ip->i_lock) @
/usr/src/sys/ufs/ufs/ufs_vnops.c:1555
lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at:
#0 witness_checkorder+0x4c0
#1 _rw_enter_read+0x49
#2 uvmfault_lookup+0x8d
#3 uvm_fault+0x72
#4 pageflttrap+0x14c
#5 trap+0x319
#6 alltraps_kern+0x7e
#7 copyout+0x48
#8 ffs_read+0x1f0
#9 VOP_READ+0x49
#10 vn_read+0xca
#11 dofilereadv+0x216
#12 sys_read+0x82
#13 syscall+0x32a
#14 Xsyscall_untramp+0xe4
lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at:
#0 witness_checkorder+0x4c0
#1 _rw_enter+0x68
#2 _rrw_enter+0x3e
#3 VOP_LOCK+0x3d
#4 vn_lock+0x34
#5 uvn_io+0x1b8
#6 uvm_pager_put+0x109
#7 uvn_flush+0x424
#8 uvm_map_clean+0x3e7
#9 syscall+0x32a
#10 Xsyscall_untramp+0xe4
Is this to be expected or is there a problem here?
If there are any other tests that will be helpful please let me know.
Thanks very much,
Vijay
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
I will do the tests again on a set of clean machines with
a newer -current. I am also wondering if testing with bsd.sp instead of
bsd.mp is a valid approach.
I'm not sure that using bsd.sp would avoid those log entries, but that's
not the point: those witness(4) traces are here to help kernel
developers track down lock ordering issues. Please try a fresh -current
and if that message appears again please report it on bugs@.
Those witness(4) traces may point out a problem that could affect samba,
but they don't *look* samba-specific to me. There's a good chance that
samba will keep working correctly, whether those warnings appear or not.
btw,
[...]
So I installed samba 4.8.3 on a different box (desktop computer with
gnome) thinking that the problem was due to my test setup.
Unfortunately starting samba with the default smb.conf (not a domain
member) resulted in the following:
error: [drm:pid48841:intel_pipe_update_start] *ERROR* Potential atomic
update failure on pipe A
lock order reversal:
1st 0xffffffff81df30b0 &sched_lock (&sched_lock) @
/usr/src/sys/kern/kern_synch.c:444
2nd 0xffff8000000ff9f0 &dev_priv->uncore.lock
(&dev_priv->uncore.lock) @
/usr/src/sys/dev/pci/drm/i915/intel_uncore.c:811
lock order "&dev_priv->uncore.lock"(mutex) -> "&sched_lock"(sched_lock)
first seen at:
#0 witness_checkorder+0x4c0
#1 ___mp_lock+0x70
#2 schedclock+0x30
#3 hardclock+0xe3
#4 lapic_clockintr+0x3d
#5 Xresume_lapic_ltimer+0x22
#6 x86_bus_space_mem_read_4+0x14
#7 gen6_read32+0x184
#8 drm_update_vblank_count+0x65
#9 drm_handle_vblank+0xee
#10 ironlake_irq_handler+0x4e4
#11 intr_handler+0x74
#12 Xintr_ioapic_edge18_untramp+0x161
#13 ___mp_lock+0xca
#14 solock+0x50
#15 sosend+0x117
#16 sendit+0x3fb
#17 sys_sendmsg+0x15a
#18 syscall+0x32a
lock order "&sched_lock"(sched_lock) -> "&dev_priv->uncore.lock"(mutex)
first seen at:
#0 witness_checkorder+0x4c0
#1 _mtx_enter+0x31
#2 gen6_read32+0x8f
#3 gen6_ring_get_seqno+0x3a
#4 __i915_wait_request+0x232
#5 i915_gem_object_wait_rendering__nonblocking+0x1d6
#6 i915_gem_set_domain_ioctl+0xdb
#7 drm_do_ioctl+0x221
#8 drmioctl+0xf9
#9 VOP_IOCTL+0x5a
#10 vn_ioctl+0x6b
#11 sys_ioctl+0x477
#12 syscall+0x32a
#13 Xsyscall_untramp+0xe4
lock order reversal:
1st 0xffffffff81df30b0 &sched_lock (&sched_lock) @
/usr/src/sys/kern/kern_synch.c:444
2nd 0xffff800000106270 &dev_priv->irq_lock (&dev_priv->irq_lock) @
/usr/src/sys/dev/pci/drm/i915/intel_ringbuffer.c:1787
lock order "&dev_priv->irq_lock"(mutex) -> "&sched_lock"(sched_lock)
first seen at:
#0 witness_checkorder+0x4c0
#1 ___mp_lock+0x70
#2 wakeup_n+0x39
#3 task_add+0x93
#4 gen6_rps_boost+0x129
#5 __i915_wait_request+0x155
#6 i915_gem_object_wait_rendering__nonblocking+0x1d6
#7 i915_gem_set_domain_ioctl+0xdb
#8 drm_do_ioctl+0x221
#9 drmioctl+0xf9
#10 VOP_IOCTL+0x5a
#11 vn_ioctl+0x6b
#12 sys_ioctl+0x477
#13 syscall+0x32a
#14 Xsyscall_untramp+0xe4
lock order "&sched_lock"(sched_lock) -> "&dev_priv->irq_lock"(mutex)
first seen at:
#0 witness_checkorder+0x4c0
#1 _mtx_enter+0x31
#2 gen6_ring_put_irq+0x36
#3 __i915_wait_request+0x367
#4 i915_gem_object_wait_rendering__nonblocking+0x1d6
#5 i915_gem_set_domain_ioctl+0xdb
#6 drm_do_ioctl+0x221
#7 drmioctl+0xf9
#8 VOP_IOCTL+0x5a
#9 vn_ioctl+0x6b
#10 sys_ioctl+0x477
#11 syscall+0x32a
#12 Xsyscall_untramp+0xe4
Those two traces don't look samba-related at all, and should be
reported. ;)
lock order reversal:
1st 0xffffff07059c4a00 vmmaplk (&map->lock) @
/usr/src/sys/uvm/uvm_map.c:4433
2nd 0xffffff070d217a30 inode (&ip->i_lock) @
/usr/src/sys/ufs/ufs/ufs_vnops.c:1555
lock order "&ip->i_lock"(rrwlock) -> "&map->lock"(rwlock) first seen at:
#0 witness_checkorder+0x4c0
#1 _rw_enter+0x68
#2 vm_map_lock_ln+0xbc
#3 uvm_map+0x1a1
#4 km_alloc+0x16a
#5 pool_multi_alloc_ni+0xbb
#6 pool_p_alloc+0x56
#7 pool_do_get+0xe4
#8 pool_get+0xaf
#9 ufsdirhash_build+0x31e
#10 ufs_lookup+0x19d
#11 VOP_LOOKUP+0x4f
#12 vfs_lookup+0x27e
#13 namei+0x226
#14 start_init+0xb2
lock order "&map->lock"(rwlock) -> "&ip->i_lock"(rrwlock) first seen at:
#0 witness_checkorder+0x4c0
#1 _rw_enter+0x68
#2 _rrw_enter+0x3e
#3 VOP_LOCK+0x3d
#4 vn_lock+0x34
#5 uvn_io+0x1b8
#6 uvm_pager_put+0x109
#7 uvn_flush+0x424
#8 uvm_map_clean+0x3e7
#9 syscall+0x32a
#10 Xsyscall_untramp+0xe4
Did a pkg_add -r samba-4.8.2 and ldb-1.3.3; restarted the desktop and
verified there are no lock reversal messages
I would of course prefer that you keep on testing with the latest 4.8.3
samba package. ;)
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Thanks very much for the detailed reply. I am going to start with the
assumption that I have made some mistake in how I upgraded snapshots
or set up the VMs. Will install the latest -current and ports on two
new sets of drives, make samba-4.8.3, and then test without any
dependence on VMs etc.
Vijay
Vijay Sankar, M.Eng., P.Eng.
ForeTell Technologies Limited
vsan...@foretell.ca
