Re: CVS commit: src/sys/netinet6
On 22/04/2020 20:32, Roy Marples wrote: Module Name:src Committed By: roy Date: Wed Apr 22 19:32:11 UTC 2020 Modified Files: src/sys/netinet6: nd6_nbr.c Log Message: inet6: nd6_na_input() now considers ln_state <= ND6_LLINFO_INCOMPLETE Otherwise if ln_state != ND6_LLINFO_INCOMPLETE and the is no lladdr and this message was solicited then ln_state is set to ND6_LLINFO_REACHABLE which could then cause a panic in nd6_resolve(). If ln_state > ND6_LLINFO_INCOMPLETE then it's assumed we have a lladdr. Potentially this could have been triggered by the introduction of ND6_LLINFO_PURGE in nd6.c r1.143 but also by the re-introduction of ND6_LLINFO_INCOMPLETE in nd6.c r1.263. I meant ND6_LLINFO_WAITDELETE, not ND6_LLINFO_INCOMPLETE here. Depending on the timing, it's technically possible to receive such a message after the llentry is created with ND6_LLINFO_NOSTATE. To generate a diff of this commit: cvs rdiff -u -r1.177 -r1.178 src/sys/netinet6/nd6_nbr.c Please note that diffs are not public domain; they are subject to the copyright notices on the relevant files.
Re: CVS commit: src
> On Apr 22, 2020, at 7:52 AM, Kamil Rytarowski wrote: > > Would it be possible to keep a global unique TID as 64-bit integer > (int64_t) equal to: pid << 32 | lwpid ? > > That way we could have predicatable numbers in the system and possibly > simplify the involved code avoiding one extra unique 32-bit id. Yes, I've been discussing this w/ ad@, chs@, and riastradh@. I have a different approach that's almost ready to go, and will remove this separate "TID". The system call was not yet exposed in libc, so it's not a problem to pull it out. For various reasons, the ID must be limited to less than 32 bits. -- thorpej
Re: CVS commit: src
On 04.04.2020 22:20, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sat Apr 4 20:20:12 UTC 2020
>
> Modified Files:
> src/sys/compat/netbsd32: syscalls.master
> src/sys/kern: kern_exit.c kern_lwp.c sys_lwp.c syscalls.master
> src/sys/sys: lwp.h
> Added Files:
> src/tests/lib/libc/sys: t_lwp_tid.c
>
> Log Message:
> Add support for lazily generating a "global thread ID" for a LWP. This
> identifier uniquely identifies an LWP across the entire system, and will
> be used in future improvements in user-space synchronization primitives.
>
> (Test disabled and libc stub not included intentionally so as to avoid
> multiple libc version bumps.)
>
> --- src/sys/sys/lwp.h:1.204 Sat Apr 4 06:51:46 2020
> +++ src/sys/sys/lwp.h Sat Apr 4 20:20:12 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: lwp.h,v 1.204 2020/04/04 06:51:46 maxv Exp $ */
> +/* $NetBSD: lwp.h,v 1.205 2020/04/04 20:20:12 thorpej Exp $*/
>
> /*
> * Copyright (c) 2001, 2006, 2007, 2008, 2009, 2010, 2019, 2020
> @@ -135,6 +135,24 @@ struct lwp {
> u_int l_slptime; /* l: time since last blocked */
> booll_vforkwaiting; /* a: vfork() waiting */
>
> + /* User-space synchronization. */
> + uintptr_t l___reserved; /* reserved for future use */
> + /*
> + * The global thread ID has special locking and access
> + * considerations. Because many LWPs may never need one,
> + * global thread IDs are allocated lazily in lwp_gettid().
> + * l___tid is not bean to be accessed directly unless
> + * the accessor has specific knowledge that doing so
> + * is safe. l___tid is only assigned by the LWP itself.
> + * Once assigned, it is stable until the LWP exits.
> + * An LWP assigns its own thread ID unlocked before it
> + * reaches visibility to the rest of the system, and
> + * can access its own thread ID unlocked. But once
> + * published, it must hold the proc's lock to change
> + * the value.
> + */
> + lwpid_t l___tid;/* p: global thread id */
> +
Would it be possible to keep a global unique TID as 64-bit integer
(int64_t) equal to: pid << 32 | lwpid ?
That way we could have predicatable numbers in the system and possibly
simplify the involved code avoiding one extra unique 32-bit id.
Are there any (atomic?) shortcomings of this approach?
signature.asc
Description: OpenPGP digital signature
Re: CVS commit: src/sys/lib/libkern/arch/m68k
In addition to these files in this mail:
Modified Files:
src/lib/libc/arch/m68k/gen: Makefile.inc
src/lib/libc/compiler_rt: Makefile.inc
src/sys/arch/sun68k/stand/libsa: Makefile.inc
Removed Files:
src/common/lib/libc/arch/m68k/gen: divsi3.S modsi3.S udivsi3.S umodsi3.S
However, cvs aborted since I forgot to ``cvs add'' and commit mail was
not sent. Sorry for the inconvenience...
Diffs are attached to this message.
Thanks,
rin
On 2020/04/22 20:58, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Apr 22 11:58:26 UTC 2020
Added Files:
src/sys/lib/libkern/arch/m68k: divsi3.S modsi3.S udivsi3.S umodsi3.S
Log Message:
Restrict usage of m68k assembler versions of {,u}divsi3 and {,u}divsi3 to
kernel and bootloader for 68010.
They requires a special calling convention to udivsi3, and cannot to be
mixed up in normal routines provided by libgcc or compiler_rt. Although,
there's no problem for using in a controlled situation, i.e., kernel and
standalone programs.
Note that this does not affect m68k ports other than sun2, since codes
generated by gcc do not call these routines.
Assembler files are moved from common/lib/libc/arch/m68k/gen to
sys/lib/libkern/arch/m68k in order not to be compiled in libc.
Revert hack introduced to lib/libc/compiler_rt/Makefile.inc rev 1.37:
http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/compiler_rt/Makefile.inc#rev1.37
Proposed on port-sun2@ with no response...
(Again, this does not affect m68k ports other than sun2.)
http://mail-index.netbsd.org/port-sun2/2020/03/10/msg000102.html
To generate a diff of this commit:
cvs rdiff -u -r0 -r1.3 src/sys/lib/libkern/arch/m68k/divsi3.S \
src/sys/lib/libkern/arch/m68k/modsi3.S \
src/sys/lib/libkern/arch/m68k/umodsi3.S
cvs rdiff -u -r0 -r1.5 src/sys/lib/libkern/arch/m68k/udivsi3.S
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Added files:
Index: src/sys/lib/libkern/arch/m68k/divsi3.S
diff -u /dev/null src/sys/lib/libkern/arch/m68k/divsi3.S:1.3
--- /dev/null Wed Apr 22 11:58:26 2020
+++ src/sys/lib/libkern/arch/m68k/divsi3.S Wed Apr 22 11:58:26 2020
@@ -0,0 +1,71 @@
+/* $NetBSD: divsi3.S,v 1.3 2020/04/22 11:58:26 rin Exp $ */
+
+/*-
+ * Copyright (c) 1990 The Regents of the University of California.
+ * All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * the Systems Programming Group of the University of Utah Computer
+ * Science Department.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+
+#if defined(LIBC_SCCS) && !defined(lint)
+#if 0
+ RCSID("from: @(#)divsi3.s 5.1 (Berkeley) 6/7/90")
+#else
+ RCSID("$NetBSD: divsi3.S,v 1.3 2020/04/22 11:58:26 rin Exp $")
+#endif
+#endif /* LIBC_SCCS and not lint */
+
+/* int / int */
+#ifndef __mc68010__
+#error
+ENTRY(__divsi3)
+ movel 4(%sp),%d0
+ divsl 8(%sp),%d0
+ rts
+END(__divsi3)
+#else
+ENTRY(__divsi3)
+| NB: this requires that __udivsi3 preserve %a0:
+ movel 4(%sp), %d1 | load the dividend
+ bpl 1f
+ negl4(%sp) | store abs(dividend)
+1: movel 8(%sp), %d0 | load the divisor
+ bpl 2f
+ negl8(%sp) | store abs(divisor)
+2: eorl%d1, %d0
+ bpl 3f | branch if sgn(divisor) == sgn(dividend)
+ movel (%sp)+, %a0 | pop return address
+ pea (.Lret,%pc) | push our return address
+3: j
Re: NO_KERNEL_RCSIDS
On 2020/04/22 19:10, m...@netbsd.org wrote: On Wed, Apr 22, 2020 at 09:23:21AM +, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Wed Apr 22 09:23:21 UTC 2020 Modified Files: src/sys/sys: cdefs.h Log Message: For NO_KERNEL_RCSIDS, strip __RCSID() also for src/common/*. Since these live in their own ELF section, wouldn't it be easier to use strip(1) to remove them, than modify source code? Well, I'm planning to add kernel option to strip non-global symbols (mainly for sun2, which is suffering from severe memory shortage). I will consider to re-implement NO_KERNEL_RCSIDS option in sys/conf/Makefile.kern.inc, at the same time. Thanks, rin
NO_KERNEL_RCSIDS
On Wed, Apr 22, 2020 at 09:23:21AM +, Rin Okuyama wrote: > Module Name: src > Committed By: rin > Date: Wed Apr 22 09:23:21 UTC 2020 > > Modified Files: > src/sys/sys: cdefs.h > > Log Message: > For NO_KERNEL_RCSIDS, strip __RCSID() also for src/common/*. Since these live in their own ELF section, wouldn't it be easier to use strip(1) to remove them, than modify source code?
