Two fresh LORs from the latest 11-stable

Maxim Sobolev sobomax at freebsd.org
Sat Jul 23 01:03:44 UTC 2016


It's a custom kernel, which is probably why we have it. By "fresh" I didn't
mean "new", it's just something that I've noticed, sorry. Is there a list
somewhere with most common ones by any chance?

-Max

On Fri, Jul 22, 2016 at 9:47 AM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On the face of it, those don't seem to be new/fresh.
> bufwait/dirhash and ufs/bufwait/ufs I have seen for a very long time and
> are believed to be harmless.
>
> Though ... isn't WITNESS out of GENERIC on stable/11?
>
> -Ben
>
> On Thu, 21 Jul 2016, Maxim Sobolev wrote:
>
> > Seen those on our build box right after pulling latest update.
> >
> > lock order reversal:
> >  1st 0xfffffe00f62564c0 bufwait (bufwait) @
> > /usr/home/sobomax/freebsd11.git/sys/kern/vfs_bio.c:3512
> >  2nd 0xfffff80003d33800 dirhash (dirhash) @
> > /usr/home/sobomax/freebsd11.git/sys/ufs/ufs/ufs_dirhash.c:281
> > stack backtrace:
> > #0 0xffffffff80ab5fc0 at witness_debugger+0x70
> > #1 0xffffffff80ab5eb4 at witness_checkorder+0xe54
> > #2 0xffffffff80a5f1d2 at _sx_xlock+0x72
> > #3 0xffffffff80d1d8dd at ufsdirhash_add+0x3d
> > #4 0xffffffff80d206aa at ufs_direnter+0x4da
> > #5 0xffffffff80d28d09 at ufs_mkdir+0x8a9
> > #6 0xffffffff810235e0 at VOP_MKDIR_APV+0xe0
> > #7 0xffffffff80b23ef8 at kern_mkdirat+0x208
> > #8 0xffffffff80ec7b2b at amd64_syscall+0x2db
> > #9 0xffffffff80ea767b at Xfast_syscall+0xfb
> >
> > lock order reversal:
> >  1st 0xfffff80064d86d50 ufs (ufs) @
> > /usr/home/sobomax/freebsd11.git/sys/kern/vfs_subr.c:2523
> >  2nd 0xfffffe00f669fe00 bufwait (bufwait) @
> > /usr/home/sobomax/freebsd11.git/sys/ufs/ffs/ffs_vnops.c:263
> >  3rd 0xfffff800a5c4eb78 ufs (ufs) @
> > /usr/home/sobomax/freebsd11.git/sys/kern/vfs_subr.c:2523
> > stack backtrace:
> > #0 0xffffffff80ab5fc0 at witness_debugger+0x70
> > #1 0xffffffff80ab5eb4 at witness_checkorder+0xe54
> > #2 0xffffffff80a2f052 at __lockmgr_args+0x4c2
> > #3 0xffffffff80d18546 at ffs_lock+0xa6
> > #4 0xffffffff81023fd0 at VOP_LOCK1_APV+0xe0
> > #5 0xffffffff80b26aaa at _vn_lock+0x9a
> > #6 0xffffffff80b16ed4 at vget+0x64
> > #7 0xffffffff80b095cc at vfs_hash_get+0xcc
> > #8 0xffffffff80d14250 at ffs_vgetf+0x40
> > #9 0xffffffff80d0b4a6 at softdep_sync_buf+0x496
> > #10 0xffffffff80d19136 at ffs_syncvnode+0x256
> > #11 0xffffffff80cefed3 at ffs_truncate+0x8d3
> > #12 0xffffffff80d20851 at ufs_direnter+0x681
> > #13 0xffffffff80d28d09 at ufs_mkdir+0x8a9
> > #14 0xffffffff810235e0 at VOP_MKDIR_APV+0xe0
> > #15 0xffffffff80b23ef8 at kern_mkdirat+0x208
> > #16 0xffffffff80ec7b2b at amd64_syscall+0x2db
> > #17 0xffffffff80ea767b at Xfast_syscall+0xfb
> >
> > -Max
> > _______________________________________________
> > freebsd-fs at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> >
>
>


More information about the freebsd-fs mailing list