From owner-freebsd-hackers@freebsd.org Sun Feb 18 01:39:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27495F00D7E for ; Sun, 18 Feb 2018 01:39:49 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A50437A004 for ; Sun, 18 Feb 2018 01:39:47 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: wcX2PgoVM1kLW9iN8MZnPI37PJMwQNlrfsskkAOfvv_cn0QEPnfpppSXZBbnydI yG5yaAd7VqcGWRLKywJBYw5nWybjl8QeAt0pgXH133Cuy1CvsxhzXt6O0Z7cOMCTY_yt24bz0w3h lEd6y2Q4GJIgKWDDQ7E6g94zQYgvpFTu953Sd3CcPFrRzH1USyQC9g_22MzStCK1FMAe7NBr1w1b sLJbdeeVCkWFgOKWbhhdIbgmZ_7DVxcbTLQzm1trlXiV9uf.QYhFWhubbbZ0RXrikeCK4wSrk1Nf vb.kmwUvCT2CfXme_7VqENXnmTrOLQ3paQZ4gfT3UiH1w_UHY5F4pK_YF0ylCiwSTIF0BqKVkkLH nLrxYqFBXaCBkdfik4WaOLFWACPrYr80H4FHjAbp1vg6pfy3AuEENGCccXJi7TpCMdmxytvciujT eL_MtyZrOnWHZLdhGVtsG8qI4ALmznK15K7onNNh0D086xlZLSyaX2OeSNmNmaw-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 01:39:41 +0000 Received: from smtp101.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([68.180.227.10]) by smtp410.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 059fc7489feb036f39796c716a262c7d; Sun, 18 Feb 2018 01:39:40 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Message-Id: Date: Sat, 17 Feb 2018 17:39:39 -0800 To: FreeBSD Current , FreeBSD Hackers X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 01:39:49 -0000 This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen Threadripper 1950X). No other Hyper-V use. This happened during: # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>> Checking for old files (Hand typed from a picture of a window's content at slighly different times, expect typos:) KDB: enter: panic [thread pid 42170 tid 100752 ] Stopped at kdb_enter+0x3b: movq $0,kdb_why db> call doadump Dumping 4825 out of 110559 MB: ... (omitted) ... Dump complete =3D 0 (The "pid 42170" identification as the process reporting the issue does not seem to appear in the core.txt.0 file.) # ls -lTdt /var/crash/* -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 = /var/crash/core.txt.0 lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 = /var/crash/vmcore.last -> vmcore.0 lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 = /var/crash/info.last -> info.0 -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 = /var/crash/vmcore.0 -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 = /var/crash/info.0 -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 = /var/crash/bounds -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 = /var/crash/minfree =46rom /var/crash/core.txt.0 : Unread portion of the kernel message buffer: spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long panic: spin lock held too long cpuid =3D 5 time =3D 1518911834 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f10094d0 vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 panic() at panic+0x43/frame 0xfffffe00f1009590 _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f10095a0 thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1009610 statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1009730 timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1009880 fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffcfc0 KDB: enter: panic __curthread () at ./machine/pcpu.h:230 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=3D-2122191464) at = /usr/src/sys/kern/kern_shutdown.c:347 #2 0xffffffff8040b42c in db_fncall_generic (addr=3D,=20 rv=3D, nargs=3D, args=3D) at /usr/src/sys/ddb/db_command.c:609 #3 db_fncall (dummy1=3D, dummy2=3D,=20 dummy3=3D, dummy4=3D) at /usr/src/sys/ddb/db_command.c:657 #4 0xffffffff8040af79 in db_command (last_cmdp=3D,=20 cmd_table=3D, dopager=3D) at /usr/src/sys/ddb/db_command.c:481 #5 0xffffffff8040acf4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534 #6 0xffffffff8040df9f in db_trap (type=3D, = code=3D) at /usr/src/sys/ddb/db_main.c:250 #7 0xffffffff80b370e3 in kdb_trap (type=3D3, code=3D-61456, = tf=3D) at /usr/src/sys/kern/subr_kdb.c:697 #8 0xffffffff80fa2c5c in trap (frame=3D0xfffffe00f1009400) at /usr/src/sys/amd64/amd64/trap.c:547 #9 #10 kdb_enter (why=3D0xffffffff811f280b "panic", msg=3D) at /usr/src/sys/kern/subr_kdb.c:479 #11 0xffffffff80aef17a in vpanic (fmt=3D, = ap=3D0xfffffe00f1009570) at /usr/src/sys/kern/kern_shutdown.c:801 #12 0xffffffff80aeefc3 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:739 #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=3D,=20 ldap=3D) at /usr/src/sys/kern/kern_mutex.c:1224 #14 0xffffffff80acfb9b in thread_lock_flags_ (td=3D0xfffff818719d1000,=20= opts=3D, file=3D, line=3D) at /usr/src/sys/kern/kern_mutex.c:913 #15 0xffffffff80a89d6c in statclock_cnt (cnt=3D1, usermode=3D) at /usr/src/sys/kern/kern_clock.c:768 #16 0xffffffff810d0003 in handleevents (now=3D43230207690178, fake=3D0) at /usr/src/sys/kern/kern_clocksource.c:196 #17 0xffffffff810d0709 in timercb (et=3D0xffffffff81c528e8 ,=20= arg=3D) at /usr/src/sys/kern/kern_clocksource.c:353 #18 0xffffffff8110dad7 in lapic_handle_timer (frame=3D0xfffffe00f1009740) at /usr/src/sys/x86/x86/local_apic.c:1305 #19 0xffffffff80f849d0 in timerint_u () at /usr/src/sys/amd64/amd64/apic_vector.S:132 #20 0xfffffe00f1009828 in ?? () #21 0x000000000000b6b1 in ?? () #22 0x0000000000002000 in ?? () #23 0x00000000ffffdfff in ?? () #24 0x00c11c08e43e7fd5 in ?? () #25 0x00000000000003e8 in ?? () #26 0x00000000fffff1eb in ?? () #27 0xfffffe00f1009828 in ?? () #28 0xfffffe00f1009810 in ?? () #29 0x00000000800e6d01 in ?? () #30 0x0000000000000064 in ?? () #31 0xfffff8011d936560 in ?? () #32 0xfffffe00f1009828 in ?? () #33 0xffffffff81771014 in mtx_delay () #34 0x0000000000000000 in ?? () (kgdb)=20 . . . UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND . . . 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 [sshd] 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 = [script] 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 [xargs] 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 [xargs] . . . Context details: # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 = amd64 1200058 1200058 # svnlite status /usr/src | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/GENERIC-DBG ? /usr/src/sys/arm/conf/GENERIC-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp M /usr/src/crypto/openssl/crypto/armcap.c M /usr/src/lib/libkvm/kvm_powerpc.c M /usr/src/lib/libkvm/kvm_private.c M /usr/src/stand/defs.mk M /usr/src/stand/powerpc/boot1.chrp/Makefile M /usr/src/stand/powerpc/kboot/Makefile M /usr/src/sys/arm64/arm64/identcpu.c M /usr/src/sys/conf/kmod.mk M /usr/src/sys/conf/ldscript.powerpc M /usr/src/sys/kern/subr_pcpu.c M /usr/src/sys/powerpc/aim/mmu_oea64.c M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/interrupt.c M /usr/src/sys/powerpc/powerpc/mp_machdep.c M /usr/src/sys/powerpc/powerpc/trap.c M /usr/src/sys/vm/uma_core.c M /usr/src/usr.bin/top/machine.c The GENERIC* files include GENERIC and then set explicit debug status choices of mine. Most of the rest is tied to historical powerpc and powerpc64 investigations. I also have top report the maximum swap-in-use figure that it sees during its run. # svnlite diff /usr/src/sys/vm/uma_core.c Index: /usr/src/sys/vm/uma_core.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- /usr/src/sys/vm/uma_core.c (revision 329465) +++ /usr/src/sys/vm/uma_core.c (working copy) @@ -3428,7 +3428,7 @@ void uma_reclaim_wakeup(void) { - +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, = uma_kmem_total, uma_reclaim_needed); if (atomic_fetchadd_int(&uma_reclaim_needed, 1) =3D=3D 0) wakeup(uma_reclaim); } Side note: It took the automatic fsck and 2 manual fsck runs to get back to a clean status (before I could get to multi-user). =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 02:10:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26FA1F03C16 for ; Sun, 18 Feb 2018 02:10:29 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-12.consmr.mail.bf2.yahoo.com (sonic304-12.consmr.mail.bf2.yahoo.com [74.6.128.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B30217B993 for ; Sun, 18 Feb 2018 02:10:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 5pGTKJcVM1lFaTn92WsBY06zJcmkpSmw6pD7_Zxocn0zd137RjRa.YxdN7904yY AZ26x._0I9clW7llLfDUuBZzN9YdZafI6XL16ZIt8_ltXJSIhEd4fxhxmiNsxM63XLjRNWTGggq8 qALD29.GISsr2cRin5a0B4_FaLfraucCYpbYT3lMblQonqFNLp.HSfncJ9dz.azc6xOTFOvzpijY ROSA52QvNPYTTlMj09aZ62RCL6W8C1L80nZKMHCB2aDIjxPr_.NZMBbb4giW9_v_LQ_b0Gci4W5z iCIQZdSAIOVvLTwP2ZElvuLQx7MfvyI_QQIf.RlQQtCAHWR7BE3KhLcfEB6mib_d.AOeP32PDgcY H6k766YzwdW9vRtfB2sYcVfsT..PWbD0L3lt1nZtylN8ETx9p8rApCddn08kkvv.rRMFQszfSgA6 QWxXUhCDWY502MJbsUUlZDEsn000EXsHE5kd4oWkkDewSpDaBaiShkGzB13d8LA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Feb 2018 02:10:22 +0000 Received: from smtp101.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([68.142.231.32]) by smtp413.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 2402d0d8508818cd1bbc18952f7a8436; Sun, 18 Feb 2018 02:10:18 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Date: Sat, 17 Feb 2018 18:10:16 -0800 References: To: FreeBSD Current , FreeBSD Hackers In-Reply-To: Message-Id: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 02:10:29 -0000 [Some more information added, from /usr/libexec/kgdb use.] On 2018-Feb-17, at 5:39 PM, Mark Millard = wrote: > This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. > 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > Threadripper 1950X). No other Hyper-V use. >=20 > This happened during: >=20 > # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>>> Checking for old files >=20 >=20 > (Hand typed from a picture of a window's content > at slighly different times, expect typos:) >=20 > KDB: enter: panic > [thread pid 42170 tid 100752 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> call doadump > Dumping 4825 out of 110559 MB: ... (omitted) ... > Dump complete > =3D 0 >=20 >=20 > (The "pid 42170" identification as the process reporting the > issue does not seem to appear in the core.txt.0 file.) >=20 >=20 > # ls -lTdt /var/crash/* > -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 = /var/crash/core.txt.0 > lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 = /var/crash/vmcore.last -> vmcore.0 > lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 = /var/crash/info.last -> info.0 > -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 = /var/crash/vmcore.0 > -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 = /var/crash/info.0 > -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 = /var/crash/bounds > -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 = /var/crash/minfree >=20 > =46rom /var/crash/core.txt.0 : >=20 > Unread portion of the kernel message buffer: > spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long > panic: spin lock held too long > cpuid =3D 5 > time =3D 1518911834 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f10094d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 > panic() at panic+0x43/frame 0xfffffe00f1009590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f10095a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame = 0xfffffe00f1009610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 > handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 > timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame = 0xfffffe00f1009730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame = 0xfffffe00f1009880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame = 0x7fffffffcfc0 > KDB: enter: panic >=20 > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=3Dr" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=3D-2122191464) at = /usr/src/sys/kern/kern_shutdown.c:347 > #2 0xffffffff8040b42c in db_fncall_generic (addr=3D,=20= > rv=3D, nargs=3D, args=3D) > at /usr/src/sys/ddb/db_command.c:609 > #3 db_fncall (dummy1=3D, dummy2=3D,=20 > dummy3=3D, dummy4=3D) > at /usr/src/sys/ddb/db_command.c:657 > #4 0xffffffff8040af79 in db_command (last_cmdp=3D,=20 > cmd_table=3D, dopager=3D) > at /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff8040acf4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff8040df9f in db_trap (type=3D, = code=3D) > at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80b370e3 in kdb_trap (type=3D3, code=3D-61456, = tf=3D) > at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff80fa2c5c in trap (frame=3D0xfffffe00f1009400) > at /usr/src/sys/amd64/amd64/trap.c:547 > #9 > #10 kdb_enter (why=3D0xffffffff811f280b "panic", msg=3D) > at /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80aef17a in vpanic (fmt=3D, = ap=3D0xfffffe00f1009570) > at /usr/src/sys/kern/kern_shutdown.c:801 > #12 0xffffffff80aeefc3 in panic (fmt=3D0x0) > at /usr/src/sys/kern/kern_shutdown.c:739 > #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=3D,=20 > ldap=3D) at /usr/src/sys/kern/kern_mutex.c:1224 > #14 0xffffffff80acfb9b in thread_lock_flags_ (td=3D0xfffff818719d1000,=20= > opts=3D, file=3D, line=3D) > at /usr/src/sys/kern/kern_mutex.c:913 > #15 0xffffffff80a89d6c in statclock_cnt (cnt=3D1, usermode=3D) > at /usr/src/sys/kern/kern_clock.c:768 > #16 0xffffffff810d0003 in handleevents (now=3D43230207690178, fake=3D0) > at /usr/src/sys/kern/kern_clocksource.c:196 > #17 0xffffffff810d0709 in timercb (et=3D0xffffffff81c528e8 ,=20= > arg=3D) at /usr/src/sys/kern/kern_clocksource.c:353 > #18 0xffffffff8110dad7 in lapic_handle_timer = (frame=3D0xfffffe00f1009740) > at /usr/src/sys/x86/x86/local_apic.c:1305 > #19 0xffffffff80f849d0 in timerint_u () > at /usr/src/sys/amd64/amd64/apic_vector.S:132 > #20 0xfffffe00f1009828 in ?? () > #21 0x000000000000b6b1 in ?? () > #22 0x0000000000002000 in ?? () > #23 0x00000000ffffdfff in ?? () > #24 0x00c11c08e43e7fd5 in ?? () > #25 0x00000000000003e8 in ?? () > #26 0x00000000fffff1eb in ?? () > #27 0xfffffe00f1009828 in ?? () > #28 0xfffffe00f1009810 in ?? () > #29 0x00000000800e6d01 in ?? () > #30 0x0000000000000064 in ?? () > #31 0xfffff8011d936560 in ?? () > #32 0xfffffe00f1009828 in ?? () > #33 0xffffffff81771014 in mtx_delay () > #34 0x0000000000000000 in ?? () > (kgdb)=20 >=20 > . . . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > . . . > 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] > 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] > 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 = [sshd] > 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] > 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] > 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 = [script] > 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] > 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] > 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] > 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] > 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 = [xargs] > 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] > 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 = [xargs] > . . . >=20 >=20 >=20 >=20 > Context details: >=20 > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 = amd64 1200058 1200058 >=20 > # svnlite status /usr/src | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/stand/defs.mk > M /usr/src/stand/powerpc/boot1.chrp/Makefile > M /usr/src/stand/powerpc/kboot/Makefile > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/kern/subr_pcpu.c > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/interrupt.c > M /usr/src/sys/powerpc/powerpc/mp_machdep.c > M /usr/src/sys/powerpc/powerpc/trap.c > M /usr/src/sys/vm/uma_core.c > M /usr/src/usr.bin/top/machine.c >=20 > The GENERIC* files include GENERIC and then set explicit > debug status choices of mine. Most of the rest is tied to > historical powerpc and powerpc64 investigations. I also > have top report the maximum swap-in-use figure that it > sees during its run. >=20 > # svnlite diff /usr/src/sys/vm/uma_core.c > Index: /usr/src/sys/vm/uma_core.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/vm/uma_core.c (revision 329465) > +++ /usr/src/sys/vm/uma_core.c (working copy) > @@ -3428,7 +3428,7 @@ > void > uma_reclaim_wakeup(void) > { > - > +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, = uma_kmem_total, uma_reclaim_needed); > if (atomic_fetchadd_int(&uma_reclaim_needed, 1) =3D=3D 0) > wakeup(uma_reclaim); > } >=20 >=20 >=20 > Side note: It took the automatic fsck and 2 manual fsck > runs to get back to a clean status (before I could get to > multi-user). /usr/local/bin/kgdb did not seem to work. But /usr/libexec/kgdb seems to. (This is likely the first time that I've used a normal vmcore.* file on any architecture. On powerpc I had to hack things into a non-default way of working. On powerpc64 dumps used to fail.) # /usr/libexec/kgdb /usr/lib/debug/boot/kernel/kernel.debug = /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] . . . So here is what thread 100691 gets as a report in "info threads" --100752 shows "doadump", but of course was doing a fork at the time of the problem: (kgdb) info threads 558 Thread 100691 (PID=3D46769: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 . . . * 556 Thread 100752 (PID=3D42170: xargs) doadump (textdump=3D0x8181ed98) = at pcpu.h:230 . . . The bt for 558 (a.k.a. 100691) does not seem to have much information: (kgdb) thread 558 [Switching to thread 558 (Thread 100691)]#0 fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 840 movq %r12,%rdi /* function */ Current language: auto; currently asm (kgdb) bt #0 fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:840 #1 0xffffffff80f8398d in fast_syscall_common () at = /usr/src/sys/amd64/amd64/exception.S:480 #2 0x0000000800c43000 in ?? () #3 0x0000000000203353 in ?? () #4 0x0000000000000001 in .rodata () #5 0x0000000800c43008 in ?? () #6 0x00c11c08e43e7fd5 in ?? () #7 0x0000000000000000 in ?? () (kgdb)=20 But the kernel message buffer material reported: (repeated from the earlier Email) spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 = (tid 100691) too long I'll note that I have no known way to cause a repeat. I'd been doing the = same sort of build activity for a time when this happened. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 06:42:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9BB22F16ABA for ; Sun, 18 Feb 2018 06:42:19 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1CDCD85EE5 for ; Sun, 18 Feb 2018 06:42:18 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by cmsmtp with ESMTPA id nIdQeWl3NS4P1nIdQeIv0a; Sun, 18 Feb 2018 06:39:40 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=FqgrAVjq c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=x7bEGLp0ZPQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=6bavckKV9vLEK6uXkfEA:9 a=pILNOxqGKmIA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=3FUG5soVS_gqBxw3TGAA:9 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 Subject: redo version 1.4 To: debian-user@lists.debian.org, "supervision@list.skarnet.org" , FreeBSD Hackers References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> <556BA130.50708@NTLWorld.com> <5590108E.2060300@NTLWorld.com> From: Jonathan de Boyne Pollard Message-ID: Date: Sun, 18 Feb 2018 06:39:40 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <5590108E.2060300@NTLWorld.com> X-CMAE-Envelope: MS4wfKSN/vsfSJzbyJ1Z/1XFFwdwKSfYLinTjT2RMQyheQzUUS8NYNPxkGF4j91yg/YUdiMN0jWZ3erYtROSfbWIvU6+6snt2TnEkActpkzBRYLJfm5yrMOO yfKXgHSus7uxHehP4lf1BerkuOHHqDNso12L2w8VR3uoewwDaiQngr9TQlAAuy8kDCGf+SNKzDjNhtZiPozcov7fT+7bkcZ2JRpJCiJg8t6hvhk+IR/FGLDh fyM6tKvx3eZv2gV2AeqCCnOxf0qS1HsP0JHBDHy9G4/VOL5+bgoMgUmSsWw2BT1G Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 06:42:19 -0000 redo is now at version 1.4 * http://jdebp.eu./Softwares/redo/ The only change from 1.3 is a belt-and-braces protection mechanism that prevents cleanup code from being told to delete a parent directory. From owner-freebsd-hackers@freebsd.org Sun Feb 18 06:44:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34FBDF16CB3 for ; Sun, 18 Feb 2018 06:44:21 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A786586086 for ; Sun, 18 Feb 2018 06:44:20 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by cmsmtp with ESMTPA id nIhueWmOaS4P1nIhueIv5d; Sun, 18 Feb 2018 06:44:19 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=FqgrAVjq c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=x7bEGLp0ZPQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=itly7gIdAAAA:8 a=0NHqYHwywp948J4VwckA:9 a=pILNOxqGKmIA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=AIbBiAM4OkFb1w5TpD8A:9 a=sbnFMe1091WDK1FD:21 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=1RpNR2E4bTkVPcsa2RFZ:22 Subject: djbwares version 7 To: Debian users , FreeBSD Hackers , Supervision References: <736737774.3548811.1490898899979.JavaMail.open-xchange@oxbe11.tb.ukmail.iss.as9143.net> From: Jonathan de Boyne Pollard Message-ID: Date: Sun, 18 Feb 2018 06:44:18 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: X-CMAE-Envelope: MS4wfCDEMUBtzJW54EeQdPIIAXn+rtuGjzZF/7WNHuDF3cAT2ryvoBHmlHDczmzEic87QpS6ygHzy28NtV6qWo9G3VVfB3tT8SZoAOjYSfAxzeEGNPOe2q2r T7Kgc+tc6SKH9ai8LqyMh1rWbyiGzsKTMg0HGvjT9vI25qBz/vbQYH2j0KMULbTyjvP3l2pVwMzGoJM4Xka3gUGsK28Kj+f19tLcGXS1JJKQXLWsojJ8kkxm V/ReTHErQIcL18zKy43tevk+ydm1J8l1YRxj59ZqgMgJbeqkH/lUKgtklQrhxyHy Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 06:44:21 -0000 djbwares is now at version 7. * http://jdebp.eu./Softwares/djbwares/ * http://jdebp.info./Softwares/djbwares/ There are only a few changes. A common build problem across several toolsets that occurs if one has set a |CDPATH|, has been fixed. |dnscache| now has a |FORWARDFIRST| mode. And a bug in |tcpserver| that manifests itself when |tcpserver| inherits no open standard I/O file descriptors has been fixed. From owner-freebsd-hackers@freebsd.org Sun Feb 18 06:49:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 736E8F170A1 for ; Sun, 18 Feb 2018 06:49:03 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-7.server.virginmedia.net (know-smtprelay-omc-7.server.virginmedia.net [80.0.253.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6847862E1 for ; Sun, 18 Feb 2018 06:49:02 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.5] ([86.10.211.13]) by cmsmtp with ESMTPA id nImTeWnrNS4P1nImTeIv9B; Sun, 18 Feb 2018 06:49:01 +0000 X-Originating-IP: [86.10.211.13] X-Authenticated-User: J.deBoynePollard-newsgroups@NTLWorld.COM X-Spam: 0 X-Authority: v=2.3 cv=FqgrAVjq c=1 sm=1 tr=0 a=SB7hr1IvJSWWr45F2gQiKw==:117 a=SB7hr1IvJSWWr45F2gQiKw==:17 a=x7bEGLp0ZPQA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=2rVjqWD_AAAA:8 a=6I5d2MoRAAAA:8 a=itly7gIdAAAA:8 a=q-4CkQFgXClyL0JMpcoA:9 a=pILNOxqGKmIA:10 a=zJ3bSuzWvcgA:10 a=ENIBttV5YU4A:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=vLJDWwrnx0GbGVVtf-8A:9 a=_VtfyBh5AlR0VOQT:21 a=_W_S_7VecoQA:10 a=ULaUcM2Ibn9MdPUUwucP:22 a=IjZwj45LgO3ly-622nXo:22 a=1RpNR2E4bTkVPcsa2RFZ:22 Subject: nosh version 1.37 To: FreeBSD Hackers , Debian users , Supervision References: <54430B41.3010301@NTLWorld.com> <76c00c13-4cc9-ed9c-f48f-81a3f050b80b@NTLWorld.com> From: Jonathan de Boyne Pollard Message-ID: <5e8454f7-8b8d-ae9f-5aca-3b1b5737f81a@NTLWorld.COM> Date: Sun, 18 Feb 2018 06:49:01 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <76c00c13-4cc9-ed9c-f48f-81a3f050b80b@NTLWorld.com> X-CMAE-Envelope: MS4wfBz5KPUnxjqmFsiVKzh9M84C5Vd7T5EKujtsWaR8PutqfZ2YhCl0LA3syiWvWo6kVMxNgrP6iGtekw3gIsIZqQzK3743mFVozT+U52qa9d3TujjP/Bfc PPxuxpm3uRDFFOxmy09x8lZfpHjekzsvLUDmDYftKCKOsaT67C1pny0FUHYsj7Gpoty3E/ycJC7fhBxe8wTv/pLZS4+j4QQJ6W5F9850/hnGGZ9N+JpA4kNe OcIqP1GlRHLJycBdy7N/UaU7rVlmaMzxkXztF2lf+zkw9vG5aI/JqEsG3cJoBtsk Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 06:49:03 -0000 The nosh package is now up to version 1.37 . * http://jdebp.eu./Softwares/nosh/ * https://www.freebsd.org/news/status/report-2017-07-2017-09.html#The-nosh-Project * http://jdebp.info./Softwares/nosh/ Some of the changes in this release are works in progress, that you will see fully realized in version 1.38 or later. Changes include: * There is a new chapter in the /nosh Guide/ for those wishing to make packages and ports of other softwares, or add service bundle support to existing packages and ports. * The external formats configuration import subsystem has been reorganized a bit. o Nothing uses the |JAVA_HOME| import system any more, where service bundles explicitly have their |JAVA_||HOME| variables set by configuration import, although it is retained. All service bundles instead use the |find-matching-jvm| mechanism to auto-detect a JVM matching their chosen criteria at start time. o The per-user services import is now in two parts. System-wide import sets up a |$HOME/.config/service-bundles/convert/| subdirectory for each (real user) user account; and each user can then use that, which contains a subordinate per-user configuration import mechanism, to set up imported per-user service bundles for things. o Per-user service source files for Desktop Bus and other services are now in their own subdirectory, as are converted keyboard maps for the userspace virtual terminals. * |static-networking| external format configuration import has been enhanced to set up |snort@/interface/| services and to handle |ipv6_cpe_wanif| and |ipv6_activate_all_interfaces| from |/etc/rc.conf|. * There is a new |make-read-only-fs| chain loading tool that is a placeholder for now. It is used in some service bundles generated by the |convert-systemd-units| tool, which now recognizes and converts |CPUAffinity|, |ProtectHome|, |ProtectSystem|, |ReadWriteDirectories|, |ReadOnlyPaths|, and |InaccessiblePaths| settings. * Per-user management has been augmented, finally fixing the problem of |system-control| locating the per-user manager by giving the per-user manager an optional listening FIFO open file descriptor, which it uses to listen for user-wide state change commands. |system-control --user| |halt|/|normal|/|sysinit|/&c. now send commands via this FIFO, and each user's |user-services@/username/| service bundle now uses |fifo-listen| to set up the FIFO and creates the |per-user-manager/| subdirectory in |/run/user|. * There are some more service bundles in the collection that comes with the toolset: clickhouse-server, hue, udhcpc-log, minissdpd, rtkit-daemon, accounts-daemon, gdm3, speech-dispatcher, gdomap, blueman-mechanism, and sysvipc. * The per-user configuration import now recognizes and sets up per-user service bundles for a whole lot more per-user services. * On FreeBSD/TrueOS systems |setup-machine-id| now writes |/usr/local/etc/machine-id|. * The userspace virtual terminal services, the multiplexor and the terminal emulators, no longer run under the aegis of the |daemon| system account. Rather, they now have their own dedicated accounts under whose aegides they run. To go with that, there is now a |user-vt-realizer| group to which users can be added to grant them realizer (i.e. front-end I/O) access to the system-wide userspace virtual terminals. * A common build problem across several toolsets that occurs if one has set a |CDPATH|, has been fixed. Various tweaks have also been made to make life easier for Archnosh and ports to other operating systems. From owner-freebsd-hackers@freebsd.org Sun Feb 18 12:25:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D197CF03A29; Sun, 18 Feb 2018 12:25:39 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53A0773E3E; Sun, 18 Feb 2018 12:25:39 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1ICPI0w026091 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 13:25:18 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1ICPHNx026088; Sun, 18 Feb 2018 13:25:18 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 13:25:17 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 12:25:40 -0000 On Sat, 17 Feb 2018 17:39-0800, Mark Millard wrote: > This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > Threadripper 1950X). No other Hyper-V use. > > This happened during: > > # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host.sh check-old DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > Script started, output file is /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils-amd64-host-2018-02-17:15:56:20 > >>> Checking for old files > > > (Hand typed from a picture of a window's content > at slighly different times, expect typos:) > > KDB: enter: panic > [thread pid 42170 tid 100752 ] > Stopped at kdb_enter+0x3b: movq $0,kdb_why > db> call doadump > Dumping 4825 out of 110559 MB: ... (omitted) ... > Dump complete > = 0 > > > (The "pid 42170" identification as the process reporting the > issue does not seem to appear in the core.txt.0 file.) > > > # ls -lTdt /var/crash/* > -rw-r--r-- 1 root wheel 100792 Feb 17 16:09:18 2018 /var/crash/core.txt.0 > lrwxr-xr-x 1 root wheel 8 Feb 17 16:09:08 2018 /var/crash/vmcore.last -> vmcore.0 > lrwxr-xr-x 1 root wheel 6 Feb 17 16:09:08 2018 /var/crash/info.last -> info.0 > -rw------- 1 root wheel 5060296704 Feb 17 16:09:08 2018 /var/crash/vmcore.0 > -rw------- 1 root wheel 392 Feb 17 16:08:59 2018 /var/crash/info.0 > -rw-r--r-- 1 root wheel 2 Feb 17 16:08:59 2018 /var/crash/bounds > -rw-r--r-- 1 root wheel 5 Nov 22 04:34:36 2017 /var/crash/minfree > > >From /var/crash/core.txt.0 : > > Unread portion of the kernel message buffer: > spin lock 0xffffffff81b2dcc0 (sched lock 5) held by 0xfffff8011d936560 (tid 100691) too long > panic: spin lock held too long > cpuid = 5 > time = 1518911834 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00f10094d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1009530 > panic() at panic+0x43/frame 0xfffffe00f1009590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 0xfffffe00f10095a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1009610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1009650 > handleevents() at handleevents+0x113/frame 0xfffffe00f10096a0 > timercb() at timercb+0xa9/frame 0xfffffe00f10096f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1009730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1009810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1009880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1009930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1009980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1009ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffcfc0 > KDB: enter: panic > > __curthread () at ./machine/pcpu.h:230 > 230 __asm("movq %%gs:%1,%0" : "=r" (td) > (kgdb) #0 __curthread () at ./machine/pcpu.h:230 > #1 doadump (textdump=-2122191464) at /usr/src/sys/kern/kern_shutdown.c:347 > #2 0xffffffff8040b42c in db_fncall_generic (addr=, > rv=, nargs=, args=) > at /usr/src/sys/ddb/db_command.c:609 > #3 db_fncall (dummy1=, dummy2=, > dummy3=, dummy4=) > at /usr/src/sys/ddb/db_command.c:657 > #4 0xffffffff8040af79 in db_command (last_cmdp=, > cmd_table=, dopager=) > at /usr/src/sys/ddb/db_command.c:481 > #5 0xffffffff8040acf4 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:534 > #6 0xffffffff8040df9f in db_trap (type=, code=) > at /usr/src/sys/ddb/db_main.c:250 > #7 0xffffffff80b370e3 in kdb_trap (type=3, code=-61456, tf=) > at /usr/src/sys/kern/subr_kdb.c:697 > #8 0xffffffff80fa2c5c in trap (frame=0xfffffe00f1009400) > at /usr/src/sys/amd64/amd64/trap.c:547 > #9 > #10 kdb_enter (why=0xffffffff811f280b "panic", msg=) > at /usr/src/sys/kern/subr_kdb.c:479 > #11 0xffffffff80aef17a in vpanic (fmt=, ap=0xfffffe00f1009570) > at /usr/src/sys/kern/kern_shutdown.c:801 > #12 0xffffffff80aeefc3 in panic (fmt=0x0) > at /usr/src/sys/kern/kern_shutdown.c:739 > #13 0xffffffff80acfa31 in _mtx_lock_indefinite_check (m=, > ldap=) at /usr/src/sys/kern/kern_mutex.c:1224 > #14 0xffffffff80acfb9b in thread_lock_flags_ (td=0xfffff818719d1000, > opts=, file=, line=) > at /usr/src/sys/kern/kern_mutex.c:913 > #15 0xffffffff80a89d6c in statclock_cnt (cnt=1, usermode=) > at /usr/src/sys/kern/kern_clock.c:768 > #16 0xffffffff810d0003 in handleevents (now=43230207690178, fake=0) > at /usr/src/sys/kern/kern_clocksource.c:196 > #17 0xffffffff810d0709 in timercb (et=0xffffffff81c528e8 , > arg=) at /usr/src/sys/kern/kern_clocksource.c:353 > #18 0xffffffff8110dad7 in lapic_handle_timer (frame=0xfffffe00f1009740) > at /usr/src/sys/x86/x86/local_apic.c:1305 > #19 0xffffffff80f849d0 in timerint_u () > at /usr/src/sys/amd64/amd64/apic_vector.S:132 > #20 0xfffffe00f1009828 in ?? () > #21 0x000000000000b6b1 in ?? () > #22 0x0000000000002000 in ?? () > #23 0x00000000ffffdfff in ?? () > #24 0x00c11c08e43e7fd5 in ?? () > #25 0x00000000000003e8 in ?? () > #26 0x00000000fffff1eb in ?? () > #27 0xfffffe00f1009828 in ?? () > #28 0xfffffe00f1009810 in ?? () > #29 0x00000000800e6d01 in ?? () > #30 0x0000000000000064 in ?? () > #31 0xfffff8011d936560 in ?? () > #32 0xfffffe00f1009828 in ?? () > #33 0xffffffff81771014 in mtx_delay () > #34 0x0000000000000000 in ?? () > (kgdb) > > . . . > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > . . . > 0 1110 1102 0 33 0 12024 3076 ttyin D+ - 0:00.00 [sh] > 0 1120 1044 0 20 0 18572 7936 select Ds - 0:00.00 [sshd] > 1001 1123 1120 0 20 0 18936 8044 select D - 0:00.00 [sshd] > 1001 1124 1123 0 34 0 12120 3196 wait Ds - 0:00.00 [sh] > 0 1134 1124 0 22 0 12060 3148 wait D - 0:00.00 [su] > 0 1135 1134 0 20 0 12312 3244 wait D - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42072 1135 0 25 0 11464 3060 wait D+ - 0:00.00 [sh] > 0 42075 42072 0 20 0 10928 2480 select D+ - 0:00.00 [script] > 0 42076 42075 0 52 0 10160 1396 wait Ds+ - 0:00.00 [make] > 0 42108 42076 0 52 0 12236 3224 wait D+ - 0:00.00 [make] > 0 42168 42108 0 52 0 11496 3068 wait D+ - 0:00.00 [sh] > 0 42169 42168 0 52 0 12608 3568 pipewr D+ - 0:00.00 [make] > 0 42170 42168 0 72 0 10956 2284 - R+ - 0:00.00 [xargs] > 0 42171 42168 0 35 0 11500 3064 piperd D+ - 0:00.00 [sh] > 0 46769 42170 0 72 0 10956 2284 - ?VL+ - 0:00.00 [xargs] > . . . > > > > > Context details: > > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r329465M amd64 amd64 1200058 1200058 > > # svnlite status /usr/src | sort > ? /usr/src/sys/amd64/conf/GENERIC-DBG > ? /usr/src/sys/amd64/conf/GENERIC-NODBG > ? /usr/src/sys/arm/conf/GENERIC-DBG > ? /usr/src/sys/arm/conf/GENERIC-NODBG > ? /usr/src/sys/arm64/conf/GENERIC-DBG > ? /usr/src/sys/arm64/conf/GENERIC-NODBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG > ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG > M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp > M /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp > M /usr/src/crypto/openssl/crypto/armcap.c > M /usr/src/lib/libkvm/kvm_powerpc.c > M /usr/src/lib/libkvm/kvm_private.c > M /usr/src/stand/defs.mk > M /usr/src/stand/powerpc/boot1.chrp/Makefile > M /usr/src/stand/powerpc/kboot/Makefile > M /usr/src/sys/arm64/arm64/identcpu.c > M /usr/src/sys/conf/kmod.mk > M /usr/src/sys/conf/ldscript.powerpc > M /usr/src/sys/kern/subr_pcpu.c > M /usr/src/sys/powerpc/aim/mmu_oea64.c > M /usr/src/sys/powerpc/ofw/ofw_machdep.c > M /usr/src/sys/powerpc/powerpc/interrupt.c > M /usr/src/sys/powerpc/powerpc/mp_machdep.c > M /usr/src/sys/powerpc/powerpc/trap.c > M /usr/src/sys/vm/uma_core.c > M /usr/src/usr.bin/top/machine.c > > The GENERIC* files include GENERIC and then set explicit > debug status choices of mine. Most of the rest is tied to > historical powerpc and powerpc64 investigations. I also > have top report the maximum swap-in-use figure that it > sees during its run. > > # svnlite diff /usr/src/sys/vm/uma_core.c > Index: /usr/src/sys/vm/uma_core.c > =================================================================== > --- /usr/src/sys/vm/uma_core.c (revision 329465) > +++ /usr/src/sys/vm/uma_core.c (working copy) > @@ -3428,7 +3428,7 @@ > void > uma_reclaim_wakeup(void) > { > - > +printf("limit %lX, total %lX, needed %d\n", uma_kmem_limit, uma_kmem_total, uma_reclaim_needed); > if (atomic_fetchadd_int(&uma_reclaim_needed, 1) == 0) > wakeup(uma_reclaim); > } > > > > Side note: It took the automatic fsck and 2 manual fsck > runs to get back to a clean status (before I could get to > multi-user). The same thing happened to me on a VirtualBox VM running base/head r329515. This VM previously ran r329101 and I can easily revert to this version where the problem doesn't exist. See https://ximalas.info/~trond/base-head-r329515/ for core.txt.0 and info.0. Crash dump of roughly 1 GiB is available on request. I achieved an uptime of roughly 26 minutes before the panic set in. I was in the process of upgrading print/texinfo using portmaster when the crash occurred. xargs was the running process. Unread portion of the kernel message buffer: spin lock 0xffffffff80e76e80 (sched lock 0) held by 0xfffff800c58d4000 (tid 100746) too long panic: spin lock held too long cpuid = 0 time = 1518955069 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff804d281b = db_trace_self_wrapper+0x2b/frame 0xfffffe004b204610 vpanic() at 0xffffffff807106cd = vpanic+0x18d/frame 0xfffffe004b204670 panic() at 0xffffffff80710533 = panic+0x43/frame 0xfffffe004b2046d0 _mtx_lock_indefinite_check() at 0xffffffff806f0fa1 = _mtx_lock_indefinite_check+0x71/frame 0xfffffe004b2046e0 thread_lock_flags_() at 0xffffffff806f110b = thread_lock_flags_+0xdb/frame 0xfffffe004b204750 statclock_cnt() at 0xffffffff806ab0dc = statclock_cnt+0xdc/frame 0xfffffe004b204790 handleevents() at 0xffffffff80a72d73 = handleevents+0x113/frame 0xfffffe004b2047e0 timercb() at 0xffffffff80a73479 = timercb+0xa9/frame 0xfffffe004b204830 lapic_handle_timer() at 0xffffffff80ad6237 = lapic_handle_timer+0xa7/frame 0xfffffe004b204870 timerint_u() at 0xffffffff80a1f080 = timerint_u+0x96/frame 0xfffffe004b204950 thread_lock_flags_() at 0xffffffff806f10f1 = thread_lock_flags_+0xc1/frame 0xfffffe004b2049c0 fork1() at 0xffffffff806d124f = fork1+0x1b9f/frame 0xfffffe004b204a70 sys_vfork() at 0xffffffff806d17ec = sys_vfork+0x4c/frame 0xfffffe004b204ac0 amd64_syscall() at 0xffffffff80a3d6c8 = amd64_syscall+0xa48/frame 0xfffffe004b204bf0 fast_syscall_common() at 0xffffffff80a1e03d = fast_syscall_common+0x101/frame 0x7fffffffe000 Uptime: 26m5s Dumping 1003 out of 6123 MB:..2%..12%..21%..31%..42%..52%..61%..71%..82%..91% __curthread () at ./machine/pcpu.h:230 230 ./machine/pcpu.h: No such file or directory. (kgdb) #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:347 #2 0xffffffff80710200 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #3 0xffffffff8071072d in vpanic (fmt=, ap=0xfffffe004b2046b0) at /usr/src/sys/kern/kern_shutdown.c:812 #4 0xffffffff80710533 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:739 #5 0xffffffff806f0fa1 in _mtx_lock_indefinite_check (m=, ldap=) at /usr/src/sys/kern/kern_mutex.c:1224 #6 0xffffffff806f110b in thread_lock_flags_ (td=0xfffff8006205d000, opts=, file=, line=) at /usr/src/sys/kern/kern_mutex.c:913 #7 0xffffffff806ab0dc in statclock_cnt (cnt=1, usermode=) at /usr/src/sys/kern/kern_clock.c:768 #8 0xffffffff80a72d73 in handleevents (now=6721246917305, fake=0) at /usr/src/sys/kern/kern_clocksource.c:196 #9 0xffffffff80a73479 in timercb (et=0xffffffff80f80ad8 , arg=) at /usr/src/sys/kern/kern_clocksource.c:353 #10 0xffffffff80ad6237 in lapic_handle_timer (frame=0xfffffe004b204880) at /usr/src/sys/x86/x86/local_apic.c:1305 #11 0xffffffff80a1f080 in timerint_u () at /usr/src/sys/amd64/amd64/apic_vector.S:132 #12 0xfffffe004b204968 in ?? () #13 0x0000000000001b8d in ?? () #14 0x0000000000000800 in ?? () #15 0x00000000fffff7ff in ?? () #16 0x0000000080000034 in ?? () #17 0x00000000000001f4 in ?? () #18 0x00000000fffff8eb in ?? () #19 0xfffffe004b204968 in ?? () #20 0xfffffe004b204950 in ?? () #21 0x000000008000ba2f in ?? () #22 0x0000000000000032 in ?? () #23 0xfffff800c58d4000 in ?? () #24 0xfffffe004b204968 in ?? () #25 0xffffffff80c41014 in mtx_delay () #26 0x0000000000000000 in ?? () Looking at the commit logs, I suspect r329419, r329420, r329422, and/or r320449 being possible candidates. I'll try revert my source tree to r329418, and take it from there. -- Trond. From owner-freebsd-hackers@freebsd.org Sun Feb 18 17:35:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6AD8CF1AF41 for ; Sun, 18 Feb 2018 17:35:28 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic315-8.consmr.mail.gq1.yahoo.com (sonic315-8.consmr.mail.gq1.yahoo.com [98.137.65.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EB350815CF for ; Sun, 18 Feb 2018 17:35:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ioAI0.cVM1lRnXssqgmnZ2UmeUn4av3USwvkx1Omcl72ZhB8TmenK.miKxsNPpJ zQqJfqI1GePPocDdnqbZGW0TfUlBLjKggMHwM8OcFicz8r0826lpCQFzC4TfOqX1ZDS0zu8.I.lV j.2s11dH96339AmHQj0IC02bCyV.mgxGxXh4Vou4S6lpZimnD54sRB4Ci1430nEhaV92Gpjg8Gv1 5YyTDJru3xmN96NLh3rtu.O4X170YWgYE8KR1nY8fvo5VuSSxBpjq94gmamDmQIArEnzwnnsqIoK UIybJ.fsxs7j5PlSzCc_ABdF.I9QnWjDZXjXihVnZVPcN9_G53fWq9IfxnalvvrhUIJ5Li_ihPDa gwwu4UbLRUl7Yy2kA6KvUNlK.nLbN6wTg7CXiPQMjUw188NqBTObHFxKcOk_YhCDFjy6.cAkmtlR uVKUTplASFU_3urcmD5mzBySDxPbLlC1ZMIotpZhHgJE4ovLi.sVth0XOE9R5Re0qhRDw Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 17:35:21 +0000 Received: from smtp104.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.214]) by smtp402.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 96e403d0707c1cd692e984bac48f01ad; Sun, 18 Feb 2018 17:35:17 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork Date: Sun, 18 Feb 2018 09:35:16 -0800 References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> To: FreeBSD Current , FreeBSD Hackers In-Reply-To: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> Message-Id: <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 17:35:28 -0000 On 2018-Feb-17, at 6:10 PM, Mark Millard = wrote: > [Some more information added, from /usr/libexec/kgdb use.] >=20 > On 2018-Feb-17, at 5:39 PM, Mark Millard = wrote: >=20 >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro = machine. >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen >> Threadripper 1950X). No other Hyper-V use. Trond's report seems to be for a "4 core" Intel i7 context (as seen by FreeBSD in virtual box). So Ryzen seems to be non-essential for reproduction. Both of our reports are from some form of using FreeBSD in a virtual machine (Hyper-V and VirtualBox). I do not know if that is a required type of context or not. >> This happened during: >>=20 >> # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils >> Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >>>>> Checking for old files >>=20 I got another example but during a buildworld: >>> Deleting stale files in build tree... cd /usr/src; MACHINE_ARCH=3Dpowerpc64 MACHINE=3Dpowerpc CPUTYPE=3D = BUILD_TOOLS_META=3D.NOMETA CC=3D"cc -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX=3D"c++ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP=3D"cpp -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" = AS=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/as" = AR=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" = LD=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=3D"" = NM=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/nm = OBJCOPY=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/ranlib = STRINGS=3D/usr/local/bin/powerpc64-unknown-freebsd12.0-strings = SIZE=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/o= bj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.power= pc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_a= ltbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/= bin:/usr/sbin:/usr/bin = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp make -f Makefile.inc1 BWPHASE=3Dworldtmp = DESTDIR=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp -DBATCH_DELETE_OLD_FILES delete-old = delete-old-libs >/dev/null load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k make: Working in: = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc= .powerpc64 packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe (I noticed the long pause and got the ^T in before the panic.) Yet again it is xargs related fork activity that gets the problem (from = core.txt.1 ): 561 Thread 100836 (PID=3D69982: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 . . . * 559 Thread 100811 (PID=3D62304: xargs) doadump (textdump=3D-2122191464)= at pcpu.h:230 spin lock 0xffffffff81b3cf00 (sched lock 24) held by 0xfffff806aa6d5000 = (tid 100836) too long panic: spin lock held too long cpuid =3D 24 time =3D 1518974055 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f11304d0 vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 panic() at panic+0x43/frame 0xfffffe00f1130590 _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f11305a0 thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1130610 statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1130730 timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1130880 fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffc5a0 =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 18:08:08 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D6FFF1D9D1; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0744382ED8; Sun, 18 Feb 2018 18:08:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id v90so6963034qte.12; Sun, 18 Feb 2018 10:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=MC4uFCPU9o5Ih7ORz48ie/x1LY2t3QACrkuaTLpZKPB1RTBIgR+SMVBJbOk40TyLn5 iIt1BClBfB+F4uI8SKz3VCb9UyVe64PTq6LIQ+CpcMrecAoiS5bAGigXxrAPTWQzt1i2 AsR4DrMEmuZnp6jZi9ujIhfLkNKcqTpVmYlQCylaiuP4es/R7UD4997sULko7s8qmsXU UzBE2e6uXm3VjNHGBK0k5XOGH4E472cOnGHQVGA5HMsbmMbcdjxKmEiwyCTcJU8EP835 Czs5+FBurGdwJqKqsr/kECDtnxuiR2IM7u1L6UhEmDFZt+2CPmQ2h1BTSO0ecLZ0P5YB NdfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m+LrZUy3RpK+YZmHv8DL7+nGCBlfbj/EGQYxYpkRu0Y=; b=SAP+Ji0RI0C0zIo2ISIszlk2kWmkG7Yq4u0kHPt4CCw9YNQqV0cpwSK0usHPmMQhJB 6y0FdDQQ1kJifnpAlfp++WbunFOvfYN6KeUYgMJyyk5nKKIw+RoZS3epUZKsxHynN4vk IrshpR+dkyNX/K6kr89A3HvXhY6jjhwYxjrShX7nJSnoI2x2geEGFpz9kjun6dCyNEr6 ZHZJwa9YviCy57FBv6ZPw5T+M/7zhcmVPgDTMKwYkz3hPSmcfJwJ6iWXKVc0zRx5sRFn P9EteRwzGJpVNT9mme5spCsQy1KYpBo/S+lBBdt7YlescS/hrAQKGQ9xiMqElS6IysAC iUQQ== X-Gm-Message-State: APf1xPAExGn3ZU+ZB04GJyr0UizDsFu93n2qmga6+ekcANSz8FTk6oQr kRbdK7Q27uzX4KKKrvJJkm7+kXF34EfAnDoPYWI= X-Google-Smtp-Source: AH8x225nxW9c4CsaZ7LS+bMN1XEaYpHsQxqpAGlxP9cnM2fz7V6+/MWdXJJwrNp00Fh6YugJPS0w4sNsWD3CYd3yfxk= X-Received: by 10.200.38.188 with SMTP id 57mr6877681qto.220.1518977287640; Sun, 18 Feb 2018 10:08:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 10:08:07 -0800 (PST) In-Reply-To: <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 19:08:07 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mark Millard Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 18:08:08 -0000 Can you please bisect this? There is another report stating that r329418 works fine. On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: > > On 2018-Feb-17, at 6:10 PM, Mark Millard > wrote: > > > [Some more information added, from /usr/libexec/kgdb use.] > > > > On 2018-Feb-17, at 5:39 PM, Mark Millard > wrote: > > > >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro machine. > >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS files. > >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen > >> Threadripper 1950X). No other Hyper-V use. > > Trond's report seems to be for a "4 core" Intel i7 context (as seen > by FreeBSD in virtual box). So Ryzen seems to be non-essential for > reproduction. > > Both of our reports are from some form of using FreeBSD in a virtual > machine (Hyper-V and VirtualBox). I do not know if that is a required > type of context or not. > > >> This happened during: > >> > >> # ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_ > nodebug_clang_altbinutils-amd64-host.sh check-old > DESTDIR=/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils > >> Script started, output file is /root/sys_typescripts/ > typescript_make_powerpc64vtsc_nodebug_clang_altbinutils- > amd64-host-2018-02-17:15:56:20 > >>>>> Checking for old files > >> > > I got another example but during a buildworld: > > >>> Deleting stale files in build tree... > cd /usr/src; MACHINE_ARCH=powerpc64 MACHINE=powerpc CPUTYPE= > BUILD_TOOLS_META=.NOMETA CC="cc -target powerpc64-unknown-freebsd12.0 > --sysroot=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX="c++ -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP="cpp -target > powerpc64-unknown-freebsd12.0 --sysroot=/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" > AS="/usr/local/powerpc64-unknown-freebsd12.0/bin/as" > AR="/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" > LD="/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK="" > NM=/usr/local/powerpc64-unknown-freebsd12.0/bin/nm > OBJCOPY="/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" > RANLIB=/usr/local/powerpc64-unknown- > freebsd12.0/bin/ranlib STRINGS=/usr/local/bin/ > powerpc64-unknown-freebsd12.0-strings SIZE="/usr/local/powerpc64-unknown-freebsd12.0/bin/size" > INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/powerpc64vtsc_ > clang_altbinutils/powerpc.powerpc64/usr/src/powerpc. > powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > legacy/usr/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/ > usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/ > usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin > SYSROOT=/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > make -f Makefile.inc1 BWPHASE=worldtmp DESTDIR=/usr/obj/ > powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp > -DBATCH_DELETE_OLD_FILES delete-old d > elete-old-libs >/dev/null > > load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k > make: Working in: /usr/obj/powerpc64vtsc_clang_ > altbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64 > packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe > > > (I noticed the long pause and got the ^T in before the panic.) > > Yet again it is xargs related fork activity that gets the problem (from > core.txt.1 ): > > 561 Thread 100836 (PID=69982: xargs) fork_trampoline () at > /usr/src/sys/amd64/amd64/exception.S:840 > . . . > * 559 Thread 100811 (PID=62304: xargs) doadump (textdump=-2122191464) at > pcpu.h:230 > > spin lock 0xffffffff81b3cf00 (sched lock 24) held by 0xfffff806aa6d5000 > (tid 100836) too long > panic: spin lock held too long > cpuid = 24 > time = 1518974055 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfffffe00f11304d0 > vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 > panic() at panic+0x43/frame 0xfffffe00f1130590 > _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame > 0xfffffe00f11305a0 > thread_lock_flags_() at thread_lock_flags_+0xdb/frame 0xfffffe00f1130610 > statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 > handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 > timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 > lapic_handle_timer() at lapic_handle_timer+0xa7/frame 0xfffffe00f1130730 > timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 > thread_lock_flags_() at thread_lock_flags_+0xc1/frame 0xfffffe00f1130880 > fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 > sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 > amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffffffc5a0 > > > > > === > Mark Millard > marklmi at yahoo.com > ( markmi at dsl-only.net is > going away in 2018-Feb, late) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Mateusz Guzik From owner-freebsd-hackers@freebsd.org Sun Feb 18 19:30:44 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C5281F23C60; Sun, 18 Feb 2018 19:30:44 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4079086BA6; Sun, 18 Feb 2018 19:30:43 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IJUYlY028458 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 20:30:34 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IJUY5K028455; Sun, 18 Feb 2018 20:30:34 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 20:30:34 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 19:30:44 -0000 On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that r329418 > works fine. My problems started yesterday with r329464. I decided to go back to r329101 (ZFS BE), update the source tree, move forward to the latest revision, and so on. I even emptied /usr/obj and /var/cache/ccache and set WITHOUT_SYSTEM_COMPILER=yes in /etc/src.conf to get rid of any bias. I have tried with success r329418, r329419, r329420, and r329422. I'm now at r329448 and have not seen any spin lock problems so far. Sooner or later I'll reach r329464 and by then it should be clear which revision is the likely culprit. -- Trond. From owner-freebsd-hackers@freebsd.org Sun Feb 18 19:52:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09858F25238 for ; Sun, 18 Feb 2018 19:52:05 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A473E87B8B for ; Sun, 18 Feb 2018 19:52:04 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: 5uz4meQVM1kbbDfbbDEEecZVxP3jU75lHCnMSy2oMdaCEOWIwMjI6k86bWoYsyi QRhNU87cnIe1MnK293QAur7PsNlbuouVpXjz74x07mZAZkItVZW5geiHqpia87ldFt3RTnUOiksL 6mx8kdj_jki.Ubl8h0pJvtAd_z72ZKLFpXHTw6e5LDu4SpHDKpyki71UWA77iH5BUzxXEPTRiBxr uK_cQpLe9NWdfAcW1PZ.J5oYFK08bJkuW8km4fEvsvHB.9NzONsYnDCytZtB9Essh3lOc_gjTG0v 4NYgYOjU99fkC0CTJ0PPs9R6tXK37et3yh6mLYhy_4Uujkj06_mdJaXawt.cQy1tLdtex7ExeaBg VT.sWQdXVpebk.P5eyTnBMQnH6mxhCff9axVu.WsivUbj.v4rr8GlwOySoAHu3I7oI6YJ918IpRr .hcg8LtYrb2kec3NasmcGygxX78AYNUZqpjcPFyQd6KH00VRiyncS_V4PQQdc_MDvd8JZ Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sun, 18 Feb 2018 19:51:58 +0000 Received: from smtp101.rhel.mail.bf1.yahoo.com (EHLO [192.168.1.25]) ([68.142.231.32]) by smtp409.mail.bf1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID ba15a840364f155c1584bae7ccf8d823; Sun, 18 Feb 2018 19:51:56 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 11:51:52 -0800 Cc: FreeBSD Current , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> To: =?utf-8?Q?Trond_Endrest=C3=B8l?= X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 19:52:05 -0000 On 2018-Feb-18, at 11:30 AM, Trond Endrest=C3=B8l wrote: > On Sun, 18 Feb 2018 19:08+0100, Mateusz Guzik wrote: >=20 >> Can you please bisect this? There is another report stating that = r329418 >> works fine. >=20 > My problems started yesterday with r329464. I decided to go back to=20 > r329101 (ZFS BE), update the source tree, move forward to the latest=20= > revision, and so on. I even emptied /usr/obj and /var/cache/ccache and=20= > set WITHOUT_SYSTEM_COMPILER=3Dyes in /etc/src.conf to get rid of any=20= > bias. >=20 > I have tried with success r329418, r329419, r329420, and r329422. >=20 > I'm now at r329448 and have not seen any spin lock problems so far. Note: -r329448 was reverted in -r329461 : racy. > Sooner or later I'll reach r329464 and by then it should be clear=20 > which revision is the likely culprit. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 20:08:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75574F26412 for ; Sun, 18 Feb 2018 20:08:22 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic313-11.consmr.mail.ne1.yahoo.com (sonic313-11.consmr.mail.ne1.yahoo.com [66.163.185.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F1AAA68735 for ; Sun, 18 Feb 2018 20:08:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: VCF2V70VM1m5bNANyuWvqveT_.28d5TVYU_3NdrPK4jcdrx8PpPN05eYtzcqEyb IAud.U9o_p75UbRHY0QhyrqMfyz3KtvXfp94OpqyEi3IbEpn7k1ONgKBjZDK0cj8_vYGCWTeOZHf 12EVMu7FYZ9Bkp9FYKL5ghN1NzXaXhNBJWwW9DSO2XJWweE_BQpU6clUSg60_E.AZ60WFxHdbtL1 IjpdyIbHInjMqcHGp69RlEkIP9JWFLkm14vj9Vwg5CYyO1s6G2EASKeNBwrX9q3L3kP12q18fg1G GMFFAnvCjTdTjZ9TWxyqcbdPIL91ZsCDghI8dLz7dI9ZpXsC25P3hJbaSpkfbLTvLm8GKcYQ_PPG yCvoMpQtxOhFdVMGi4x37EPVBeSIlnW6NCTYRWyzSmXjYc9BQ2mwzaWuKaYNgOx5E.YXy2h1fRv0 A9XpWFvz4Nh33gBiNxcYexeQseEdOjomfzu1Xmc7bpePJbNjHg0zNSiEynY5gcd4jg.ww Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Feb 2018 20:08:20 +0000 Received: from smtp231.mail.ne1.yahoo.com (EHLO [192.168.1.25]) ([10.218.253.210]) by smtp412.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 9cb940f2491913eaffd95b58e217359f; Sun, 18 Feb 2018 19:48:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 11:48:05 -0800 Cc: FreeBSD Current , FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <7914AB08-AC79-4D83-BBD7-CE8B78070624@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:08:22 -0000 On 2018-Feb-18, at 10:08 AM, Mateusz Guzik wrote: > Can you please bisect this? There is another report stating that = r329418 works fine. I saw that Trond indicated an intent to test -r329418 but I've not seen any reports about -r329418 or how much activity was used to make any judgment about its status. But I can assume -r329418 is good if you want. Bisecting is likely going to be problematical for self-updates: builds and installs and such can crash, making the installs risky. I do not have an alternate builder for amd64 set up. Even without that, it is not clear how many hours of build-related = activity it takes to have a high probability that the problem is gone. (I've seen widely variable amounts of activity between failures in -r329465 .) It = is obvious to try an earlier version after failure but not obvious when to try a later version. My FreeBSD time is also rather limited (compared to historically over = the last few years), so the activity could be spread over parts of various weekends, depending on how it goes. >> On Sun, Feb 18, 2018 at 6:35 PM, Mark Millard wrote: >>=20 >> On 2018-Feb-17, at 6:10 PM, Mark Millard wrote: >>=20 >> > [Some more information added, from /usr/libexec/kgdb use.] >> > >> > On 2018-Feb-17, at 5:39 PM, Mark Millard wrote: >> > >> >> This is for FreeBSD running under Hyper-V on a Windows 10 Pro = machine. >> >> The FreeBSD "disk" bindings are to SSDs, not the insides of NTFS = files. >> >> 29 logical processors assigned to FreeBSD (on a 32-thread Ryzen >> >> Threadripper 1950X). No other Hyper-V use. >>=20 >> Trond's report seems to be for a "4 core" Intel i7 context (as seen >> by FreeBSD in virtual box). So Ryzen seems to be non-essential for >> reproduction. >>=20 >> Both of our reports are from some form of using FreeBSD in a virtual >> machine (Hyper-V and VirtualBox). I do not know if that is a required >> type of context or not. >>=20 >> >> This happened during: >> >> >> >> # = ~/sys_build_scripts.amd64-host/make_powerpc64vtsc_nodebug_clang_altbinutil= s-amd64-host.sh check-old = DESTDIR=3D/usr/obj/DESTDIRs/clang-powerpc64-installworld_altbinutils >> >> Script started, output file is = /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinut= ils-amd64-host-2018-02-17:15:56:20 >> >>>>> Checking for old files >> >> >>=20 >> I got another example but during a buildworld: >>=20 >> >>> Deleting stale files in build tree... >> cd /usr/src; MACHINE_ARCH=3Dpowerpc64 MACHINE=3Dpowerpc CPUTYPE=3D = BUILD_TOOLS_META=3D.NOMETA CC=3D"cc -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CXX=3D"c++ -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" CPP=3D"cpp -target = powerpc64-unknown-freebsd12.0 = --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr= /src/powerpc.powerpc64/tmp = -B/usr/local/powerpc64-unknown-freebsd12.0/bin/" = AS=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/as" = AR=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ar" = LD=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/ld" LLVM_LINK=3D"" = NM=3D/usr/local/powerpc64-unknown-freebsd12.0/bin/nm = OBJCOPY=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/objcopy" = RANLIB=3D/usr/local/powerpc64-unknown- >> freebsd12.0/bin/ranlib = STRINGS=3D/usr/local/bin/powerpc64-unknown-freebsd12.0-strings = SIZE=3D"/usr/local/powerpc64-unknown-freebsd12.0/bin/size" INSTALL=3D"sh = /usr/src/tools/install.sh" = PATH=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/= powerpc.powerpc64/tmp/legacy/usr/sbin:/usr/obj/powerpc64vtsc_clang_altbinu= tils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/legacy/usr/bin:/usr/o= bj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.power= pc64/tmp/legacy/bin:/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.power= pc64/usr/src/powerpc.powerpc64/tmp/usr/sbin:/usr/obj/powerpc64vtsc_clang_a= ltbinutils/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/bin:/sbin:/= bin:/usr/sbin:/usr/bin = SYSROOT=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp make -f Makefile.inc1 BWPHASE=3Dworldtmp = DESTDIR=3D/usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/s= rc/powerpc.powerpc64/tmp -DBATCH_DELETE_OLD_FILES delete-old d >> elete-old-libs >/dev/null >>=20 >> load: 0.68 cmd: make 62180 [select] 25.15r 0.00u 0.00s 0% 1468k >> make: Working in: = /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc= .powerpc64 >> packet_write_wait: Connection to 192.168.1.165 port 22: Broken pipe >>=20 >>=20 >> (I noticed the long pause and got the ^T in before the panic.) >>=20 >> Yet again it is xargs related fork activity that gets the problem = (from core.txt.1 ): >>=20 >> 561 Thread 100836 (PID=3D69982: xargs) fork_trampoline () at = /usr/src/sys/amd64/amd64/exception.S:840 >> . . . >> * 559 Thread 100811 (PID=3D62304: xargs) doadump = (textdump=3D-2122191464) at pcpu.h:230 >>=20 >> spin lock 0xffffffff81b3cf00 (sched lock 24) held by = 0xfffff806aa6d5000 (tid 100836) too long >> panic: spin lock held too long >> cpuid =3D 24 >> time =3D 1518974055 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame = 0xfffffe00f11304d0 >> vpanic() at vpanic+0x18d/frame 0xfffffe00f1130530 >> panic() at panic+0x43/frame 0xfffffe00f1130590 >> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame = 0xfffffe00f11305a0 >> thread_lock_flags_() at thread_lock_flags_+0xdb/frame = 0xfffffe00f1130610 >> statclock_cnt() at statclock_cnt+0xdc/frame 0xfffffe00f1130650 >> handleevents() at handleevents+0x113/frame 0xfffffe00f11306a0 >> timercb() at timercb+0xa9/frame 0xfffffe00f11306f0 >> lapic_handle_timer() at lapic_handle_timer+0xa7/frame = 0xfffffe00f1130730 >> timerint_u() at timerint_u+0x96/frame 0xfffffe00f1130810 >> thread_lock_flags_() at thread_lock_flags_+0xc1/frame = 0xfffffe00f1130880 >> fork1() at fork1+0x1b9f/frame 0xfffffe00f1130930 >> sys_vfork() at sys_vfork+0x4c/frame 0xfffffe00f1130980 >> amd64_syscall() at amd64_syscall+0xa48/frame 0xfffffe00f1130ab0 >> fast_syscall_common() at fast_syscall_common+0x101/frame = 0x7fffffffc5a0 >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 20:39:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C82CCF01E56; Sun, 18 Feb 2018 20:39:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F60D6A25E; Sun, 18 Feb 2018 20:39:03 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IKctK8028855 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 21:38:55 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IKctkA028852; Sun, 18 Feb 2018 21:38:55 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 21:38:55 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 20:39:04 -0000 On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > Note: -r329448 was reverted in -r329461 : racy. True. I got a crash when compiling r329451 while running r329449. I've now booted the r329422 ZFS BE and I'm attempting to build r329529. -- Trond. From owner-freebsd-hackers@freebsd.org Sun Feb 18 21:33:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C374F0634B; Sun, 18 Feb 2018 21:33:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 316046CDCD; Sun, 18 Feb 2018 21:33:28 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id d26so10064539qtk.10; Sun, 18 Feb 2018 13:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fl+Rag2s3g1SHTkqSikrKV27NR9wBXoYAC9YZ7einYs=; b=LaBo/jK9gL8dxtuy7Dl85P4Zms7zxynHW+lx5OWx3dp212Fua/P8rlly9D/9G0X/6g 4a3MvRsEzos7Zdu7vv0puhUvQcyqvWuPuzEG/C/k2+zk1r/ffXixw4SiZoXEQJShBiBr qYyZec07T6cLCWx4tReDfKpfB0HpnFZwRPSXR8kKyCCQL4EOTcs1DRC57bGMTbJbxrk2 WLu+b5nQK4d+cnzqBlgWx4dOdyGbE7+z7RNQt9oncQKz6cjlUcvp//piKQj6zc2NwAkr Gwh0KSKPtJdYrICs0NMcK5P3rpRmcOuMVp55G6Idr9mxaZYyTWpTVEXT1ynTNviabCBc DB4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fl+Rag2s3g1SHTkqSikrKV27NR9wBXoYAC9YZ7einYs=; b=Qy5wTjAqWXXIa+pmJDQQDWQ2DvKTI4BPTRZIY9LH7PfRajLGZnaTpal4FabhCcA5/+ 0jEGBc4uQAE2kVjOlh+Ra6jhK1dc15/Xt0h1IjbO+3UEbmCYe4ZhobLALNbRw+oonXne Cr+79hGXsL7x/OXQeGajsD8wKkKweSMAEtUPaSfGG7NOR13vHczcSLVcl8jMt3UBvICx XEIjLGTGuRsLOehufS92AXCoWWvocUDTN/PNFCDNebnjv5uFhEiiWl9Rb31hRLlbELJf i3yCHmFLyI4ZVMmIhOwcp/SJIOePBKNWjC0SY4pffSZng+QcvPsMdbh0FTpYsCBjdUkV /roA== X-Gm-Message-State: APf1xPBlvQYOS5Gj6VGh5+2JRcu4FD6ylUmZPKg7mg4ygWhnm169kc2t JSp0kS6WK+neuiZrtCXsDjqpPIFWNjtCUlzGsBaxTg== X-Google-Smtp-Source: AH8x225LYUGRZp5MBhVgx4r6dUPNGX6EPaRdW2PqOFjED/Yk4nnxO74oNgKjY5nMKoAsZgVn2a2G2cxphMKaWz1Ftlw= X-Received: by 10.200.38.188 with SMTP id 57mr7516794qto.220.1518989607871; Sun, 18 Feb 2018 13:33:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 13:33:27 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 22:33:27 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:33:28 -0000 On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > Note: -r329448 was reverted in -r329461 : racy. > > True. I got a crash when compiling r329451 while running r329449. > I've now booted the r329422 ZFS BE and I'm attempting to build > r329529. > Looking around strongly suggests r329448 is the culprit. If you can verify 329447 works fine we are mostly done here. Note the revision got reverted and different variant got in in r329531. That said, if r329447 works then the issue should be already fixed and in particular fresh head should work fine. --=20 Mateusz Guzik From owner-freebsd-hackers@freebsd.org Sun Feb 18 21:50:19 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F719F079CC for ; Sun, 18 Feb 2018 21:50:19 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8B716D7CE for ; Sun, 18 Feb 2018 21:50:18 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: g5wpv9YVM1nU3Vz3DKsJEL6Q2sWuv8hXQpTKHWGLF35CrM5wSlsndSxpmi1XN1g 7tzTr9FWILKNJEDqtYhEr6DubmNk69bx21YEHbxEd8T1sz346uUAmlVGZljHOYVOKgIiatr2paZU dYc4duWszmVpzxjGL__2JcqT0ojVWFo8hnyaoyCNJcz4j6VYLdi8RUAkJD7JtJ2sWaq_Ox8M8aVZ QJvzkv_nk9cBZ_Brzr3Y8yqVrqAxM_3nS72bq09jMsfZAVAIIxxMwUHqn75zflALFzsmNS6pEQFl tiPE.p_Lzg2GWSGfUU41MzuANC2ChayS0N7PBZPWqNGhA6XmuPFGRsOVy0JCM1r_638vmXTfEkK_ mRnkf6KdW.wTM54NXOgCqY3t_ukpIEcjjB9FKHaPDrP79dgi4AwVO6gqnsAtprNcKvmsa6nKKao2 ZJMN5QVrQTI.GsaYhGU1ActL3xRnfzGsFhX0FwtSjmauoDr6E62Fg7dv6zDmpZBpszL4u Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Sun, 18 Feb 2018 21:50:17 +0000 Received: from smtp104.rhel.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([216.39.57.214]) by smtp405.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 3be2782e0ba0a0d55693c0e3a45b5691; Sun, 18 Feb 2018 21:50:16 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 13:50:15 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:50:19 -0000 On 2018-Feb-18, at 1:46 PM, Mark Millard = wrote: > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: >=20 >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < >> Trond.Endrestol@fagskolen.gjovik.no> wrote: >>=20 >>> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >>>=20 >>>> Note: -r329448 was reverted in -r329461 : racy. >>>=20 >>> True. I got a crash when compiling r329451 while running r329449. >>> I've now booted the r329422 ZFS BE and I'm attempting to build >>> r329529. >>>=20 >>=20 >> Looking around strongly suggests r329448 is the culprit. If you can = verify >> 329447 works fine we are mostly done here. >>=20 >> Note the revision got reverted and different variant got in in = r329531. >>=20 >> That said, if r329447 works then the issue should be already fixed = and in >> particular fresh head should work fine. >=20 > My initial problem was with -r329465, which is after -r329461 reverted > -r329488 . Trond reported in one note that he had problems with > -r329464 , also after -r329488 was reverted. Trond has also reported > -r329449 failed. Dumb typos above: I meant -r329448 instead of -r329488 both times. > I did manage to revert to -r329447 earlier and so far the results > suggests that it works. >=20 > =46rom this I get that -r329449 is the the one that is common to > all the so--far failing combinations. -r329448 is not common to > all of them. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 21:56:14 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1ACCEF0858E for ; Sun, 18 Feb 2018 21:56:14 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic312-22.consmr.mail.ne1.yahoo.com (sonic312-22.consmr.mail.ne1.yahoo.com [66.163.191.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A76C86E047 for ; Sun, 18 Feb 2018 21:56:13 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: ZJnuUqAVM1kwCETSo7fp8SGPq0DVfwTww6TMElF1laG7VZFwTuX2orhVolTUroY SumsBGVM1aoxLF39uzD7VZg6pjNVwGFdPhBqbIt6LZ3finw0qj3UrLAkM8Y91jOj3IT85G1znwKo 2naSM5p9Q4qgLzCUIkiLZbM3QnhJwHF8AupFCtA8DUmJr3giDPt0WTKKYU3FdSaPIlioukUjgmrl KRqgqq2a9q.3OuyN6GzFNY9iNVnPKhJiLWFZ2V0aejz6t82p5ByehFPcC_OtgEj4cqYSLtauQWeS 3m9N1N5kyVoKA6SPniqnsgHh5DPc282fcfXF55MmgwQAqHdCWftq.FBSmVG1w4BIM1FVU3fqD81M _hdxLZA7LOVT3HJqWDnzAG3z8xyLNmA9n4v3OES.vTPT4r33ZzIwuyfuDhFEvzielgbIUhtmaLvQ G7EHz54vWciwsP05WAAcUpRZQzDJXIQsfcbGqKcBQ5rghbVXi53z_Z0sjtdZRUjcZOWoQ Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.ne1.yahoo.com with HTTP; Sun, 18 Feb 2018 21:56:12 +0000 Received: from smtpgate102.mail.ne1.yahoo.com (EHLO [192.168.1.25]) ([216.155.193.199]) by smtp406.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 987bc49e0cd8d1c09a4ca76cc5525b18; Sun, 18 Feb 2018 21:46:05 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 13:46:02 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 21:56:14 -0000 On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: >=20 >> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >>=20 >>> Note: -r329448 was reverted in -r329461 : racy. >>=20 >> True. I got a crash when compiling r329451 while running r329449. >> I've now booted the r329422 ZFS BE and I'm attempting to build >> r329529. >>=20 >=20 > Looking around strongly suggests r329448 is the culprit. If you can = verify > 329447 works fine we are mostly done here. >=20 > Note the revision got reverted and different variant got in in = r329531. >=20 > That said, if r329447 works then the issue should be already fixed and = in > particular fresh head should work fine. My initial problem was with -r329465, which is after -r329461 reverted -r329488 . Trond reported in one note that he had problems with -r329464 , also after -r329488 was reverted. Trond has also reported -r329449 failed. I did manage to revert to -r329447 earlier and so far the results suggests that it works. =46rom this I get that -r329449 is the the one that is common to all the so--far failing combinations. -r329448 is not common to all of them. =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Sun Feb 18 22:24:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF711F0AA54; Sun, 18 Feb 2018 22:24:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 28DCB6F5A2; Sun, 18 Feb 2018 22:24:59 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id w1IMOps9029504 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 18 Feb 2018 23:24:51 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id w1IMOpFQ029501; Sun, 18 Feb 2018 23:24:51 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Sun, 18 Feb 2018 23:24:51 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD Current , FreeBSD Hackers Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork In-Reply-To: Message-ID: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> User-Agent: Alpine 2.21 (BSF 202 2017-01-01) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-2.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:24:59 -0000 On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrestøl < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > True. I got a crash when compiling r329451 while running r329449. > > I've now booted the r329422 ZFS BE and I'm attempting to build > > r329529. > > > > Looking around strongly suggests r329448 is the culprit. If you can verify > 329447 works fine we are mostly done here. I noticed no errors in r329447. When r329529 is built and installed, I'll try to incrementally build and install r329531. > Note the revision got reverted and different variant got in in r329531. > > That said, if r329447 works then the issue should be already fixed and in > particular fresh head should work fine. -- Trond. From owner-freebsd-hackers@freebsd.org Sun Feb 18 22:25:15 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16F1EF0AAA1; Sun, 18 Feb 2018 22:25:15 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FE086F5D1; Sun, 18 Feb 2018 22:25:14 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x244.google.com with SMTP id q18so10181839qtl.3; Sun, 18 Feb 2018 14:25:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Mz4rua7Pa3nzFZ50ABKH/hndRiO+i+rdmf7JPPiPnM=; b=M11eNmfCVxZAktlIlU8FBtpt/4EO+oV4Ra8LKDfqciV1MBvk5sQvRzvyimvhBvzJzT lm5gtu9GVSK12W0/VmDzxrkwPv64uDKLbIicBnyXg0k7+ssMCYyvdJPFxeRJy1BJaib5 9CX8eAZxy+ggQ7YHQG6fLKe5UWbFtMAMt3ylmjWRm1HUXfRjID/sJpMr/afHj1nNDhiP 5yLB+RsCCzxpSMPzFZJasxF5tD5ZJE9eJRTCuH+w2/GRba4M8+ifJDHOWAJt6xK5CvXX zNZTvLXVV3ys0lde0MW+JtCKuck/3rDKWyh90rsFW0AelgsVIZqgOMQTlg785ATL7wmJ 29oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Mz4rua7Pa3nzFZ50ABKH/hndRiO+i+rdmf7JPPiPnM=; b=kZY/GSQHt72lRrlzdp7jZJ2WX2oPujv8/llCX8cAmbQJ3LQ6kfThnCikEo+U0fXcjV 8ByXhsSsobCnTAjvYSC7hd2r6TDRu+ey/C3NiYOgXcz2XelrGYR4krV4n8fVVXQZhjXP NTUn2htQ7xxtMzINFNspvAZ/JcZyLCdtwdCDWtaeiMRJ5R+42dZOFJKzP0G8kbnX2LUU NslEMSef8EXJg9aVOyeP3nCul4XDstKcnr8zZfWHnR5WEqFdjS2Obf/1hvvXBlbfO/gY 0GvAjGWlTjhqZWlqg/cnzqoWXQ+hIks+/970jOATc+diOf/nw0FsND50oyC6nmZxebYb 4deg== X-Gm-Message-State: APf1xPDdtgkQCcHwO+Iug6D/RBe5KZvTyWEIQ9goOFMdbbVIyhE9E8WE 0yW6hyZD4V6qQhKKqZPmPgYoMlEObbczTJFxXp1R0Q== X-Google-Smtp-Source: AH8x225eE+wjAhvjheRNf7o1LatxKVBlohyL7Y7OgqbzI4/6x7zoLT7/utKn3KzHbYvGH0feMdfYxMBbK/H5gQgIhA4= X-Received: by 10.200.48.13 with SMTP id f13mr21554173qte.140.1518992714326; Sun, 18 Feb 2018 14:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 14:25:13 -0800 (PST) In-Reply-To: <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> <24563F96-B1A3-48E6-ABE3-D77E0887FFEE@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 23:25:13 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: Mark Millard Cc: =?UTF-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:25:15 -0000 On Sun, Feb 18, 2018 at 10:50 PM, Mark Millard wrote: > > > On 2018-Feb-18, at 1:46 PM, Mark Millard wrote= : > > > On 2018-Feb-18, at 1:33 PM, Mateusz Guzik wrote: > > > >> On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > >> Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> > >>> On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > >>> > >>>> Note: -r329448 was reverted in -r329461 : racy. > >>> > >>> True. I got a crash when compiling r329451 while running r329449. > >>> I've now booted the r329422 ZFS BE and I'm attempting to build > >>> r329529. > >>> > >> > >> Looking around strongly suggests r329448 is the culprit. If you can > verify > >> 329447 works fine we are mostly done here. > >> > >> Note the revision got reverted and different variant got in in r329531= . > >> > >> That said, if r329447 works then the issue should be already fixed and > in > >> particular fresh head should work fine. > > > > My initial problem was with -r329465, which is after -r329461 reverted > > -r329488 . Trond reported in one note that he had problems with > > -r329464 , also after -r329488 was reverted. Trond has also reported > > -r329449 failed. > > Dumb typos above: I meant -r329448 instead of -r329488 both times. > > Ok, I think I see the bug: exit1 does: PROC_SLOCK(p); p->p_state =3D PRS_ZOMBIE; /* work continues */ pre-patch proc_to_reap does an equivalent of: if (p->p_state =3D=3D PRS_ZOMBIE) { PROC_SLOCK(p); PROC_SUNLOCK(p); .... reap; } It is possible the exiting thread will be caught just after setting the state to PRS_ZOMBIE. With the slock/sunlock cycle we guarantee the reaping thread will wait for it to finish. Without the cycle we can end up reaping the still exiting thread. I'll fix it soon(tm). --=20 Mateusz Guzik From owner-freebsd-hackers@freebsd.org Sun Feb 18 22:55:51 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77CBDF0D935; Sun, 18 Feb 2018 22:55:51 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDD5371077; Sun, 18 Feb 2018 22:55:50 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22c.google.com with SMTP id f4so10222451qtj.6; Sun, 18 Feb 2018 14:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vQg7NjbuN5ZYJR+b9ooxyZLtjDwmcTh+M4TzhqSi7so=; b=mA/YW+gQ2rGHeMCRx9kM5SN3URah/s3MbXkxU0jxyAUdw/wpW3qCg5NWY0w4Bh987X pE1AbqDF3JSgAnn/yb7vhUnOb0BA75OwKz0u2muS0dabW1eCYAcmhQqLcDrU2DB+Npey bXL2+9Dsx9ei7wNeCuqsNvwZ4RtOYZD3IGDqDWSq0LqiU4rtvOMnu8VxBs0Fw4K+S+ZD Ki3jK8eFJb7HUYHz/oL8vE5bsgTdz6/l2TlCMiNr8eat9Xz7XrvhPdNpkCKbIxzr5FoK kdf5Gsafjyf4+HO6ln3LWQW1ZzkN3kN7fvba2jKz/XCpfMZLLG1wZIX+CFGVghr+YaFn k1Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vQg7NjbuN5ZYJR+b9ooxyZLtjDwmcTh+M4TzhqSi7so=; b=KqkzHzWPxuZu0GPcx5NWpvhmNVadrp0YIwJaPsZaHYh7aF2VsrtHrttgQYZzxPGg6t cGWvpydApNVevKdr48VHGHQF1IbxI5ytq+HOp12ILQky6Fbaoq0YArYgkbf/8muhhJRW rMBeekITq6xSNxzUdKlyb0ztQDdM4sUQCNNAVcviZYQ1aH7IMM1tPFsBienBmSfU4saI vAxptAjWdZHJV02QSAF6VH5bmO6EIqziCNxk5O2BzADy76ls9R+g33/O3A8qhJaAENBx Lm3Uu6y9pF50ioeclwwA9oE8jHmI7BLnl8nvcZSTu8AznT0ie2+SJ48Dq03h1EUNpSmV Z7Fw== X-Gm-Message-State: APf1xPCQF4WFoOogpfvsunLxN6vfYPeGWTWk8ZjEuKFGY8rnVeLD/5Vk 15bv7RISQA+5UXfHyrntlD1HOV93Eq0XUzcSfossBg== X-Google-Smtp-Source: AH8x225Mk8pw7jWFVhBK93GSVRdM7jZmLihz7CIqNsobdJ348wahS24ChMthWzBgAzKtA2piyWCUVcneqhDZJhVoEwg= X-Received: by 10.237.62.233 with SMTP id o38mr20690864qtf.3.1518994550502; Sun, 18 Feb 2018 14:55:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 14:55:50 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Sun, 18 Feb 2018 23:55:50 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Feb 2018 22:55:51 -0000 On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrest=C3=B8l < Trond.Endrestol@fagskolen.gjovik.no> wrote: > On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: > > > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < > > Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: > > > > > > > Note: -r329448 was reverted in -r329461 : racy. > > > > > > True. I got a crash when compiling r329451 while running r329449. > > > I've now booted the r329422 ZFS BE and I'm attempting to build > > > r329529. > > > > > > > Looking around strongly suggests r329448 is the culprit. If you can > verify > > 329447 works fine we are mostly done here. > > I noticed no errors in r329447. When r329529 is built and installed, > I'll try to incrementally build and install r329531. > Can you grab a panicking kernel and apply this: https://people.freebsd.org/~mjg/wait_unlocked.diff there may be debug printfs signifying the problem condition was hit, however the patch should fix the panic --=20 Mateusz Guzik From owner-freebsd-hackers@freebsd.org Mon Feb 19 00:55:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77901F16D7D; Mon, 19 Feb 2018 00:55:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0336E761C9; Mon, 19 Feb 2018 00:55:59 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt0-x22b.google.com with SMTP id k13so10404958qtg.5; Sun, 18 Feb 2018 16:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSyrJ2J6ToRuxNmwZkFaGDtzFDuX6suKmKvlBwFgcWA=; b=jx/FUIfjdV0a//3e5nXo8yKu4IbPubMX4QJDcMpQpY47CORYlkaKOGI1o+hc8VcUC2 NuxQqm6Il3I2mBvsoB9iXrHvnT4agV8hP3ORrmQHLJzviV0uS0v7x6GEK/uNeziq9xRC 7Q3XWsv5UfrtuWYmNBjBb1nRFjRXQYuNv3P5AG1BmDfwl7SGGRH/Dg6OxMRf5jHM0d8a Ddkc1UY+g1NC/wIE0ItZu1c+tvQnmDQg62YJe4dNepBmSjQTgkdg719LWhRui7rLjMaG c9/DCdF7eOfBbhFP0bBKtmjG3Nmhpfz4NPHu/GC7IRtPzXw5bSfdailPbpWsU90pU5ZR qpug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JSyrJ2J6ToRuxNmwZkFaGDtzFDuX6suKmKvlBwFgcWA=; b=CUcKSlE5hjsIQjus8KNVL1Oidsjg2sCfhI6zZUCcuZgQOzbWMhD4zWIk9inCVtlotu /wHeN3IrDhmXRErgIntqaQduELbFKoVA0duJSUeyMcIatmDAPB41eHjxB2SgTJzUM76R KLm9Z2Lf3tBfmMz6DBf337q4oNw8ak1EuHquMHEJmYoTQvpW1smaIT19sQcjViHez1dE nMPbMy/vFRlAlGPQeZ+Vj+fkNXEa4rzNJ9f0DFE1JTh0hoBOdkgXDoaRHWc3j5l8n2Re kdYJrSvshmB1tLia8ZFdhMpiGtf61ONMQZsVP9S/wRIMTIpY8MNLwU2SXoR15AVTXQSA T4YQ== X-Gm-Message-State: APf1xPA0wqVpp/YXaBmO7pREUIUWzn58gshzuVs7XmFUq783eFeR6Rwy 0lQLAfvfvcT49esFzgzhtGmHQx7FxsmBH3fGyAo= X-Google-Smtp-Source: AH8x226AGQFnLK5feEphsYKNYDne7bCAVPMLfEmCFYUAZBycZTkXhjCfkAu1YjVusGIKs/lyr3H/bZOXYZlKP8QxbRU= X-Received: by 10.200.38.188 with SMTP id 57mr8039817qto.220.1519001758685; Sun, 18 Feb 2018 16:55:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sun, 18 Feb 2018 16:55:58 -0800 (PST) In-Reply-To: References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> From: Mateusz Guzik Date: Mon, 19 Feb 2018 01:55:58 +0100 Message-ID: Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork To: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Cc: FreeBSD Current , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 00:55:59 -0000 I committed the fix in https://svnweb.freebsd.org/base?view=3Drevision&revision=3D329542 i.e. should be stable from this point on. On Sun, Feb 18, 2018 at 11:55 PM, Mateusz Guzik wrote: > On Sun, Feb 18, 2018 at 11:24 PM, Trond Endrest=C3=B8l < > Trond.Endrestol@fagskolen.gjovik.no> wrote: > >> On Sun, 18 Feb 2018 22:33+0100, Mateusz Guzik wrote: >> >> > On Sun, Feb 18, 2018 at 9:38 PM, Trond Endrest=C3=B8l < >> > Trond.Endrestol@fagskolen.gjovik.no> wrote: >> > >> > > On Sun, 18 Feb 2018 11:51-0800, Mark Millard wrote: >> > > >> > > > Note: -r329448 was reverted in -r329461 : racy. >> > > >> > > True. I got a crash when compiling r329451 while running r329449. >> > > I've now booted the r329422 ZFS BE and I'm attempting to build >> > > r329529. >> > > >> > >> > Looking around strongly suggests r329448 is the culprit. If you can >> verify >> > 329447 works fine we are mostly done here. >> >> I noticed no errors in r329447. When r329529 is built and installed, >> I'll try to incrementally build and install r329531. >> > > Can you grab a panicking kernel and apply this: > https://people.freebsd.org/~mjg/wait_unlocked.diff > > there may be debug printfs signifying the problem condition was hit, > however the patch should fix the panic > > -- > Mateusz Guzik > --=20 Mateusz Guzik From owner-freebsd-hackers@freebsd.org Mon Feb 19 01:51:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1BBDF1ACAC for ; Mon, 19 Feb 2018 01:51:22 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2847A78675 for ; Mon, 19 Feb 2018 01:51:21 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: EN1hd9AVM1lgCor36_5VFOnk4LlLHYBr8BEikhjHqaNWssvaEUqvfI0810W.wFx f3olePC.kLa4zai7.VEjz7_dHprJR2bBhUB0iNmY.chas9RtVzyNcG3vfixxw1A10vJCqZrFkjPI zqihHZzNswsBpYWt7JRTBDR0WEF0UNrZcf4M01LQ9bpStuQhA67g0OAU_QD_N78HrsddKj5vwU4C lpz_8N33Tdf962uKKTYmyx47gqegpZnYnYWYjJL7aKBozcZIwtK2ePp6U9Ij_7abLF7JRzzsn4nT WaApY03jJGK0IivwSKzUslYoRC0YTd9J9aGgEfIn._qx3_zeWmf_pMEpRHd59qksJVY_aRPZs5hM S53E9n1NanLvPQgaVEKeYRLmDen37WAvigCu3VzY4_iHkZszVCYvQ_vPmQ10AB2Cx6OQ5h65CJbm j5KVdj9pu_77NbCGtHNjl1jsLMH8KhObTk9RCHLg3W0jpoTDmPNjRl9kd9c2fa2bNPE8- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Feb 2018 01:51:20 +0000 Received: from smtpgate101.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.214.169.33]) by smtp408.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID a416070d3c41bc4f9f12eb9c7f0f076e; Mon, 19 Feb 2018 01:51:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork From: Mark Millard In-Reply-To: Date: Sun, 18 Feb 2018 17:51:15 -0800 Cc: =?utf-8?Q?Trond_Endrest=C3=B8l?= , FreeBSD Hackers , FreeBSD Current Content-Transfer-Encoding: 7bit Message-Id: <47049961-C3F5-454A-89A9-E768B2EBF0DF@yahoo.com> References: <6907E068-C80A-44B8-A8AD-3EF27D52D127@yahoo.com> <20832C61-AA5D-41A6-8BF9-90CC87D17219@yahoo.com> <6D47FEC0-7991-4F76-AC31-2CC1E8934521@yahoo.com> To: Mateusz Guzik X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 01:51:22 -0000 On 2018-Feb-18, at 4:55 PM, Mateusz Guzik wrote: > I committed the fix in > https://svnweb.freebsd.org/base?view=revision&revision=329542 > > i.e. should be stable from this point on. Thanks! === Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Mon Feb 19 03:22:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA626F21B2F for ; Mon, 19 Feb 2018 03:22:27 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic315-10.consmr.mail.gq1.yahoo.com (sonic315-10.consmr.mail.gq1.yahoo.com [98.137.65.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3B0517C92F for ; Mon, 19 Feb 2018 03:22:26 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: rSTg3mgVM1m7HaxLQ9r89wlxSmROF2MIcqLwvCzp5dP78nSf.0VQl4FZGQ5oQ9b 2BfPMW75hNoEolMbezcG.LxS_xLUd29Py_v.6M3x_PdFWazD0IjgYeRbAElLx0ryJJefREc39fKW RvKFEzNVK5HHDBvI9baZ2OQtP_IRGmlGRH_ov9j1jyK9WhzJa8ewW9d.Lqj5FuDscNlohVSxJt0W mT8Qq_joFAUGL1ig_mhsp9xl4OIgTk435Ht77cPFuj8yCSxhHJtL_NYb9QnJyLht4OKuKMAMtarX xueaohgrumHEXnRcm9QKFlYVwaLukfGc4YGFR5DH2StCZcRnnNsmZQ.tGLxWuwzq_G1M2Vz272Ub 6cSpFZr6nl36gZc7ntqiBkGv0K9gTH_m8mGoGh4ng277C6lc4LletN0q5MylVA7z9nIUZS5tEL3A W0CbqwaapNNe.icRyOc1xWHUmifR1aK4POIMivQZIXMrnX1azBxS27KR15iIRothxxw2E Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Mon, 19 Feb 2018 03:22:20 +0000 Received: from smtpgate101.mail.gq1.yahoo.com (EHLO [192.168.1.25]) ([10.214.169.33]) by smtp402.mail.gq1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 04ab64547a3d5dda105e3784a99041b0; Mon, 19 Feb 2018 03:12:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Is the clang 5.0.1 use of .rela.plt and R_PPC64_JMP_SLOT for kernel modules a llvm issue? Just a FreeBSD one? (Still true of clang 6.) From: Mark Millard In-Reply-To: <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> Date: Sun, 18 Feb 2018 19:12:11 -0800 Cc: Justin Hibbits , Nathan Whitehorn , FreeBSD Hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <6F547F69-2821-40D3-AD89-6481F576C6EF@yahoo.com> References: <39C042C5-9800-464C-84AC-677DB45DA1C1@dsl-only.net> <244D5C85-E1E7-4349-A46A-1D275D54833F@dsl-only.net> <55A9388E-2C04-4388-A4E9-F25574FAF129@dsl-only.net> <68EA105F-3ADF-4CBB-BD59-7A9F18E52DB3@dsl-only.net> <313C2310-ABEF-4BEE-A853-A9965680C3AC@dsl-only.net> <2BD5FD21-95E7-4661-B8B9-2FDCDB986149@dsl-only.net> To: Ed Maste , Dimitry Andric X-Mailer: Apple Mail (2.3445.5.20) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 03:22:28 -0000 [Notes on clang 6 properties for this. Also note: newer Email address than the original.] On 2017-Dec-29, at 4:18 PM, Mark Millard wrote: > I've not been able to figure out if I should submit something > into llvm's bugzilla for the powerpc64 switching to .rela.plt > and R_PPC64_JMP_SLOT for kernel modules from the earlier > .rela.dyn and R/PPC64_RELATIVE and R_PPC64_ADDR64 for kernel > modules. (I do not know if powerpc would also have the issue > since other things have been stopping that build for a long > time.) >=20 > Do one or more of you have a clue? >=20 > Reminder: >=20 >=20 > I have submitted FreeBSD bugzilla 224561 for the issue. >=20 > The difference in the likes of filemon.ko > produced by system clang 5.0.1 vs. > devel/powerpc64-xtoolchain-gcc is. . . >=20 > clang 5.0.1: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000000014480 000300000015 R_PPC64_JMP_SLOT 0000000000000000 = copyinstr + 0 > 000000014488 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = devfs_set_cdevpriv + 0 > . . . I finally did some updating of part of my FreeBSD environment, jumping something like 2000 revision numbers . . . Under head -r329542 and its clang 6 there is still a "Relocation section with addend (.rela.plt)" that uses R_PPC64_JMP_SLOT r_types. (This is using devel/powerpc64-binutils .) (There was and is some .rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64 use as well.) So: 6 is like 5.0.1 for this issue. > vs. >=20 > devel/powerpc64-xtoolchain-gcc: >=20 > Relocation section with addend (.rela.dyn): > r_offset r_info r_type st_value st_name = + r_addend > 0000000145c0 000000000016 R_PPC64_RELATIVE 0000000000000000 + 40d0 > 0000000145e0 000000000016 R_PPC64_RELATIVE 0000000000000000 + = 145b0 > . . . > 000000014408 000600000026 R_PPC64_ADDR64 0000000000000000 sysent = + 0 > 000000014410 001100000026 R_PPC64_ADDR64 0000000000000000 = freebsd32_sysent + 0 Under head -r329542 devel/powerpc64-gcc there is no use of .rela.plt or R_PPC64_JMP_SLOT: Just .rela.dyn and R_PPC64_RELATIVE/R_PPC64_ADDR64 use. (This is using devel/powerpc64-binutils .) > Apparently R_PPC64_JMP_SLOT is mishandled > and does not explicitly lead to rejection > of the attempted dynamic load. >=20 > It might be an issue if .rela.plt and > R_PPC64_JMP_SLOT should even be generated > instead of .rela.dyn and R_PPC64_RELATIVE > and R_PPC64_ADDR64. I have not actually tried the modern builds on a old PowerMac G5 yet: other things took up time. Also the USB devmatch issues are a worry since I have no alternatives to directly connected USB keyboards, mice (and possibly more) if I end up unable to connect over the local network for some reason. But I've not noticed anything go by that indicated adding support for R_PPC64_JMP_SLOT or .rela.plt in filemon.ko or other such .ko's. So I only expect dynamic module loading to work for the devel/powerpc64-gcc based kernel. (I still build-in two(?) extra .ko's to avoid the loading issue for them if I play with the clang based kernel. One of them is filemon.ko .) =3D=3D=3D Mark Millard marklmi at yahoo.com ( markmi at dsl-only.net is going away in 2018-Feb, late) From owner-freebsd-hackers@freebsd.org Mon Feb 19 06:20:04 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1AA4F05842 for ; Mon, 19 Feb 2018 06:20:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 635ED826E0 for ; Mon, 19 Feb 2018 06:20:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1J6JxSg028828 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Feb 2018 22:20:01 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: 1 << 31 redux To: Kyle Evans , Eitan Adler Cc: FreeBSD Hackers References: From: Julian Elischer Message-ID: <798b566c-dc9c-cdd8-9040-6fa0806c1406@freebsd.org> Date: Mon, 19 Feb 2018 14:19:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 06:20:04 -0000 On 14/1/18 1:34 am, Kyle Evans wrote: > On Thu, Jan 11, 2018 at 6:03 AM, Eitan Adler wrote: >> Hi all, >> >> A few years ago I fixed most of the cases where we used 1 << 31 in FreeBSD. >> This expression is illegal in C. Since then the issue has arisen again. >> >> https://reviews.freebsd.org/D13858 fixed most of the non-contrib cases. >> >> I'd also like to see if we could find some more general solution, be it a >> compiler warning, bit set macro, or otherwise. >> > For what it's worth, I've really come to like and appreciate NetBSD's > approach with __BIT/__BITS. See [1] for implementation, [2] for usage. > > [1] http://src.illumos.org/source/xref/netbsd-src/sys/sys/cdefs.h#577 I like __BIT() but it should give a compile error if the number is too large rather than just setting it to 0. in fact I think I think it should take a target and use the size of the target rather than assuming int. > [2] http://src.illumos.org/source/xref/netbsd-src/sys/arch/arm/sunxi/sunxi_usbphy.c#L44 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Mon Feb 19 14:48:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F600F056FA for ; Mon, 19 Feb 2018 14:48:17 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E17D478B5A for ; Mon, 19 Feb 2018 14:48:16 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 6567C2EECE; Mon, 19 Feb 2018 15:48:08 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOZ93GtUIxoW; Mon, 19 Feb 2018 15:48:07 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id EC7502EECD for ; Mon, 19 Feb 2018 15:48:07 +0100 (CET) To: FreeBSD Hackers From: Willem Jan Withagen Subject: Using fstatfs on a ZFS disk Message-ID: Date: Mon, 19 Feb 2018 15:48:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 14:48:17 -0000 Hi, I'm trying to find the values of the returned f_type for ZFS in the fstatfs call when a file is on ZFS.... But I have not yet found the definitions of the ENUMS that would fill that value... Let alone the value for ZFS. struct statfs { uint32_t f_version; /* structure version number */ uint32_t f_type; /* type of filesystem */ uint64_t f_flags; /* copy of mount exported flags */ ...... } Any hints where to look would be welcomed. Thanx, --WjW From owner-freebsd-hackers@freebsd.org Mon Feb 19 15:12:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 877C6F0761A for ; Mon, 19 Feb 2018 15:12:43 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16F5D79BA4 for ; Mon, 19 Feb 2018 15:12:42 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id w1JF0U8t081478; Mon, 19 Feb 2018 15:00:30 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Using fstatfs on a ZFS disk From: Bob Bishop In-Reply-To: Date: Mon, 19 Feb 2018 15:00:30 +0000 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <1C4DBFA3-5E79-4503-840C-0C548741363B@gid.co.uk> References: To: Willem Jan Withagen X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:12:43 -0000 Hi, > On 19 Feb 2018, at 14:48, Willem Jan Withagen wrote: >=20 > Hi, >=20 > I'm trying to find the values of the returned f_type for ZFS > in the fstatfs call when a file is on ZFS.... >=20 > But I have not yet found the definitions of the ENUMS that > would fill that value... Let alone the value for ZFS. I chased this particular wild goose myself recently. It=E2=80=99s FS_... = in /usr/include/sys/disklabel,h that you want. > struct statfs { > uint32_t f_version; /* structure version number */ > uint32_t f_type; /* type of filesystem */ > uint64_t f_flags; /* copy of mount exported flags */ > ...... > } >=20 > Any hints where to look would be welcomed. >=20 > Thanx, > --WjW > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@freebsd.org Mon Feb 19 15:50:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1899EF0A310 for ; Mon, 19 Feb 2018 15:50:34 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB4227B704 for ; Mon, 19 Feb 2018 15:50:33 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 36B302E6F6; Mon, 19 Feb 2018 16:50:31 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfwIhCSa77Y1; Mon, 19 Feb 2018 16:50:30 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 8C6892E6F4; Mon, 19 Feb 2018 16:50:30 +0100 (CET) Subject: Re: Using fstatfs on a ZFS disk To: Bob Bishop Cc: FreeBSD Hackers References: <1C4DBFA3-5E79-4503-840C-0C548741363B@gid.co.uk> From: Willem Jan Withagen Message-ID: Date: Mon, 19 Feb 2018 16:50:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1C4DBFA3-5E79-4503-840C-0C548741363B@gid.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 15:50:34 -0000 On 19-2-2018 16:00, Bob Bishop wrote: > Hi, > >> On 19 Feb 2018, at 14:48, Willem Jan Withagen wrote: >> >> Hi, >> >> I'm trying to find the values of the returned f_type for ZFS >> in the fstatfs call when a file is on ZFS.... >> >> But I have not yet found the definitions of the ENUMS that >> would fill that value... Let alone the value for ZFS. > > I chased this particular wild goose myself recently. It’s FS_... in /usr/include/sys/disklabel,h that you want. Hi Bob, I grepped on MAGIC and FS, but the combo did not deliver anything useful. So this is already more that I found. I did get: /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */ So I was looking for something like: FS_ZFS_MAGIC disklabel.h contains: #ifdef FSTYPENAMES static const char *fstypenames[] = { And further search: /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */ Running: #include "stdio.h" #include #include int main() { struct statfs fstr; char * str; str = "/tmp"; statfs(str, &fstr); printf("%s, ftype: 0x%x.\n", str, fstr.f_type); } results in: /tmp, ftype: 0xde. Now 0xde != 27, so the question is, where is this 0xde specified. And more important is this f_type constant over all FreeBSD ZFS filesystems? --WjW > >> struct statfs { >> uint32_t f_version; /* structure version number */ >> uint32_t f_type; /* type of filesystem */ >> uint64_t f_flags; /* copy of mount exported flags */ >> ...... >> } >> >> Any hints where to look would be welcomed. >> >> Thanx, >> --WjW >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > -- > Bob Bishop > rb@gid.co.uk > > > > From owner-freebsd-hackers@freebsd.org Mon Feb 19 17:57:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1C4B1F15C6E for ; Mon, 19 Feb 2018 17:57:18 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A40B582C31 for ; Mon, 19 Feb 2018 17:57:17 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [194.32.164.27] ([194.32.164.27]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id w1JHvFSZ011331; Mon, 19 Feb 2018 17:57:15 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Using fstatfs on a ZFS disk From: rb@gid.co.uk In-Reply-To: Date: Mon, 19 Feb 2018 17:57:15 +0000 Cc: FreeBSD Hackers Content-Transfer-Encoding: quoted-printable Message-Id: <456B0CAA-367F-478A-BB61-153942C3EB7A@gid.co.uk> References: <1C4DBFA3-5E79-4503-840C-0C548741363B@gid.co.uk> To: Willem Jan Withagen X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 17:57:18 -0000 Hi, > On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: >=20 > On 19-2-2018 16:00, Bob Bishop wrote: >> Hi, >>> On 19 Feb 2018, at 14:48, Willem Jan Withagen = wrote: >>>=20 >>> Hi, >>>=20 >>> I'm trying to find the values of the returned f_type for ZFS >>> in the fstatfs call when a file is on ZFS.... >>>=20 >>> But I have not yet found the definitions of the ENUMS that >>> would fill that value... Let alone the value for ZFS. >> I chased this particular wild goose myself recently. It=E2=80=99s = FS_... in /usr/include/sys/disklabel,h that you want. >=20 > Hi Bob, >=20 > I grepped on MAGIC and FS, but the combo did not deliver anything = useful. So this is already more that I found. > I did get: > /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* = UFS1 fast filesystem magic number */ > /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* = UFS2 fast filesystem magic number */ > /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* = UFS incomplete newfs magic number */ Those I believe are magic numbers for UFS superblocks...=20 > So I was looking for something like: FS_ZFS_MAGIC ... so you won=E2=80=99t find that. > disklabel.h contains: > #ifdef FSTYPENAMES > static const char *fstypenames[] =3D { >=20 > And further search: > /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */ >=20 > Running: > #include "stdio.h" >=20 > #include > #include >=20 > int main() { > struct statfs fstr; > char * str; >=20 > str =3D "/tmp"; > statfs(str, &fstr); > printf("%s, ftype: 0x%x.\n", str, fstr.f_type); > } > results in: > /tmp, ftype: 0xde. >=20 > Now 0xde !=3D 27, so the question is, where is this 0xde specified. > And more important is this f_type constant over all FreeBSD ZFS = filesystems? You got me. And a quick look at sys/kern/vfs_syscalls.c doesn=E2=80=99t = help except to imply that the type is set when the filesystem is = mounted. I have no idea where 0xde comes from. > --WjW >=20 >>> struct statfs { >>> uint32_t f_version; /* structure version number */ >>> uint32_t f_type; /* type of filesystem */ >>> uint64_t f_flags; /* copy of mount exported flags = */ >>> ...... >>> } >>>=20 >>> Any hints where to look would be welcomed. >>>=20 >>> Thanx, >>> --WjW >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >>>=20 >> -- >> Bob Bishop >> rb@gid.co.uk >=20 -- Bob Bishop t: +44 (0)118 940 1243 rb@gid.co.uk m: +44 (0)783 626 4518 From owner-freebsd-hackers@freebsd.org Mon Feb 19 18:33:52 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B4530F18BE2 for ; Mon, 19 Feb 2018 18:33:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2662A8497F for ; Mon, 19 Feb 2018 18:33:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w1JIXir0078023; Mon, 19 Feb 2018 10:33:44 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w1JIXhVL078022; Mon, 19 Feb 2018 10:33:43 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> Subject: Re: Using fstatfs on a ZFS disk In-Reply-To: <456B0CAA-367F-478A-BB61-153942C3EB7A@gid.co.uk> To: rb@gid.co.uk Date: Mon, 19 Feb 2018 10:33:43 -0800 (PST) CC: Willem Jan Withagen , FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 19 Feb 2018 18:51:47 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 18:33:53 -0000 > Hi, > > > On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: > > > > On 19-2-2018 16:00, Bob Bishop wrote: > >> Hi, > >>> On 19 Feb 2018, at 14:48, Willem Jan Withagen wrote: > >>> > >>> Hi, > >>> > >>> I'm trying to find the values of the returned f_type for ZFS > >>> in the fstatfs call when a file is on ZFS.... > >>> > >>> But I have not yet found the definitions of the ENUMS that > >>> would fill that value... Let alone the value for ZFS. > >> I chased this particular wild goose myself recently. It?s FS_... in /usr/include/sys/disklabel,h that you want. > > > > Hi Bob, > > > > I grepped on MAGIC and FS, but the combo did not deliver anything useful. So this is already more that I found. > > I did get: > > /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ > > /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ > > /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */ > > Those I believe are magic numbers for UFS superblocks... > > > So I was looking for something like: FS_ZFS_MAGIC > > ... so you won?t find that. > > > disklabel.h contains: > > #ifdef FSTYPENAMES > > static const char *fstypenames[] = { > > > > And further search: > > /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */ > > > > Running: > > #include "stdio.h" > > > > #include > > #include > > > > int main() { > > struct statfs fstr; > > char * str; > > > > str = "/tmp"; > > statfs(str, &fstr); > > printf("%s, ftype: 0x%x.\n", str, fstr.f_type); > > } > > results in: > > /tmp, ftype: 0xde. > > > > Now 0xde != 27, so the question is, where is this 0xde specified. > > And more important is this f_type constant over all FreeBSD ZFS filesystems? > > You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from. Could that 0xde be the start of 0xdeadcode? 0xde is 222 decimal, that does not ring a bell for me either. > > --WjW > > > >>> struct statfs { > >>> uint32_t f_version; /* structure version number */ > >>> uint32_t f_type; /* type of filesystem */ > >>> uint64_t f_flags; /* copy of mount exported flags */ > >>> ...... > >>> } > >>> > >>> Any hints where to look would be welcomed. > >>> > >>> Thanx, > >>> --WjW > >> -- > >> Bob Bishop > >> rb@gid.co.uk > -- > Bob Bishop t: +44 (0)118 940 1243 > rb@gid.co.uk m: +44 (0)783 626 4518 -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Feb 19 20:33:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92B50F2238E for ; Mon, 19 Feb 2018 20:33:54 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 280A56A3B2 for ; Mon, 19 Feb 2018 20:33:54 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 195C42EB0D; Mon, 19 Feb 2018 21:33:52 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjyaurV31OhN; Mon, 19 Feb 2018 21:33:51 +0100 (CET) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 2DEF32EB0C; Mon, 19 Feb 2018 21:33:51 +0100 (CET) Subject: Re: Using fstatfs on a ZFS disk To: "Rodney W. Grimes" , rb@gid.co.uk Cc: FreeBSD Hackers References: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> From: Willem Jan Withagen Message-ID: <1dfe0d2b-48dd-3f99-8332-b3979faad45d@digiware.nl> Date: Mon, 19 Feb 2018 21:33:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 20:33:54 -0000 On 19/02/2018 19:33, Rodney W. Grimes wrote: >> Hi, >> >>> On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: >>> >>> On 19-2-2018 16:00, Bob Bishop wrote: >>>> Hi, >>>>> On 19 Feb 2018, at 14:48, Willem Jan Withagen wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to find the values of the returned f_type for ZFS >>>>> in the fstatfs call when a file is on ZFS.... >>>>> >>>>> But I have not yet found the definitions of the ENUMS that >>>>> would fill that value... Let alone the value for ZFS. >>>> I chased this particular wild goose myself recently. It?s FS_... in /usr/include/sys/disklabel,h that you want. >>> >>> Hi Bob, >>> >>> I grepped on MAGIC and FS, but the combo did not deliver anything useful. So this is already more that I found. >>> I did get: >>> /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ >>> /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ >>> /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */ >> >> Those I believe are magic numbers for UFS superblocks... >> >>> So I was looking for something like: FS_ZFS_MAGIC >> >> ... so you won?t find that. >> >>> disklabel.h contains: >>> #ifdef FSTYPENAMES >>> static const char *fstypenames[] = { >>> >>> And further search: >>> /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */ >>> >>> Running: >>> #include "stdio.h" >>> >>> #include >>> #include >>> >>> int main() { >>> struct statfs fstr; >>> char * str; >>> >>> str = "/tmp"; >>> statfs(str, &fstr); >>> printf("%s, ftype: 0x%x.\n", str, fstr.f_type); >>> } >>> results in: >>> /tmp, ftype: 0xde. >>> >>> Now 0xde != 27, so the question is, where is this 0xde specified. >>> And more important is this f_type constant over all FreeBSD ZFS filesystems? >> >> You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from. > > Could that 0xde be the start of 0xdeadcode? > > 0xde is 222 decimal, that does not ring a bell for me either. Searching on 0xde did deliver indeed plenty 0xdeadc0de and sisters. the resulting size is 32bit, so if it is a leftover of 0xdeadcode, it is due to a not-32bit aligned access, since the 3 upper bytes are 0. Only way to find this out is dig thru the code. :) But I'm no hero at that. But there is atleast not a particular FS_ZFS_MAGIC!! And there is no obvious definition what is returned in f_type?? --WjW >>>>> struct statfs { >>>>> uint32_t f_version; /* structure version number */ >>>>> uint32_t f_type; /* type of filesystem */ >>>>> uint64_t f_flags; /* copy of mount exported flags */ >>>>> ...... >>>>> } >>>>> >>>>> Any hints where to look would be welcomed. >>>>> >>>>> Thanx, >>>>> --WjW >>>> -- >>>> Bob Bishop >>>> rb@gid.co.uk >> -- >> Bob Bishop t: +44 (0)118 940 1243 >> rb@gid.co.uk m: +44 (0)783 626 4518 > From owner-freebsd-hackers@freebsd.org Mon Feb 19 21:20:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CFD8F252DE for ; Mon, 19 Feb 2018 21:20:50 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 890F76BD53 for ; Mon, 19 Feb 2018 21:20:49 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f47.google.com with SMTP id g72so1344904lfg.5 for ; Mon, 19 Feb 2018 13:20:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gOOj3vrbAuhzv1+eXLUQo6kVyw3SCCxWbZpT73Kr+P0=; b=FSU+Eq3wQY0Aqiva6gaNvrNxRa7zSc7a0whEKGgm5KgGtgrd8fnw3DU4F8oEUMQN5b 9l4fIIeCKXAEsvwk2AdpdaMH4lFHaBPEhf/VNCTK1hdIcIg2SNcqHZQN+tCt4Tj2eoPv SBUq+FknB1l1q9d66zn+gjG4bEXk3SGdEC5Y/bDSotkuZ6nqFDHaVxc3LxHnt20KvQGX TfEnQ2q5Hiey3ZhRVZOeUdIGVjmWk2Mhg+NsWITNnhEM8f1hJDspaQjKR0Sg/ixgacNO vwOxPwaqPvIik2XeCoc6Nfy1NjF5aDKmEBdW3h79o+p4436WEsGhpIkmgDu8WoXlJSb5 kLLw== X-Gm-Message-State: APf1xPCc2Z9a/D4rSgpGe38+fZ5y3lcC8+ml6AFOHq1c42d9ow59hprf Zpqhk0Wr/0+7cstTiqQjVnuqvldLdPY= X-Google-Smtp-Source: AH8x224vMPNdJhMIBdVFiGLhFVWkA1YbISFS9zvHu9d1ayo0HNmnPulhnPKWX/lrkdHP9wMFrK61aA== X-Received: by 10.25.15.98 with SMTP id e95mr10909632lfi.36.1519075241645; Mon, 19 Feb 2018 13:20:41 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id n2sm3392560lja.21.2018.02.19.13.20.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 13:20:40 -0800 (PST) Subject: Re: Using fstatfs on a ZFS disk To: "Rodney W. Grimes" , rb@gid.co.uk Cc: FreeBSD Hackers , Willem Jan Withagen References: <456B0CAA-367F-478A-BB61-153942C3EB7A@gid.co.uk> <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> From: Andriy Gapon Message-ID: <45bd4a05-406b-d6ac-6679-6897ab1fc742@FreeBSD.org> Date: Mon, 19 Feb 2018 23:20:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:20:50 -0000 On 19/02/2018 20:33, Rodney W. Grimes wrote: >> Hi, >> >>> On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: >>> Now 0xde != 27, so the question is, where is this 0xde specified. >>> And more important is this f_type constant over all FreeBSD ZFS filesystems? >> >> You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from. > > Could that 0xde be the start of 0xdeadcode? > > 0xde is 222 decimal, that does not ring a bell for me either. This is simpler, I think. It is a hash value (calculated using a specific algorithm) of a filesystem type name. See vfs_register(). There are no magic predefined constants for the types. BTW, lsvfs(1) and its source code could be of interest to the original poster. E.g., getvfsbyname(3). -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Feb 19 21:55:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10295F01DC1 for ; Mon, 19 Feb 2018 21:55:43 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3FB6D823 for ; Mon, 19 Feb 2018 21:55:42 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9AF492EE9E; Mon, 19 Feb 2018 22:55:40 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YE4JaVnocVI; Mon, 19 Feb 2018 22:55:40 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 0D6E52EE9D; Mon, 19 Feb 2018 22:55:40 +0100 (CET) Subject: Re: Using fstatfs on a ZFS disk To: "Rodney W. Grimes" , rb@gid.co.uk Cc: FreeBSD Hackers References: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> From: Willem Jan Withagen Message-ID: <82ef8d5d-ef62-f746-f415-728e34257924@digiware.nl> Date: Mon, 19 Feb 2018 22:55:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 21:55:43 -0000 On 19-2-2018 19:33, Rodney W. Grimes wrote: >> Hi, >> >>> On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: >>> >>> On 19-2-2018 16:00, Bob Bishop wrote: >>>> Hi, >>>>> On 19 Feb 2018, at 14:48, Willem Jan Withagen wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm trying to find the values of the returned f_type for ZFS >>>>> in the fstatfs call when a file is on ZFS.... >>>>> >>>>> But I have not yet found the definitions of the ENUMS that >>>>> would fill that value... Let alone the value for ZFS. >>>> I chased this particular wild goose myself recently. It?s FS_... in /usr/include/sys/disklabel,h that you want. >>> >>> Hi Bob, >>> >>> I grepped on MAGIC and FS, but the combo did not deliver anything useful. So this is already more that I found. >>> I did get: >>> /usr/include/ufs/ffs/fs.h:#define FS_UFS1_MAGIC 0x011954 /* UFS1 fast filesystem magic number */ >>> /usr/include/ufs/ffs/fs.h:#define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ >>> /usr/include/ufs/ffs/fs.h:#define FS_BAD_MAGIC 0x19960408 /* UFS incomplete newfs magic number */ >> >> Those I believe are magic numbers for UFS superblocks... >> >>> So I was looking for something like: FS_ZFS_MAGIC >> >> ... so you won?t find that. >> >>> disklabel.h contains: >>> #ifdef FSTYPENAMES >>> static const char *fstypenames[] = { >>> >>> And further search: >>> /usr/include/sys/disk/bsd.h:#define FS_ZFS 27 /* Sun's ZFS */ >>> >>> Running: >>> #include "stdio.h" >>> >>> #include >>> #include >>> >>> int main() { >>> struct statfs fstr; >>> char * str; >>> >>> str = "/tmp"; >>> statfs(str, &fstr); >>> printf("%s, ftype: 0x%x.\n", str, fstr.f_type); >>> } >>> results in: >>> /tmp, ftype: 0xde. >>> >>> Now 0xde != 27, so the question is, where is this 0xde specified. >>> And more important is this f_type constant over all FreeBSD ZFS filesystems? >> >> You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from. > > Could that 0xde be the start of 0xdeadcode? > > 0xde is 222 decimal, that does not ring a bell for me either. Well the VSTAT node gets setup during vfs_mount_alloc() which copies data from: /* * Filesystem configuration information. One of these exists for each * type of filesystem supported by the kernel. These are searched at * mount time to identify the requested filesystem. * * XXX: Never change the first two arguments! */ struct vfsconf { u_int vfc_version; /* ABI version number */ char vfc_name[MFSNAMELEN]; /* filesystem type name */ struct vfsops *vfc_vfsops; /* filesystem operations vector */ int vfc_typenum; /* historic filesystem type number */ int vfc_refcount; /* number mounted of this type */ int vfc_flags; /* permanent flags */ struct vfsoptdecl *vfc_opts; /* mount options */ TAILQ_ENTRY(vfsconf) vfc_list; /* list of vfscons */ }; And the "historic filesystem type number" is a worrying comment. As it turns out the type is calculated/hashed in vfs_init: ==== if (vfs_typenumhash != 0) { /* * Calculate a hash on vfc_name to use for vfc_typenum. Unless * all of 1<->255 are assigned, it is limited to 8bits since * that is what ZFS uses from vfc_typenum and is also the * preferred range for vfs_getnewfsid(). */ hashval = fnv_32_str(vfc->vfc_name, FNV1_32_INIT); hashval &= 0xff; secondpass = 0; do { /* Look for and fix any collision. */ TAILQ_FOREACH(tvfc, &vfsconf, vfc_list) { if (hashval == tvfc->vfc_typenum) { if (hashval == 255 && secondpass == 0) { hashval = 1; secondpass = 1; } else hashval++; break; } } } while (tvfc != NULL); vfc->vfc_typenum = hashval; if (vfc->vfc_typenum >= maxvfsconf) maxvfsconf = vfc->vfc_typenum + 1; So the f_type is sort of stable over time, unless een new type creates a collision and things start moving. Made a small test program: /tmp, ftype: 0xde, name: zfs. /home/wjw, ftype: 0x3a, name: nfs. /home/wjw/.tcshrc, ftype: 0x3a, name: nfs. /dev/random, ftype: 0x71, name: devfs. So I guess I'm going to '#define FS_ZFS_TYPE 0xde' --WjW From owner-freebsd-hackers@freebsd.org Mon Feb 19 22:03:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CECDF02A8E for ; Mon, 19 Feb 2018 22:03:23 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A82F6E389; Mon, 19 Feb 2018 22:03:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id B71B52E3FA; Mon, 19 Feb 2018 23:03:21 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyQfhJofetsy; Mon, 19 Feb 2018 23:03:21 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 338342E3F9; Mon, 19 Feb 2018 23:03:21 +0100 (CET) Subject: Re: Using fstatfs on a ZFS disk To: Andriy Gapon , "Rodney W. Grimes" , rb@gid.co.uk Cc: FreeBSD Hackers References: <456B0CAA-367F-478A-BB61-153942C3EB7A@gid.co.uk> <201802191833.w1JIXhVL078022@pdx.rh.CN85.dnsmgr.net> <45bd4a05-406b-d6ac-6679-6897ab1fc742@FreeBSD.org> From: Willem Jan Withagen Message-ID: <8134dba0-fdae-0109-4bae-3441d750566d@digiware.nl> Date: Mon, 19 Feb 2018 23:03:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <45bd4a05-406b-d6ac-6679-6897ab1fc742@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 22:03:23 -0000 On 19-2-2018 22:20, Andriy Gapon wrote: > On 19/02/2018 20:33, Rodney W. Grimes wrote: >>> Hi, >>> >>>> On 19 Feb 2018, at 15:50, Willem Jan Withagen wrote: > >>>> Now 0xde != 27, so the question is, where is this 0xde specified. >>>> And more important is this f_type constant over all FreeBSD ZFS filesystems? >>> >>> You got me. And a quick look at sys/kern/vfs_syscalls.c doesn?t help except to imply that the type is set when the filesystem is mounted. I have no idea where 0xde comes from. >> >> Could that 0xde be the start of 0xdeadcode? >> >> 0xde is 222 decimal, that does not ring a bell for me either. > > This is simpler, I think. > It is a hash value (calculated using a specific algorithm) of a filesystem type > name. See vfs_register(). Right in vfs_init.c > There are no magic predefined constants for the types. It is a bit of work doing the hashes, but there could very well be pre-calculated FS__TYPE defines. See my other post. > BTW, lsvfs(1) and its source code could be of interest to the original poster. > E.g., getvfsbyname(3). lsvfs output could even be used to generate part of the ENUM list. --WjW From owner-freebsd-hackers@freebsd.org Tue Feb 20 03:16:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B1A94F1F431 for ; Tue, 20 Feb 2018 03:16:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EAD27D030 for ; Tue, 20 Feb 2018 03:16:28 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id v135-v6so3511952ybe.2 for ; Mon, 19 Feb 2018 19:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to; bh=Fl0M1nNFwH/I6iK+Y6wq3cDmoPk+z1zV1EIrlTv7xec=; b=XOqXQqAWhWqz2oGMzqhAvLTrLeEowvMpiV7UKn+NQrL03aNFa47PmchJsb2TCTnSo+ PTwEnsTxsZi8Lg8F+dKdtLQR/qW+aA2/HUczImVcRnZ8zl83A0+KDMEuSv0rY5jhd2ce McxWg1oDwvigfAgGpNZh8qOIOknv9QPwXOLFQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Fl0M1nNFwH/I6iK+Y6wq3cDmoPk+z1zV1EIrlTv7xec=; b=D8726NlZ7g2KYb09mVrE01o5lQj3Evjkq6IIFuyhslsmG1uPhfdiFJh1NmEUCEodPn hg9jnEFYRbeZpz67qDDaJVmalzox4Im+1S9H44cYE4BTV6WvU2C9yJ7x+lcPlC+S49hW 3P1lZCUWKq/1BndkXvLeyIt+wyfjd+nncuagkcL/D2aZFlgrVv8K+e4elS/PhcRSjAOI zBHHQ+zJeEKB2Cw477bo32xvl5fkCqpqoMBVWhP7KVBcR1jWEmAGCO3itTQVglOGvKwQ mEJRc9oqbewTR3VLU30QSt1i0Plc1fsstaHa6RZ+65CpNE16mibHY93c2YXWExY77evL L6ew== X-Gm-Message-State: APf1xPAYw9WL5PZhvxn30DczKRxpUYxaINulbTVJIpzXkue5UAmP31M1 KbJ1rwp8Gk+MdcJF9cq/N9chWnv8Gxuttnf9L4tPRw== X-Google-Smtp-Source: AH8x227QrSJHRZM5aj7yRq7vPbUsHarlwDx/x0gdmwcBb4jHciYIeNo6/JRYCtuY27IEVg71aSn1NwWTqFNk1YLb5Bg= X-Received: by 10.37.194.133 with SMTP id s127mr11909630ybf.338.1519096587745; Mon, 19 Feb 2018 19:16:27 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Mon, 19 Feb 2018 19:15:57 -0800 (PST) From: Eitan Adler Date: Mon, 19 Feb 2018 19:15:57 -0800 Message-ID: Subject: gf128_add can be marked as __pure2 To: John Baldwin , FreeBSD Hackers , jmg@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 03:16:28 -0000 Is there any reason not to apply this patch? __pure2 means __attribute__((const)) which is correct in this case as gf128_add read no global memory: Index: gfmult.h =================================================================== --- gfmult.h (revision 329611) +++ gfmult.h (working copy) @@ -108,7 +108,7 @@ gf128_write(struct gf128 v, uint8_t *buf) be64enc(buf, v.v[1]); } -static inline struct gf128 __pure /* XXX - __pure2 instead */ +static inline struct gf128 __pure2 gf128_add(struct gf128 a, struct gf128 b) { a.v[0] ^= b.v[0]; -- Eitan Adler From owner-freebsd-hackers@freebsd.org Tue Feb 20 15:41:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63A1EF0D900 for ; Tue, 20 Feb 2018 15:41:43 +0000 (UTC) (envelope-from blackskygg@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8CB07C961 for ; Tue, 20 Feb 2018 15:41:42 +0000 (UTC) (envelope-from blackskygg@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id h78so4804250lfg.6 for ; Tue, 20 Feb 2018 07:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=SrbHXU6J+foaDi+0Mo4nrwjZeXE7EUGIsVTE7YBbqrQ=; b=Gb1p4BQqFWX5bScHOOTAb8J8zh/sME93KM8SD50XKdC0WbnyOZncKf+hl/gVaREfxR RUgY6MP42VTCjzP29fgEZBcxHFcpzjRTOj64LNAiEDaEbl6cOjfDcuWuiM01gRlBiFtG b65CTXlGA1RdoUnhNCDhdolmb0t5uZ+EdUKeNoAiZ9mpb3S2tG1dHU92+6D9xmN9o1/x /U0spkAigDOu/QbJ+5H8BzlbjTSadJUnUeoH2unyKrkWR7vl5cKWFQPzpYZvZjmBke0f +5tBhuVf1vEgZOJbwER9YD1A79LY1aJ+UkJu55iIN3Z/cWQTPrGB5Y20RFQx1CnRuJfS sPUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=SrbHXU6J+foaDi+0Mo4nrwjZeXE7EUGIsVTE7YBbqrQ=; b=V4fyy+syMkip5D/dUpq0xYdqDk7JwphH479iPRKy9pQjeKnU9Rc6VsY6wQSN6EJ4kF GFPfg8zugwOD4A9KiNQLxVvJjfln1Qs4qMXc8djLQGz9elt8zvefe62ptJsF/HU0hmMe /DhH76nXUYvUe7JXu51h0UGe1iDvY+BlcD0HIlTdKLcsQUO32C3wEPWt70kKi4jGjQP6 nzQrxzpoOPBQIVyj7fp/uv0FupoSzFvAT9JyHr0Pxj+uWL2uRRENJIqrtjG6aoqYaq2y IkRRjkFP7SWDamEZcZdRVlJChTVgdwZRdXo58veQcovhWKdtRGVbCBlVgWTH37ML91eX nrkQ== X-Gm-Message-State: APf1xPBW9vXirdmy/o17Q6SQ+9TDUtdvjEp/Vx239Acl5o0MGs9wO1NM jT0dG3P9mbiWDEpanHYh0ifSEUaOBvYn/dTR/Ya2VQ== X-Google-Smtp-Source: AH8x225bsZqh5JyQy9PC0mdCjijY6IUj6GHRNd6vJTA/A1AlfkebH2WGj+2zGaHHOPgeNMnfygKzu/ufexf0XCDSDLM= X-Received: by 10.25.67.80 with SMTP id m16mr16722lfj.105.1519141301138; Tue, 20 Feb 2018 07:41:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.153 with HTTP; Tue, 20 Feb 2018 07:41:40 -0800 (PST) From: Zhongze Liu Date: Tue, 20 Feb 2018 23:41:40 +0800 Message-ID: Subject: [GSoC]Implementing the Parallel Scheduling Parallel Transmission subsystem on FreeBSD, help needed To: freebsd-hackers@freebsd.org Cc: giuseppe.lettieri@unipi.it Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 15:41:43 -0000 HI there, I'm an undergraduate student majoring in information security and have always been interested in systems programming. While seeking for some challenge for this summer on the GSoC page (I've completed a GSoC project with the Xen hypervisor community last year, and really want to do it again), I found FreeBSD's idea of Implementing the Parallel Scheduling Parallel Transmission subsystem really interesting and would like to take this challenge. I've been reading the PSSPT paper for a general idea of the project. And at the same time, I also want to get familiar with FreeBSD's code base, especially the part related to this project. I think the most natural way to get started would be making some small yet related contributions to the project. Do we have such small fixes that could be assigned to me? Besides that, I'would really appreciate any form of suggestions or information about how the project could be completed. Cheers, Zhongze Liu From owner-freebsd-hackers@freebsd.org Tue Feb 20 18:15:33 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9ADA0F1BDAE for ; Tue, 20 Feb 2018 18:15:33 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2D96C8447C for ; Tue, 20 Feb 2018 18:15:32 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w1KIFUAK072641 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 20 Feb 2018 10:15:31 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me To: Freebsd hackers list From: Yuri Subject: 'scanimage -L' from 'graphics/sane-backends' causes system crashes after a while Message-ID: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> Date: Tue, 20 Feb 2018 10:15:28 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:15:33 -0000 For my system this works with a 100% reliability: run 'scanimage -L' (or just scan something), and system will crash after a few hours or so. '-L' option calls the function 'sane_get_devices', which has about 90 implementations there. It calls all of them trying to find a scanner. Some of them cause system to crash later. My real scanner is on the wifi network. I'm not sure if the real scanner is what causes the problem, or maybe it's some other test among these 90 'sane_get_devices' functions that causes this problem. What is the easiest way to troubleshoot this? The problem is that the crash doesn't come right away. 11.1-STABLE Yuri From owner-freebsd-hackers@freebsd.org Tue Feb 20 18:19:23 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5A987F1C240 for ; Tue, 20 Feb 2018 18:19:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0617846A5 for ; Tue, 20 Feb 2018 18:19:22 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B91E92603D1; Tue, 20 Feb 2018 19:19:21 +0100 (CET) Subject: Re: 'scanimage -L' from 'graphics/sane-backends' causes system crashes after a while To: Yuri , Freebsd hackers list References: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> From: Hans Petter Selasky Message-ID: <4dc31781-c6df-04bf-0158-fc09d14b3fb8@selasky.org> Date: Tue, 20 Feb 2018 19:19:21 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:19:23 -0000 On 02/20/18 19:15, Yuri wrote: > For my system this works with a 100% reliability: run 'scanimage -L' (or > just scan something), and system will crash after a few hours or so. > > '-L' option calls the function 'sane_get_devices', which has about 90 > implementations there. It calls all of them trying to find a scanner. > Some of them cause system to crash later. > > My real scanner is on the wifi network. I'm not sure if the real scanner > is what causes the problem, or maybe it's some other test among these 90 > 'sane_get_devices' functions that causes this problem. > > What is the easiest way to troubleshoot this? The problem is that the > crash doesn't come right away. > > 11.1-STABLE > Try ktrac'ing the program first, or run from inside of gdb801 from ports: gdb801 > file scanimage > run -L --HPS From owner-freebsd-hackers@freebsd.org Tue Feb 20 18:19:59 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02762F1C379 for ; Tue, 20 Feb 2018 18:19:59 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A5DD84774 for ; Tue, 20 Feb 2018 18:19:58 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x233.google.com with SMTP id q69so5508585lfi.10 for ; Tue, 20 Feb 2018 10:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Axvc2TpTQDaX8TJw5Lvdw9r0tPs4PmrZVZ6iE6QUhms=; b=SvrQhWKr721rxMyE+vyg8MsuMG6+2+UFAa7ic1KpiusAwEZJofyUm5rZh1ls2S/Nku qZozWut8bpofHQfQSZVFEoV9UiS14oMo1yGj51g2iAfuD4pCVPiKC/9j44tk+hoZS8fb K3mz6y/A7n8QOqZkhUeYBzVKka21KtBRc+0NvLkTOCYeBxZm5BhSkSOrwticaLWRvHwF wcu8poIG3GbXRkv9WXjg9DI/wDdkReqCEjflZwWcgedVjENm9bpTYXaeBn7DZoVzcYgh 0uNGX/mbgBrmVkBLiCoFa/4yimD7XktJN7EeqXvYPW4fhKSmiEHB8t/XbxUlCng1NL7U WoSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Axvc2TpTQDaX8TJw5Lvdw9r0tPs4PmrZVZ6iE6QUhms=; b=XYdzH5SUQnrHEkGfK+NboT2kmy5tCChd3MDJNqJEu4J48hCjg5gTkdhqgc64gS54g/ wRKntN8AkpzAviiuSzQE/y+/AQ6zxw+FugNrzhsac/W8+8vTzMpKUhXeN6p4czVdkMYJ HmYDfxH37Njf1a793T4vy+TsjRbrPhLK6f6mbaKNFIugsk1fWDWfAUkmg0qRlzq6m+Fs zgMiOtqQ2Yt7FhpoV+3ZKQyhVi1M6FXCtxTH5yefxkO0VYpRGxPhKP3vr1gLld1LL5ga rlrhuiMwhqY+QiyaU1oUe7EK1+BNNh4fZR/DkPpVYFoBc3asqgwjepxOGNRrAFKAH0uR LzkA== X-Gm-Message-State: APf1xPBedn5p0YS/erENvJ1wr8ZW5BdrUxhPKmtgLtxlkoreXVIHpQeE JSQnKgw/LhPWmGz13WosqKr4nucc7995TAY837g= X-Google-Smtp-Source: AH8x227yWC1DzZRduWdLrgD1wfTzbjqGa5VIoX1PUtnAc7Z0KNg5HCETX3bXHVsQ/bQBbtdcfG+tAYyCtBlfMxfHr50= X-Received: by 10.25.147.219 with SMTP id w88mr397844lfk.58.1519150796515; Tue, 20 Feb 2018 10:19:56 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.35 with HTTP; Tue, 20 Feb 2018 10:19:55 -0800 (PST) In-Reply-To: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> References: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> From: Alan Somers Date: Tue, 20 Feb 2018 11:19:55 -0700 X-Google-Sender-Auth: tsao2UM2yKe2AP2aQV_-yycYhD0 Message-ID: Subject: Re: 'scanimage -L' from 'graphics/sane-backends' causes system crashes after a while To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:19:59 -0000 Please open an issue on bugzilla, and include the full stacktrace of the crash. On Tue, Feb 20, 2018 at 11:15 AM, Yuri wrote: > For my system this works with a 100% reliability: run 'scanimage -L' (or > just scan something), and system will crash after a few hours or so. > > '-L' option calls the function 'sane_get_devices', which has about 90 > implementations there. It calls all of them trying to find a scanner. Some > of them cause system to crash later. > > My real scanner is on the wifi network. I'm not sure if the real scanner > is what causes the problem, or maybe it's some other test among these 90 > 'sane_get_devices' functions that causes this problem. > > What is the easiest way to troubleshoot this? The problem is that the > crash doesn't come right away. > > 11.1-STABLE > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Feb 20 18:35:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 667E8F1DD59 for ; Tue, 20 Feb 2018 18:35:42 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id A165D85B2E; Tue, 20 Feb 2018 18:35:41 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from yv.noip.me (c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id w1KIZeEV076842 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Feb 2018 10:35:40 -0800 (PST) (envelope-from yuri@rawbw.com) X-Authentication-Warning: shell1.rawbw.com: Host c-24-4-131-132.hsd1.ca.comcast.net [24.4.131.132] claimed to be yv.noip.me Subject: Re: 'scanimage -L' from 'graphics/sane-backends' causes system crashes after a while To: Freebsd hackers list Cc: Alan Somers References: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> From: Yuri Message-ID: <766fc276-afd0-a214-509f-3ccf98bef733@rawbw.com> Date: Tue, 20 Feb 2018 10:35:39 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 18:35:42 -0000 On 02/20/18 10:19, Alan Somers wrote: > Please open an issue on bugzilla, and include the full stacktrace of the > crash. It actually freezes, doesn't crash. So I won't be able to get a stack trace. Yuri From owner-freebsd-hackers@freebsd.org Tue Feb 20 19:20:20 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AA9EBF2305E for ; Tue, 20 Feb 2018 19:20:20 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46EAB87F62; Tue, 20 Feb 2018 19:20:19 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 06BB02603D1; Tue, 20 Feb 2018 20:20:12 +0100 (CET) Subject: Re: 'scanimage -L' from 'graphics/sane-backends' causes system crashes after a while To: Yuri , Freebsd hackers list Cc: Alan Somers References: <5fe20134-4b4f-4789-fa54-8ce746453130@rawbw.com> <766fc276-afd0-a214-509f-3ccf98bef733@rawbw.com> From: Hans Petter Selasky Message-ID: <0de11b5e-b154-9f20-e59c-0a5b7d932375@selasky.org> Date: Tue, 20 Feb 2018 20:20:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <766fc276-afd0-a214-509f-3ccf98bef733@rawbw.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2018 19:20:20 -0000 On 02/20/18 19:35, Yuri wrote: > On 02/20/18 10:19, Alan Somers wrote: >> Please open an issue on bugzilla, and include the full stacktrace of the >> crash. > > > It actually freezes, doesn't crash. So I won't be able to get a stack > trace. > Hi, "procstat -ak " might give some clues. --HPS From owner-freebsd-hackers@freebsd.org Wed Feb 21 00:30:31 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E8C3F15CB4 for ; Wed, 21 Feb 2018 00:30:31 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C06D79D56 for ; Wed, 21 Feb 2018 00:30:31 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x22c.google.com with SMTP id e135-v6so4594153ybb.3 for ; Tue, 20 Feb 2018 16:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7tAI1DYxtlRr90kqxIIDQddCgWeSeKq8zA5/jiQDDCo=; b=e6fijYIhK65hRm5IC4uLlhD/8+zg41vkMUp8B8cThYqmehrAwYcNYZFAdQCLpGXmG/ CLQGzbyFupct+PlIKU3CvnF9LO60yvCVchATHU0wiYZtEvZYQFzFwh2LS0PUlNE1OVig TADzMJ+/AjJt+kDBc6Jbu4dZo4NyQsvXnEy50= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7tAI1DYxtlRr90kqxIIDQddCgWeSeKq8zA5/jiQDDCo=; b=A5T6JOOa9ZLvjEmBPdc+6TzSWC2VclT2pn3hUOP5pmZGk2uMCZNyzUbfBxE3NRQUUW 9kNnKgrdQHFT9Nwwzky5c7x7PdQ5eQvf5UsYch+onoAqSSRCcOaX5Ab/9eup5nVsHOlA 4LlGPdaJ0E/VvaDc3XiDVST6SlhtLBymETV8gBzh70PUknIQAeOmdWB70XO5Hvqan8Ey EbWSiN1MGmaXJjBeM8I+X4uT3673Tt00eNcjBmy41vgSCwBKHDSilzkFirdycwchvdo+ ph+MDf2b7ouDkmWa1z9BnxsfmbVnwHAVnle/Vt1+TifFFOTMCUe4/Pfuxlrjzd48dJo/ YMvw== X-Gm-Message-State: APf1xPBVG1oqSkSXoJ/SVnYLh/Em7KD0n7F9TJiMOAhz1LkKIvymGjEu 9MA8ynPgjM7j1aAed8X9k48ao2VNs3WHdI8+/tbbfuy4 X-Google-Smtp-Source: AH8x225EK8U6hGMTF7TN9sogFNgQjXZqUn/8w9JQhMTYn/aNEk5/RJPwIOV4BWmOow9QuBYdENbyYYuCoPKp4gW0VPU= X-Received: by 2002:a25:7b06:: with SMTP id w6-v6mr1093180ybc.69.1519173030009; Tue, 20 Feb 2018 16:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 16:29:59 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Tue, 20 Feb 2018 16:29:59 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: FreeBSD Hackers , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 00:30:31 -0000 I filed a request for a slightly modified version of this patch to be exp-run. I'm planning on committing unless there is significant fallout or objections on this list. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 On 15 February 2018 at 00:10, Eitan Adler wrote: > Hi all, > > POSIX requires that the fd_set arguments in select(2) be marked as > restrict. This patch attempts to implement that. > > (a) Am I missing anything? > (b) Anything in particular to watch out for? > (c) Assuming an exp-run passes any reason not to commit? > > > Index: lib/libc/sys/select.2 > =================================================================== > --- lib/libc/sys/select.2 (revision 329296) > +++ lib/libc/sys/select.2 (working copy) > @@ -39,7 +39,7 @@ > .Sh SYNOPSIS > .In sys/select.h > .Ft int > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > *exceptfds" "struct timeval *timeout" > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > .Fn FD_SET fd &fdset > .Fn FD_CLR fd &fdset > .Fn FD_ISSET fd &fdset > Index: lib/libc/sys/select.c > =================================================================== > --- lib/libc/sys/select.c (revision 329296) > +++ lib/libc/sys/select.c (working copy) > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > #pragma weak select > int > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > restrict es, struct timeval *t) > { > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) > Index: sys/sys/select.h > =================================================================== > --- sys/sys/select.h (revision 329296) > +++ sys/sys/select.h (working copy) > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > const struct timespec *__restrict, const sigset_t *__restrict); > #ifndef _SELECT_DECLARED > #define _SELECT_DECLARED > -/* XXX missing restrict type-qualifier */ > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > *__restrict, struct timeval *); > #endif > __END_DECLS > #endif /* !_KERNEL */ > > > -- > Eitan Adler -- Eitan Adler From owner-freebsd-hackers@freebsd.org Wed Feb 21 01:52:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D562CF1D5B6 for ; Wed, 21 Feb 2018 01:52:36 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 68AB87D4FC for ; Wed, 21 Feb 2018 01:52:36 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-qt0-x22f.google.com with SMTP id v90so114669qte.12 for ; Tue, 20 Feb 2018 17:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JaH26S1HWVW1E/QSWCcyQNpHUojcN2+HZnec9mksyiM=; b=P8/EOJTe+WxXbh6MMgrBtHNc67RuC/HltjYNVhdg1fieUgfsgh7oNH8cB/tF1MkQ+c uYGSBZ6D3tty2BCTRYhaOsgD9htYiUoPHe2Qyk62RIVIRxbsbpZAn7r4QQyHaidNexEG W+KgTY/alwqANc26WGJ5ZqLFB9Zg5RflFGUBEeSUSYaihvBs9ON1MPaalCVNC1TIzAwN Wy3b01bNZVhMiPF0MdHOOmq7Kyg/mfdK4mbs0ZZLR+LvdtFoO1y1i8ikP8caE/d1Mm5R hEfVeWY3VU/9PKbokX9vVSBrzycHvOYP+o1bNlOqi2nYyNddAL5Z8vG39cvzNhEAFiNG bEMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JaH26S1HWVW1E/QSWCcyQNpHUojcN2+HZnec9mksyiM=; b=ZY87XE0EBI9PlsrKKkqpHYSQANFdyMjQCQCBE8OCN8DZY1RgTExYovHkcypBxtiw3T aKmD8Dl7GoGwkOeKeGyIokGKUBcMxHZ/vuQFa2aehLNk7pfuFSIEzsj6f7Q+1rVMiXF4 hFBY8tvfNqI8hS71A67VJONUWdn8CxcjPGoqFICnrCoduqpwsVXZNh0fwYmAPuIu5Isz i5sCoLJoi5fP+7sUDp+FC3bMZtWp1BebXJYPqnpDWTEicw2SwMd/X95NowLjODEY3UlN RvS2mj1NM5NiHqMW3O/Urjfz6hBwqZ4sn21EcjnvZebEdcLsrB3fMbaqlqfCHv4QEYJB 9F8g== X-Gm-Message-State: APf1xPCMI985XCkl/mdNDdmRbwd64e9Gv5OOWdriOtRGRqL6sgZvcoro m96bQhxyPN3OQY1Nr6SeLKH2zDV9/MQe+KDFz3NfLw== X-Google-Smtp-Source: AH8x226afCHH5zhohDuJeX19CuaQjr4w66A1CwxEtMLYT31i9FrLoRFl7tyK3Kx8z//AtqG0G3ByxlGWzDtxUHT6eVE= X-Received: by 10.200.52.204 with SMTP id x12mr2741011qtb.267.1519177956046; Tue, 20 Feb 2018 17:52:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.32.74 with HTTP; Tue, 20 Feb 2018 17:52:35 -0800 (PST) In-Reply-To: References: From: Stefan Blachmann Date: Wed, 21 Feb 2018 02:52:35 +0100 Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers , Warner Losh Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 01:52:37 -0000 As the last C standard I know is ANSI, I was curious and read what restrict does (https://en.wikipedia.org/wiki/Restrict). To understand more about select() I read in the Linux tutorial (http://man7.org/linux/man-pages/man2/select_tut.2.html) . The section "Select Law" looks like that things could break easy. Personally (in particular because I don't know the matter) I would be afraid that making select pointers restrict could cause hard-to debug misbehavior of a few programs that are already working borderline (linux ports etc). But as said, this is my unqualified guess. And, few, almost no documents on select show it as restrict. Always following Posix isn't necessarily good, as many don't care about it. For example, with 11.0 the default Posix conform SHM setting was changed to non-Posix-compliant, because posix conformity caused just too many people troubles. And, maybe the gain would be little anyway? Just my worthless 2 cents. Have a good day @hackers :) Stefan On 2/21/18, Eitan Adler wrote: > I filed a request for a slightly modified version of this patch to be > exp-run. I'm planning on committing unless there is significant > fallout or objections on this list. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > > On 15 February 2018 at 00:10, Eitan Adler wrote: >> Hi all, >> >> POSIX requires that the fd_set arguments in select(2) be marked as >> restrict. This patch attempts to implement that. >> >> (a) Am I missing anything? >> (b) Anything in particular to watch out for? >> (c) Assuming an exp-run passes any reason not to commit? >> >> >> Index: lib/libc/sys/select.2 >> =================================================================== >> --- lib/libc/sys/select.2 (revision 329296) >> +++ lib/libc/sys/select.2 (working copy) >> @@ -39,7 +39,7 @@ >> .Sh SYNOPSIS >> .In sys/select.h >> .Ft int >> -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set >> *exceptfds" "struct timeval *timeout" >> +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict >> writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" >> .Fn FD_SET fd &fdset >> .Fn FD_CLR fd &fdset >> .Fn FD_ISSET fd &fdset >> Index: lib/libc/sys/select.c >> =================================================================== >> --- lib/libc/sys/select.c (revision 329296) >> +++ lib/libc/sys/select.c (working copy) >> @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); >> >> #pragma weak select >> int >> -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) >> +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * >> restrict es, struct timeval *t) >> { >> >> return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) >> Index: sys/sys/select.h >> =================================================================== >> --- sys/sys/select.h (revision 329296) >> +++ sys/sys/select.h (working copy) >> @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res >> const struct timespec *__restrict, const sigset_t *__restrict); >> #ifndef _SELECT_DECLARED >> #define _SELECT_DECLARED >> -/* XXX missing restrict type-qualifier */ >> -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); >> +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set >> *__restrict, struct timeval *); >> #endif >> __END_DECLS >> #endif /* !_KERNEL */ >> >> >> -- >> Eitan Adler > > > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Feb 21 03:27:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EF23F25C1B for ; Wed, 21 Feb 2018 03:27:40 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (220-135-115-6.HINET-IP.hinet.net [220.135.115.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns.kevlo.org", Issuer "ns.kevlo.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7572E81A18 for ; Wed, 21 Feb 2018 03:27:37 +0000 (UTC) (envelope-from kevlo@ns.kevlo.org) Received: from ns.kevlo.org (localhost [127.0.0.1]) by ns.kevlo.org (8.15.2/8.15.2) with ESMTPS id w1L3Mn1j081693 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 11:22:50 +0800 (CST) (envelope-from kevlo@ns.kevlo.org) Received: (from kevlo@localhost) by ns.kevlo.org (8.15.2/8.15.2/Submit) id w1L3MlsG081692; Wed, 21 Feb 2018 11:22:47 +0800 (CST) (envelope-from kevlo) Date: Wed, 21 Feb 2018 11:22:47 +0800 From: Kevin Lo To: Eitan Adler Cc: FreeBSD Hackers , Warner Losh Subject: Re: Marking select(2) as restrict Message-ID: <20180221032247.GA81670@ns.kevlo.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.0 (2017-02-23) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:27:40 -0000 On Tue, Feb 20, 2018 at 04:29:59PM -0800, Eitan Adler wrote: > > I filed a request for a slightly modified version of this patch to be > exp-run. I'm planning on committing unless there is significant > fallout or objections on this list. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 Please send your patch to standards@. The freebsd-standards mailing list was created for precisely this purpose, thanks. > On 15 February 2018 at 00:10, Eitan Adler wrote: > > Hi all, > > > > POSIX requires that the fd_set arguments in select(2) be marked as > > restrict. This patch attempts to implement that. > > > > (a) Am I missing anything? > > (b) Anything in particular to watch out for? > > (c) Assuming an exp-run passes any reason not to commit? > > > > > > Index: lib/libc/sys/select.2 > > =================================================================== > > --- lib/libc/sys/select.2 (revision 329296) > > +++ lib/libc/sys/select.2 (working copy) > > @@ -39,7 +39,7 @@ > > .Sh SYNOPSIS > > .In sys/select.h > > .Ft int > > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > > *exceptfds" "struct timeval *timeout" > > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > > .Fn FD_SET fd &fdset > > .Fn FD_CLR fd &fdset > > .Fn FD_ISSET fd &fdset > > Index: lib/libc/sys/select.c > > =================================================================== > > --- lib/libc/sys/select.c (revision 329296) > > +++ lib/libc/sys/select.c (working copy) > > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > > > #pragma weak select > > int > > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > > restrict es, struct timeval *t) > > { > > > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) > > Index: sys/sys/select.h > > =================================================================== > > --- sys/sys/select.h (revision 329296) > > +++ sys/sys/select.h (working copy) > > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > > const struct timespec *__restrict, const sigset_t *__restrict); > > #ifndef _SELECT_DECLARED > > #define _SELECT_DECLARED > > -/* XXX missing restrict type-qualifier */ > > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > > *__restrict, struct timeval *); > > #endif > > __END_DECLS > > #endif /* !_KERNEL */ > > > > > > -- > > Eitan Adler > > > > -- > Eitan Adler > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Feb 21 03:28:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9960F25D8E for ; Wed, 21 Feb 2018 03:28:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7789F81B18 for ; Wed, 21 Feb 2018 03:28:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1L3SomN038973 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Feb 2018 19:28:52 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers References: From: Julian Elischer Message-ID: <83920964-9ad6-4019-14c5-3e16eff21f2e@freebsd.org> Date: Wed, 21 Feb 2018 11:28:44 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:28:56 -0000 > On 2/21/18, Eitan Adler wrote: >> I filed a request for a slightly modified version of this patch to be >> exp-run. I'm planning on committing unless there is significant >> fallout or objections on this list. >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 >> >> On 15 February 2018 at 00:10, Eitan Adler wrote: >>> Hi all, >>> >>> POSIX requires that the fd_set arguments in select(2) be marked as >>> restrict. This patch attempts to implement that. >>> >>> (a) Am I missing anything? >>> (b) Anything in particular to watch out for? >>> (c) Assuming an exp-run passes any reason not to commit? >>> >>> >>> Index: lib/libc/sys/select.2 >>> =================================================================== >>> --- lib/libc/sys/select.2 (revision 329296) >>> +++ lib/libc/sys/select.2 (working copy) >>> @@ -39,7 +39,7 @@ >>> .Sh SYNOPSIS >>> .In sys/select.h >>> .Ft int >>> -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set >>> *exceptfds" "struct timeval *timeout" >>> +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict >>> writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" >>> .Fn FD_SET fd &fdset >>> .Fn FD_CLR fd &fdset >>> .Fn FD_ISSET fd &fdset >>> Index: lib/libc/sys/select.c >>> =================================================================== >>> --- lib/libc/sys/select.c (revision 329296) >>> +++ lib/libc/sys/select.c (working copy) >>> @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); >>> >>> #pragma weak select >>> int >>> -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) >>> +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * >>> restrict es, struct timeval *t) >>> { >>> >>> return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) >>> Index: sys/sys/select.h >>> =================================================================== >>> --- sys/sys/select.h (revision 329296) >>> +++ sys/sys/select.h (working copy) >>> @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res >>> const struct timespec *__restrict, const sigset_t *__restrict); >>> #ifndef _SELECT_DECLARED >>> #define _SELECT_DECLARED >>> -/* XXX missing restrict type-qualifier */ >>> -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); >>> +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set >>> *__restrict, struct timeval *); >>> #endif >>> __END_DECLS >>> #endif /* !_KERNEL */ >>> >>> >>> -- >>> Eitan Adler >> >> >> -- >> Eitan Adler >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> So, you are saying that the bitmaps can not be shared.. I can not think of a reason they would be shared but...  I can also say that I can not think of a proof that there does not exist a case where it would make sense. What is the potential gain?  and is it set so in other OS or standards? Julian From owner-freebsd-hackers@freebsd.org Wed Feb 21 03:29:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 125DFF25E76 for ; Wed, 21 Feb 2018 03:29:35 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 9705981BA9 for ; Wed, 21 Feb 2018 03:29:34 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (203-59-173-201.dyn.iinet.net.au [203.59.173.201]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id w1L3TUfT038978 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 20 Feb 2018 19:29:32 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: Marking select(2) as restrict To: Stefan Blachmann , Eitan Adler Cc: FreeBSD Hackers References: From: Julian Elischer Message-ID: <01800d65-ec8d-2337-5459-803b5e2fbe0e@freebsd.org> Date: Wed, 21 Feb 2018 11:29:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 03:29:35 -0000 On 21/2/18 9:52 am, Stefan Blachmann wrote: > As the last C standard I know is ANSI, I was curious and read what > restrict does (https://en.wikipedia.org/wiki/Restrict). > > To understand more about select() I read in the Linux tutorial > (http://man7.org/linux/man-pages/man2/select_tut.2.html) . > The section "Select Law" looks like that things could break easy. > > Personally (in particular because I don't know the matter) I would be > afraid that making select pointers restrict could cause hard-to debug > misbehavior of a few programs that are already working borderline > (linux ports etc). > > But as said, this is my unqualified guess. > And, few, almost no documents on select show it as restrict. > > Always following Posix isn't necessarily good, as many don't care about it. > For example, with 11.0 the default Posix conform SHM setting was > changed to non-Posix-compliant, because posix conformity caused just > too many people troubles. > And, maybe the gain would be little anyway? > > Just my worthless 2 cents. > Have a good day @hackers :) > Stefan > > > On 2/21/18, Eitan Adler wrote: >> I filed a request for a slightly modified version of this patch to be >> exp-run. I'm planning on committing unless there is significant >> fallout or objections on this list. >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 >> >> On 15 February 2018 at 00:10, Eitan Adler wrote: >>> Hi all, >>> >>> POSIX requires that the fd_set arguments in select(2) be marked as >>> restrict. This patch attempts to implement that. >>> >>> (a) Am I missing anything? >>> (b) Anything in particular to watch out for? >>> (c) Assuming an exp-run passes any reason not to commit? >>> >>> >>> Index: lib/libc/sys/select.2 >>> =================================================================== >>> --- lib/libc/sys/select.2 (revision 329296) >>> +++ lib/libc/sys/select.2 (working copy) >>> @@ -39,7 +39,7 @@ >>> .Sh SYNOPSIS >>> .In sys/select.h >>> .Ft int >>> -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set >>> *exceptfds" "struct timeval *timeout" >>> +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict >>> writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" >>> .Fn FD_SET fd &fdset >>> .Fn FD_CLR fd &fdset >>> .Fn FD_ISSET fd &fdset >>> Index: lib/libc/sys/select.c >>> =================================================================== >>> --- lib/libc/sys/select.c (revision 329296) >>> +++ lib/libc/sys/select.c (working copy) >>> @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); >>> >>> #pragma weak select >>> int >>> -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) >>> +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * >>> restrict es, struct timeval *t) >>> { >>> >>> return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) >>> Index: sys/sys/select.h >>> =================================================================== >>> --- sys/sys/select.h (revision 329296) >>> +++ sys/sys/select.h (working copy) >>> @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res >>> const struct timespec *__restrict, const sigset_t *__restrict); >>> #ifndef _SELECT_DECLARED >>> #define _SELECT_DECLARED >>> -/* XXX missing restrict type-qualifier */ >>> -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); >>> +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set >>> *__restrict, struct timeval *); >>> #endif >>> __END_DECLS >>> #endif /* !_KERNEL */ >>> >>> >>> -- >>> Eitan Adler >> >> >> -- >> Eitan Adler >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Wed Feb 21 04:52:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92816F031CF for ; Wed, 21 Feb 2018 04:52:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2915F8582F for ; Wed, 21 Feb 2018 04:52:02 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yw0-x22a.google.com with SMTP id l34so129883ywk.11 for ; Tue, 20 Feb 2018 20:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=87+jY1Jz7UxZaZvpNHNkdVrbgGotLdqJrBJ6d1BgE50=; b=glEIgpkll3IqLn8kj7gfIgyizcHGLyf+n8QumDjU2OJKDNNDCXCAA9juJMjq679L61 mc93RCjCXU1OJPNMVAgE8Q4ATopXBOFSai99cMj1j2HmA3zrDRwmbMXQTH7we1dL6W9n udb7h5FdUM7H3TslJhPY8qzYaYshBnybWGwo8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=87+jY1Jz7UxZaZvpNHNkdVrbgGotLdqJrBJ6d1BgE50=; b=J/CJurl/B2v+vry2O7WsGAWC6l4D3vAa5MwtN5k3RvGcI5cnb8LZZDaclcxFn/EAhq n/vnI8dvHt0MX+fBJFqu4RIOdcX7YZfWf2LwmVVhXhsixhS8R2GkyBzYy53KCHCFM1e1 ZSTwd+7Vb9xQW9+0yN6J9b2T1JulETwqbKFnTRc1ZZXWC/0QgzVnHEim84ssgK9/qk41 lwlc7LXApm35QvE3UZ0n1HCTs8ei4/KfgnhlnUnKJca6BSA6ywFtLnFbiI8NRy33/xOv MZMllIWCMUheTM7Vv2uWOt0B3fLWcMK1NiNd+lPjyN+PMFrilz61ALHazYjDhhilAMdt Tavg== X-Gm-Message-State: APf1xPCv+cyL7gWt8xjHYvHl7OQwrdpHtyXWyxeTFM9Y6SQdIqdCnn2E 32FRun5ChoBlqaSiQ3NeeFmT3jbclE6e56dE/R5n0w== X-Google-Smtp-Source: AH8x226+5NxN/OfgBLzVW91wh20LM03CDGT1yvkMZ+5nMz0wKtG0kFt6nWhHy6C9Igr5NKKH7pNBGS9Kc3ZoKkPBFdM= X-Received: by 10.13.214.214 with SMTP id y205mr1416048ywd.37.1519188721582; Tue, 20 Feb 2018 20:52:01 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 20:52:00 -0800 (PST) In-Reply-To: <20180221032247.GA81670@ns.kevlo.org> References: <20180221032247.GA81670@ns.kevlo.org> From: Eitan Adler Date: Tue, 20 Feb 2018 20:52:00 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Kevin Lo , FreeBSD Standards Cc: FreeBSD Hackers , Warner Losh Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 04:52:02 -0000 Adding standards mailing list On Tuesday, 20 February 2018, Kevin Lo wrote: > On Tue, Feb 20, 2018 at 04:29:59PM -0800, Eitan Adler wrote: > > > > I filed a request for a slightly modified version of this patch to be > > exp-run. I'm planning on committing unless there is significant > > fallout or objections on this list. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > > Please send your patch to standards@. The freebsd-standards mailing list > was created for precisely this purpose, thanks. > > > On 15 February 2018 at 00:10, Eitan Adler wrote: > > > Hi all, > > > > > > POSIX requires that the fd_set arguments in select(2) be marked as > > > restrict. This patch attempts to implement that. > > > > > > (a) Am I missing anything? > > > (b) Anything in particular to watch out for? > > > (c) Assuming an exp-run passes any reason not to commit? > > > > > > > > > Index: lib/libc/sys/select.2 > > > =================================================================== > > > --- lib/libc/sys/select.2 (revision 329296) > > > +++ lib/libc/sys/select.2 (working copy) > > > @@ -39,7 +39,7 @@ > > > .Sh SYNOPSIS > > > .In sys/select.h > > > .Ft int > > > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > > > *exceptfds" "struct timeval *timeout" > > > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > > > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > > > .Fn FD_SET fd &fdset > > > .Fn FD_CLR fd &fdset > > > .Fn FD_ISSET fd &fdset > > > Index: lib/libc/sys/select.c > > > =================================================================== > > > --- lib/libc/sys/select.c (revision 329296) > > > +++ lib/libc/sys/select.c (working copy) > > > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > > > > > #pragma weak select > > > int > > > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > > > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > > > restrict es, struct timeval *t) > > > { > > > > > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval > *)) > > > Index: sys/sys/select.h > > > =================================================================== > > > --- sys/sys/select.h (revision 329296) > > > +++ sys/sys/select.h (working copy) > > > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > > > const struct timespec *__restrict, const sigset_t *__restrict); > > > #ifndef _SELECT_DECLARED > > > #define _SELECT_DECLARED > > > -/* XXX missing restrict type-qualifier */ > > > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > > > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > > > *__restrict, struct timeval *); > > > #endif > > > __END_DECLS > > > #endif /* !_KERNEL */ > > > > > > > > > -- > > > Eitan Adler > > > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > -- Sent from my Turing Machine From owner-freebsd-hackers@freebsd.org Wed Feb 21 05:19:02 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7215DF0519C for ; Wed, 21 Feb 2018 05:19:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03F3D86663 for ; Wed, 21 Feb 2018 05:19:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id m22so797706iob.12 for ; Tue, 20 Feb 2018 21:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=m4sPwmQigNOQQJi/tKhRkjiKy4ZYnCrWG7adkLIiYJg=; b=bcXZWlxud9dOu3tE1g/KBx25GL+E3qLYsebAE5R9BcxHGnCT5+QMlznu5wzNBIHUFq bOBqpNQyIr9y3Om0oWC+1sCMuv6EvDLgGALFh34vNac8H4FnThM4XKRABfrrsIlGmJd6 2hn+melm1Ug2Q4pOKSHJ2zhIWfhfb7FbOcGoSu7YfKbQffuFLi46CKJxYseP/Mxc0de/ n8Pg8vm14tGiNts6Rozd3iRf7flLILggvz0fyLLKGKGy9YpZeyzvABhbXe5hoYoGbREE iZO/3cuJOIDK6NnK++Qq+9inn7OOLp0sPTQQ6IBUNTDAdEFcFEc2j5G/QKGrIN4u90+T OWeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=m4sPwmQigNOQQJi/tKhRkjiKy4ZYnCrWG7adkLIiYJg=; b=J0EwUvhdriHUoO+tJSYW72GBqWiq0Rjsgi5S4ZrUWiILI7iiJ0+VMwTmGfLH3htc6F S+tTRiKioph7jVK/2WDilQ0x4r/02u7SQuWFe8Vi9+q3eA5f4Nfuet1p+hB9HQgIsCxb za5jZcJOe9PzAHBVbPWIAK+kKm3r2nBY9EvHv3lAskYEIryxB/b1VDuUdToXjgaKuqN0 Me5/jr8nKhOzT4GHgNP3h7N5DW56yCW8glX9uERtws/2trQ/DqNHf7BzpfxgFtxrWfIO 8imVuuZ/pYBuk0e5tY+vrxPtq5H2j9yXz5QE0dUQyBC7B+W51gXsF1PdaMoaqiObacol 3zOg== X-Gm-Message-State: APf1xPAqcppDMYrrjqv/WgMB5iIH4KW2Gsa3ghdAu7HCy/xk8etVyeyS fRq+PY/9ZaicZHimvU3lPLFxQJLe1lzYXDEjRmXuNg== X-Google-Smtp-Source: AG47ELvp+6Rpq1CKNipFUtqxiGkg0Wmp5pfqysSY8m52ACok3fgVkhrh7JsAU6A0Jr2ks1JdzIE5kJWdjkgveXv/KAg= X-Received: by 10.107.175.77 with SMTP id y74mr2724896ioe.37.1519190341199; Tue, 20 Feb 2018 21:19:01 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Tue, 20 Feb 2018 21:19:00 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:9198:c568:89aa:9c67] Received: by 10.79.201.67 with HTTP; Tue, 20 Feb 2018 21:19:00 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> From: Warner Losh Date: Tue, 20 Feb 2018 22:19:00 -0700 X-Google-Sender-Auth: 2aoxrDjCPShCvlqRVEjvQVupYYw Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: Kevin Lo , freebsd-standards@freebsd.org, FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 05:19:02 -0000 On Feb 20, 2018 9:52 PM, "Eitan Adler" wrote: Adding standards mailing list On Tuesday, 20 February 2018, Kevin Lo wrote: > On Tue, Feb 20, 2018 at 04:29:59PM -0800, Eitan Adler wrote: > > > > I filed a request for a slightly modified version of this patch to be > > exp-run. I'm planning on committing unless there is significant > > fallout or objections on this list. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > > Please send your patch to standards@. The freebsd-standards mailing list > was created for precisely this purpose, thanks. > > > On 15 February 2018 at 00:10, Eitan Adler wrote: > > > Hi all, > > > > > > POSIX requires that the fd_set arguments in select(2) be marked as > > > restrict. This patch attempts to implement that. > > > > > > (a) Am I missing anything? > > > (b) Anything in particular to watch out for? > > > (c) Assuming an exp-run passes any reason not to commit? > > > > > > > > > Index: lib/libc/sys/select.2 > > > =================================================================== > > > --- lib/libc/sys/select.2 (revision 329296) > > > +++ lib/libc/sys/select.2 (working copy) > > > @@ -39,7 +39,7 @@ > > > .Sh SYNOPSIS > > > .In sys/select.h > > > .Ft int > > > -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > > > *exceptfds" "struct timeval *timeout" > > > +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > > > writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > > > .Fn FD_SET fd &fdset > > > .Fn FD_CLR fd &fdset > > > .Fn FD_ISSET fd &fdset > > > Index: lib/libc/sys/select.c > > > =================================================================== > > > --- lib/libc/sys/select.c (revision 329296) > > > +++ lib/libc/sys/select.c (working copy) > > > @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > > > > > > #pragma weak select > > > int > > > -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > > > +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > > > restrict es, struct timeval *t) > > > { > > > > > > return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval > *)) > > > Index: sys/sys/select.h > > > =================================================================== > > > --- sys/sys/select.h (revision 329296) > > > +++ sys/sys/select.h (working copy) > > > @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > > > const struct timespec *__restrict, const sigset_t *__restrict); > > > #ifndef _SELECT_DECLARED > > > #define _SELECT_DECLARED > > > -/* XXX missing restrict type-qualifier */ > > > -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > > > +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > > > *__restrict, struct timeval *); > > > #endif > > > __END_DECLS > > > #endif /* !_KERNEL */ > Once upon a time, this would break a lot of code. Perhaps times have changed. Does the state of the art give warnings,when restrict is violated? If not, how do you propose the ports broken subtlely be detected? Warner From owner-freebsd-hackers@freebsd.org Wed Feb 21 06:14:37 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DD03F08647 for ; Wed, 21 Feb 2018 06:14:37 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A408668665 for ; Wed, 21 Feb 2018 06:14:36 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x229.google.com with SMTP id z7-v6so177588ybz.13 for ; Tue, 20 Feb 2018 22:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=46bdcs421TJ4f9uLhJEPcomtuF0utsyTayp8Bvgr6SQ=; b=W3QbIjzSQ77F2havxZPHL71NI2y1AwG/WAxNhY8CGGP/m/94ImPLKG18/kocm6D6CL OTCYLHca8o6MvI9xP6ayDrHN46DUZR7Pqm9nSb9FdDj5IKb5no9hbSQRP+m30yERlI7B Mh2/Nxq66FRIQ1PBYOU9VTYvqNn+e1z5pgUg8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=46bdcs421TJ4f9uLhJEPcomtuF0utsyTayp8Bvgr6SQ=; b=kZfmJtjMt9tH4L+RZYnTNuVHHDBq3Gyx9ywsrMOYJdQP0nCwegM7nfVfMQdsfrJHL7 Xf7JXeUPlupyTn8GBGmAcskZzLKUMpKsGAobpdE+r36yCafhQQDI1lI3vlkUgR20dL4V 1arLLvQhS0l5j5LG8G4vxdWpqDgY6MNUPh6o5zih2nXDCio8k64xM3++Idm8gUq8tS2q J/HvErmitlzviBZS17IkVEIVvUNZxDqo/1t7juityYHaTHpU0Ascj0Ln9mjW0kDUvTxX LL7jb2eFekSwhWVTj/jOPZTY7ON9jAgZNb5oVUTBKNIVtBbI6jLqS7kzCCqIqafsVsQL XYQA== X-Gm-Message-State: APf1xPAaYe1EsyIuCmL3VsoLQ343bELRVOjyWHMsGkSumcsFWVk03vNm RhK6Vx0wNLweyqHTS6ug1M02iYrJv71RLzdbDPIhmQ== X-Google-Smtp-Source: AH8x224NxJfskrNMCjN20+XUIMvbwLp1KfOEQUfEyD13dxoMxmWYhu3Z7L9avA1NvKJyKQEKJUkiO99ptT+tG2jjMfc= X-Received: by 2002:a25:86c5:: with SMTP id y5-v6mr1562437ybm.194.1519193676084; Tue, 20 Feb 2018 22:14:36 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 22:14:05 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> From: Eitan Adler Date: Tue, 20 Feb 2018 22:14:05 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Warner Losh Cc: Kevin Lo , FreeBSD Standards , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 06:14:37 -0000 On 20 February 2018 at 21:19, Warner Losh wrote: > Once upon a time, this would break a lot of code. Perhaps times have > changed. I've seen very little code that this would break though some of it certainly exists. > Does the state of the art give warnings,when restrict is violated? In the general case it can not since aliasing may occur through run-time warnings. Modern compilers can warn in specific sub-cases though: restrict.c:10:6: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] meh(&a, &a); > If not, > how do you propose the ports broken subtlely be detected? My plan was to commit to current but not MFC. This would allow users to detect issues and report them. Another option is to request that POSIX change the definition of select to not require restrict though I am doubtful this will happen. -- Eitan Adler From owner-freebsd-hackers@freebsd.org Wed Feb 21 08:55:58 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D0DCF140D6 for ; Wed, 21 Feb 2018 08:55:58 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03CC36DC8C; Wed, 21 Feb 2018 08:55:58 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr0-x235.google.com with SMTP id u49so2164029wrc.10; Wed, 21 Feb 2018 00:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=VQ2+zQxwUTBArFXlN9T0+UzJLEPAYTlO3MlcIWUQcdU=; b=R1g7eETSL+83MGjdZ9C8nM1ioPb1NTm5sgl5+DaoprQCvxECaLZ0WxHT36/PoIuC21 NFo9udy2a7Wg1JaBNRvte0qr6AL1ATBwdQdEuF8VVfj5GqSXqjHPGtN8G5/n+kuzQcRu V1lCe87EOQUfeSYh2zpap8mDoDE2inha5/O1QN1dsNuT7bSgUrdteL+o23ZAqpbNCwl0 xxrH0DoD40g1QtTgA9pEmqUWgtk98MmusMzPwK0k6qFcdxESCTbLv4NgaiUTC7XBZO69 QVYCDKRwRuN37+4symSUSq1jr1uqrhDTGdnwRxwp+niC3dRoVJ/TZqPdn1sWfB6MwxXr 9e2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=VQ2+zQxwUTBArFXlN9T0+UzJLEPAYTlO3MlcIWUQcdU=; b=omtnCQ1xMOj+90bzZEj+OYuM99wGwUBkAMlbZtLPSEvQ0NP86j9hvy234L2h8vMkC6 O58wpE+r5bdypWWELcFqN0E6xsakhAnJQUUXvZCqZlbTrN5LfdOh6sMFpJTd5WB/Iude gj0U50a+QYKzLQb5wVLxe2+YO7Uxo2R1KFwcWkM88FSDm5CY6UBAtOksbPYZ0m+1Pls0 b3+e++tvjCBOPalLZqacIwNeHb/T6kVKjAYIVtsSnJoCEik79MT7o4qp+Zs3GEEFPIMP kCWLr+SK+P93XUdY5shoY9EGp4KQA7fU04lVMJCmBOYTma+QBzkRe9UbRW8+3wkXIHxL sB3A== X-Gm-Message-State: APf1xPAEdfaAenU7Q/3S5bhNNlPKBEhbdqaoP4gQ6DfJUbkwTWFCCC2K 2fzlSy9Eq8sunhgIbF+LSwg1cg== X-Google-Smtp-Source: AH8x2266mHM0Xg6GEin4XgUdDNwkBY73n4HqVlpr3sCZ8jODYuTSJdL/VCxj7ZG6BjkBVrD2ZA+kPA== X-Received: by 10.28.202.26 with SMTP id a26mr1468317wmg.45.1519203356571; Wed, 21 Feb 2018 00:55:56 -0800 (PST) Received: from ernst.home (p5B0232F6.dip0.t-ipconnect.de. [91.2.50.246]) by smtp.gmail.com with ESMTPSA id s125sm6545588wmf.4.2018.02.21.00.55.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Feb 2018 00:55:55 -0800 (PST) Date: Wed, 21 Feb 2018 09:55:54 +0100 From: Gary Jennejohn To: Julian Elischer Cc: Eitan Adler , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180221095554.1dba0797@ernst.home> In-Reply-To: <83920964-9ad6-4019-14c5-3e16eff21f2e@freebsd.org> References: <83920964-9ad6-4019-14c5-3e16eff21f2e@freebsd.org> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 08:55:58 -0000 On Wed, 21 Feb 2018 11:28:44 +0800 Julian Elischer wrote: > > On 2/21/18, Eitan Adler wrote: > >> I filed a request for a slightly modified version of this patch to be > >> exp-run. I'm planning on committing unless there is significant > >> fallout or objections on this list. > >> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225981 > >> > >> On 15 February 2018 at 00:10, Eitan Adler wrote: > >>> Hi all, > >>> > >>> POSIX requires that the fd_set arguments in select(2) be marked as > >>> restrict. This patch attempts to implement that. > >>> > >>> (a) Am I missing anything? > >>> (b) Anything in particular to watch out for? > >>> (c) Assuming an exp-run passes any reason not to commit? > >>> > >>> > >>> Index: lib/libc/sys/select.2 > >>> =================================================================== > >>> --- lib/libc/sys/select.2 (revision 329296) > >>> +++ lib/libc/sys/select.2 (working copy) > >>> @@ -39,7 +39,7 @@ > >>> .Sh SYNOPSIS > >>> .In sys/select.h > >>> .Ft int > >>> -.Fn select "int nfds" "fd_set *readfds" "fd_set *writefds" "fd_set > >>> *exceptfds" "struct timeval *timeout" > >>> +.Fn select "int nfds" "fd_set * restrict readfds" "fd_set * restrict > >>> writefds" "fd_set * restrict exceptfds" "struct timeval *timeout" > >>> .Fn FD_SET fd &fdset > >>> .Fn FD_CLR fd &fdset > >>> .Fn FD_ISSET fd &fdset > >>> Index: lib/libc/sys/select.c > >>> =================================================================== > >>> --- lib/libc/sys/select.c (revision 329296) > >>> +++ lib/libc/sys/select.c (working copy) > >>> @@ -41,7 +41,7 @@ __weak_reference(__sys_select, __select); > >>> > >>> #pragma weak select > >>> int > >>> -select(int n, fd_set *rs, fd_set *ws, fd_set *es, struct timeval *t) > >>> +select(int n, fd_set * restrict rs, fd_set * restrict ws, fd_set * > >>> restrict es, struct timeval *t) > >>> { > >>> > >>> return (((int (*)(int, fd_set *, fd_set *, fd_set *, struct timeval *)) > >>> Index: sys/sys/select.h > >>> =================================================================== > >>> --- sys/sys/select.h (revision 329296) > >>> +++ sys/sys/select.h (working copy) > >>> @@ -101,8 +101,7 @@ int pselect(int, fd_set *__restrict, fd_set *__res > >>> const struct timespec *__restrict, const sigset_t *__restrict); > >>> #ifndef _SELECT_DECLARED > >>> #define _SELECT_DECLARED > >>> -/* XXX missing restrict type-qualifier */ > >>> -int select(int, fd_set *, fd_set *, fd_set *, struct timeval *); > >>> +int select(int, fd_set *__restrict, fd_set *__restrict, fd_set > >>> *__restrict, struct timeval *); > >>> #endif > >>> __END_DECLS > >>> #endif /* !_KERNEL */ > >>> > >>> > >>> -- > >>> Eitan Adler > >> > >> > >> -- > >> Eitan Adler > >> _______________________________________________ > >> freebsd-hackers@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >> > So, you are saying that the bitmaps can not be shared.. > I can not think of a reason they would be shared but... > __I can also say that I can not think of a proof that there does not > exist a case where it would make sense. > > What is the potential gain?__ and is it set so in other OS or standards? > Strangely enough, the FreeBSD pselect(2) has restrict on all pointers. pselect(2) is basically a variant of select(2) with a signal mask. -- Gary Jennejohn From owner-freebsd-hackers@freebsd.org Wed Feb 21 10:44:18 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8171DF1C787; Wed, 21 Feb 2018 10:44:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EF83672198; Wed, 21 Feb 2018 10:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1LAi1SB084085 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Feb 2018 12:44:04 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1LAi1SB084085 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1LAi0xC084083; Wed, 21 Feb 2018 12:44:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 21 Feb 2018 12:44:00 +0200 From: Konstantin Belousov To: Eitan Adler Cc: Warner Losh , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 10:44:18 -0000 On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > On 20 February 2018 at 21:19, Warner Losh wrote: > > Once upon a time, this would break a lot of code. Perhaps times have > > changed. > > I've seen very little code that this would break though some of it > certainly exists. You certainly seen very little code, but the question was about the existed code. > > > Does the state of the art give warnings,when restrict is violated? > > In the general case it can not since aliasing may occur through > run-time warnings. Modern compilers can warn in specific sub-cases > though: What run-time warnings ? Point out the code that issues them in the case of restrict (or generic aliasing) violation. In libc ? In kernel ? Did you even tried to estimate how many code around still requires disabling alias analysis to run ? How does restrict mix with no-aliasing option ? Above question contains a hint how it is possible to detect existing calls which violate the restrict specifier for select(2), but this requires running of all select(2) consumers, on patched kernel or libc/libthr. > > restrict.c:10:6: warning: passing argument 1 to restrict-qualified > parameter aliases with argument 2 [-Wrestrict] > meh(&a, &a); > > > If not, > > how do you propose the ports broken subtlely be detected? > > My plan was to commit to current but not MFC. This would allow users > to detect issues and report them. And, how to do plan to classify the bugs appeared due the change ? What specific indicators would allow you to find them out in the stream of the bug reports ? > > Another option is to request that POSIX change the definition of > select to not require restrict though I am doubtful this will happen. I fail to find an explanation of the supposed benefit of the change you proposing. Please point it out. From owner-freebsd-hackers@freebsd.org Thu Feb 22 10:29:05 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC4AFF1D2F5; Thu, 22 Feb 2018 10:29:04 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay104.isp.belgacom.be (mailrelay104.isp.belgacom.be [195.238.20.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2507B79B55; Thu, 22 Feb 2018 10:29:03 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes IronPort-PHdr: =?us-ascii?q?9a23=3Afq38BRdqJcbJwJEuZAPZUf42lGMj4u6mDksu8pMi?= =?us-ascii?q?zoh2WeGdxcS4Zh7h7PlgxGXEQZ/co6odzbaO6Oa4ASQp2tWoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7?= =?us-ascii?q?Ovr6GpLIj8Swyuu+54Dfbx9HiTahb75+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYe?= =?us-ascii?q?RWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZ?= =?us-ascii?q?TAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hy?= =?us-ascii?q?gbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyJPDIOi?= =?us-ascii?q?YYUSDOQOP+hYoIbhqFUBtha+GQuhCP/zxjNUmnP6w6s32PkhHwHc2wwgGsoDvm?= =?us-ascii?q?rVrNX3MKcZTP64zK7PzTXYcfxW3C3y6I7Tchs8pvyMQbNwccjVyUQ0Fw3FlEuf?= =?us-ascii?q?ppL4Mj2I2OoBqW+b7/BvVe+2jWMstg9/oj+qxsg2i4nJgJoYykvD9SVk2oY6Oc?= =?us-ascii?q?O3SUBhbt6+DpRcrSaaN5F5Qs4kXmpmuz46x6UFtJKmZiQG1psqyh/FZ/CafYWF?= =?us-ascii?q?7AjvWPufLDp3gn9uZaixiAyo8Ue6z+3xTsy00FFXoSVbitTMrXUN1wDL6siAV/?= =?us-ascii?q?t94l+t2TaR2ADX7eFJOUM0mrDfK54gx74/iIATsUPZEi/qmUX2jquWel849eiv?= =?us-ascii?q?7OTneavpppqGOI9ykQHyKKMumtawAeggMwgOWXaU+fik2bDg4EH1WqtGg/I3n6?= =?us-ascii?q?XDrZzXK8oWqrSkDwJb3Ysv8xO/AC2n0NQck3kHNlVFeBefgoj1OlHOIvT4AOyx?= =?us-ascii?q?g1S2jjhk2evJPqb8DZnXKXjDirjhca5n60FA0Aoz0cxf55VMB7ECJ/LzQVPxtN?= =?us-ascii?q?3bDhAiLQO0x/3qCNp41owEWGKPBrWVP7/VsV+NtaoTJLyvY4kOpD/7N/kjr9Tj?= =?us-ascii?q?iXgkglgDNf2q2oALaXOyE/BOLECQYH6qidAERzQkpA07GdDrilnKejlUfHu3Vq?= =?us-ascii?q?QnrmUnCYCiJanZS42Hu5DH2z20SM4FLltaA0yBRC+7P76PXO0BPWfLepds?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ARCwCOmo5a/4aF9lFcHAEBAQQBAQoBA?= =?us-ascii?q?YNPRhAQcCiPAY0DAQGCATIBY4gBjk2CFi+FCQQCAoIxVhcBAgEBAQEBAQIBaih?= =?us-ascii?q?CDgGBZyQBgkcBBTocIxALDgoJJQ8SGB4GE4oLAxkMrSKHOA2BMoITAQEBAQEBA?= =?us-ascii?q?QMBAQEBAQEdBYURhWWDLoJsRAQZh1IFpAo1CYgoiFuEfoEGk0uODEiLEiEBNoF?= =?us-ascii?q?RTTAIgn2Ed0A3AQmBSYpxAQEB?= X-IPAS-Result: =?us-ascii?q?A2ARCwCOmo5a/4aF9lFcHAEBAQQBAQoBAYNPRhAQcCiPAY0?= =?us-ascii?q?DAQGCATIBY4gBjk2CFi+FCQQCAoIxVhcBAgEBAQEBAQIBaihCDgGBZyQBgkcBB?= =?us-ascii?q?TocIxALDgoJJQ8SGB4GE4oLAxkMrSKHOA2BMoITAQEBAQEBAQMBAQEBAQEdBYU?= =?us-ascii?q?RhWWDLoJsRAQZh1IFpAo1CYgoiFuEfoEGk0uODEiLEiEBNoFRTTAIgn2Ed0A3A?= =?us-ascii?q?QmBSYpxAQEB?= Received: from 134.133-246-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.246.133.134]) by relay.skynet.be with ESMTP; 22 Feb 2018 11:27:54 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id w1MARqqA036862; Thu, 22 Feb 2018 11:27:53 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 22 Feb 2018 11:27:52 +0100 From: Tijl Coosemans To: Konstantin Belousov Cc: Eitan Adler , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180222112752.10da7e51@kalimero.tijl.coosemans.org> In-Reply-To: <20180221104400.GU94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:29:05 -0000 On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov wrote: > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: >> On 20 February 2018 at 21:19, Warner Losh wrote: >>> Once upon a time, this would break a lot of code. Perhaps times have >>> changed. >> >> I've seen very little code that this would break though some of it >> certainly exists. > You certainly seen very little code, but the question was about the > existed code. FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to be much fallout: https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=98cbe360d947b59e7a5eda068581f4cfeb4b99b3 From owner-freebsd-hackers@freebsd.org Thu Feb 22 10:56:21 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E11C1F217A9; Thu, 22 Feb 2018 10:56:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 596C27AFC4; Thu, 22 Feb 2018 10:56:21 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w1MAu905013493 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Feb 2018 12:56:12 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w1MAu905013493 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w1MAu8Bw013492; Thu, 22 Feb 2018 12:56:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Feb 2018 12:56:08 +0200 From: Konstantin Belousov To: Tijl Coosemans Cc: Eitan Adler , Kevin Lo , FreeBSD Standards , FreeBSD Hackers Subject: Re: Marking select(2) as restrict Message-ID: <20180222105608.GE94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180222112752.10da7e51@kalimero.tijl.coosemans.org> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 10:56:22 -0000 On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov wrote: > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > >> On 20 February 2018 at 21:19, Warner Losh wrote: > >>> Once upon a time, this would break a lot of code. Perhaps times have > >>> changed. > >> > >> I've seen very little code that this would break though some of it > >> certainly exists. > > You certainly seen very little code, but the question was about the > > existed code. > > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to > be much fallout: > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=98cbe360d947b59e7a5eda068581f4cfeb4b99b3 Clearly, nobody knowns. At least, glibc is used with gcc compilation, not with clang. Consider the recently changed devd code: select(n + 1, &fd, &fd, &fd); There, compiler can see that restrict is applied to arguments which are given same values. Since this leads to the self-contradicting statement fd != fd which cannot be true, compliler in its optimizing wisdom can assume that the code is never executing and remove it. I do not know whether clang actually makes such transformation, but it does not sound unfeasible looking at its other advances. From owner-freebsd-hackers@freebsd.org Thu Feb 22 14:43:13 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 95231F09F7D for ; Thu, 22 Feb 2018 14:43:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 238B686FE8 for ; Thu, 22 Feb 2018 14:43:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id p204so6480496itc.4 for ; Thu, 22 Feb 2018 06:43:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=EM2KxAZL0XlKpUghAGAK4YI/6AP1FycMznJ54Q1qHyw=; b=W6+hiLqGilN/tl3OZ39a7jYcLDp1bc+racuYui2dIe19Ps+09R0Rk8/CdAbuLiqzWZ YSqcAgEgsrbt39ZhX2Y7G/8LrdooJamp9/1Fi52y2emqLTugVZnhzLqmXqyLsly2TOrw QFbvY/V5GWxpetV4krypRC4zi5YoXM6B6F6yqLb2+t1zKChS9cpn/Cq1czMUn3w7RNAt CMTaV1DOtQzEGDsX4m5ut/EigUds7wGviPm3MB2fKOh/gIxc7XiOMvdaZ1rm6mLmaBt4 +isK1MIYJVVeewlqOUrLUrGc7WRgPVKhKXWWTL1GbZjfV4Yk3ZxqH+hBFyHp9OYJo2fv VZGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=EM2KxAZL0XlKpUghAGAK4YI/6AP1FycMznJ54Q1qHyw=; b=W92qsAkjsQqyjg0GpWQ/MxYH/crBRtMYhk1xrR1KsqKwZCgwAnumv0EQOPuaGioIC8 7A50pbRm6U2chHBXhXhA06tv0P88Snu9gwmA3f0a8vnBEuWsV8/UwbZt1vuvmD+CuNug PiIBvxfga7xSn4YImuEgcNfBibEj1R43MTos4GfdLwMCDbAV5wIVu/N8KqUdlBrTDmA+ xbcEVVzIob4sSipJrcunEDLhYh7j4o+tPrt74GpBM6HadDaKpUFvHkVJcb51XI2zKHdR pBHuKZ3SEWeePDeDgQB2OjgS+SN/36vgUu6WHB+bdBeQPv2WKyahxlAgob3qK49WvsAe xktg== X-Gm-Message-State: APf1xPANbnjtS7kZCVfttpEIX8IfW8vPXP52W9yrtmiZD2FeEgR06BsX 1m1G/lZCke2CFY8/fCDaP1Bv7IN70U2lrnRcUR24+g== X-Google-Smtp-Source: AH8x225fxLzIL+FiRRoRNva9EsVMydE2iVl/B3mbsn/qp0AImMFXNnP/Nsz0ehtl7jb2NhviGGqGFiFnVBIGOG+rQvA= X-Received: by 10.36.6.70 with SMTP id 67mr1664189itv.57.1519310592351; Thu, 22 Feb 2018 06:43:12 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Thu, 22 Feb 2018 06:43:11 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:18a2:a4f7:170:8dd9] In-Reply-To: <20180222105608.GE94212@kib.kiev.ua> References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Warner Losh Date: Thu, 22 Feb 2018 07:43:11 -0700 X-Google-Sender-Auth: iQ1hcDK5R_Eedt1-bvTRbCjG1nA Message-ID: Subject: Re: Marking select(2) as restrict To: Konstantin Belousov Cc: Tijl Coosemans , FreeBSD Standards , FreeBSD Hackers , Kevin Lo Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 14:43:13 -0000 On Thu, Feb 22, 2018 at 3:56 AM, Konstantin Belousov wrote: > On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: > > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov < > kostikbel@gmail.com> wrote: > > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: > > >> On 20 February 2018 at 21:19, Warner Losh wrote: > > >>> Once upon a time, this would break a lot of code. Perhaps times have > > >>> changed. > > >> > > >> I've seen very little code that this would break though some of it > > >> certainly exists. > > > You certainly seen very little code, but the question was about the > > > existed code. > > > > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to > > be much fallout: > > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h > > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h= > 98cbe360d947b59e7a5eda068581f4cfeb4b99b3 > > Clearly, nobody knowns. At least, glibc is used with gcc compilation, not > with clang. > > Consider the recently changed devd code: > select(n + 1, &fd, &fd, &fd); > There, compiler can see that restrict is applied to arguments which are > given same values. Since this leads to the self-contradicting statement > fd != fd > which cannot be true, compliler in its optimizing wisdom can assume that > the code is never executing and remove it. I do not know whether clang > actually makes such transformation, but it does not sound unfeasible > looking at its other advances. > If the compilers affirmatively fails when this happens, then the exp run will catch this stuff. If it doesn't, or just gives a warning, it likely will not. Absent that, nobody can say with certainty this change won't break anything. Warner From owner-freebsd-hackers@freebsd.org Thu Feb 22 19:42:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE025F25091 for ; Thu, 22 Feb 2018 19:42:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7D33674E2B for ; Thu, 22 Feb 2018 19:42:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-qt0-x22c.google.com with SMTP id m13so3056441qtg.13 for ; Thu, 22 Feb 2018 11:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Az/Y2jgP1/LWb2ojSWHIvH6X9NYXxZaprxLuWwWLc3M=; b=ttm2Dsq5lacKRgNFstSklTiH1ReurUahNm0XU7b/7uiVbdPzO1ZvaI0ArGyYlOrfYb dGkHFree+eiuBwJH+J25jSmiwuuHhycsVgBMXcI7v+Im/WF6auv6tEJBVtD1f/nuNPo2 1gNLcybYpovRPdnqOncoBvj5emNoDLBwM+iyo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Az/Y2jgP1/LWb2ojSWHIvH6X9NYXxZaprxLuWwWLc3M=; b=sIThYDpvwkyKwAE9UPt2RXnGX8K40wNkqZ+lBZ13Ja77Pen2aafsByrbHwTbeA4JFS qjcR6FIRHeO8+BQX3FEQz1KBkIsIfuaV08zP77nNUwJx8GsSuZ6L1QcNDG8aaqKz1WrK ltCsVd4Zvsvi23pnTEHJxb0xq7arQlq+WAOVuD1MF92fS0QwgExd9FUirm2lFSXisI6F NOEVTyaKzvvXdOdJVs9bXOy4NXeFPWf6YYib+t8GQEJ3qyEZ8by3vt14kP7HkzT0AZCI GEzMT2yf3D9RkmfSctj80yAlrBiWco7+BDka6YxZ6U9/EvJi+qg2++3ov9K/pP+oelXF hgWA== X-Gm-Message-State: APf1xPBligmrOg4wz7BCCv+stBZfSQEGoHxlA5bI3KwnbcmIk/d/rcma i9TyC+nXogEGAxBWgkrLista1YMyIOoBdcXW7pnMsg== X-Google-Smtp-Source: AH8x224/5zKCCC9mN3j1sS3nbvIukj61GaIiKTYwJ9Gz2CGcocIIoJRGg3JJi2ijbRBDl9a34gJd2HC0z4HEbKwM50c= X-Received: by 10.237.55.33 with SMTP id i30mr13019262qtb.202.1519328559888; Thu, 22 Feb 2018 11:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.173 with HTTP; Thu, 22 Feb 2018 11:42:09 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Eitan Adler Date: Thu, 22 Feb 2018 11:42:09 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Warner Losh Cc: Konstantin Belousov , FreeBSD Hackers , Tijl Coosemans , FreeBSD Standards , Kevin Lo Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 19:42:41 -0000 On 22 February 2018 at 06:43, Warner Losh wrote: > On Thu, Feb 22, 2018 at 3:56 AM, Konstantin Belousov > wrote: > >> On Thu, Feb 22, 2018 at 11:27:52AM +0100, Tijl Coosemans wrote: >> > On Wed, 21 Feb 2018 12:44:00 +0200 Konstantin Belousov < >> kostikbel@gmail.com> wrote: >> > > On Tue, Feb 20, 2018 at 10:14:05PM -0800, Eitan Adler wrote: >> > >> On 20 February 2018 at 21:19, Warner Losh wrote: >> > >>> Once upon a time, this would break a lot of code. Perhaps times have >> > >>> changed. >> > >> >> > >> I've seen very little code that this would break though some of it >> > >> certainly exists. >> > > You certainly seen very little code, but the question was about the >> > > existed code. >> > >> > FWIW, it seems that glibc uses restrict since 2000 so there's unlikely to >> > be much fallout: >> > https://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/select.h >> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h= >> 98cbe360d947b59e7a5eda068581f4cfeb4b99b3 >> >> Clearly, nobody knowns. At least, glibc is used with gcc compilation, not >> with clang. >> >> Consider the recently changed devd code: >> select(n + 1, &fd, &fd, &fd); >> There, compiler can see that restrict is applied to arguments which are >> given same values. Since this leads to the self-contradicting statement >> fd != fd >> which cannot be true, compliler in its optimizing wisdom can assume that >> the code is never executing and remove it. I do not know whether clang >> actually makes such transformation, but it does not sound unfeasible >> looking at its other advances. >> > > If the compilers affirmatively fails when this happens Compilers cannot fail since errors are only detectable at runtime. The value of the exp-run is (a) ensuring that we don't break prototypes of some applications (b) exercising the applications as much as we can -- Eitan Adler From owner-freebsd-hackers@freebsd.org Thu Feb 22 20:04:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EB7ECF26DE3; Thu, 22 Feb 2018 20:04:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f175.google.com (mail-io0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 818AB76E07; Thu, 22 Feb 2018 20:04:52 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f175.google.com with SMTP id l12so7302895ioc.10; Thu, 22 Feb 2018 12:04:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=cDdwIlb6TKmMvF/a/5buQpO0bZDmkrCbzeqjh8+WVTo=; b=WOY8ZT+atj4TFeVEPCk2byzESI8UKfMM34Gh9cSJB/7SSfyHKSdvzHiL9KHm4iRZMw USDCjpYSEfimKnrgTNwXZUAl5MITjXeX2zssNkP1YP54+CpdTXi539Z29U6tOWdBlibe 9kN6/8ynAHKzOMIvcrLByhNNyA90//iWKfVOVz5TZ5sfoPv5pTah8tfh5D8/utThBh46 2xjwaGA+fJ5EjTgTkG6yLyfMgkpC8lmhT4Ljl3ntIUcJgWZ9oqOJf71kPa5bM9tQGT/E o69+xJbtajSk/+DVFlOMWfGahXRqTJuU71pPL0URgQRoQ4N7LjUW1Ijnf0Jnk6+JH9I1 +tkw== X-Gm-Message-State: APf1xPCWt/1AF0zTGeruvzboKccuhfdwQQsUJdj0h/JOpwx/WmIfkcY8 6AJj66+iJuSJqdjgF2vqr9vY/Df8 X-Google-Smtp-Source: AH8x2262SBVRPzM88oE1/oeQvF5pbd6aD9Dq8rzDc6CFQydrtNBl1ILcCk+UJu2ZF8YbV8xv9R60Vw== X-Received: by 10.107.6.139 with SMTP id f11mr7431492ioi.23.1519329886288; Thu, 22 Feb 2018 12:04:46 -0800 (PST) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com. [209.85.223.177]) by smtp.gmail.com with ESMTPSA id 30sm445350iop.73.2018.02.22.12.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 12:04:46 -0800 (PST) Received: by mail-io0-f177.google.com with SMTP id v6so6191091iog.7; Thu, 22 Feb 2018 12:04:46 -0800 (PST) X-Received: by 10.107.41.16 with SMTP id p16mr10348722iop.173.1519329886009; Thu, 22 Feb 2018 12:04:46 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Thu, 22 Feb 2018 12:04:45 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Conrad Meyer Date: Thu, 22 Feb 2018 12:04:45 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 20:04:53 -0000 On Thu, Feb 22, 2018 at 11:42 AM, Eitan Adler wrote: > On 22 February 2018 at 06:43, Warner Losh wrote: >> If the compilers affirmatively fails when this happens > > Compilers cannot fail since errors are only detectable at runtime. This is simply not true. *Some* instances of this error could only be detected at run time, but compilers can and do perform some kinds of static analysis for warning/error purposes and for optimization. In the extremely common case where fdsets are local or global variables, the compiler could easily detect when the same pointer is passed multiple times. If we're unlucky, it produces no warning and "optimizes" the undefined behavior into something awful. In my local testing, neither Clang nor GCC6 produces any error or warning for this, which is disappointing. From owner-freebsd-hackers@freebsd.org Thu Feb 22 21:10:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17FCFF01385 for ; Thu, 22 Feb 2018 21:10:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE0A1798CC for ; Thu, 22 Feb 2018 21:10:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-qt0-x236.google.com with SMTP id a9so8099975qtj.8 for ; Thu, 22 Feb 2018 13:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yr7jqfdI29yCeaPTLGpIgNIo3sHlEa2eW4pyEEz+ydg=; b=o5Udjgm9WO7gwmen0OWMpKUckYMP4mBFsPlmWDhChlsQJDPiwGumLtT09H6dxkjyje TlULmr+PdfSMxa3QTUmGlaLZ+C+7ISx/7gBVOTYB9BBDZ+cX5cz5hLHP7agETz9qldc1 ZSlAZ00m++TVOoI5gLPTDtqvMKHVtv+eHO/yI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yr7jqfdI29yCeaPTLGpIgNIo3sHlEa2eW4pyEEz+ydg=; b=CN5Wxv8sjD8X3cfbKClrF86gTSdKGqnpUBqv9Xy+/89+ehuPuCh2PXg5komVtiEHdV iTrX0V27MyqyiMyP51lygpJTlT2cozNlXG75n7OqsNtVWP7UZiyQMlMj7IRo+vIeS4hA 3zDXFuESw9kYrfvlXlJ6XuSukJqPWTX1HPcAyr+a3QMODdlbA1Co/GEsuyxJIVj7B82T LMjQJBwUsQTVeEjzOmAC88cJtIdrVAttaMY5WyOFH8GopMJ9Dl6PFYNUtuBHCguu9kUS abTx/D6udkyji3XZb7IA99sByQIGBkeygzJTW/cNwHYkIO7rqFcFN0iIaxW3JuUWQ6cx PXkA== X-Gm-Message-State: APf1xPBReIyLsnIt4KYENrgNPYRQ5IhW+0tnRZ3iz8oTZv1YmbrJWD3o i3OeT+lWV6qYVR+rygP/58HNs2SuDuBY6Ae4du5lcA== X-Google-Smtp-Source: AH8x227lftP2q90KblKwH8ZT41aMmq309Wiqgn7+X25bkcMp8WnyvHLFI/yUl2RlWnRL7+tM9K0pY4myd/9zwIDI3y4= X-Received: by 10.200.62.1 with SMTP id z1mr12714198qtf.218.1519333854152; Thu, 22 Feb 2018 13:10:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.173 with HTTP; Thu, 22 Feb 2018 13:10:23 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <20180222112752.10da7e51@kalimero.tijl.coosemans.org> <20180222105608.GE94212@kib.kiev.ua> From: Eitan Adler Date: Thu, 22 Feb 2018 13:10:23 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: cem@freebsd.org Cc: FreeBSD Hackers , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 21:10:55 -0000 On 22 February 2018 at 12:04, Conrad Meyer wrote: > > In my local testing, neither Clang nor GCC6 produces any error or > warning for this, which is disappointing. I forget the exact version but gcc produces this warning: restrict.c:10:6: warning: passing argument 1 to restrict-qualified parameter aliases with argument 2 [-Wrestrict] meh(&a, &a); -- Eitan Adler From owner-freebsd-hackers@freebsd.org Fri Feb 23 11:33:17 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 47EEBF178BA for ; Fri, 23 Feb 2018 11:33:17 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD9F17A6A5 for ; Fri, 23 Feb 2018 11:33:16 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id f75so6895015lfg.6 for ; Fri, 23 Feb 2018 03:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=70uTYDMubVenn3tw++0lG351toedlljrL1I0VVUAhrQ=; b=tXA07VAeWgayqy8zK8P1H+6o6LTx30oy6GaT0pw3aGgorypBnLsWSKkppiS4bhCeQ4 8Qt0sDpsnHTJycK1F8ZO7BZqON9k5PH+rpJQHPxF8+dMvWRuh1KxGO/HoMOZUNnEmBR6 Gt57UFG5oIL4hxJSPZTxWSMfvmGVAAxhSPcmVEGsstCpOnLziLlbcqgxE0xh2fvb2ubN mXfrt2DCrE/rCKvEDCtjFO2eC8ARW/EcgBEk8lbXQhjzc+/LoktUvWjkNOxph8d/k6sT rhJ62h7BKCFNNsTI64Mu+tVCuRt9z6C3LJ3iNKQimXC6rNkL94HbHb6DY8nUJ6qriHTF fg8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=70uTYDMubVenn3tw++0lG351toedlljrL1I0VVUAhrQ=; b=uJeSVX/On/8aXWBHfKRNUfmefrCgUjzzj4DR7Q5HyBODbanO/9kRhx58qBg6wAW1aW cC31QOKTm8xQS6cVsuF9sZa1uLECRQpMHMLYZs2WF8mbyanVLpfhcIaZTlDkV3pcBLYT 5ePJvCz8ISDUh5tDWwWSl3KMhTQ2gzQiHH3MYaaztfbSusRepAYlXjrSctDBM3S/Z42J fbCbbdi5Eu5rqiA6Ck8UUqf7zelIpFdepkjGCn4SLNXu6ZPKeq6ccmJSSsLgtJfm7qTF pB0M5mIBRrQ915IFPSsSki5+4H22BKF0Q8ypF5xdkeiUf0VS7/RmwbELyNuDwC0nknny 4NXg== X-Gm-Message-State: APf1xPDmO0Fgu2A5vJN1lX4Tsc0s15Befc1Xl/+o7e/pXOkF5pryL99g i0oWUSiQoRIiogkrUsEnh7JC7N1p3graOUVmhiDtNXpb X-Google-Smtp-Source: AG47ELuwxh2MsOy8/9xB1EhCqG5fWBz/scYXVWB35bYLi8mU321Wk/CmHMxsZ7z8FwTh95FGdmOLvydOwBAyMHifVIM= X-Received: by 10.25.142.141 with SMTP id a13mr1199084lfl.140.1519385595082; Fri, 23 Feb 2018 03:33:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.72.17 with HTTP; Fri, 23 Feb 2018 03:33:14 -0800 (PST) From: "D. Ebdrup" Date: Fri, 23 Feb 2018 12:33:14 +0100 Message-ID: Subject: Re: [GSoC]Implementing the Parallel Scheduling Parallel Transmission subsystem on FreeBSD, help needed To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Fri, 23 Feb 2018 11:52:06 +0000 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 11:33:17 -0000 >HI there, >I'm an undergraduate student majoring in information security and have >always been interested in systems programming. While seeking for some >challenge for this summer on the GSoC page (I've completed a GSoC >project with the Xen hypervisor community last year, and really want >to do it again), I found FreeBSD's idea of Implementing the Parallel >Scheduling Parallel Transmission subsystem really interesting and >would like to take this challenge. >I've been reading the PSSPT paper for a general idea of the project. >And at the same time, I also want to get familiar with FreeBSD's code >base, especially the part related to this project. I think the most >natural way to get started would be making some small yet related >contributions to the project. Do we have such small fixes that could >be assigned to me? >Besides that, I'would really appreciate any form of suggestions or >information about how the project could be completed. >Cheers, >Zhongze Liu This is probably a stupid question, so please bear with me. Did you try reaching out to Giuseppe Lettieri? Daniel Ebdrup aka. D. Ebdrup. From owner-freebsd-hackers@freebsd.org Fri Feb 23 15:15:41 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1B0CF29BEF for ; Fri, 23 Feb 2018 15:15:41 +0000 (UTC) (envelope-from blackskygg@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B1A3859C2 for ; Fri, 23 Feb 2018 15:15:41 +0000 (UTC) (envelope-from blackskygg@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id y19so12845345lfd.4 for ; Fri, 23 Feb 2018 07:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pM90en+zwKsVwmynynmackvGJTRAJ1TSfiIczruwB5w=; b=mmTTqCQunesO8kfyIkWuArafDF39yvku7D3I2EzfGUVQ6OYqqv9koeoQQffyDObCIQ ADzD32NdCPzBLtiTNlfrBOBe4GdZPhLxvGC46EhDaTmAi+oPO55IkH6jZYwGMqdoiu4V PfAEtYoSRk2E8iQWNU+mNQZ7D/ujgfvHxfJtbdJoHdTr31KS06DtuTGV01feg8Uu7QNz dB8/v5gwSj2VtM1VMvXLZrNrLp3UqdFUNOUdycNuu/eDI3OPdAC2VOY+CxVe0YhSRnPS rDzHi+PeQUTeTqVi0mjfHXF9HkduaOMi8uGmVxf1IPmHSb8Ti97R82sVhzsMBlncMJ2D 2W3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pM90en+zwKsVwmynynmackvGJTRAJ1TSfiIczruwB5w=; b=cWSeYTmciTmddv3emCt/l4tYEY0tfAnHDw5mRbRBVxLpD0n5l1FY6RmKPe473Uk8Vl 3PlooGPWVbEuaOD2BS2Y4JKwkfgRGLqWQrCOeMZHAxLSSVqCeaAPbvxb0yUeGqstpR4A CaF5FmevedBKZ4OzsO/SnJYX5513/DvCAm0FoK7qGk+JmVnx5BXoILlZTiPrGQ2V7uB3 i3R3ZLMpuAnzWTl34HP+SvomRHjz0vH1kcTeZKve1k+ayAMgIVhxAumNFOGZsOIhpujd yzRg4zLVS2+Dwq1ICH/CYVu5HTw8ZSUXeljEC1T/R/pl3AOr5UpII9l7qu/ru3TYHE1I pRnw== X-Gm-Message-State: APf1xPA5TnwwuCYwJUsoFM1TRvEqLLhx3FOyygt2rexvYdet7XuqrmVv f3QuwueiD+PD9Uyd5WzSejxTKUBjqsqU3st+SXw= X-Google-Smtp-Source: AG47ELts9v6CsX9g9cpT5/7VtNFd87mpMYWZgmsbR6gJVwgMb9M2pAqyomzVftlnsPfX9IZLvjFkd60Smp7wxcwecuI= X-Received: by 10.25.35.132 with SMTP id j126mr1573351lfj.130.1519398939808; Fri, 23 Feb 2018 07:15:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.92.153 with HTTP; Fri, 23 Feb 2018 07:15:39 -0800 (PST) In-Reply-To: References: From: Zhongze Liu Date: Fri, 23 Feb 2018 23:15:39 +0800 Message-ID: Subject: Re: [GSoC]Implementing the Parallel Scheduling Parallel Transmission subsystem on FreeBSD, help needed To: "D. Ebdrup" Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:15:42 -0000 Hi, 2018-02-23 19:33 GMT+08:00 D. Ebdrup : >>HI there, > >>I'm an undergraduate student majoring in information security and have >>always been interested in systems programming. While seeking for some >>challenge for this summer on the GSoC page (I've completed a GSoC >>project with the Xen hypervisor community last year, and really want >>to do it again), I found FreeBSD's idea of Implementing the Parallel >>Scheduling Parallel Transmission subsystem really interesting and >>would like to take this challenge. > >>I've been reading the PSSPT paper for a general idea of the project. >>And at the same time, I also want to get familiar with FreeBSD's code >>base, especially the part related to this project. I think the most >>natural way to get started would be making some small yet related >>contributions to the project. Do we have such small fixes that could >>be assigned to me? > >>Besides that, I'would really appreciate any form of suggestions or >>information about how the project could be completed. > > >>Cheers, > >>Zhongze Liu > > This is probably a stupid question, so please bear with me. > Did you try reaching out to Giuseppe Lettieri? > I've CC'ed him this email, but not sure if he sees it. I think I'll try directly sending a copy of this email to him. Thank you for your suggestion. Cheers, Zhongze Liu From owner-freebsd-hackers@freebsd.org Fri Feb 23 15:48:03 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2A7DF01337 for ; Fri, 23 Feb 2018 15:48:03 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 15F44870EB for ; Fri, 23 Feb 2018 15:48:03 +0000 (UTC) (envelope-from debdrup@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id z9so5376209wmb.3 for ; Fri, 23 Feb 2018 07:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1rK4XmL5xfGTAxXDnifzUJMkVog7SeaUZgGW12urtb0=; b=fTgZp3yzCLq0l6Rp/y1MhtkFektk0O9dV9eG9IxlggWaya4ImqxGo/PuwAiXQSScQh 2ehIqJlpt7QDszdGQvi7V6IjCPgcWUnSWGqAx8kcJeV3RMhhwE+l0wzufA6o5nI5HtDf 6t/uO3PVDhF7SWzLUIbQsFzF0T55JjSTdS2GR4Wogqsdupe55rQVHTnUNWm83JzFbrty L7FBf3qS1i+O+7d1FlenEXh5/SxreK832828AkOHQ7Eksa8A2iXysOjMhA7JTz+KE1hu Hkj1a6LyAJ+RJWZ5j0ka+2JuAtIdoDR5z2HS1vW/hU8g6A6qBfoqvaA65eW80geOaOu1 pANA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1rK4XmL5xfGTAxXDnifzUJMkVog7SeaUZgGW12urtb0=; b=Y3RqKIfmRF3Gy4zXoch/CSeakztCt32ItFlP6HzkpkMJN6PkJckYmRMPDvj1ZXTdDa jZRaKKDyaxYPnksk5VX2if6PQong/+Ane1xKgz5K2oFQk6syQF/mPo51ntceLY80YpFE 1hDTEPllTHkKiP11UtrpMp6xFvOfPL+7lGgHKEEHrjLyIa6K3iHYbwgaPqRCreKx5g+1 /ETWG/5LP6UJTd5YX/nE96HLSeRqJ9nahwClvy2yMLvVibMYvkE4uR8lRlSZUK2IKiFu V1fq8L7agjM4jAjr0KOqV4kQT1SD3kkcaFmdfBCz7VMd0iTCwwKNzjv7JBSikZfegL9w CI2Q== X-Gm-Message-State: APf1xPBpqcjPB7tlrVo7/lqkLpXNOIO+i0a0GFULy4PdJsWFb8NxO1pp PIeAaR87u234mEZpJnnzpis= X-Google-Smtp-Source: AH8x225gT/RweazohEe0EXW4E0uVa0rmzkQJAyGusURI/SZZlvNp/7hHvj6XcbtVrH68U8bi7+v0oQ== X-Received: by 10.80.196.73 with SMTP id w9mr3309590edf.293.1519400881990; Fri, 23 Feb 2018 07:48:01 -0800 (PST) Received: from macbook-pro.localdomain ([85.27.246.15]) by smtp.gmail.com with ESMTPSA id q11sm2202427edj.64.2018.02.23.07.48.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 07:48:00 -0800 (PST) From: Daniel Jensen Message-Id: <24871895-37E3-46DA-8098-488C035E2AEB@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [GSoC]Implementing the Parallel Scheduling Parallel Transmission subsystem on FreeBSD, help needed Date: Fri, 23 Feb 2018 16:47:59 +0100 In-Reply-To: Cc: freebsd-hackers@freebsd.org To: Zhongze Liu References: X-Mailer: Apple Mail (2.3445.5.20) X-Mailman-Approved-At: Fri, 23 Feb 2018 18:49:36 +0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:48:04 -0000 > On 23 Feb 2018, at 16.15, Zhongze Liu wrote: >=20 > Hi, >=20 > 2018-02-23 19:33 GMT+08:00 D. Ebdrup >: >>> HI there, >>=20 >>> I'm an undergraduate student majoring in information security and = have >>> always been interested in systems programming. While seeking for = some >>> challenge for this summer on the GSoC page (I've completed a GSoC >>> project with the Xen hypervisor community last year, and really want >>> to do it again), I found FreeBSD's idea of Implementing the Parallel >>> Scheduling Parallel Transmission subsystem really interesting and >>> would like to take this challenge. >>=20 >>> I've been reading the PSSPT paper for a general idea of the project. >>> And at the same time, I also want to get familiar with FreeBSD's = code >>> base, especially the part related to this project. I think the most >>> natural way to get started would be making some small yet related >>> contributions to the project. Do we have such small fixes that could >>> be assigned to me? >>=20 >>> Besides that, I'would really appreciate any form of suggestions or >>> information about how the project could be completed. >>=20 >>=20 >>> Cheers, >>=20 >>> Zhongze Liu >>=20 >> This is probably a stupid question, so please bear with me. >> Did you try reaching out to Giuseppe Lettieri? >>=20 >=20 > I've CC'ed him this email, but not sure if he sees it. I think I'll > try directly sending a copy of this email to him. >=20 > Thank you for your suggestion. >=20 >=20 > Cheers, >=20 > Zhongze Liu If you have access to irc and EfNet, you may also want to look in the = #freebsd-soc channel as there are also helpful people there. :) From owner-freebsd-hackers@freebsd.org Sat Feb 24 18:35:55 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 552A5F00BFA for ; Sat, 24 Feb 2018 18:35:55 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E7359709B9 for ; Sat, 24 Feb 2018 18:35:54 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: by mail-yb0-x236.google.com with SMTP id i13-v6so4027059ybl.9 for ; Sat, 24 Feb 2018 10:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uY7mq37ngYgaBwjpjHzIRQqjZoOUrRCm+t8ntrrh0ok=; b=qU5QqdQrV1lNzAkwtDm1/7s5QzuSWkmXWrhdQqg6XAuM3TOP4IRewg3DoZvyNdXmYY Q2eBxujiiCfsaRslP/xB40ull6XaTGAnkNG6J1owyAspt+cBgGcj+VVr3sF2x05c3nF4 0GKC2LUPqcROo38LMHKjwCK/C/gAXrYJs9WGs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uY7mq37ngYgaBwjpjHzIRQqjZoOUrRCm+t8ntrrh0ok=; b=RY5psBP2k0VygxYbEQDK14IKdF1cXOm4NLAL4FuQLAZd+rsiX1tdA2oiaoASr6kPGl m4/T4nulBw/j7EeVXcWRB4Y9ZSmBYyfAFuVFa0q8R0Cs1rg3ngGGGVykeNU+3Qpb7BpP XKeqWpm+DGVpxzWvUaIAPrGaoHWIuBonqKjPOzWd/DvG51PFW5luyhDvgSeO7d/udT+M GMYuFj63M/UTEKTOnxXLEYrpX0QWbwBxbTfFcgUIk5vjxMJ2myQJZsDg5W/L9dSZBJS4 Z1c+v18WP0XSyOJgkenSk17wzK+HmIat83eN9K5hNGk6SWCLNSxTy/DlTTz+ATBzaYOK h7Kg== X-Gm-Message-State: APf1xPDMUO997LK9SQYAaRX4Y93F2xBAoobm/fyHEJ85GnC+C5Z9u1Sm rW2dvLs2552CW3A6MYrT96/LJAmhDXi8jnUTpoWx0g== X-Google-Smtp-Source: AG47ELvbbnVZG/avZmCrSCt4xp79Z+G+jhZckVOYC8tcwTE+7BNYRxuryQey1ovNkyT7Z/RczvysHG6mUUqD7wvcZ4c= X-Received: by 2002:a25:6006:: with SMTP id u6-v6mr3767999ybb.460.1519497354117; Sat, 24 Feb 2018 10:35:54 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:dfcb:0:0:0:0:0 with HTTP; Sat, 24 Feb 2018 10:35:23 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Eitan Adler Date: Sat, 24 Feb 2018 10:35:23 -0800 Message-ID: Subject: Re: Marking select(2) as restrict To: Jilles Tjoelker , FreeBSD Hackers Cc: Garrett Wollman , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 18:35:55 -0000 After this entire thread here is the summary. If I've misrepresented you here please let me know. Stefan Blachmann - concerned about possible breakages. kevlo - no comment julian@freebsd.org - no comment imp@ - concerned about lack of warnings; objected to original fix of devd Gary Jennejohn - pselect already has the modifiers. no comment. kib@ - no benefit; concerned fallout could be hard to observe Garrett Wollman - positive due to following the standard Tijil - glibc already uses it. limited fallout expected Eric van Gyzen - would prefer "make check" in the exp-run as well cem@ - concerned about warnings My thoughts: The main concern is that things /might/ break in undetectable was. However most other operating already have these marked as restrict, and no concrete brokenness for FreeBSD have been shown. I'd rather aim for correctness than avoiding speculative fallout. This is a tradeoff, but one I think is good here. Final action: I am planning on committing a modified version of the original patch after an exp-run. I will ask for port tests to be run if possible. This will be posted to phab for review for technical correctness. This will not be merged to stable/11. In the event of observable fallout it can be reverted. On 22 February 2018 at 23:26, Eitan Adler wrote: > On 22 February 2018 at 13:27, Jilles Tjoelker wrote: >> On Wed, Feb 21, 2018 at 03:27:21PM -0500, Garrett Wollman wrote: >>> < said: > ... > > FWIW > > glibc: already done - > https://github.com/bminor/glibc/blob/master/misc/sys/select.h#L101 > openbsd: already done > https://github.com/openbsd/src/blob/master/sys/sys/select.h#L128 > dragonflyBSD: alredy done: > https://github.com/dragonflybsd/dragonflybsd/blob/master/sys/sys/select.h#L50 > netbsd: already done: > https://github.com/NetBSD/src/blob/trunk/sys/sys/select.h#L69 > > The patch that started this thread was incomplete, as it didn't > include the timeval but I'll have an updated version in a phab soon. > > -- > Eitan Adler -- Eitan Adler From owner-freebsd-hackers@freebsd.org Sat Feb 24 19:18:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A836EF0654A; Sat, 24 Feb 2018 19:18:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 29B2772577; Sat, 24 Feb 2018 19:18:27 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f176.google.com with SMTP id q24so5914597ioh.8; Sat, 24 Feb 2018 11:18:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=PXx8CmKVDudnZKn2lqRf3DuFpdxUr8+25dlD/o0mbuw=; b=cAlTPJHVnsCMJjMgVAfAV+Gh0AzQmPg2QKpN5uvW8OhVYwAdeB3J/iKkoYe81KDBH1 xZXn8+hxb+Q4lgRbLc5HjcJByzY+t6jvOpNbDZGflP8O16mjmNsCf9C9CIs+Pmg5AsAM 0nx6Qtqox1J/40DoeGDU3g99S5HPisFIv3s5ko7ekXMf+BHJBZE0d3ZqsdlVTdlB64UI 7eruJRyjJUS8HQ1+R05+oE/f9vvHe1WL9czYJ/wedVyWHrTLeqHAkFgzFp+vxX0PLtK1 qYpjwLpvxI2ZGkonUZhAy4gRRQt+FdzxsstUGwZb9PtH3iwJ3rDdDfOwMSiC+E0q+jN1 ol8g== X-Gm-Message-State: APf1xPDJAALpbKdLfTEjLYcfNq8O00Ljy36GAMyW9npvIiojo/1BiZdU MeShHfpvq+PRwLwC+4GzNHi8NLDa X-Google-Smtp-Source: AG47ELt81JlB3RyfsyZOQLqBZp5mF/vEmTxt0GTOCES5NDeXnzgjLfJifeqM2m5G2jPwrJeduQotCQ== X-Received: by 10.107.101.13 with SMTP id z13mr6021328iob.141.1519498551901; Sat, 24 Feb 2018 10:55:51 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id k62sm2038036iod.28.2018.02.24.10.55.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Feb 2018 10:55:51 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id p78so13143807iod.13; Sat, 24 Feb 2018 10:55:51 -0800 (PST) X-Received: by 10.107.222.10 with SMTP id v10mr6551362iog.267.1519498551638; Sat, 24 Feb 2018 10:55:51 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 10.2.30.149 with HTTP; Sat, 24 Feb 2018 10:55:51 -0800 (PST) In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Conrad Meyer Date: Sat, 24 Feb 2018 10:55:51 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Marking select(2) as restrict To: Eitan Adler Cc: FreeBSD Hackers , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 19:18:28 -0000 On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler wrote: > After this entire thread here is the summary. If I've misrepresented > you here please let me know. > ... > > kib@ - no benefit; concerned fallout could be hard to observe > cem@ - concerned about warnings Consider me a +1 to kib@. I did not voice those concerns explicitly in earlier email because kib did already and I didn't anticipate you would ignore him. Conrad From owner-freebsd-hackers@freebsd.org Sat Feb 24 19:24:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C4D1F07043 for ; Sat, 24 Feb 2018 19:24:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9908C72B35 for ; Sat, 24 Feb 2018 19:24:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id a75so6601489itd.0 for ; Sat, 24 Feb 2018 11:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0PD9gOOjtdInxYQcjqWu8Y4Io/oLahzY9iFuR7EABek=; b=TvMJaiKgdUgb9lBQib8Bcmu95gwC1iXwMyiWA1qNr1KQUUbvmJD9/PXJ10aWqCRhDw uJPqxaKjjM19F0982Vju0P2bAJ0zJwwLFvtCnxnr8VQTYM5In7XMM6oRrxlrnqYbODsK TajFniP6UxajVZUqZK+WWzR2yX6tU3D250FiewAHFob7sukpQJglaH8Ph4yo/BnTkByb tbqP6FBkUPE4eDRSfvGjL91mRa3+oHIIs4yRRNHGchfRTiUSFNE5793MI/JTejMe4RZK 1JVQ88UXpt7uylWDpnCXSOLQf4IQ2cGdMPkuM0+AguhxZ9bH2ElkZiNdCxLivEGOFmL8 S7mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0PD9gOOjtdInxYQcjqWu8Y4Io/oLahzY9iFuR7EABek=; b=qzwXiWt8QxwjyYMxwNegoczRpnMzOelDgZaA7+ipysmEBkKLZEOWDM5XxzYkvxSL7K O3iGGRyZswuzO5dzqI/McIC+zK+YRl98ZYiJn9ztAxzGDPqUvhoJRXjavphcvjRgWu3A qbOLiFNaiB+DThNnQjpLEkI/VPd4M0l0Ef3BmvwAFEkcKjcRtjeTepJ5NtxpZusn4fJN jjdVn7MPmWpaH3DN7VfAcHcStXsRw9OC+iwa6KWHrLvXtAvwamW8Jjfa8B4Aeb1ZwGdX 6QwVHxDrilIFlbum7EfxIpbQSoUmtps7dtpjd/wOIpqkFwxYw7/J5H62TLWf3H4soHwe 586A== X-Gm-Message-State: APf1xPDr5VG8E++Pgmhq5mILrvxqF+22pVI1ilq4RkbVGfkv9O7e/Azg 4nmswBSzwkpTvrpEYyQL6yTtKH6CaLJ0KXtbrEPOpQ== X-Google-Smtp-Source: AG47ELt647OapaU3F12OlM2cWT8YcMbQAH863VMQvrlzXTjVqzo/3/Y3efXc0jWP60IajKgumvRTcLv6R3T7jchPfuw= X-Received: by 10.36.6.70 with SMTP id 67mr7020461itv.57.1519500286471; Sat, 24 Feb 2018 11:24:46 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Sat, 24 Feb 2018 11:24:45 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180221032247.GA81670@ns.kevlo.org> <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> From: Warner Losh Date: Sat, 24 Feb 2018 12:24:45 -0700 X-Google-Sender-Auth: UjE_V0FEkGeWZwqGgXutPkNjIyI Message-ID: Subject: Re: Marking select(2) as restrict To: "Conrad E. Meyer" Cc: Eitan Adler , FreeBSD Hackers , FreeBSD Standards Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 19:24:48 -0000 On Sat, Feb 24, 2018 at 11:55 AM, Conrad Meyer wrote: > On Sat, Feb 24, 2018 at 10:35 AM, Eitan Adler > wrote: > > After this entire thread here is the summary. If I've misrepresented > > you here please let me know. > > ... > > > > kib@ - no benefit; concerned fallout could be hard to observe > > cem@ - concerned about warnings > > Consider me a +1 to kib@. I did not voice those concerns explicitly > in earlier email because kib did already and I didn't anticipate you > would ignore him. So there's no benefit to the change (we won't optimize better). It's hard to observe breakage. No answer about how we'd even know if something broke because a exp run sure as hell isn't going to tell us. All that militates against the change rather strongly. Your exp run will change no minds because it is useless. Warner From owner-freebsd-hackers@freebsd.org Sat Feb 24 22:24:48 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8139F284DF; Sat, 24 Feb 2018 22:24:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 532C07ACD8; Sat, 24 Feb 2018 22:24:48 +0000 (UTC) (envelope-from joerg@bec.de) Received: from britannica.bec.de (p200300D2ABCCC4104639C4FFFE599710.dip0.t-ipconnect.de [IPv6:2003:d2:abcc:c410:4639:c4ff:fe59:9710]) (Authenticated sender: joerg@bec.de) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id ECF8DA80C6; Sat, 24 Feb 2018 23:24:44 +0100 (CET) Date: Sat, 24 Feb 2018 23:23:46 +0100 From: Joerg Sonnenberger To: Eitan Adler Cc: Jilles Tjoelker , FreeBSD Hackers , Garrett Wollman , FreeBSD Standards Subject: Re: Marking select(2) as restrict Message-ID: <20180224222346.GB16529@britannica.bec.de> Mail-Followup-To: Eitan Adler , Jilles Tjoelker , FreeBSD Hackers , Garrett Wollman , FreeBSD Standards References: <20180221104400.GU94212@kib.kiev.ua> <23181.46427.671514.319710@khavrinen.csail.mit.edu> <20180221185920.GA94212@kib.kiev.ua> <23181.50488.186767.579361@khavrinen.csail.mit.edu> <20180221201002.GC94212@kib.kiev.ua> <23181.54825.511195.393054@khavrinen.csail.mit.edu> <20180222212746.GB58772@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.0 (2017-09-02) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Feb 2018 22:24:48 -0000 On Sat, Feb 24, 2018 at 10:35:23AM -0800, Eitan Adler wrote: > The main concern is that things /might/ break in undetectable was. This argument puzzles me quite a bit. The code here is *already* broken and depends on unspecified behavior of the kernel, i.e. the order in which the fdsets are copied in/out. Joerg