From owner-freebsd-threads@freebsd.org Mon Feb 15 14:17:37 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DCF9EAA995F for ; Mon, 15 Feb 2016 14:17:37 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CD4201C1C for ; Mon, 15 Feb 2016 14:17:37 +0000 (UTC) (envelope-from martin@lispworks.com) Received: by mailman.ysv.freebsd.org (Postfix) id C69C1AA995D; Mon, 15 Feb 2016 14:17:37 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6153AA995B; Mon, 15 Feb 2016 14:17:37 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 10E551C16; Mon, 15 Feb 2016 14:17:30 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u1FEHKDT031345; Mon, 15 Feb 2016 14:17:20 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u1FEHKih003396; Mon, 15 Feb 2016 14:17:20 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u1FEHKwL003392; Mon, 15 Feb 2016 14:17:20 GMT Date: Mon, 15 Feb 2016 14:17:20 GMT Message-Id: <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> From: Martin Simmons To: Konstantin Belousov CC: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org In-reply-to: <20160213143815.GB91220@kib.kiev.ua> (message from Konstantin Belousov on Sat, 13 Feb 2016 16:38:15 +0200) Subject: Re: libthr shared locks References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 14:17:38 -0000 Is pthread_barrier_destroy making the wrong comparison? + if (barrier == THR_PSHARED_PTR) { I think this should be *barrier. Also, a general question: why not use some flag in the barrier (and other objects) to indicate pshared, removing the need for __thr_pshared_offpage except in init? __Martin From owner-freebsd-threads@freebsd.org Mon Feb 15 14:44:17 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D84FCAA89E8 for ; Mon, 15 Feb 2016 14:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C46D712D6 for ; Mon, 15 Feb 2016 14:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BE356AA89E6; Mon, 15 Feb 2016 14:44:17 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDB16AA89E4; Mon, 15 Feb 2016 14:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 59EAC12D3; Mon, 15 Feb 2016 14:44:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1FEiAQQ029016 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2016 16:44:10 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1FEiAQQ029016 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1FEiAfr029015; Mon, 15 Feb 2016 16:44:10 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Feb 2016 16:44:10 +0200 From: Konstantin Belousov To: Martin Simmons Cc: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org Subject: Re: libthr shared locks Message-ID: <20160215144410.GT91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 14:44:17 -0000 On Mon, Feb 15, 2016 at 02:17:20PM +0000, Martin Simmons wrote: > Is pthread_barrier_destroy making the wrong comparison? > > + if (barrier == THR_PSHARED_PTR) { > > I think this should be *barrier. You are right, thank you for noticing. I uploaded https://www.kib.kiev.ua/kib/pshared/pshared.3.patch > > Also, a general question: why not use some flag in the barrier (and other > objects) to indicate pshared, removing the need for __thr_pshared_offpage > except in init? But where would I keep the object ? All that I have with the current ABI is a single pointer, which de facto behaves like the flag which you proposed. It is either real pointer or (if set to some specific value impossible for a valid pointer) there is an offpage. From owner-freebsd-threads@freebsd.org Mon Feb 15 16:46:15 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D75F0AA85BB for ; Mon, 15 Feb 2016 16:46:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 BC9F2195E for ; Mon, 15 Feb 2016 16:46:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1FGkFT9041896 for ; Mon, 15 Feb 2016 16:46:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 15 Feb 2016 16:46:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:46:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #42 from Robert Blayzor --- Caught exim and dovecot full core dumps, same VM, couple hours apart... #0 handle_smtp_call (listen_sockets=3D0x803065140, listen_socket_count=3D4, accept_socket=3D7, accepted=3D0x7fffffffcd38) at daemon.c:375 375 daemon.c: No such file or directory. in daemon.c [New Thread 803006400 (LWP 100155/)] (gdb) bt full #0 handle_smtp_call (listen_sockets=3D0x803065140, listen_socket_count=3D4, accept_socket=3D7, accepted=3D0x7fffffffcd38) at daemon.c:375 i =3D 32767 queue_only_reason =3D 0 old_pool =3D 0 save_debug_selector =3D 0 local_queue_only =3D 32767 session_local_queue_only =3D -4800 act =3D {__sigaction_u =3D {__sa_handler =3D 0, __sa_sigaction =3D = 0}, sa_flags =3D 0, sa_mask =3D { __bits =3D 0x7fffffffc91c}} pid =3D 0 interface_sockaddr =3D {v4 =3D {sin_len =3D 28 '\034', sin_family = =3D 28 '\034', sin_port =3D 6400, sin_addr =3D {s_addr =3D 0}, sin_zero =3D 0x7fffffffc9a0 "&\a=C3=B0X\00= 1\020"}, v6 =3D { sin6_len =3D 28 '\034', sin6_family =3D 28 '\034', sin6_port =3D 6400, sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D {__u6_addr8 =3D 0x7fffffffc9a0 "&\a=C3=B0X= \001\020", __u6_addr16 =3D 0x7fffffffc9a0, __u6_addr32 =3D 0x7fffffffc9a0}}, sin6_scope_id =3D 0}, v0 =3D { sa_len =3D 28 '\034', sa_family =3D 28 '\034', sa_data =3D 0x7fffffffc9= 9a ""}} ifsize =3D 28 dup_accept_socket =3D 9 max_for_this_host =3D 10 wfsize =3D 100 wfptr =3D 22 use_log_write_selector =3D 1980 whofrom =3D (uschar *) 0x803065e30 "[2607:f058:110:2::f:0]" reset_point =3D (void *) 0x803065e00 #1 0x0000000000427c55 in daemon_go () at daemon.c:2040 accept_socket =3D 7 sk =3D 0 max_socket =3D 6 lcount =3D 0 select_errno =3D 4 select_failed =3D 0 select_listen =3D {__fds_bits =3D 0x7fffffffcc40} accepted =3D {sin6_len =3D 28 '\034', sin6_family =3D 28 '\034', si= n6_port =3D 46531, sin6_flowinfo =3D 0, sin6_addr =3D {__u6_addr =3D {__u6_addr8 =3D 0x7ffff= fffcd40 "&\a=C3=B0X\001\020", __u6_addr16 =3D 0x7fffffffcd40, __u6_addr32 =3D 0x7fffffffcd40}}, sin6_scope_id =3D 0} len =3D 28 pid =3D 53159 pw =3D (struct passwd *) 0x802698328 listen_sockets =3D (int *) 0x803065140 listen_socket_count =3D 4 addresses =3D (ip_address_item *) 0x803065040 last_connection_time =3D 1455463157 #2 0x000000000044af25 in main (argc=3D3, cargv=3D0x7fffffffed48) at exim.c= :4719 rsopts =3D 0x761b00 argv =3D (uschar **) 0x7fffffffed48 arg_receive_timeout =3D -1 arg_smtp_receive_timeout =3D -1 arg_error_handling =3D 0 ---Type to continue, or q to quit--- filter_sfd =3D -1 filter_ufd =3D -1 group_count =3D 1 i =3D 0 rv =3D 0 list_queue_option =3D 0 msg_action =3D 0 msg_action_arg =3D -1 namelen =3D 20 queue_only_reason =3D 0 perl_start_option =3D 0 recipients_arg =3D 3 sender_address_domain =3D 0 test_retry_arg =3D -1 test_rewrite_arg =3D -1 arg_queue_only =3D 0 bi_option =3D 0 checking =3D 0 count_queue =3D 0 expansion_test =3D 0 extract_recipients =3D 0 flag_G =3D 0 flag_n =3D 0 forced_delivery =3D 0 f_end_dot =3D 0 deliver_give_up =3D 0 list_queue =3D 0 list_options =3D 0 local_queue_only =3D 7868416 more =3D 1 one_msg_action =3D 0 queue_only_set =3D 0 receiving_message =3D 0 sender_ident_set =3D 0 session_local_queue_only =3D -5288 unprivileged =3D 0 removed_privilege =3D 0 usage_wanted =3D 0 verify_address_mode =3D 0 verify_as_sender =3D 0 version_printed =3D 0 alias_arg =3D (uschar *) 0x0 called_as =3D (uschar *) 0x554616 "" cmdline_syslog_name =3D (uschar *) 0x0 start_queue_run_id =3D (uschar *) 0x0 stop_queue_run_id =3D (uschar *) 0x0 expansion_test_message =3D (uschar *) 0x0 ftest_domain =3D (uschar *) 0x0 ftest_localpart =3D (uschar *) 0x0 ---Type to continue, or q to quit--- ftest_prefix =3D (uschar *) 0x0 ftest_suffix =3D (uschar *) 0x0 log_oneline =3D (uschar *) 0x0 malware_test_file =3D (uschar *) 0x0 real_sender_address =3D (uschar *) 0x7fffffffeb58 " \005v" originator_home =3D (uschar *) 0x803065018 "/root" sz =3D 140737488350168 reset_point =3D (void *) 0x80231a310 pw =3D (struct passwd *) 0x802698328 statbuf =3D {st_dev =3D 1895890688, st_ino =3D 5, st_mode =3D 8576,= st_nlink =3D 1, st_uid =3D 0, st_gid =3D 0, st_rdev =3D 5, st_atim =3D {tv_sec =3D 1455201710, tv_nsec = =3D 90063000}, st_mtim =3D { tv_sec =3D 1455201749, tv_nsec =3D 0}, st_ctim =3D {tv_sec =3D 14552017= 49, tv_nsec =3D 0}, st_size =3D 0, st_blocks =3D 0, st_blksize =3D 4096, st_flags =3D 0, st_gen =3D 0, st_ls= pare =3D 0, st_birthtim =3D { tv_sec =3D -1, tv_nsec =3D 0}} passed_qr_pid =3D 0 passed_qr_pipe =3D -1 group_list =3D 0x7fffffffd8f0 info_flag =3D CMDINFO_NONE info_stdout =3D 0 Current language: auto; currently minimal (gdb) x/i $rip 0x428c9e : mov %eax,0x764b34 (gdb) info registers rax 0x7bc 1980 rbx 0x0 0 rcx 0x4 4 rdx 0x1 1 rsi 0x8030064e8 34410095848 rdi 0x3 3 rbp 0x7fffffffc9d0 0x7fffffffc9d0 rsp 0x7fffffffc830 0x7fffffffc830 r8 0x0 0 r9 0xfffff8003b2a1000 -8795100409856 r10 0x1 1 r11 0x246 582 r12 0x7fffffffed40 140737488350528 r13 0x7fffffffed68 140737488350568 r14 0x7fffffffed48 140737488350536 r15 0x3 3 rip 0x428c9e 0x428c9e eflags 0x10202 66050 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 procstat -v exim.core PID START END PRT RES PRES REF SHD FL TP P= ATH 53547 0x400000 0x560000 r-x 324 637 3 1 CN-- vn /usr/local/sbin/exim 53547 0x760000 0x76a000 rw- 10 0 1 0 C--- vn /usr/local/sbin/exim 53547 0x76a000 0x779000 rw- 15 0 1 0 C--- df 53547 0x800760000 0x80077e000 r-x 30 32 35 0 CN-- vn /libexec/ld-elf.so.1 53547 0x80077e000 0x800785000 rw- 7 7 2 0 CN-- df 53547 0x800787000 0x8007b7000 rw- 48 48 2 1 CN-- df 53547 0x80097d000 0x80097f000 rw- 2 2 2 0 CN-- df 53547 0x80097f000 0x80098d000 r-x 14 16 7 3 CN-- vn 53547 0x80098d000 0x800b8d000 --- 0 0 2 0 CN-- df 53547 0x800b8d000 0x800b8e000 rw- 1 0 2 0 CN-- vn 53547 0x800b8e000 0x800b9f000 rw- 0 0 0 0 ---- -- 53547 0x800b9f000 0x800bc8000 r-x 41 46 9 4 CN-- vn 53547 0x800bc8000 0x800dc7000 --- 0 0 2 0 CN-- df 53547 0x800dc7000 0x800dc8000 rw- 1 0 2 0 CN-- vn 53547 0x800dc8000 0x800dd8000 r-x 16 18 19 9 CN-- vn 53547 0x800dd8000 0x800fd8000 --- 0 0 2 0 CN-- df 53547 0x800fd8000 0x800fd9000 rw- 1 0 2 0 CN-- vn 53547 0x800fd9000 0x800fdb000 rw- 0 0 0 0 ---- -- 53547 0x800fdb000 0x800ff3000 r-x 20 23 3 1 CN-- vn 53547 0x800ff3000 0x8011f3000 --- 0 0 2 0 CN-- df 53547 0x8011f3000 0x8011f5000 rw- 2 0 2 0 CN-- vn 53547 0x8011f5000 0x80120d000 r-x 24 26 20 9 CN-- vn /lib/libthr.so.3 53547 0x80120d000 0x80140d000 --- 0 0 2 0 CN-- df 53547 0x80140d000 0x80140e000 rw- 1 0 1 0 C--- vn /lib/libthr.so.3 53547 0x80140e000 0x80141a000 rw- 12 0 1 0 C--- df 53547 0x80141a000 0x801445000 r-x 41 45 5 2 CN-- vn 53547 0x801445000 0x801645000 --- 0 0 2 0 CN-- df 53547 0x801645000 0x801648000 rw- 3 0 2 0 CN-- vn 53547 0x801648000 0x80181d000 r-x 425 434 3 1 CN-- vn 53547 0x80181d000 0x801a1c000 --- 0 0 2 0 CN-- df 53547 0x801a1c000 0x801a25000 rw- 9 0 2 0 CN-- vn 53547 0x801a25000 0x801a88000 r-x 87 98 27 13 CN-- vn /usr/lib/libssl.so.7 53547 0x801a88000 0x801c88000 --- 0 0 2 0 CN-- df 53547 0x801c88000 0x801c92000 rw- 10 0 2 0 CN-- vn /usr/lib/libssl.so.7 53547 0x801c92000 0x801e5f000 r-x 461 501 31 15 CN-- vn /lib/libcrypto.so.7 53547 0x801e5f000 0x80205f000 --- 0 0 2 0 CN-- df 53547 0x80205f000 0x802087000 rw- 40 0 2 0 CN-- vn /lib/libcrypto.so.7 53547 0x802087000 0x802089000 rw- 2 2 2 0 CN-- df 53547 0x802089000 0x8020fe000 r-x 45 46 8 3 CN-- vn 53547 0x8020fe000 0x8022fd000 --- 0 0 2 0 CN-- df 53547 0x8022fd000 0x8022fe000 rw- 1 0 2 0 CN-- vn 53547 0x8022fe000 0x802476000 r-x 376 390 68 33 CN-- vn /lib/libc.so.7 53547 0x802476000 0x802675000 --- 0 0 2 0 CN-- df 53547 0x802675000 0x802681000 rw- 12 0 1 0 C--- vn /lib/libc.so.7 53547 0x802681000 0x8026ab000 rw- 42 0 1 0 C--- df 53547 0x8026ab000 0x8026b5000 r-x 10 14 10 4 CN-- vn /usr/local/lib/libintl.so.8.1.4 53547 0x8026b5000 0x8028b5000 --- 0 0 2 0 CN-- df 53547 0x8028b5000 0x8028b6000 rw- 1 0 2 0 CN-- vn /usr/local/lib/libintl.so.8.1.4 53547 0x802c00000 0x803400000 rw- 512 0 1 0 C--- df 53547 0x7fffdfffe000 0x7fffdffff000 --- 0 0 0 0 ---- -- 53547 0x7ffffffdf000 0x7ffffffff000 rw- 10 0 1 0 C--D df 53547 0x7ffffffff000 0x800000000000 r-x 1 1 37 0 ---- ph --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Mon Feb 15 16:47:32 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4644FAA864E for ; Mon, 15 Feb 2016 16:47:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 2BB1019B2 for ; Mon, 15 Feb 2016 16:47:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u1FGlVs9043733 for ; Mon, 15 Feb 2016 16:47:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 204426] Processes terminating cannot access memory Date: Mon, 15 Feb 2016 16:47:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rblayzor@inoc.net X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-threads@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 16:47:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D204426 --- Comment #43 from Robert Blayzor --- #0 t_pop () at data-stack.c:275 275 data-stack.c: No such file or directory. in data-stack.c (gdb) bt full #0 t_pop () at data-stack.c:275 frame_block =3D (struct stack_frame_block *) 0x8014b1378 #1 0x000000080090e584 in io_loop_call_io (io=3D0x80144e4c0) at ioloop.c:560 ioloop =3D (struct ioloop *) 0x801421080 t_id =3D 2 #2 0x0000000800911497 in io_loop_handler_run_internal (ioloop=3D0x80142108= 0) at ioloop-kqueue.c:151 ctx =3D (struct ioloop_handler_context *) 0x801419880 events =3D (struct kevent *) 0x8014b9000 event =3D (const struct kevent *) 0x8014b9000 tv =3D {tv_sec =3D 43499, tv_usec =3D 883196} ts =3D {tv_sec =3D 43499, tv_nsec =3D 883196000} io =3D (struct io_file *) 0x80144e4c0 events_count =3D 67 ret =3D 1 i =3D 0 #3 0x000000080090eb0e in io_loop_handler_run (ioloop=3D0x801421080) at ioloop.c:607 No locals. #4 0x000000080090e92f in io_loop_run (ioloop=3D0x801421080) at ioloop.c:583 No locals. #5 0x000000080086a8bb in master_service_run (service=3D0x80141b140, callba= ck=3D0) at master-service.c:640 No locals. #6 0x0000000000406558 in main (argc=3D3, argv=3D0x7fffffffb4c0) at main.c:= 888 set =3D (struct master_settings *) 0x801429110 error =3D 0x800ca9283 "H\203=C3=84 ]=C3=83\017\037\200" doveconf_arg =3D 0x0 orig_info_callback =3D (failure_callback_t *) 0x8008ee880 orig_debug_callback =3D (failure_callback_t *) 0x8008ee880 foreground =3D false ask_key_pass =3D false i =3D 3 c =3D -1 doubleopts =3D 0x7fffffffb3a0 Current language: auto; currently minimal (gdb) x/i $rip 0x8008eb306 : mov %rax,0x29d523(%rip) # 0x800b88830 (gdb) info registers rax 0x801406000 34380734464 rbx 0x0 0 rcx 0x80140f280 34380771968 rdx 0x0 0 rsi 0x7fffffffb198 140737488335256 rdi 0x0 0 rbp 0x7fffffffb280 0x7fffffffb280 rsp 0x7fffffffb260 0x7fffffffb260 r8 0x0 0 r9 0xfffffe007c476718 -2196938201320 r10 0x0 0 r11 0x246 582 r12 0x7fffffffb4b8 140737488336056 r13 0x7fffffffb4e0 140737488336096 r14 0x7fffffffb4c0 140737488336064 r15 0x3 3 rip 0x8008eb306 0x8008eb306 eflags 0x10246 66118 cs 0x43 67 ss 0x3b 59 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 procstat -v dovecot.core PID START END PRT RES PRES REF SHD FL TP P= ATH 716 0x400000 0x417000 r-x 19 19 1 0 CN-- vn 716 0x617000 0x618000 rw- 1 1 1 0 CN-- df 716 0x800617000 0x800635000 r-x 30 32 32 0 CN-- vn /libexec/ld-elf.so.1 716 0x800635000 0x800663000 rw- 36 36 1 0 C--- df 716 0x800834000 0x800836000 rw- 2 2 1 0 CN-- df 716 0x800836000 0x800983000 r-x 213 219 34 17 CN-- vn /usr/local/lib/dovecot/libdovecot.so.0.0.0 716 0x800983000 0x800b82000 --- 0 0 1 0 CN-- df 716 0x800b82000 0x800b89000 rw- 7 0 1 0 C--- vn /usr/local/lib/dovecot/libdovecot.so.0.0.0 716 0x800b89000 0x800b8b000 rw- 2 2 1 0 CN-- df 716 0x800b8b000 0x800d03000 r-x 376 390 63 31 CN-- vn /lib/libc.so.7 716 0x800d03000 0x800f02000 --- 0 0 1 0 CN-- df 716 0x800f02000 0x800f0e000 rw- 12 0 1 0 CN-- vn /lib/libc.so.7 716 0x800f0e000 0x800f38000 rw- 13 13 1 0 CN-- df 716 0x801000000 0x801800000 rw- 94 94 1 0 C--- df 716 0x7ffffffdf000 0x7ffffffff000 rw- 8 8 1 0 C--D df 716 0x7ffffffff000 0x800000000000 r-x 1 1 34 0 ---- ph --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-threads@freebsd.org Mon Feb 15 17:35:38 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A821AA9E9F for ; Mon, 15 Feb 2016 17:35:38 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 78690A67 for ; Mon, 15 Feb 2016 17:35:38 +0000 (UTC) (envelope-from martin@lispworks.com) Received: by mailman.ysv.freebsd.org (Postfix) id 779B1AA9E9D; Mon, 15 Feb 2016 17:35:38 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 77284AA9E9C; Mon, 15 Feb 2016 17:35:38 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 1E261A66; Mon, 15 Feb 2016 17:35:37 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u1FHZXVA039524; Mon, 15 Feb 2016 17:35:33 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u1FHZXwV006194; Mon, 15 Feb 2016 17:35:33 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u1FHZXKV006190; Mon, 15 Feb 2016 17:35:33 GMT Date: Mon, 15 Feb 2016 17:35:33 GMT Message-Id: <201602151735.u1FHZXKV006190@higson.cam.lispworks.com> From: Martin Simmons To: Konstantin Belousov CC: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org In-reply-to: <20160215144410.GT91220@kib.kiev.ua> (message from Konstantin Belousov on Mon, 15 Feb 2016 16:44:10 +0200) Subject: Re: libthr shared locks References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> <20160215144410.GT91220@kib.kiev.ua> X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:35:38 -0000 >>>>> On Mon, 15 Feb 2016 16:44:10 +0200, Konstantin Belousov said: > > On Mon, Feb 15, 2016 at 02:17:20PM +0000, Martin Simmons wrote: > > > > Also, a general question: why not use some flag in the barrier (and other > > objects) to indicate pshared, removing the need for __thr_pshared_offpage > > except in init? > > But where would I keep the object ? All that I have with the current > ABI is a single pointer, which de facto behaves like the flag which you > proposed. It is either real pointer or (if set to some specific value > impossible for a valid pointer) there is an offpage. I'm probably missing something, but I was thinking pthread_barrier_init would do something like if ( attr is PTHREAD_PROCESS_PRIVATE ) { bar = calloc(1, sizeof(struct pthread_barrier)); pshared = 0; } else { bar = __thr_pshared_offpage(barrier, 1); pshared = 1; } bar->psharedflag = pshared; *barrier = bar; Then pthread_barrier_destroy would use the psharedflag slot to decide how to free it and pthread_barrier_wait would need no changes. From owner-freebsd-threads@freebsd.org Mon Feb 15 17:56:28 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A5846AA8BAC for ; Mon, 15 Feb 2016 17:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF5D1781 for ; Mon, 15 Feb 2016 17:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8B99BAA8BAB; Mon, 15 Feb 2016 17:56:28 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B0FDAA8BA8; Mon, 15 Feb 2016 17:56:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0ACB3177E; Mon, 15 Feb 2016 17:56:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1FHuMk4081577 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Feb 2016 19:56:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1FHuMk4081577 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1FHuL2h081576; Mon, 15 Feb 2016 19:56:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 15 Feb 2016 19:56:21 +0200 From: Konstantin Belousov To: Martin Simmons Cc: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org Subject: Re: libthr shared locks Message-ID: <20160215175621.GU91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> <20160215144410.GT91220@kib.kiev.ua> <201602151735.u1FHZXKV006190@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201602151735.u1FHZXKV006190@higson.cam.lispworks.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 17:56:28 -0000 On Mon, Feb 15, 2016 at 05:35:33PM +0000, Martin Simmons wrote: > >>>>> On Mon, 15 Feb 2016 16:44:10 +0200, Konstantin Belousov said: > > > > On Mon, Feb 15, 2016 at 02:17:20PM +0000, Martin Simmons wrote: > > > > > > Also, a general question: why not use some flag in the barrier (and other > > > objects) to indicate pshared, removing the need for __thr_pshared_offpage > > > except in init? > > > > But where would I keep the object ? All that I have with the current > > ABI is a single pointer, which de facto behaves like the flag which you > > proposed. It is either real pointer or (if set to some specific value > > impossible for a valid pointer) there is an offpage. > > I'm probably missing something, but I was thinking pthread_barrier_init would > do something like > > if ( attr is PTHREAD_PROCESS_PRIVATE ) { > bar = calloc(1, sizeof(struct pthread_barrier)); > pshared = 0; > } else { > bar = __thr_pshared_offpage(barrier, 1); > pshared = 1; > } > bar->psharedflag = pshared; > *barrier = bar; > > Then pthread_barrier_destroy would use the psharedflag slot to decide how to > free it and pthread_barrier_wait would need no changes. A process which has the page where the initialized pthread_barrier_t is located, must be able to operate on the barrier. Now, look at your scheme. One process which executed pthread_barrier_init(), performed what you proposed. What should do the pthread_barrier_wait() call in another process, which shares the 'barrier' with the first process, but does not share the whole address space ? After your pthread_barrier_init() executed, barrier contains the address of the object (off-page) in the other address space, for that process. From owner-freebsd-threads@freebsd.org Mon Feb 15 21:39:27 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04348AA8653 for ; Mon, 15 Feb 2016 21:39:27 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA02633C for ; Mon, 15 Feb 2016 21:39:26 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id E50B4AA8650; Mon, 15 Feb 2016 21:39:26 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E48F8AA864E; Mon, 15 Feb 2016 21:39:26 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id D025F33A; Mon, 15 Feb 2016 21:39:26 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 8D38F56B12; Mon, 15 Feb 2016 15:39:19 -0600 (CST) Subject: Re: libthr shared locks To: Konstantin Belousov , threads@freebsd.org, arch@freebsd.org References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> From: Eric van Gyzen X-Enigmail-Draft-Status: N1110 Message-ID: <56C24586.9050906@FreeBSD.org> Date: Mon, 15 Feb 2016 15:39:18 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56BE69B8.9020808@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 21:39:27 -0000 On 02/12/16 05:24 PM, Eric van Gyzen wrote: > On 12/23/2015 11:25, Konstantin Belousov wrote: >> The implementation in the patch >> https://www.kib.kiev.ua/kib/pshared/pshared.1.patch >> gives shared mutexes, condvars, rwlocks and barriers. > I reviewed everything except kern_umtx.c, which I plan to review on > Monday. My only comment on kern_umtx.c is, why are the permission checks compiled out? I also reviewed versions 2 and 3; the revisions look fine. Thanks for the chance to review, and for waiting for me to find time. Eric From owner-freebsd-threads@freebsd.org Tue Feb 16 11:32:33 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 34A6FAAAAA8 for ; Tue, 16 Feb 2016 11:32:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1F9551EE7 for ; Tue, 16 Feb 2016 11:32:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1D384AAAAA6; Tue, 16 Feb 2016 11:32:33 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1CBF3AAAAA2; Tue, 16 Feb 2016 11:32:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 918D01EE4; Tue, 16 Feb 2016 11:32:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1GBWMsR011473 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 16 Feb 2016 13:32:23 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1GBWMsR011473 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1GBWMnp011470; Tue, 16 Feb 2016 13:32:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 16 Feb 2016 13:32:22 +0200 From: Konstantin Belousov To: Eric van Gyzen Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160216113222.GY91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56C24586.9050906@FreeBSD.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 11:32:33 -0000 On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: > My only comment on kern_umtx.c is, why are the permission checks compiled out? Assume that we changed the ABI of libthr and shared locks do not require an offpage. Then, access to the locks is completely controlled by the access to the page containing the lock. If a process can mmap the page, it can own the lock. >From this point of view, access to the offpage shared memory object is the same as the access to the key page. Which is the reason to not include the access permissions checks. On the other hand, if you have something in kernel, which also owns a reference on ucred (for other means), you sure consider whether the usual access control is appropriate. Mostly, I leave the #ifdef-ed checks to reconsider it later, which worked since you asked the question. I definitely do not see much use of the shm_access() checks, but I am not completely sure about possible mac policies utilization there, although I do not really think they could be usefully attached to the app-level locks. > I also reviewed versions 2 and 3; the revisions look fine. Thank you very much. From owner-freebsd-threads@freebsd.org Tue Feb 16 14:56:44 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26FF8AAA806 for ; Tue, 16 Feb 2016 14:56:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1793184 for ; Tue, 16 Feb 2016 14:56:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1376CAAA804; Tue, 16 Feb 2016 14:56:44 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 129D2AAA801; Tue, 16 Feb 2016 14:56:44 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [IPv6:2607:fc50:1000:7400:216:3eff:fe72:314f]) by mx1.freebsd.org (Postfix) with ESMTP id F155A82; Tue, 16 Feb 2016 14:56:43 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from sweettea.beer.town (unknown [76.164.8.130]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 2A87556B13; Tue, 16 Feb 2016 08:56:37 -0600 (CST) Subject: Re: libthr shared locks To: Konstantin Belousov References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> Cc: threads@freebsd.org, arch@freebsd.org From: Eric van Gyzen X-Enigmail-Draft-Status: N1110 Message-ID: <56C338A0.2060205@FreeBSD.org> Date: Tue, 16 Feb 2016 08:56:32 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <20160216113222.GY91220@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 14:56:44 -0000 On 02/16/2016 05:32, Konstantin Belousov wrote: > On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: >> My only comment on kern_umtx.c is, why are the permission checks compiled out? > Assume that we changed the ABI of libthr and shared locks do not require > an offpage. Then, access to the locks is completely controlled by the > access to the page containing the lock. If a process can mmap the page, > it can own the lock. > > From this point of view, access to the offpage shared memory object > is the same as the access to the key page. Which is the reason to not > include the access permissions checks. This makes sense. > On the other hand, if you have something in kernel, which also owns a > reference on ucred (for other means), you sure consider whether the usual > access control is appropriate. This sounds wise. I'll keep it in mind. > I > definitely do not see much use of the shm_access() checks, but I am not > completely sure about possible mac policies utilization there, although > I do not really think they could be usefully attached to the app-level > locks. I would tend to agree, but I haven't used MAC for several years, so I'm not sure either. Cheers, Eric From owner-freebsd-threads@freebsd.org Tue Feb 16 16:17:57 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 231E1AA9C0D for ; Tue, 16 Feb 2016 16:17:57 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 10E8AFD4 for ; Tue, 16 Feb 2016 16:17:57 +0000 (UTC) (envelope-from martin@lispworks.com) Received: by mailman.ysv.freebsd.org (Postfix) id 01C90AA9C0B; Tue, 16 Feb 2016 16:17:57 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 013CFAA9C09; Tue, 16 Feb 2016 16:17:57 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from lwfs1-cam.cam.lispworks.com (mail.lispworks.com [46.17.166.21]) by mx1.freebsd.org (Postfix) with ESMTP id 9BB3AFD1; Tue, 16 Feb 2016 16:17:55 +0000 (UTC) (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (higson.cam.lispworks.com [192.168.1.7]) by lwfs1-cam.cam.lispworks.com (8.14.9/8.14.9) with ESMTP id u1GGHkx5039283; Tue, 16 Feb 2016 16:17:46 GMT (envelope-from martin@lispworks.com) Received: from higson.cam.lispworks.com (localhost.localdomain [127.0.0.1]) by higson.cam.lispworks.com (8.14.4) id u1GGHkPF023638; Tue, 16 Feb 2016 16:17:46 GMT Received: (from martin@localhost) by higson.cam.lispworks.com (8.14.4/8.14.4/Submit) id u1GGHkil023634; Tue, 16 Feb 2016 16:17:46 GMT Date: Tue, 16 Feb 2016 16:17:46 GMT Message-Id: <201602161617.u1GGHkil023634@higson.cam.lispworks.com> From: Martin Simmons To: Konstantin Belousov CC: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org In-reply-to: <20160215175621.GU91220@kib.kiev.ua> (message from Konstantin Belousov on Mon, 15 Feb 2016 19:56:21 +0200) Subject: Re: libthr shared locks References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> <20160215144410.GT91220@kib.kiev.ua> <201602151735.u1FHZXKV006190@higson.cam.lispworks.com> <20160215175621.GU91220@kib.kiev.ua> X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 16:17:57 -0000 >>>>> On Mon, 15 Feb 2016 19:56:21 +0200, Konstantin Belousov said: > > One process which executed pthread_barrier_init(), performed what you > proposed. What should do the pthread_barrier_wait() call in another > process, which shares the 'barrier' with the first process, but does > not share the whole address space ? After your pthread_barrier_init() > executed, barrier contains the address of the object (off-page) in the > other address space, for that process. Ah, sorry, I understand now (the init functions are called before any sharing). How should the destroy functions be used by the processes? I.e. should only the "last" process call destroy or can every process call it? From owner-freebsd-threads@freebsd.org Tue Feb 16 17:27:19 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1CABAAA7BD for ; Tue, 16 Feb 2016 17:27:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CF8131D34 for ; Tue, 16 Feb 2016 17:27:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CC3F8AAA7BC; Tue, 16 Feb 2016 17:27:19 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBB53AAA7BA; Tue, 16 Feb 2016 17:27:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 960F71D33; Tue, 16 Feb 2016 17:27:19 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u1GHRC30058087; Tue, 16 Feb 2016 12:27:12 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 16 Feb 2016 12:27:12 -0500 (EST) Date: Tue, 16 Feb 2016 12:27:12 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20160216113222.GY91220@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 17:27:20 -0000 On Tue, 16 Feb 2016, Konstantin Belousov wrote: > On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: >> My only comment on kern_umtx.c is, why are the permission checks compiled out? > > Assume that we changed the ABI of libthr and shared locks do not require > an offpage. How are you coming with that? I thought maybe you were going to think about making the synch types structs, but not actually changing the implementation (yet). -- DE From owner-freebsd-threads@freebsd.org Wed Feb 17 16:16:24 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 717F2AAB431 for ; Wed, 17 Feb 2016 16:16:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 544C81CB9 for ; Wed, 17 Feb 2016 16:16:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 516CAAAB42F; Wed, 17 Feb 2016 16:16:24 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50F46AAB42D; Wed, 17 Feb 2016 16:16:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C44B11CB7; Wed, 17 Feb 2016 16:16:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1HGGC04088915 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Feb 2016 18:16:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1HGGC04088915 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1HGGCOq088914; Wed, 17 Feb 2016 18:16:12 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Feb 2016 18:16:12 +0200 From: Konstantin Belousov To: Martin Simmons Cc: vangyzen@FreeBSD.org, threads@FreeBSD.org, arch@FreeBSD.org Subject: Re: libthr shared locks Message-ID: <20160217161612.GL91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <20160213143815.GB91220@kib.kiev.ua> <201602151417.u1FEHKwL003392@higson.cam.lispworks.com> <20160215144410.GT91220@kib.kiev.ua> <201602151735.u1FHZXKV006190@higson.cam.lispworks.com> <20160215175621.GU91220@kib.kiev.ua> <201602161617.u1GGHkil023634@higson.cam.lispworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201602161617.u1GGHkil023634@higson.cam.lispworks.com> User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:16:24 -0000 On Tue, Feb 16, 2016 at 04:17:46PM +0000, Martin Simmons wrote: > >>>>> On Mon, 15 Feb 2016 19:56:21 +0200, Konstantin Belousov said: > > > > One process which executed pthread_barrier_init(), performed what you > > proposed. What should do the pthread_barrier_wait() call in another > > process, which shares the 'barrier' with the first process, but does > > not share the whole address space ? After your pthread_barrier_init() > > executed, barrier contains the address of the object (off-page) in the > > other address space, for that process. > > Ah, sorry, I understand now (the init functions are called before any > sharing). Well, the memory is either already shared between processes, or it should become shared before other process may operate on the object carried by the memory. It is that pthread_mutex_init() must be called before any other pthread_mutex_*() functions, but only once globally. > > How should the destroy functions be used by the processes? I.e. should only > the "last" process call destroy or can every process call it? Hm, this is a good observation. pthread_mutex_destroy() must be called only by last process, i.e. no other pthread_mutex_* calls are allowed for the object after the _destroy() was called. What this means for my implementation, is that processes other than the _destroy() caller keep the record in the pshared cache, and this needs fixing. For now, I added a mechanism which scans the whole hash and re-checks the validity on any object destroy. This can be optimized, e.g. by doing the scan only each N calls to _destroy(), or by scanning only the same hash chain, or by not doing this at all. I think it is an acceptable compromise for now. A specific test for the case is at https://www.kib.kiev.ua/kib/pshared/pthread_shared_destroy.c Updated patch https://www.kib.kiev.ua/kib/pshared/pshared.4.patch From owner-freebsd-threads@freebsd.org Wed Feb 17 16:45:48 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9E32EAAA2EA for ; Wed, 17 Feb 2016 16:45:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 883E91D5A for ; Wed, 17 Feb 2016 16:45:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 85356AAA2E9; Wed, 17 Feb 2016 16:45:48 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 84AABAAA2E7; Wed, 17 Feb 2016 16:45:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 035231D59; Wed, 17 Feb 2016 16:45:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1HGjfC6095470 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 17 Feb 2016 18:45:41 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1HGjfC6095470 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1HGjfUg095469; Wed, 17 Feb 2016 18:45:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 17 Feb 2016 18:45:41 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160217164541.GM91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 16:45:48 -0000 On Tue, Feb 16, 2016 at 12:27:12PM -0500, Daniel Eischen wrote: > On Tue, 16 Feb 2016, Konstantin Belousov wrote: > > > On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: > >> My only comment on kern_umtx.c is, why are the permission checks compiled out? > > > > Assume that we changed the ABI of libthr and shared locks do not require > > an offpage. > > How are you coming with that? I thought maybe you were going to think > about making the synch types structs, but not actually changing the > implementation (yet). Are you asking what is the state of the work for changing the libthr ABI by replacing object pointers with inline structures, am I reading the question right ? (Sorry, english is not my native language) I do plan to introduce inlined objects (most likely in the form of libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my plans are to get the existing patch for pshared into the tree for 11.0. After that I wanted to implement robust mutexes, still in the context of the libthr. Then libthr2. Finishing the current patch for 11.0 is the immediate goal, while I did not forget neither abandoned the inline alternative and do plan to work on it. From owner-freebsd-threads@freebsd.org Wed Feb 17 17:38:00 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 776D6AAB989 for ; Wed, 17 Feb 2016 17:38:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 63E9A1A8E for ; Wed, 17 Feb 2016 17:38:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 60EDCAAB988; Wed, 17 Feb 2016 17:38:00 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60709AAB985; Wed, 17 Feb 2016 17:38:00 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC891A8D; Wed, 17 Feb 2016 17:37:59 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u1HHbqJV029498; Wed, 17 Feb 2016 12:37:52 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 17 Feb 2016 12:37:52 -0500 (EST) Date: Wed, 17 Feb 2016 12:37:52 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20160217164541.GM91220@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 17:38:00 -0000 On Wed, 17 Feb 2016, Konstantin Belousov wrote: > On Tue, Feb 16, 2016 at 12:27:12PM -0500, Daniel Eischen wrote: >> On Tue, 16 Feb 2016, Konstantin Belousov wrote: >> >>> On Mon, Feb 15, 2016 at 03:39:18PM -0600, Eric van Gyzen wrote: >>>> My only comment on kern_umtx.c is, why are the permission checks compiled out? >>> >>> Assume that we changed the ABI of libthr and shared locks do not require >>> an offpage. >> >> How are you coming with that? I thought maybe you were going to think >> about making the synch types structs, but not actually changing the >> implementation (yet). > > Are you asking what is the state of the work for changing the libthr > ABI by replacing object pointers with inline structures, am I reading > the question right ? (Sorry, english is not my native language) I am sorry, my question was not phrased very well. Sometimes I am amazed that non-native English speakers can write better English than native English speakers :-) But, yes, that was my question. > I do plan to introduce inlined objects (most likely in the form of > libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my > plans are to get the existing patch for pshared into the tree for 11.0. > After that I wanted to implement robust mutexes, still in the context of > the libthr. Then libthr2. As soon as this is done, will we build FreeBSD base OS against the new API? So only ports would be affected. I was hoping to see partially inlined objects (with the first word being a pointer to the allocated object, just like now) in for 11.0. So by 12.0 we could make the switch over to fully inlined. If we introduce either partially or fully inlined objects for 11.1 (with your libthr2), how does that affect our ability to move to fully inlined by default (base & ports) for 12.0? We would not have had a full release cycle for the ABI change. > Finishing the current patch for 11.0 is the immediate goal, while I did > not forget neither abandoned the inline alternative and do plan to work > on it. Thanks! -- DE From owner-freebsd-threads@freebsd.org Thu Feb 18 15:33:01 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB887AAD0E9 for ; Thu, 18 Feb 2016 15:33:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B1539E73 for ; Thu, 18 Feb 2016 15:33:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B0E70AAD0E7; Thu, 18 Feb 2016 15:33:01 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96892AAD0E6; Thu, 18 Feb 2016 15:33:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EEBEE6E; Thu, 18 Feb 2016 15:33:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1IFWuT4025136 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 18 Feb 2016 17:32:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1IFWuT4025136 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1IFWu76025135; Thu, 18 Feb 2016 17:32:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 18 Feb 2016 17:32:56 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160218153256.GS91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:33:02 -0000 On Wed, Feb 17, 2016 at 12:37:52PM -0500, Daniel Eischen wrote: > On Wed, 17 Feb 2016, Konstantin Belousov wrote: > > I do plan to introduce inlined objects (most likely in the form of > > libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my > > plans are to get the existing patch for pshared into the tree for 11.0. > > After that I wanted to implement robust mutexes, still in the context of > > the libthr. Then libthr2. > > As soon as this is done, will we build FreeBSD base OS against > the new API? So only ports would be affected. I do not think this is feasible. Base system does not have any significant thread consumers, might be only ntpd qualifies. Small things like ngctl are not that important. But base system provides C++ runtime for ports and I suspect that libc++ depends on the libthr ABI. Even jemalloc depends on libthr ABI. So changing only the base ABI is probably impossible, from the first look the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this must be considered carefully during the later stage of the libthr2 development, right now it is rather empty speculation on my side. > > I was hoping to see partially inlined objects (with the first word > being a pointer to the allocated object, just like now) in for 11.0. > So by 12.0 we could make the switch over to fully inlined. I do not see how this is realistic. The issue of introducing the inlined objects is the stumbling block, regardless of their use in full or only as a placeholder for the pointer. Not even mentioning that we do not want to radically break the userspace ABI for 11.0 when the freeze is so close, we would need much more time to develop the WITH_LIBTHR2 alone. This is my opinion, but it is supported by my experience. > > If we introduce either partially or fully inlined objects for 11.1 > (with your libthr2), how does that affect our ability to move to > fully inlined by default (base & ports) for 12.0? We would not > have had a full release cycle for the ABI change. I cannot answer this question, the issue requires careful investigation, as I noted earlier in the message. Might be I or somebody else would be able to produce some trick that would ease the pain. If not, the bump of dso version numbers and dynamic linker awareness of the incompatible libraries would be to coded. > > > Finishing the current patch for 11.0 is the immediate goal, while I did > > not forget neither abandoned the inline alternative and do plan to work > > on it. That is. From owner-freebsd-threads@freebsd.org Thu Feb 18 17:10:01 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8CE9AAC72A for ; Thu, 18 Feb 2016 17:10:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B241CD48 for ; Thu, 18 Feb 2016 17:10:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id AD009AAC729; Thu, 18 Feb 2016 17:10:01 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC613AAC727; Thu, 18 Feb 2016 17:10:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 725C9D34; Thu, 18 Feb 2016 17:10:01 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u1IH9xD2034133; Thu, 18 Feb 2016 12:09:59 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 18 Feb 2016 12:09:59 -0500 (EST) Date: Thu, 18 Feb 2016 12:09:59 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20160218153256.GS91220@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:10:01 -0000 On Thu, 18 Feb 2016, Konstantin Belousov wrote: > On Wed, Feb 17, 2016 at 12:37:52PM -0500, Daniel Eischen wrote: >> On Wed, 17 Feb 2016, Konstantin Belousov wrote: >>> I do plan to introduce inlined objects (most likely in the form of >>> libthr2 initially, i.e. cc -D_LIBTHR2 -o file file.c -lthr2). But my >>> plans are to get the existing patch for pshared into the tree for 11.0. >>> After that I wanted to implement robust mutexes, still in the context of >>> the libthr. Then libthr2. >> >> As soon as this is done, will we build FreeBSD base OS against >> the new API? So only ports would be affected. > I do not think this is feasible. Base system does not have any significant > thread consumers, might be only ntpd qualifies. Small things like ngctl > are not that important. > > But base system provides C++ runtime for ports and I suspect that libc++ > depends on the libthr ABI. Even jemalloc depends on libthr ABI. So > changing only the base ABI is probably impossible, from the first look > the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this > must be considered carefully during the later stage of the libthr2 > development, right now it is rather empty speculation on my side. I would think partially inlined objects (still a pointer inside) could be made in libthr (not libthr2) by default for 11.0 (or 11.x). So that the only change is the size of the objects, not anything else. The only breakage would be layout related. -- DE From owner-freebsd-threads@freebsd.org Fri Feb 19 00:33:02 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9CA9AABBE8 for ; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C1B78145E for ; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BC9CCAABBE5; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BC172AABBE3; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DA7B145B; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1J0Wted021594 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Feb 2016 02:32:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1J0Wted021594 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1J0Wtdm021593; Fri, 19 Feb 2016 02:32:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2016 02:32:55 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160219003255.GU91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 00:33:03 -0000 On Thu, Feb 18, 2016 at 12:09:59PM -0500, Daniel Eischen wrote: > On Thu, 18 Feb 2016, Konstantin Belousov wrote: > > But base system provides C++ runtime for ports and I suspect that libc++ > > depends on the libthr ABI. Even jemalloc depends on libthr ABI. So > > changing only the base ABI is probably impossible, from the first look > > the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this > > must be considered carefully during the later stage of the libthr2 > > development, right now it is rather empty speculation on my side. This paragraph is relevant for my answer below. > > I would think partially inlined objects (still a pointer inside) > could be made in libthr (not libthr2) by default for 11.0 (or 11.x). > So that the only change is the size of the objects, not anything > else. The only breakage would be layout related. Structure size is part of the library ABI, when the structure is exposed to user, it cannot be increased without consequences. Changing the size of the libthr objects changes layout of the objects embedding the locks. Doing class MyLock { private: pthread_mutex_t m_lock; const char *name; }; is the common and very popular practice. With the change proposed to libthr.so.3, you get subtle and sudden ABI breakage for all libthr consumers as well. In particular, it would affect libc (jemalloc) and libc++. Depending on the variant of headers used for the compilation, you get different layout for user structures. From owner-freebsd-threads@freebsd.org Fri Feb 19 02:31:52 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D1E9AAD5F9 for ; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 049631FB7 for ; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 01CACAAD5F7; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F4186AAD5F5; Fri, 19 Feb 2016 02:31:51 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E9D21FB2; Fri, 19 Feb 2016 02:31:51 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u1J2VibS010379; Thu, 18 Feb 2016 21:31:44 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 18 Feb 2016 21:31:44 -0500 (EST) Date: Thu, 18 Feb 2016 21:31:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20160219003255.GU91220@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> <20160219003255.GU91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 02:31:52 -0000 On Fri, 19 Feb 2016, Konstantin Belousov wrote: > On Thu, Feb 18, 2016 at 12:09:59PM -0500, Daniel Eischen wrote: >> On Thu, 18 Feb 2016, Konstantin Belousov wrote: >>> But base system provides C++ runtime for ports and I suspect that libc++ >>> depends on the libthr ABI. Even jemalloc depends on libthr ABI. So >>> changing only the base ABI is probably impossible, from the first look >>> the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this >>> must be considered carefully during the later stage of the libthr2 >>> development, right now it is rather empty speculation on my side. > This paragraph is relevant for my answer below. > >> >> I would think partially inlined objects (still a pointer inside) >> could be made in libthr (not libthr2) by default for 11.0 (or 11.x). >> So that the only change is the size of the objects, not anything >> else. The only breakage would be layout related. > > Structure size is part of the library ABI, when the structure is exposed > to user, it cannot be increased without consequences. > > Changing the size of the libthr objects changes layout of the objects > embedding the locks. Doing > class MyLock { > private: > pthread_mutex_t m_lock; > const char *name; > }; > is the common and very popular practice. With the change proposed to > libthr.so.3, you get subtle and sudden ABI breakage for all libthr > consumers as well. In particular, it would affect libc (jemalloc) and > libc++. Depending on the variant of headers used for the compilation, > you get different layout for user structures. libc is part of FreeBSD, so it would be recompiled for the new size. I was also assuming library version bumps. -- DE From owner-freebsd-threads@freebsd.org Fri Feb 19 15:08:37 2016 Return-Path: Delivered-To: freebsd-threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6F84AADA3F for ; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id BB499139A for ; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id B9077AADA3D; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) Delivered-To: threads@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9EB5FAADA3B; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4702C1399; Fri, 19 Feb 2016 15:08:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1JF8Sei034403 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Feb 2016 17:08:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1JF8Sei034403 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1JF8RRu034402; Fri, 19 Feb 2016 17:08:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2016 17:08:27 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160219150827.GW91220@kib.kiev.ua> References: <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> <20160219003255.GU91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:08:38 -0000 On Thu, Feb 18, 2016 at 09:31:44PM -0500, Daniel Eischen wrote: > On Fri, 19 Feb 2016, Konstantin Belousov wrote: > > > On Thu, Feb 18, 2016 at 12:09:59PM -0500, Daniel Eischen wrote: > >> On Thu, 18 Feb 2016, Konstantin Belousov wrote: > >>> But base system provides C++ runtime for ports and I suspect that libc++ > >>> depends on the libthr ABI. Even jemalloc depends on libthr ABI. So > >>> changing only the base ABI is probably impossible, from the first look > >>> the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this > >>> must be considered carefully during the later stage of the libthr2 > >>> development, right now it is rather empty speculation on my side. > > This paragraph is relevant for my answer below. > > > >> > >> I would think partially inlined objects (still a pointer inside) > >> could be made in libthr (not libthr2) by default for 11.0 (or 11.x). > >> So that the only change is the size of the objects, not anything > >> else. The only breakage would be layout related. > > > > Structure size is part of the library ABI, when the structure is exposed > > to user, it cannot be increased without consequences. > > > > Changing the size of the libthr objects changes layout of the objects > > embedding the locks. Doing > > class MyLock { > > private: > > pthread_mutex_t m_lock; > > const char *name; > > }; > > is the common and very popular practice. With the change proposed to > > libthr.so.3, you get subtle and sudden ABI breakage for all libthr > > consumers as well. In particular, it would affect libc (jemalloc) and > > libc++. Depending on the variant of headers used for the compilation, > > you get different layout for user structures. > > libc is part of FreeBSD, so it would be recompiled for the new > size. I was also assuming library version bumps. Increasing the structures sizes (and bumping versions) would - break ABI - invalidate all the work which was done by people from the FreeBSD 7.x time to keep the ABI stable, by writing shims, by adopting changes to provide compatibility, and by testing the compatibility without any benefit of a new feature. It would be only promised to provide a new feature sometime in the 11.x scope. My immediate goal is to get the published patch committed. After that, I want to look at the implementation of the robust mutexes. I hope that this would be done for 11.0, but if not, it should be mergeable. The libthr2 stuff, by which I call everything related to inlining, should be started after that.