Re: CVS commit: src/sys/uvm

2020-05-10 Thread Alistair Crooks
On Sat, 9 May 2020 at 14:50, Taylor R Campbell wrote: > Module Name:src > Committed By: riastradh > Date: Sat May 9 21:50:39 UTC 2020 > > Modified Files: > src/sys/uvm: uvm_swap.c > > Log Message: > Implement swap encryption. > > Enabled by sysctl -w vm.swap_encrypt=1.

Re: CVS commit: src/sys/uvm

2020-05-10 Thread Taylor R Campbell
> Date: Sun, 10 May 2020 23:53:00 +0100 > From: Alexander Nasonov > > Taylor R Campbell wrote: > > Log Message: > > Implement swap encryption. > > > > Enabled by sysctl -w vm.swap_encrypt=1. > > If secmodel_securelevel(9) is still a thing, locking down this sysctl > at high securelevel may

Re: CVS commit: src/sys/uvm

2020-05-10 Thread Alexander Nasonov
Taylor R Campbell wrote: > Log Message: > Implement swap encryption. > > Enabled by sysctl -w vm.swap_encrypt=1. If secmodel_securelevel(9) is still a thing, locking down this sysctl at high securelevel may improve our security. Prior to this change, swap devices were readable (even if enrypted

Re: CVS commit: src/sys

2020-05-10 Thread Christos Zoulas
In article <20200508220155.446eef...@cvs.netbsd.org>, Andrew Doran wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: ad >Date: Fri May 8 22:01:55 UTC 2020 > >Modified Files: > src/sys/arch/x86/include: cpu_counter.h > src/sys/arch/x86/x86: cpu.c tsc.c >

Re: CVS commit: src

2020-05-10 Thread Yorick Hardy
Dear Martin, On 2020-05-08, Martin Husemann wrote: > On Thu, May 07, 2020 at 10:52:26PM +0200, Yorick Hardy wrote: > > Thanks! It took a while for this to sink in ... > > > > So I think the test should only be built if MKCOMPAT=yes ? > > (It does fail to build for me, because I usually have

Re: CVS commit: src/bin/kill

2020-05-08 Thread Kamil Rytarowski
On 06.05.2020 14:48, Robert Elz wrote: > Date:Wed, 6 May 2020 11:28:42 +0200 > From:Kamil Rytarowski > Message-ID: > > > | While there, we have got a long standing issue with wait.1 man page, > > Huh! I had no idea any such thing existed... (do you know of

Re: CVS commit: src

2020-05-07 Thread Martin Husemann
On Thu, May 07, 2020 at 10:52:26PM +0200, Yorick Hardy wrote: > Thanks! It took a while for this to sink in ... > > So I think the test should only be built if MKCOMPAT=yes ? > (It does fail to build for me, because I usually have MKCOMPAT=no). Yes, either the Makefile needs a conditional, or

Re: CVS commit: src

2020-05-07 Thread Yorick Hardy
Dear Martin, On 2020-05-07, Martin Husemann wrote: > On Thu, May 07, 2020 at 12:31:12AM +0200, Yorick Hardy wrote: > > I think this test depends on MKCOMPAT=yes. Does the attached the patch > > below look reasonable? > [..] > > -.if ${MACHINE} == "amd64" > > +.if ${MACHINE} == "amd64" &&

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-05-07 Thread J. Hannken-Illjes
> On May 7, 2020, at 5:47 PM, Taylor R Campbell > wrote: > >> Module Name:src >> Committed By: hannken >> Date: Thu May 7 09:12:03 UTC 2020 >> >> Modified Files: >>src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c >> >> Log Message: >> Revert Rev. 1.63 and

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs

2020-05-07 Thread Taylor R Campbell
> Module Name:src > Committed By: hannken > Date: Thu May 7 09:12:03 UTC 2020 > > Modified Files: > src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c > > Log Message: > Revert Rev. 1.63 and add a comment why we have to zil_commit() here: > > Operation

Re: CVS commit: src/sys/kern

2020-05-07 Thread Kamil Rytarowski
On 07.05.2020 07:46, Michael van Elst wrote: > On Wed, May 06, 2020 at 12:39:21PM +0200, Kamil Rytarowski wrote: > > Hi Kamil, > >> If I revert the pipe(2) changes on top of NetBSD-current, the test is no >> longer racy again. > > I tried 9.99.60 with and without my bugfix. The test always

Re: CVS commit: src/sys/kern

2020-05-06 Thread Michael van Elst
On Wed, May 06, 2020 at 12:39:21PM +0200, Kamil Rytarowski wrote: Hi Kamil, > If I revert the pipe(2) changes on top of NetBSD-current, the test is no > longer racy again. I tried 9.99.60 with and without my bugfix. The test always failed after some time with exactly that error. If the change

Re: CVS commit: src/lib/librumpuser

2020-05-06 Thread Alistair Crooks
On Tue, 5 May 2020 at 20:54, Kamil Rytarowski wrote: > Ping? We are blocked by this in GSoC now. > > > I doubt that you are "blocked by this in GSoC", as the GSoC projects were just announced yesterday. You should be planning the milestones right now with your student

Re: CVS commit: src

2020-05-06 Thread Martin Husemann
On Thu, May 07, 2020 at 12:31:12AM +0200, Yorick Hardy wrote: > I think this test depends on MKCOMPAT=yes. Does the attached the patch > below look reasonable? [..] > -.if ${MACHINE} == "amd64" > +.if ${MACHINE} == "amd64" && ${MKCOMPATTESTS} == "yes" MKCOMPATTESTS is something slightly

Re: CVS commit: src

2020-05-06 Thread Yorick Hardy
Dear Maxime, On 2020-04-19, Maxime Villard wrote: > Module Name: src > Committed By: maxv > Date: Sun Apr 19 13:22:58 UTC 2020 > > Modified Files: > src/distrib/sets/lists/debug: md.amd64 > src/distrib/sets/lists/tests: md.amd64 mi > src/etc/mtree: NetBSD.dist.tests >

re: CVS commit: src

2020-05-06 Thread matthew green
> Added Files: > src/lib/libc/gen: getentropy.3 getentropy.c thanks for this. can you fix a minor nit? + return sysctl(name, 2, buf, , NULL, 0); please write '2' as '__arraycount(name)'. thanks. .mrg.

Re: CVS commit: src

2020-05-06 Thread Christos Zoulas
In article <20200506161737.59410f...@cvs.netbsd.org>, Nia Alarie wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: nia >Date: Wed May 6 16:17:37 UTC 2020 > >Modified Files: > src/distrib/sets/lists/comp: mi > src/include: unistd.h > src/lib/libc/gen:

Re: CVS commit: src/bin/kill

2020-05-06 Thread Robert Elz
Date:Wed, 6 May 2020 11:28:42 +0200 From:Kamil Rytarowski Message-ID: | While there, we have got a long standing issue with wait.1 man page, Huh! I had no idea any such thing existed... (do you know of any more bizarre ones like that?) | it should be

Re: CVS commit: src/sys/kern

2020-05-06 Thread Kamil Rytarowski
This caused regressions in t_ptrace_wait* tests and random hangs/timeouts/failures. If I revert the pipe(2) changes on top of NetBSD-current, the test is no longer racy again. http://netbsd.org/~kamil/patch-00249-pipe-revert.txt Reproducer: cd /usr/tests/lib/libc/sys ./t_ptrace_waitpid

Re: CVS commit: src/bin/kill

2020-05-06 Thread Kamil Rytarowski
On 06.05.2020 11:07, Robert Elz wrote: > Module Name: src > Committed By: kre > Date: Wed May 6 09:07:15 UTC 2020 > > Modified Files: > src/bin/kill: kill.1 > > Log Message: > kill is built-in to more than just csh(1). > While here, add missing Xr sh 1 (which was previously

Re: CVS commit: src/lib/librumpuser

2020-05-06 Thread Robert Elz
Date:Wed, 6 May 2020 07:30:17 +0200 From:Kamil Rytarowski Message-ID: | I reverted my fix It wasn't a fix, it simply made the problem go away, incorrectly. If you want you can just delete the relevant lines (the ones you changed). I've been running like that now

Re: CVS commit: src/lib/librumpuser

2020-05-05 Thread Kamil Rytarowski
On 06.05.2020 07:17, Alistair Crooks wrote: > > > On Tue, 5 May 2020 at 20:54, Kamil Rytarowski > wrote: > > Ping? We are blocked by this in GSoC now. > > > I doubt that you are "blocked by this in GSoC", as the GSoC projects > were just announced yesterday. > > You

Re: CVS commit: src/lib/librumpuser

2020-05-05 Thread Kamil Rytarowski
Ping? We are blocked by this in GSoC now. On 01.04.2020 20:19, Kamil Rytarowski wrote: > On 01.04.2020 17:06, Robert Elz wrote: >> Date:Wed, 1 Apr 2020 15:54:15 +0200 >> From:Kamil Rytarowski >> Message-ID: <969362d2-d93e-2cf4-7437-ab593ab11...@gmx.com> >> >> |

Re: CVS commit: src

2020-05-04 Thread Taylor R Campbell
> Module Name:src > Committed By: maxv > Date: Sat May 2 11:37:17 UTC 2020 > > Log Message: > Modify the hotpatch mechanism, in order to make it much less ROP-friendly. > > Currently x86_patch_window_open is a big problem, because it is a perfect > function to inject/modify

Re: CVS commit: src/usr.bin/rlogin

2020-05-03 Thread Christos Zoulas
In article <28236.1588524...@splode.eterna.com.au>, matthew green wrote: >"Christos Zoulas" writes: >> Module Name: src >> Committed By:christos >> Date:Sun May 3 16:32:16 UTC 2020 >> >> Modified Files: >> src/usr.bin/rlogin: rlogin.c >> >> Log Message: >>

re: CVS commit: src/usr.bin/rlogin

2020-05-03 Thread matthew green
"Christos Zoulas" writes: > Module Name: src > Committed By: christos > Date: Sun May 3 16:32:16 UTC 2020 > > Modified Files: > src/usr.bin/rlogin: rlogin.c > > Log Message: > PR/54435: Adjust for new kernel behavior of soreceive(9) clearing MSG_OOB > when receiving the oob

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread David Brownlee
On Sat, 2 May 2020, 20:10 Jason Thorpe, wrote: > > > On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > > > Hi, > > > > Have you missed this thread? > > > > If the problem requires more time to investigate, > > could you consider to revert ata change for a while? > > > > Thank you. > > I backed

Re: Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-02 Thread Jason Thorpe
> On May 1, 2020, at 1:07 PM, Ryo ONODERA wrote: > > Hi, > > Have you missed this thread? > > If the problem requires more time to investigate, > could you consider to revert ata change for a while? > > Thank you. I backed it out, but would appreciate some help tracking down the issue

Re: [sctp fix] Re: CVS commit: src/sys/kern

2020-05-02 Thread maya
On Fri, May 01, 2020 at 04:46:36PM +, m...@netbsd.org wrote: > We can setup an equivalence: put as much effort into the SCTP removal > proposal as there was for the SCTP introduction proposal. > > Since SCTP was just dropped in src without any prior discussion, I don't > think we need any

Freeze or panic during boot was: Re: CVS commit: src/sys/dev/ata

2020-05-01 Thread Ryo ONODERA
Hi, Have you missed this thread? If the problem requires more time to investigate, could you consider to revert ata change for a while? Thank you. Alexander Nasonov writes: > David Brownlee wrote: >> Just another data point - seeing this same panic on a T480 with the >> latest kernel from

Re: CVS commit: src/sys/dev/ata

2020-05-01 Thread David Brownlee
Plus to confirm reverting just this commit from today's github copy of current (d5b32e03eac8b05d38a143ee0ec615efb2233201) boots fine on the T480 Thanks On Thu, 30 Apr 2020 at 00:12, Alexander Nasonov wrote: > > David Brownlee wrote: > > Just another data point - seeing this same panic on a T480

Re: [sctp fix] Re: CVS commit: src/sys/kern

2020-05-01 Thread maya
We can setup an equivalence: put as much effort into the SCTP removal proposal as there was for the SCTP introduction proposal. Since SCTP was just dropped in src without any prior discussion, I don't think we need any discussion for removing it.

Re: CVS commit: src/sys

2020-05-01 Thread Tetsuya Isaki
At Fri, 01 May 2020 15:41:14 +1000, matthew green wrote: > > > .. I mean, if it's a "tuneable" value like this rather than a constant > > > like > > > __HAVE_SLOW_COMPUTER. :-) > > > > I see. I like this feeling. (not strong opinion too though) > > How about you, mrg@? > > works for me. i

re: CVS commit: src/sys

2020-04-30 Thread matthew green
> At Wed, 29 Apr 2020 21:59:59 +, > Andrew Doran wrote: > > > > How about this diff? > > > > The old platforms are the same as before, hppa, m68k, sh3, sparc(!64) > > > > and vax. > > > > > > machine/param.h seems more natural to me. I don't have a strong opinion > > > though. > > > > .. I

Re: CVS commit: src/sys

2020-04-30 Thread Tetsuya Isaki
At Wed, 29 Apr 2020 21:59:59 +, Andrew Doran wrote: > > > How about this diff? > > > The old platforms are the same as before, hppa, m68k, sh3, sparc(!64) > > > and vax. > > > > machine/param.h seems more natural to me. I don't have a strong opinion > > though. > > .. I mean, if it's a

re: CVS commit: src/doc

2020-04-30 Thread matthew green
> Modified Files: > src/doc: HACKS thank you for keeping this upto date. .mrg.

Re: CVS commit: src/sys/dev/ata

2020-04-29 Thread Alexander Nasonov
David Brownlee wrote: > Just another data point - seeing this same panic on a T480 with the > latest kernel from nyftp Same problem on T470. -- Alex

Re: CVS commit: src/sys

2020-04-29 Thread Andrew Doran
On Wed, Apr 29, 2020 at 09:58:55PM +, Andrew Doran wrote: > On Wed, Apr 29, 2020 at 02:32:39PM +0900, Tetsuya Isaki wrote: > > At Wed, 29 Apr 2020 12:22:01 +0900, > > > Tetsuya Isaki wrote: > > > > i would just put it in types.h called __AUDIO_BLK_MS, > > > > and leave a default used in the

Re: CVS commit: src/sys

2020-04-29 Thread Andrew Doran
On Wed, Apr 29, 2020 at 02:32:39PM +0900, Tetsuya Isaki wrote: > At Wed, 29 Apr 2020 12:22:01 +0900, > Tetsuya Isaki wrote: > > > i would just put it in types.h called __AUDIO_BLK_MS, > > > and leave a default used in the code if unset. > > It sounds nice. > > I commit once here, and then I will

Re: CVS commit: src/sys/dev/ata

2020-04-29 Thread David Brownlee
Just another data point - seeing this same panic on a T480 with the latest kernel from nyftp

Re: CVS commit: src/external/gpl3/gdb/lib/libgdb

2020-04-29 Thread Christos Zoulas
In article <20200429110459.0d9bcf...@cvs.netbsd.org>, Rin Okuyama wrote: >-=-=-=-=-=- > >Module Name: src >Committed By: rin >Date: Wed Apr 29 11:04:58 UTC 2020 > >Modified Files: > src/external/gpl3/gdb/lib/libgdb: Makefile > >Log Message: >PR toolchain/54820 >PR

Re: CVS commit: src/sys

2020-04-28 Thread Tetsuya Isaki
At Wed, 29 Apr 2020 12:22:01 +0900, Tetsuya Isaki wrote: > > i would just put it in types.h called __AUDIO_BLK_MS, > > and leave a default used in the code if unset. > It sounds nice. > I commit once here, and then I will try it. How about this diff? The old platforms are the same as before,

Re: CVS commit: src/sys

2020-04-28 Thread Tetsuya Isaki
At Tue, 28 Apr 2020 05:33:45 +1000, matthew green wrote: > i would just put it in types.h called __AUDIO_BLK_MS, > and leave a default used in the code if unset. It sounds nice. I commit once here, and then I will try it. Thanks, --- Tetsuya Isaki

Re: CVS commit: src/sys

2020-04-28 Thread Tetsuya Isaki
At Mon, 27 Apr 2020 15:58:01 +0200, Joerg Sonnenberger wrote: > > Then how about this? > > (thanks tsutsui@ for comment about choosing archs) > > This #ifdefs may not look elegance, but I think it's simple and > > realistic. > > I'd just move it the whole block into audio.c, but otherwise this

Re: [sctp fix] Re: CVS commit: src/sys/kern

2020-04-28 Thread Luke Mewburn
On 20-04-26 18:15, Maxime Villard wrote: | - There was no demonstrated use-case justifying importing it. In addition, |major OSes like Windows and macOS do not implement SCTP. There just is no |demand for SCTP on the market; and on NetBSD, proportionally even less. SCTP is used in

Re: CVS commit: src/sys/dev/ata

2020-04-27 Thread Ryo ONODERA
Ryo ONODERA writes: > Hi, > > After this commit, NetBSD/amd64-current on my HP Spectre x360 > freezes after acpiacad0 detection (before ld0 detection). > Reverting this commit in latest tree fixes my freeze problem. > > Could you take a look at my problem? > > Thank you. > > === === === > cpu7:

Re: CVS commit: src/sys

2020-04-27 Thread maya
On Tue, Apr 28, 2020 at 05:33:45AM +1000, matthew green wrote: > i would just put it in types.h called __AUDIO_BLK_MS, > and leave a default used in the code if unset. Adding: please consider making the default assume a fast machine. This is the value that will also be used by newly added

re: CVS commit: src/sys

2020-04-27 Thread matthew green
i would just put it in types.h called __AUDIO_BLK_MS, and leave a default used in the code if unset. .mrg.

Re: CVS commit: src/sys/external/bsd/drm2/dist/drm/radeon

2020-04-27 Thread Izumi Tsutsui
> Module Name: src > Committed By: tsutsui > Date: Mon Apr 27 16:57:31 UTC 2020 > > Modified Files: > src/sys/external/bsd/drm2/dist/drm/radeon: radeon_ttm.c > > Log Message: > Fix possible bus_dmamap_load(9) leak. PR/55127 > > "Looks good to me" from riastradh@. > Note it was

Re: CVS commit: src/sys/dev/ata

2020-04-27 Thread Ryo ONODERA
Hi, After this commit, NetBSD/amd64-current on my HP Spectre x360 freezes after acpiacad0 detection (before ld0 detection). Reverting this commit in latest tree fixes my freeze problem. Could you take a look at my problem? Thank you. === === === cpu7: CPU max freq 40 Hz cpu7: TSC freq

Re: CVS commit: src/sys

2020-04-27 Thread Joerg Sonnenberger
On Mon, Apr 27, 2020 at 06:19:18PM +0900, Tetsuya Isaki wrote: > As a result of some discussion here, adding 60+ one-line header > files like is troublesome or annoying. > And I have no good idea to generate a suitable border line from > existing parameters or something. > > Then how about this?

Re: CVS commit: src/sys

2020-04-27 Thread Tetsuya Isaki
As a result of some discussion here, adding 60+ one-line header files like is troublesome or annoying. And I have no good idea to generate a suitable border line from existing parameters or something. Then how about this? (thanks tsutsui@ for comment about choosing archs) This #ifdefs may not

Re: CVS commit: src/sys/netinet6

2020-04-27 Thread Thomas Klausner
On Fri, Apr 24, 2020 at 05:36:55PM +, Jonathan A. Kollasch wrote: > Module Name: src > Committed By: jakllsch > Date: Fri Apr 24 17:36:55 UTC 2020 > > Modified Files: > src/sys/netinet6: in6_proto.c > > Log Message: > Fill in .pr_usrreqs for SOCK_SEQPACKET and SOCK_STREAM

Re: CVS commit: src

2020-04-26 Thread Jason Thorpe
> On Apr 26, 2020, at 5:23 AM, Maxime Villard wrote: > > Because I modeled my tests after the ufetchstore and threadpool tests which > are > both in this directory and provide user access to kernel internals via > modules, > which is exactly what I'm doing. ..and those are there because,

Re: CVS commit: src/sys/uvm

2020-04-26 Thread Rin Okuyama
On 2020/04/27 11:47, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Mon Apr 27 02:47:26 UTC 2020 Modified Files: src/sys/uvm: uvm_extern.h Log Message: Add missing \ to fix build for PMAP_CACHE_VIVT, i.e., ARMv4 and prior. s/v4/v5/

Re: CVS commit: src/sys/kern

2020-04-26 Thread Jason Thorpe
> On Apr 26, 2020, at 2:04 PM, Michael van Elst wrote: > > Log Message: > fix DIAGNOSTIC build non-DIAGNOSTIC you mean? -- thorpej

[sctp fix] Re: CVS commit: src/sys/kern

2020-04-26 Thread Maxime Villard
Le 26/04/2020 à 16:21, Jonathan A. Kollasch a écrit : > Module Name: src > Committed By: jakllsch > Date: Sun Apr 26 14:21:14 UTC 2020 > > Modified Files: > src/sys/kern: uipc_socket.c > > Log Message: > Implement SCTP bug fixes found by maxv@. > > Adding these seems to improve

Re: CVS commit: src

2020-04-26 Thread Paul Goyette
On Sun, 26 Apr 2020, Maxime Villard wrote: Le 26/04/2020 à 14:05, Paul Goyette a écrit : Why are these files being placed in src/tests/modules? Because I modeled my tests after the ufetchstore and threadpool tests which are both in this directory and provide user access to kernel internals

Re: CVS commit: src

2020-04-26 Thread Maxime Villard
Le 26/04/2020 à 14:05, Paul Goyette a écrit : > Why are these files being placed in src/tests/modules? Because I modeled my tests after the ufetchstore and threadpool tests which are both in this directory and provide user access to kernel internals via modules, which is exactly what I'm doing.

Re: CVS commit: src

2020-04-26 Thread Paul Goyette
Why are these files being placed in src/tests/modules? That directory is supposed to contain tests of the module feature; it is not intended to place modules-that-support-tests-of-other- features. Can you please put these in src/tests/sys/ or somewhere more appropriate? On Sun, 26 Apr 2020,

Re: CVS commit: src/sys/rump

2020-04-25 Thread Manuel Bouyer
On Sat, Apr 25, 2020 at 08:49:14AM -0700, Jason Thorpe wrote: > Why were any of these files touched by Xen changes? listsrcdirs is expected, we need to add xen here (because we now need xen/intrdefs.h For others I don't know. Actually a cvs diff shows that only the $NetBSD: $ did change. --

Re: CVS commit: src/sys/rump

2020-04-25 Thread Jason Thorpe
Why were any of these files touched by Xen changes? > On Apr 25, 2020, at 8:42 AM, Manuel Bouyer wrote: > > Module Name: src > Committed By: bouyer > Date: Sat Apr 25 15:42:15 UTC 2020 > > Modified Files: > src/sys/rump: listsrcdirs > src/sys/rump/dev/lib/libumass:

Re: CVS commit: src/sys

2020-04-24 Thread Jason Thorpe
> On Apr 24, 2020, at 3:39 AM, Kamil Rytarowski wrote: > > This is a good idea (and preexisting in other kernels), unfortunately we > had locking issues in rust. If a multithreaded process is forked, we > shall create a replica of a calling thread and keep mutexes functional. > We tried to

Re: CVS commit: src/sys

2020-04-24 Thread Kamil Rytarowski
On 24.04.2020 05:22, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Fri Apr 24 03:22:06 UTC 2020 > > Modified Files: > src/sys/compat/linux/common: linux_exec.c linux_sched.c > src/sys/kern: kern_exec.c kern_exit.c kern_fork.c kern_lwp.c >

Re: CVS commit: src/tests/lib/libc/sys

2020-04-24 Thread Kamil Rytarowski
On 24.04.2020 05:25, Jason R Thorpe wrote: > Module Name: src > Committed By: thorpej > Date: Fri Apr 24 03:25:20 UTC 2020 > > Modified Files: > src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_x86_wait.h > > Log Message: > Update for new LWP behavior -- as of 9.99.59, the LWP ID

Re: CVS commit: src/sys/netinet6

2020-04-22 Thread Roy Marples
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 !=

Re: CVS commit: src

2020-04-22 Thread Jason Thorpe
> 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

Re: CVS commit: src

2020-04-22 Thread Kamil Rytarowski
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:

Re: CVS commit: src/sys/lib/libkern/arch/m68k

2020-04-22 Thread Rin Okuyama
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

Re: CVS commit: src/sys/modules/compat_netbsd32

2020-04-19 Thread Maxime Villard
I almost got a heart attack between your first email and your second one, wondering how this code got re-enabled. Thanks for clarifying. Relevant example, by the way. Committed on August 20th 2019 at 09:32 https://mail-index.netbsd.org/source-changes/2019/08/20/msg108321.html Disabled

Re: CVS commit: src/sys/modules/compat_netbsd32

2020-04-19 Thread maya
Good news everyone. Does not affect any release at all. Also might not have been a security issue, because christos did a weird thing where it is compiled but somehow still disabled. On Sun, Apr 19, 2020 at 05:40:50PM +, Maya Rashish wrote: > Module Name: src > Committed By: maya > Date:

Re: CVS commit: src/sys

2020-04-19 Thread Warner Losh
On Fri, Apr 17, 2020 at 9:02 AM Manuel Bouyer wrote: > On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > > >From:Manuel Bouyer > > >Message-ID:

Re: CVS commit: src/sys

2020-04-18 Thread Robert Elz
Date:Sat, 18 Apr 2020 10:29:33 + From:m...@netbsd.org Message-ID: <20200418102933.ga24...@homeworld.netbsd.org> | I feel like it's difficult to decide which is objectively better. It all depends upon usage patterns, and objectives. | CVS encourages you to

Re: CVS commit: src/sys

2020-04-18 Thread maya
On Fri, Apr 17, 2020 at 11:39:01PM +0700, Robert Elz wrote: > Date:Fri, 17 Apr 2020 07:52:53 -0700 > From:Jason Thorpe > Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com> > > | The New Hotness (which isn't particularly new, at this point) > | is to create

Re: CVS commit: src/include

2020-04-17 Thread Paul Goyette
On Fri, 17 Apr 2020, Kamil Rytarowski wrote: On 17.04.2020 22:22, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h

Re: CVS commit: src/include

2020-04-17 Thread Kamil Rytarowski
On 17.04.2020 22:22, Joerg Sonnenberger wrote: > On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: >> Module Name: src >> Committed By:kamil >> Date:Fri Apr 17 15:22:35 UTC 2020 >> >> Modified Files: >> src/include: assert.h >> >> Log Message: >> Remove

Re: CVS commit: src/include

2020-04-17 Thread Paul Goyette
On Fri, 17 Apr 2020, Joerg Sonnenberger wrote: On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: Module Name:src Committed By: kamil Date: Fri Apr 17 15:22:35 UTC 2020 Modified Files: src/include: assert.h Log Message: Remove the static_assert()

Re: CVS commit: src/include

2020-04-17 Thread Joerg Sonnenberger
On Fri, Apr 17, 2020 at 03:22:35PM +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Fri Apr 17 15:22:35 UTC 2020 > > Modified Files: > src/include: assert.h > > Log Message: > Remove the static_assert() fallback for pre-C11 and pre-C++11 > > C++

Re: CVS commit: src/sys

2020-04-17 Thread Robert Elz
Date:Fri, 17 Apr 2020 07:52:53 -0700 From:Jason Thorpe Message-ID: <7e54033f-9f14-4db3-a11a-01d63cd92...@me.com> | The New Hotness (which isn't particularly new, at this point) | is to create branches and merge what you want into that branch. What I don't

Re: CVS commit: src/sys

2020-04-17 Thread maya
On Fri, Apr 17, 2020 at 05:01:15PM +0200, Manuel Bouyer wrote: > On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > > >From:Manuel Bouyer > > >

Re: CVS commit: src/distrib/utils/libhack

2020-04-17 Thread Izumi Tsutsui
jdolecek@ wrote: > Module Name: src > Committed By: jdolecek > Date: Fri Apr 17 14:55:24 UTC 2020 > > Modified Files: > src/distrib/utils/libhack: Makefile.inc > > Log Message: > include aligned_alloc(3), now needed for newfs and fsck_ffs Could you consider to disable such extra

Re: CVS commit: src/sys

2020-04-17 Thread Manuel Bouyer
On Fri, Apr 17, 2020 at 07:52:53AM -0700, Jason Thorpe wrote: > > > On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > > > >Date:Fri, 17 Apr 2020 15:37:33 +0200 > >From:Manuel Bouyer > >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > > > | And that would be

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 7:46 AM, Robert Elz wrote: > >Date:Fri, 17 Apr 2020 15:37:33 +0200 >From:Manuel Bouyer >Message-ID: <20200417133733.ga5...@antioche.eu.org> > > | And that would be a problem for me. I regulary update a single file to a > | specific

Re: CVS commit: src/sys

2020-04-17 Thread Robert Elz
Date:Fri, 17 Apr 2020 15:37:33 +0200 From:Manuel Bouyer Message-ID: <20200417133733.ga5...@antioche.eu.org> | And that would be a problem for me. I regulary update a single file to a | specific revision in a source tree. Me too - I pull the current sh into

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 6:28 AM, Rin Okuyama wrote: > > On 2020/04/17 22:14, Jason Thorpe wrote: >>> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: >>> >>> For this, RCS and RCS semantics are irrelevant aren't they? >> No, not really. With the modern systems, the "commit ID" identifies the

Re: CVS commit: src/sys

2020-04-17 Thread Manuel Bouyer
On Fri, Apr 17, 2020 at 06:14:26AM -0700, Jason Thorpe wrote: > > > On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: > > > > For this, RCS and RCS semantics are irrelevant aren't they? > > No, not really. With the modern systems, the "commit ID" identifies the > state of the entire collection

Re: CVS commit: src/sys

2020-04-17 Thread Rin Okuyama
On 2020/04/17 22:14, Jason Thorpe wrote: On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: For this, RCS and RCS semantics are irrelevant aren't they? No, not really. With the modern systems, the "commit ID" identifies the state of the entire collection of files, not individual ones.

Re: CVS commit: src/sys

2020-04-17 Thread Jason Thorpe
> On Apr 17, 2020, at 12:24 AM, Robert Elz wrote: > > For this, RCS and RCS semantics are irrelevant aren't they? No, not really. With the modern systems, the "commit ID" identifies the state of the entire collection of files, not individual ones. Thus, you only need exactly one instance

Re: CVS commit: src/sys

2020-04-17 Thread Robert Elz
Date:Thu, 16 Apr 2020 18:04:04 -0700 From:Jason Thorpe Message-ID: <432f538a-b863-441b-b4d0-0cd2e9d38...@me.com> | The sooner we get off of "things that use RCS semantics" the better. For this, RCS and RCS semantics are irrelevant aren't they? The only relevance

Re: CVS commit: src/sys

2020-04-16 Thread Jason Thorpe
> On Apr 16, 2020, at 5:51 PM, Joerg Sonnenberger wrote: > > > That can be fixed generically? .ident needs the SHF_MERGE|SHF_STRINGS as > section flags and then the linker should do the rest by itself. Does it matter? The sooner we get off of "things that use RCS semantics" the better. --

Re: CVS commit: src/sys

2020-04-16 Thread Joerg Sonnenberger
On Fri, Apr 17, 2020 at 07:31:51AM +0900, Rin Okuyama wrote: > On 2020/04/17 6:56, Rin Okuyama wrote: > > Module Name:src > > Committed By: rin > > Date: Thu Apr 16 21:56:43 UTC 2020 > > > > Modified Files: > > src/sys/arch/arm/omap: omap3_sdmareg.h omap3_sdmavar.h

Re: CVS commit: src/sys

2020-04-16 Thread Rin Okuyama
On 2020/04/17 6:56, Rin Okuyama wrote: Module Name:src Committed By: rin Date: Thu Apr 16 21:56:43 UTC 2020 Modified Files: src/sys/arch/arm/omap: omap3_sdmareg.h omap3_sdmavar.h omapfbreg.h src/sys/arch/arm/ti: omap3_dssreg.h src/sys/arch/macppc/dev:

Re: CVS commit: src/sys/arch/xen/xen

2020-04-13 Thread Manuel Bouyer
On Mon, Apr 13, 2020 at 08:09:13PM +, Jaromir Dolecek wrote: > Module Name: src > Committed By: jdolecek > Date: Mon Apr 13 20:09:13 UTC 2020 > > Modified Files: > src/sys/arch/xen/xen: xbd_xenbus.c > > Log Message: > KASSERT() that requested I/O size is <= XBD_MAX_XFER - this

Re: CVS commit: src/sys/kern

2020-04-13 Thread Andrew Doran
On Mon, Apr 13, 2020 at 04:34:48PM +0100, Roy Marples wrote: > On 13/04/2020 16:31, Andrew Doran wrote: > > Hi Roy. > > > > On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote: > > > On 10/04/2020 23:34, Andrew Doran wrote: > > > > Module Name:src > > > > Committed By: ad > > > >

Re: CVS commit: src/sys/kern

2020-04-13 Thread Roy Marples
On 13/04/2020 16:31, Andrew Doran wrote: Hi Roy. On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote: On 10/04/2020 23:34, Andrew Doran wrote: Module Name:src Committed By: ad Date: Fri Apr 10 22:34:36 UTC 2020 Modified Files: src/sys/kern: vfs_mount.c Log

Re: CVS commit: src/sys/kern

2020-04-13 Thread Andrew Doran
Hi Roy. On Sat, Apr 11, 2020 at 02:13:06AM +0100, Roy Marples wrote: > On 10/04/2020 23:34, Andrew Doran wrote: > > Module Name:src > > Committed By: ad > > Date: Fri Apr 10 22:34:36 UTC 2020 > > > > Modified Files: > > src/sys/kern: vfs_mount.c > > > > Log

Re: CVS commit: src/sys/netinet6

2020-04-12 Thread Robert Elz
Now that's a simpler fix than I imagined it would be... kre

Re: CVS commit: src/sys

2020-04-11 Thread Tetsuya Isaki
At Thu, 9 Apr 2020 16:54:12 +0200, Joerg Sonnenberger wrote: > There are two possible reasons for a lower limit for the buffer size: > (1) The device requires a certain amount. > (2) The system wants to ensure the interrupt rate doesn't go over a > certain rate. > > The real value shouldn't be a

Re: CVS commit: src/sys/kern

2020-04-10 Thread Roy Marples
On 10/04/2020 23:34, Andrew Doran wrote: Module Name:src Committed By: ad Date: Fri Apr 10 22:34:36 UTC 2020 Modified Files: src/sys/kern: vfs_mount.c Log Message: vfs_mountroot(): don't needlessly grab a second reference to the root vnode (the kernel never chdirs) nor

Re: CVS commit: src/share/man/man4

2020-04-10 Thread maya
On Fri, Apr 10, 2020 at 07:16:24AM -0700, Jason Thorpe wrote: > > > On Apr 10, 2020, at 4:44 AM, m...@netbsd.org wrote: > > > > I had to stop using m_defrag because implementation details broke > > bwfm@pci. It can only handle a chain of length 1, and m_defrag gives > > a minimum of 2. > >

<    11   12   13   14   15   16   17   18   19   20   >