date:20170108

RE: New Lock Order Reversal in 12.0?

2017-01-08 Thread Anindya Mukherjee

Hi Ben,

Thanks for your reply, and yes, I did notice #238. I should say at this point 
that I'm a newbie when it comes to kernel code and am trying to learn about it 
(hence current).

The entry you refer to does look a bit like the one I've got, but I'm not 
totally sure if the same code path is being followed to arrive at this LOR. An 
inode is being created in my case, vs a directory creation (entry + inode 
probably) in #238, and then a sync is being attempted, which causes locks to 
activate in the softdep code. I've read a bit about this from McCusick's book 
but the details are still fuzzy.

Perhaps you are trying to tell me that it's benign? I know that WITNESS has 
false positives, an example being #236 where due to shared vs exclusive vnode 
locks required on the two ways to lock bufwait and dirhash a deadlock never 
happens. 

Best,
Anindya

From: Benjamin Kaduk [ka...@mit.edu]
Sent: January 8, 2017 4:47 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: New Lock Order Reversal in 12.0?

On Mon, Jan 09, 2017 at 12:32:28AM +, Anindya Mukherjee wrote:
> Hi, I'm running 12.0-current and noticed a LOR message from WITNESS which I 
> couldn't find a report about. I looked at 
> http://sources.zabbadoz.net/freebsd/lor.html, among other places.
>
> system details:
> root@triskelion:~ # uname -a
> FreeBSD triskelion 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan  5 
> 22:46:38 UTC 2017 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> root@triskelion:~ # freebsd-version
> 12.0-CURRENT
>
>
> WITNESS report:
> lock order reversal:
>  1st 0xf8002e8049a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
>  2nd 0xfe01e7ce9b40 bufwait (bufwait) @ 
> /usr/src/sys/ufs/ffs/ffs_vnops.c:277
>  3rd 0xf8002ec7b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
> stack backtrace:
> #0 0x80aa6fd0 at witness_debugger+0x70
> #1 0x80aa6ed3 at witness_checkorder+0xde3
> #2 0x80a20c15 at __lockmgr_args+0x725
> #3 0x80d06fc5 at ffs_lock+0xa5
> #4 0x8101c0c0 at VOP_LOCK1_APV+0xe0
> #5 0x80b1a6aa at _vn_lock+0x9a
> #6 0x80b0ac94 at vget+0x64
> #7 0x80afd19c at vfs_hash_get+0xcc
> #8 0x80d02e5e at ffs_vgetf+0x3e
> #9 0x80cf9787 at softdep_sync_buf+0xc37
> #10 0x80d07c51 at ffs_syncvnode+0x2a1
> #11 0x80d06e60 at ffs_fsync+0x20
> #12 0x8101b110 at VOP_FSYNC_APV+0xe0
> #13 0x80d0f2f0 at ufs_direnter+0x870
> #14 0x80d18050 at ufs_makeinode+0x5c0
> #15 0x80d13d7a at ufs_create+0x3a
> #16 0x810199ca at VOP_CREATE_APV+0xda
> #17 0x80b19f77 at vn_open_cred+0x2c7
>
> This is based on the FreeBSD-12.0-CURRENT-amd64-20170105-r311461-memstick.img 
> installer. Known issue?

You do not think it looks like http://sources.zabbadoz.net/freebsd/lor/238.html 
?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New Lock Order Reversal in 12.0?

2017-01-08 Thread Benjamin Kaduk

On Mon, Jan 09, 2017 at 12:32:28AM +, Anindya Mukherjee wrote:
> Hi, I'm running 12.0-current and noticed a LOR message from WITNESS which I 
> couldn't find a report about. I looked at 
> http://sources.zabbadoz.net/freebsd/lor.html, among other places.
> 
> system details:
> root@triskelion:~ # uname -a
> FreeBSD triskelion 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan  5 
> 22:46:38 UTC 2017 
> r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64
> root@triskelion:~ # freebsd-version
> 12.0-CURRENT
> 
> 
> WITNESS report:
> lock order reversal:
>  1st 0xf8002e8049a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
>  2nd 0xfe01e7ce9b40 bufwait (bufwait) @ 
> /usr/src/sys/ufs/ffs/ffs_vnops.c:277
>  3rd 0xf8002ec7b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
> stack backtrace:
> #0 0x80aa6fd0 at witness_debugger+0x70
> #1 0x80aa6ed3 at witness_checkorder+0xde3
> #2 0x80a20c15 at __lockmgr_args+0x725
> #3 0x80d06fc5 at ffs_lock+0xa5
> #4 0x8101c0c0 at VOP_LOCK1_APV+0xe0
> #5 0x80b1a6aa at _vn_lock+0x9a
> #6 0x80b0ac94 at vget+0x64
> #7 0x80afd19c at vfs_hash_get+0xcc
> #8 0x80d02e5e at ffs_vgetf+0x3e
> #9 0x80cf9787 at softdep_sync_buf+0xc37
> #10 0x80d07c51 at ffs_syncvnode+0x2a1
> #11 0x80d06e60 at ffs_fsync+0x20
> #12 0x8101b110 at VOP_FSYNC_APV+0xe0
> #13 0x80d0f2f0 at ufs_direnter+0x870
> #14 0x80d18050 at ufs_makeinode+0x5c0
> #15 0x80d13d7a at ufs_create+0x3a
> #16 0x810199ca at VOP_CREATE_APV+0xda
> #17 0x80b19f77 at vn_open_cred+0x2c7
> 
> This is based on the FreeBSD-12.0-CURRENT-amd64-20170105-r311461-memstick.img 
> installer. Known issue?

You do not think it looks like http://sources.zabbadoz.net/freebsd/lor/238.html 
?

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

New Lock Order Reversal in 12.0?

2017-01-08 Thread Anindya Mukherjee

Hi, I'm running 12.0-current and noticed a LOR message from WITNESS which I 
couldn't find a report about. I looked at 
http://sources.zabbadoz.net/freebsd/lor.html, among other places.

system details:
root@triskelion:~ # uname -a
FreeBSD triskelion 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r311461: Thu Jan  5 
22:46:38 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC 
 amd64
root@triskelion:~ # freebsd-version
12.0-CURRENT


WITNESS report:
lock order reversal:
 1st 0xf8002e8049a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
 2nd 0xfe01e7ce9b40 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:277
 3rd 0xf8002ec7b9a0 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2598
stack backtrace:
#0 0x80aa6fd0 at witness_debugger+0x70
#1 0x80aa6ed3 at witness_checkorder+0xde3
#2 0x80a20c15 at __lockmgr_args+0x725
#3 0x80d06fc5 at ffs_lock+0xa5
#4 0x8101c0c0 at VOP_LOCK1_APV+0xe0
#5 0x80b1a6aa at _vn_lock+0x9a
#6 0x80b0ac94 at vget+0x64
#7 0x80afd19c at vfs_hash_get+0xcc
#8 0x80d02e5e at ffs_vgetf+0x3e
#9 0x80cf9787 at softdep_sync_buf+0xc37
#10 0x80d07c51 at ffs_syncvnode+0x2a1
#11 0x80d06e60 at ffs_fsync+0x20
#12 0x8101b110 at VOP_FSYNC_APV+0xe0
#13 0x80d0f2f0 at ufs_direnter+0x870
#14 0x80d18050 at ufs_makeinode+0x5c0
#15 0x80d13d7a at ufs_create+0x3a
#16 0x810199ca at VOP_CREATE_APV+0xda
#17 0x80b19f77 at vn_open_cred+0x2c7

This is based on the FreeBSD-12.0-CURRENT-amd64-20170105-r311461-memstick.img 
installer. Known issue?

It happened during a portsnap fetch. the filesystem is UFS with default mount 
options.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Possible race condiction during -j16 buildworld (r311640 -> r311678)

2017-01-08 Thread David Wolfskill

One (of four) in-place source-based updates of head/amd64 from r311640
-> r311678 failed twice for me in "make buildworld" (at slightly
different points during the build).  The first retry got a bit further;
the second completed successfully.

I have a typescript of the entire thing, so I'll make that available in
.

The reason that there were 4 updates is that I have to machines (my
laptop and a build machine, "freebeast"), each of which builds its
normal kernel ("CANARY" for the laptop; "GENERIC" for the build
machine), then I've also been testing building & running with the
EARLY_AP_TEST option enabled in the kernel.  And while I could do that
by merely building the additional kernel in the "normal" environment and
giving it a "smoke test" every once in a while, I chose to duplicate the
entire slice, then add the EARLY_AP_TEST option to the kernels in
questions.

In any case, it was the EARLY_AP_TEST on the build machine that had the
apparent issue.

So, in , you'll find
typescript_r311678 (9MB), as well as typescript_r311678.gz (780KB).

I use the "_bw" csh alias to do the builds; as described in
, that alias
(ultimately) expands to:

setenv TMPDIR /tmp && \
 id && \
 mount && \
 cd /usr/src && \
 uname -a && \
 date && \
 make -j16 buildworld && \
 date && \
 make -j16 buildkernel && \
 date && \
 rm -fr /boot/modules.old && \
 cp -pr /boot/modules{,.old} && \
 make installkernel && \
 date && \
 pushd /usr/ports && \
 pushd x11/nvidia-driver && \
 make clean ; popd ; popd && \
 date && \
 mergemaster -U -u 0022 -p && \
 date && \
 rm -fr /usr/include.old && \
 date && \
 mv /usr/include{,.old} && \
 date && \
 rm -fr /usr/share/man && \
 date && \
 make installworld && \
 date && \
 mergemaster -F -U -u 0022 -i && \
 date && \
 make delete-old && \
 date && \
 df -k

There's a copy of the machine's (verbose) dmesg.boot at
.

I have 2 local modifications to the tree:
1) The hack to src/sys/conf/newvers.sh, discussed on
   .

2) A change I had made several days ago to src/Makefile.inc1, augmenting
   ITOOLS with "env" (as some installation step apparently needed it).
   I hadn't got around to testing to determine if it's still needed.

As for why it seeme dto hit the EARLY_AP_TEST and not the GENERIC
one...?  No clue -- dumb luck, I suppose: that should have no effect
once the machine has attained multi-user mode

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Epistemology for post-truthers: How do we select parts of reality to ignore?

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

FreeBSD_HEAD_i386 - Build #4602 - Fixed

2017-01-08 Thread jenkins-admin

FreeBSD_HEAD_i386 - Build #4602 - Fixed:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4602/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4602/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4602/console

Change summaries:

311678 by adrian:
[net80211] add roaming parameters for 11ac.

These are mostly placeholders for now.

311677 by adrian:
[net80211] use the correct freq2 field when populating VHT operation element.

Whilst here, leave a TODO comment so I revisit this routine in the context
of hostap operation probe requests for IBSS/mesh.

311675 by cem:
iso_rrip.h: Hide kernel definitions from makefs(8)

Reported by:O. Hartmann 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_i386 - Build #4601 - Still Failing

2017-01-08 Thread jenkins-admin

FreeBSD_HEAD_i386 - Build #4601 - Still Failing:

Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4601/
Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4601/changes
Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/4601/console

Change summaries:

311671 by cem:
libprocstat: Include cd9660 headers in the same order as the kernel

Fix userspace build after r311665.



The end of the build log:

[...truncated 124749 lines...]
--- all_subdir_usr.bin ---
--- test_option_nodump.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe 
-DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/config_freebsd.h\" 
-I/usr/src/lib/libarchive -I/usr/obj/usr/src/usr.bin/tar/tests 
-I/usr/src/contrib/libarchive/tar -I/usr/src/contrib/libarchive/test_utils   -g 
-MD  -MF.depend.bsdtar_test.test_option_nodump.o -MTtest_option_nodump.o 
-std=gnu99 -fstack-protector-strong-Qunused-arguments  -c 
/usr/src/contrib/libarchive/tar/test/test_option_nodump.c -o 
test_option_nodump.o
--- all_subdir_lib ---
--- parse.po ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -pg  -O2 -pipe   -MD  -MF.depend.parse.po 
-MTparse.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments  -c 
/usr/src/lib/libusbhid/parse.c -o parse.po
--- all_subdir_usr.bin ---
--- test_option_older_than.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe 
-DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/config_freebsd.h\" 
-I/usr/src/lib/libarchive -I/usr/obj/usr/src/usr.bin/tar/tests 
-I/usr/src/contrib/libarchive/tar -I/usr/src/contrib/libarchive/test_utils   -g 
-MD  -MF.depend.bsdtar_test.test_option_older_than.o 
-MTtest_option_older_than.o -std=gnu99 -fstack-protector-strong
-Qunused-arguments  -c 
/usr/src/contrib/libarchive/tar/test/test_option_older_than.c -o 
test_option_older_than.o
--- all_subdir_usr.sbin ---
--- ef_obj.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe   -g -MD  -MF.depend.ef_obj.o 
-MTef_obj.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare 
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function 
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum 
-Wno-knr-promoted-parameter  -Qunused-arguments  -c 
/usr/src/usr.sbin/kldxref/ef_obj.c -o ef_obj.o
--- all_subdir_usr.bin ---
--- test_option_passphrase.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe 
-DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/config_freebsd.h\" 
-I/usr/src/lib/libarchive -I/usr/obj/usr/src/usr.bin/tar/tests 
-I/usr/src/contrib/libarchive/tar -I/usr/src/contrib/libarchive/test_utils   -g 
-MD  -MF.depend.bsdtar_test.test_option_passphrase.o 
-MTtest_option_passphrase.o -std=gnu99 -fstack-protector-strong
-Qunused-arguments  -c 
/usr/src/contrib/libarchive/tar/test/test_option_passphrase.c -o 
test_option_passphrase.o
--- test_option_q.o ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin  -O2 -pipe 
-DPLATFORM_CONFIG_H=\"/usr/src/lib/libarchive/config_freebsd.h\" 
-I/usr/src/lib/libarchive -I/usr/obj/usr/src/usr.bin/tar/tests 
-I/usr/src/contrib/libarchive/tar -I/usr/src/contrib/libarchive/test_utils   -g 
-MD  -MF.depend.bsdtar_test.test_option_q.o -MTtest_option_q.o -std=gnu99 
-fstack-protector-strong-Qunused-arguments  -c 
/usr/src/contrib/libarchive/tar/test/test_option_q.c -o test_option_q.o
--- all_subdir_lib ---
--- usage.po ---
cc -target i386-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp 
-B/usr/obj/usr/src/tmp/usr/bin -pg  -O2 -pipe   -MD  -MF.depend.usage.po 
-MTusage.po -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall 
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign 
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body 
-Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments  -c 
/usr/src/lib/libusbhid/usage.c -o usage.po

Re: r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

2017-01-08 Thread Conrad Meyer

Please try r311675.

Thanks,
Conrad

On Sun, Jan 8, 2017 at 1:05 AM, O. Hartmann  wrote:
> It seems, the most recent CURRENT sources are broken (r311674), buildworld 
> failure occur
> at:
>
> [...]
>  --- cd9660.o ---
> In file included from /usr/src/usr.sbin/makefs/cd9660.c:108:
> In file included from /usr/src/usr.sbin/makefs/cd9660.h:57:
> /usr/src/sys/fs/cd9660/iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'; 
> did you mean
> '__ino_t'? cd_ino_t*inump; /* inode number pointer */
> ^~~~
> __ino_t
>
> --
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

2017-01-08 Thread O. Hartmann

It seems, the most recent CURRENT sources are broken (r311674), buildworld 
failure occur
at:

[...]
 --- cd9660.o ---
In file included from /usr/src/usr.sbin/makefs/cd9660.c:108:
In file included from /usr/src/usr.sbin/makefs/cd9660.h:57:
/usr/src/sys/fs/cd9660/iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'; 
did you mean
'__ino_t'? cd_ino_t*inump; /* inode number pointer */
^~~~
__ino_t

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpXYkgh5eeGn.pgp
Description: OpenPGP digital signature

RE: New Lock Order Reversal in 12.0?

Re: New Lock Order Reversal in 12.0?

New Lock Order Reversal in 12.0?

Possible race condiction during -j16 buildworld (r311640 -> r311678)

FreeBSD_HEAD_i386 - Build #4602 - Fixed

FreeBSD_HEAD_i386 - Build #4601 - Still Failing

Re: r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

r311674: buildworld failure: iso_rrip.h:64:2: error: unknown type name 'cd_ino_t'

8 matches

Site Navigation

Mail list logo

Footer information