"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jun 6 21:26:00 UTC 2020
>
> Modified Files:
> src/lib/libprop: Makefile shlib_version
i wonder, since this adds to the kernel ABI, you should have
also bumped the kernel version, since modules using
On Sat, Jun 06, 2020 at 06:11:21PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jun 6 18:11:21 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_lwp_create.c
>
> Log Message:
> Add a test case to ensure that _lwp_create() fails with
On Thu, Jun 04, 2020 at 09:28:09PM +, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 06:26:07PM +, Martin Husemann wrote:
>
> > On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Wed Jun 3 22:10:24
In article <20200606135850.ge14...@pony.stderr.spb.ru>,
Valery Ushakov wrote:
>On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
>
>> On 06.06.2020 09:42, Simon Burge wrote:
>> > "Kamil Rytarowski" wrote:
>> >
>> >> Module Name: src
>> >> Committed By: kamil
>> >> Date:
On Sat, Jun 06, 2020 at 11:25:19 +0200, Kamil Rytarowski wrote:
> On 06.06.2020 09:42, Simon Burge wrote:
> > "Kamil Rytarowski" wrote:
> >
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Fri Jun 5 21:48:04 UTC 2020
> >>
> >> Modified Files:
> >>
> >>
On 06.06.2020 09:42, Simon Burge wrote:
> "Kamil Rytarowski" wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Jun 5 21:48:04 UTC 2020
>>
>> Modified Files:
>>
>> src/sys/arch/x86/x86: cpu_rng.c
>>
>> Log Message:
>>
>> Change const unsigned to
"Kamil Rytarowski" wrote:
> Module Name: src
> Committed By: kamil
> Date: Fri Jun 5 21:48:04 UTC 2020
>
> Modified Files:
>
> src/sys/arch/x86/x86: cpu_rng.c
>
> Log Message:
>
> Change const unsigned to preprocessor define
>
> Fixes GCC -O0 build with the stack protector.
In article ,
Kamil Rytarowski wrote:
>On 09.05.2017 13:14, Robert Elz wrote:
>> Module Name: src
>> Committed By:kre
>> Date:Tue May 9 11:14:16 UTC 2017
>>
>> Modified Files:
>> src/distrib/sets/lists/base: shl.mi
>> src/distrib/sets/lists/comp: mi
>>
Date:Fri, 5 Jun 2020 04:19:09 +0200
From:Kamil Rytarowski
Message-ID: <99440f2e-c0fc-5e47-4f8b-137bdf5a3...@netbsd.org>
| I can see the problem now. It's a fault in ksh(1).
Whether this actually amounts to being called a "fault" or not is
not so clear ... most
On 05.06.2020 04:06, Robert Elz wrote:
> Date:Fri, 5 Jun 2020 01:50:47 +0200
> From:Kamil Rytarowski
> Message-ID:
>
> | What happened to RT signal names?
> |
> | I'm not sure what's wrong as this code works under a debugger.
>
> No idea right now, but I will
Date:Fri, 5 Jun 2020 01:50:47 +0200
From:Kamil Rytarowski
Message-ID:
| What happened to RT signal names?
|
| I'm not sure what's wrong as this code works under a debugger.
No idea right now, but I will take a look.
Which shell are you using for that? And
On 09.05.2017 13:14, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Tue May 9 11:14:16 UTC 2017
>
> Modified Files:
> src/distrib/sets/lists/base: shl.mi
> src/distrib/sets/lists/comp: mi
> src/distrib/sets/lists/debug: shl.mi
> src/include:
On 04.06.2020 23:41, Andrew Doran wrote:
> On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
>
>> On 04.06.2020 00:42, Andrew Doran wrote:
>>> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>>>
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly
On Thu, Jun 04, 2020 at 02:35:17AM +0200, Kamil Rytarowski wrote:
> On 04.06.2020 00:42, Andrew Doran wrote:
> > On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> >
> >> On 03.06.2020 01:49, Andrew Doran wrote:
> >>> On the assembly thing recall that recently you expressed a
Hi,
On Thu, Jun 04, 2020 at 06:26:07PM +, Martin Husemann wrote:
> On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Wed Jun 3 22:10:24 UTC 2020
> >
> > Modified Files:
> > src/lib/libpthread:
On Wed, Jun 03, 2020 at 10:10:24PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Wed Jun 3 22:10:24 UTC 2020
>
> Modified Files:
> src/lib/libpthread: pthread.c pthread_cond.c pthread_mutex.c
>
> Log Message:
> Deal with a couple of problems with
On 04.06.2020 00:42, Andrew Doran wrote:
> On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
>
>> On 03.06.2020 01:49, Andrew Doran wrote:
>>> On the assembly thing recall that recently you expressed a desire to remove
>>> all of the amd64 assembly string functions from libc
Maxime,
I read your e-mail carefully and conclude that the best way forward here is
put this one to core@ for a technical decision.
Cheers,
Andrew
On Wed, Jun 03, 2020 at 08:25:32AM +0200, Maxime Villard wrote:
> Le 03/06/2020 ? 01:49, Andrew Doran a ?crit?:
> > On Tue, Jun 02, 2020 at
On Wed, Jun 03, 2020 at 02:03:22AM +0200, Kamil Rytarowski wrote:
> On 03.06.2020 01:49, Andrew Doran wrote:
> > On the assembly thing recall that recently you expressed a desire to remove
> > all of the amd64 assembly string functions from libc because of sanitizers -
> > I invested my time to
Le 03/06/2020 à 02:03, Kamil Rytarowski a écrit :
On 03.06.2020 01:49, Andrew Doran wrote:
On the assembly thing recall that recently you expressed a desire to remove
all of the amd64 assembly string functions from libc because of sanitizers -
I invested my time to do up a little demo to try
Le 03/06/2020 à 01:49, Andrew Doran a écrit :
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64:
Well, you can't have it both ways.
Sent from Nine
From: Valery Ushakov
Sent: Tuesday, 2 June 2020 22:26
To: source-changes-d@NetBSD.org
Cc: Roy Marples; Martin Husemann
Subject: Re: CVS commit: src/distrib/sets/lists/base
On Tue, Jun 02, 2020 at 19:15:15 +
On 03.06.2020 01:49, Andrew Doran wrote:
> On the assembly thing recall that recently you expressed a desire to remove
> all of the amd64 assembly string functions from libc because of sanitizers -
> I invested my time to do up a little demo to try and show you why that's not
> a good idea:
>
>
On Tue, Jun 02, 2020 at 08:41:53AM +0200, Maxime Villard wrote:
> Le 02/06/2020 ? 00:58, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Jun 1 22:58:06 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/amd64/amd64: cpufunc.S
> >
On Tue, Jun 02, 2020 at 19:15:15 +, Roy Marples wrote:
> Module Name: src
> Committed By: roy
> Date: Tue Jun 2 19:15:15 UTC 2020
>
> Modified Files:
> src/distrib/sets/lists/base: mi
>
> Log Message:
> dhcpcd: delete the obsolete chroot paths
>
> postinstall will take care
On 2020/06/02 17:03, matthew green wrote:
Module Name:src
Committed By: mrg
Date: Tue Jun 2 08:03:59 UTC 2020
Modified Files:
src/external/gpl3/gcc: gcc2netbsd
Log Message:
don't elide fortran components. we'd like to revive g77-as-gfortran.
To generate a diff of
Le 02/06/2020 à 00:58, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Mon Jun 1 22:58:06 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/amd64/include: frameasm.h
Log Message:
Reported-by:
On 2020/06/02 2:08, Joerg Sonnenberger wrote:
On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun May 31 23:24:20 UTC 2020
Modified Files:
src/sys/kern: kern_timeout.c
Log Message:
Stop allocating buffers dynamically
On Sun, May 31, 2020 at 11:24:20PM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May 31 23:24:20 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_timeout.c
>
> Log Message:
> Stop allocating buffers dynamically in a DDB session, in order not to
>
> This feels not good.
> strncpy->strlcpy has repercussions like how strlcpy doesn't zero out the
> remaining length and thus leaks uninitialized data.
>
> There has to be a reasonable way to handle these warnings instead of
> rototilling which str*cpy function is used.
Please read the code
On Sun, May 31, 2020 at 07:24:24PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun May 31 23:24:24 UTC 2020
>
> Modified Files:
> src/lib/libedit: terminal.c tty.c
>
> Log Message:
> use strlcpy() instead of strncpy() for gcc happiness
>
...
Le 01/06/2020 à 03:23, Shoichi Yamaguchi a écrit :
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
I modified virtio(4) not to allocate unused memory.
I guess it fixes the issue.
Could you check this?
I confirmed your closing the report on syzbot.
Hi,
On Wed, May 27, 2020 at 8:47 PM Shoichi Yamaguchi wrote:
>
> I modified virtio(4) not to allocate unused memory.
> I guess it fixes the issue.
>
> Could you check this?
I confirmed your closing the report on syzbot.
On 2020/06/01 9:36, Kamil Rytarowski wrote:
If you can find a use-case today in DDB for an exclusive allocator. I
have it ready and tested.
I intended to use it in ddb for one project, but that project is still
unfinished.
Good to know! I will ask you when I want it!
Thanks,
rin
On 01.06.2020 02:31, Rin Okuyama wrote:
> On 2020/06/01 9:23, Kamil Rytarowski wrote:
>> I wrote a tiny malloc (libc-style) implementation over a small static
>> storage (could be over stack or preallocated on the heap) without any
>> external dependencies.
>>
>> Would it be useful for you?
>
>
On 2020/06/01 9:23, Kamil Rytarowski wrote:
I wrote a tiny malloc (libc-style) implementation over a small static
storage (could be over stack or preallocated on the heap) without any
external dependencies.
Would it be useful for you?
At the moment, we need buffers only in db_show_callout(),
I wrote a tiny malloc (libc-style) implementation over a small static
storage (could be over stack or preallocated on the heap) without any
external dependencies.
Would it be useful for you?
On 01.06.2020 01:34, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun May
"Rin Okuyama" writes:
> Module Name: src
> Committed By: rin
> Date: Sun May 31 08:33:48 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_timeout.c
>
> Log Message:
> db_show_callout(): struct callout_cpu and cpu_info are too much for stack.
>
> XXX
> DDB can be running in the
> On May 31, 2020, at 1:33 AM, Rin Okuyama wrote:
>
> db_show_callout(): struct callout_cpu and cpu_info are too much for stack.
>
> XXX
> DDB can be running in the interrupt context, e.g., when activated from
> console. Therefore, use kmem_intr_alloc(9) instead of kmem_alloc(9).
>
> Frame
On Sat, May 30, 2020 at 04:48:00PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat May 30 20:47:59 UTC 2020
>
> Modified Files:
> src/distrib/sets/lists/base: mi shl.mi
> src/distrib/sets/lists/comp: mi shl.mi
>
Jaromir Dolecek wrote:
> Index: src/sys/dev/ic/bwfmvar.h
> diff -u src/sys/dev/ic/bwfmvar.h:1.9 src/sys/dev/ic/bwfmvar.h:1.10
> --- src/sys/dev/ic/bwfmvar.h:1.9 Sat May 30 13:41:58 2020
> +++ src/sys/dev/ic/bwfmvar.h Sat May 30 15:55:47 2020
> @@ -1,4 +1,4 @@
> -/* $NetBSD: bwfmvar.h,v 1.9
On Sat, May 30, 2020 at 09:48:36PM +0900, Tetsuya Isaki wrote:
> I will do it on next weekend.
>
> Thanks,
> ---
> Tetsuya Isaki
Thank you.
At Fri, 29 May 2020 12:32:39 +,
nia wrote:
> OK... Can you request a pullup to ensure resuming with a stream
> playing doesn't panic on 9.1?
I will do it on next weekend.
Thanks,
---
Tetsuya Isaki
> Makefile.installimage refers to it before including Makefile.bootimage and
> this test was causing make to throw an error:
>
>
> https://nxr.netbsd.org/xref/src/distrib/common/bootimage/Makefile.installimage#41
>
> All other users (i386, amd64) of Makefile.installimage explicitly set
>
On Fri, 29 May 2020, Izumi Tsutsui wrote:
src/distrib/common/bootimage/Makefile.bootimage (included from
Makefile.installimage) already has "USE_MBR?= no" line.
Makefile.installimage refers to it before including Makefile.bootimage and
this test was causing make to throw an error:
On 29.05.2020 16:15, Tobias Nygren wrote:
> On Fri, 29 May 2020 16:08:30 +0200
> Joerg Sonnenberger wrote:
>
>> On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Fri May 29 10:53:02 UTC 2020
>>>
>>>
On Fri, 29 May 2020 16:08:30 +0200
Joerg Sonnenberger wrote:
> On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
> > Module Name:src
> > Committed By: kamil
> > Date: Fri May 29 10:53:02 UTC 2020
> >
> > Modified Files:
> >
On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Fri May 29 10:53:02 UTC 2020
>
> Modified Files:
> src/external/bsd/ntp/bin/ntpd: Makefile
>
> Log Message:
> Fix the ntpd build with Clang/LLVM
>
> Set
OK... Can you request a pullup to ensure resuming with a stream
playing doesn't panic on 9.1?
Playing audio is very distorted on resume, but that can be resolved
by killing the streams...
Le 28/05/2020 à 23:58, Andrew Doran a écrit :
On Thu, May 28, 2020 at 07:06:04PM +0200, Maxime Villard wrote:
Le 27/05/2020 ? 21:58, Maxime Villard a ?crit?:
Le 27/05/2020 ? 21:33, Andrew Doran a ?crit?:
Module Name:??? src
Committed By:??? ad
Date:??? Wed May 27 19:33:40 UTC 2020
At Wed, 27 May 2020 13:19:22 +,
nia wrote:
> I think this is because audio_rmixer_start is used unguarded
> in audio_open (it doesn't check for the sc_rbusy flag).
> This isn't the case for pmixer.
>
> So, if the audio device is opened for recording for the
> first time after system
> Modified Files:
> src/distrib/common/bootimage: Makefile.installimage
>
> Log Message:
> Default USE_MBR to no
Is this necessary?
src/distrib/common/bootimage/Makefile.bootimage (included from
Makefile.installimage) already has "USE_MBR?= no" line.
---
Izumi Tsutsui
On Thu, May 28, 2020 at 07:06:04PM +0200, Maxime Villard wrote:
> Le 27/05/2020 ? 21:58, Maxime Villard a ?crit?:
> > Le 27/05/2020 ? 21:33, Andrew Doran a ?crit?:
> > > Module Name:??? src
> > > Committed By:??? ad
> > > Date:??? Wed May 27 19:33:40 UTC 2020
> > >
> > > Modified Files:
> > >
Le 28/05/2020 à 19:06, Maxime Villard a écrit :
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
Le 27/05/2020 à 21:58, Maxime Villard a écrit :
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name: src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
Le 27/05/2020 à 21:33, Andrew Doran a écrit :
Module Name:src
Committed By: ad
Date: Wed May 27 19:33:40 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S locore.S
src/sys/arch/i386/i386: cpufunc.S locore.S
src/sys/arch/x86/include: pmap.h
On Wed, 27 May 2020, Taylor R Campbell wrote:
Not really, because we just need to know whether usb_once_init has
been run.
OK, great!
Now, should we use something other than RUN_ONCE, which can both set
up and tear down? Sure, that might be better in principle, but there
probably aren't
> Date: Wed, 27 May 2020 05:28:41 -0700 (PDT)
> From: Paul Goyette
>
> Do you also need to decrement the number of busses when one is
> detached?
Not really, because we just need to know whether usb_once_init has
been run.
Now, should we use something other than RUN_ONCE, which can both set
up
On Wed, May 27, 2020 at 09:46:04PM +0900, Tetsuya Isaki wrote:
> Why are playback and recording asymmetric?
>
> Thanks,
I think this is because audio_rmixer_start is used unguarded
in audio_open (it doesn't check for the sc_rbusy flag).
This isn't the case for pmixer.
So, if the audio device
nia,
At Tue, 26 May 2020 15:20:16 +,
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Tue May 26 15:20:16 UTC 2020
>
> Modified Files:
> src/sys/dev/audio: audio.c
>
> Log Message:
> audio: Only restart recording mixer on resume if it's already been started
>
Do you also need to decrement the number of busses when one is
detached?
On Wed, 27 May 2020, Nick Hudson wrote:
Module Name:src
Committed By: skrll
Date: Wed May 27 07:17:45 UTC 2020
Modified Files:
src/sys/dev/usb: usb.c
Log Message:
Don't allow open of /dev/usb if
Hi,
On Wed, May 27, 2020 at 2:20 AM Maxime Villard wrote:
>
> Hi,
> I don't know if this is related to your changes, but kMSan detected one uninit
> variable in virtio 3h ago:
>
> https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610
>
> [ 153.4370851] panic: MSan:
Hi,
I don't know if this is related to your changes, but kMSan detected one uninit
variable in virtio 3h ago:
https://syzkaller.appspot.com/text?tag=CrashReport=12084ef610
[ 153.4370851] panic: MSan: Uninitialized Kmem Memory From
virtio_pci_setup_interrupts()
[
>> Has any consideration be given to perhaps creating a new MACHINE_ARCH for
>> this, or somehow otherwise decorating the ELF files to indicate their
>> exec-ability?
>
>I am under the impression that PAC was designed to be forewards
>compatible, so older CPUs can execute code with this
On Sat, May 23, 2020 at 02:13:46PM -0700, Jason Thorpe wrote:
>
> > On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
> >
> > Module Name:src
> > Committed By: ryo
> > Date: Sat May 23 18:08:59 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/aarch64/aarch64:
> On May 23, 2020, at 11:08 AM, Ryo Shimizu wrote:
>
> Module Name: src
> Committed By: ryo
> Date: Sat May 23 18:08:59 UTC 2020
>
> Modified Files:
> src/sys/arch/aarch64/aarch64: cpufunc.c cpuswitch.S exec_machdep.c
> genassym.cf netbsd32_machdep.c vectors.S
On Thu, May 21, 2020 at 11:19:49PM +0200, Joerg Sonnenberger wrote:
> On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Thu May 21 21:12:31 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/x86/acpi:
On Thu, May 21, 2020 at 09:12:31PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Thu May 21 21:12:31 UTC 2020
>
> Modified Files:
> src/sys/arch/x86/acpi: acpi_wakeup.c
> src/sys/arch/x86/include: i82489var.h
> src/sys/arch/x86/x86: cpu.c
On 20/05/2020 21:18, Sevan Janiyan wrote:
> Bump rcs tag which was missed in r1.9
That should've been r1.10
Sevan
Module Name:src
Committed By: christos
Date: Sat May 16 18:31:54 UTC 2020
Modified Files:
[...]
Log Message:
Add ACL support for FFS. From FreeBSD.
This broke compilation on LLVM.
https://syzkaller.appspot.com/text?tag=CrashReport=153178f610
Please fix
Module Name:src
Committed By: ad
Date: Tue May 19 21:40:55 UTC 2020
Modified Files:
src/sys/arch/amd64/amd64: cpufunc.S
src/sys/arch/i386/i386: cpufunc.S i386func.S
Log Message:
Make cpu_counter(), cpu_counter32() and tsc_get_timecount() into a single
On Tue, May 19, 2020 at 11:09:07PM +, Andrew Doran wrote:
> vnode locks are not held during getpages/putpages.
^ for fault handling, anyway. for read/write they are held by the caller to
ubc_uiomove().
Andrew
On Sun, May 17, 2020 at 11:49:52PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> > On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > > Module Name: src
> > > Committed By: ad
> > > Date: Sun May 17 19:39:15
Unfortunately this breaks building on a 9.0 arm64 host because it is
picking up /usr/include/aarch64/armreg.h and the one in 9.0 is missing a
bunch of stuff. It works when using armreg.h from the source tree instead,
eg:
-#include
+#include "/path/to/src/sys/arch/aarch64/include/armreg.h"
On Sun, May 17, 2020 at 09:47:50PM +, m...@netbsd.org wrote:
> On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> > Module Name:src
> > Committed By: ad
> > Date: Sun May 17 19:39:15 UTC 2020
> >
> > Modified Files:
> > src/sys/fs/tmpfs: tmpfs.h
On Sun, May 17, 2020 at 07:39:15PM +, Andrew Doran wrote:
> Module Name: src
> Committed By: ad
> Date: Sun May 17 19:39:15 UTC 2020
>
> Modified Files:
> src/sys/fs/tmpfs: tmpfs.h tmpfs_subr.c tmpfs_vnops.c
>
> Log Message:
> PR kern/55268: tmpfs is slow
>
>
I will test this with ASan and report back!
On 16.05.2020 16:15, Christos Zoulas wrote:
> That is a completely different issue here. There are no linker tricks.
> We want the module loader to include all the symbols any module
> can require, this is why we load all the libraries.
>
> While it is
That is a completely different issue here. There are no linker tricks.
We want the module loader to include all the symbols any module
can require, this is why we load all the libraries.
While it is questionable if nofifofs is part of the base system or not,
this is the way it was before. Anyway
On 16.05.2020 14:54, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat May 16 12:54:27 UTC 2020
>
> Modified Files:
> src/tests/rump/modautoload: Makefile
>
> Log Message:
> Do the same thing with linker flags instead of directly specifying the
>
On Sat, May 16, 2020 at 02:51:43PM +1000, matthew green wrote:
> "Jaromir Dolecek" writes:
> > Module Name:src
> > Committed By: jdolecek
> > Date: Fri May 15 07:42:58 UTC 2020
> >
> > Modified Files:
> > src/sys/arch/xen/include: intr.h
> >
"Jaromir Dolecek" writes:
> Module Name: src
> Committed By: jdolecek
> Date: Fri May 15 07:42:58 UTC 2020
>
> Modified Files:
> src/sys/arch/xen/include: intr.h
> src/sys/arch/xen/x86: pintr.c
>
> Log Message:
> use short for irq2port[] to save memory (4KB), it only needs
In article <20200515123104.297c5f...@cvs.netbsd.org>,
Emmanuel Dreyfus wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: manu
>Date: Fri May 15 12:31:04 UTC 2020
>
>Modified Files:
> src/external/mpl/dhcp/dist/common: bpf.c discover.c lpf.c packet.c
> raw.c
On 15.05.2020 00:43, Taylor R Campbell wrote:
>> Date: Thu, 14 May 2020 23:36:28 +0200
>> From: Kamil Rytarowski
>>
>> If a signal would not reach the child process (as it is ignored or
>> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
>> checked, it's the design in UNIX to
> Date: Thu, 14 May 2020 23:36:28 +0200
> From: Kamil Rytarowski
>
> If a signal would not reach the child process (as it is ignored or
> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
> Race free
On Thu, May 14, 2020 at 11:36:28PM +0200, Kamil Rytarowski wrote:
> On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Thu May 14 19:21:35 UTC 2020
>
On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu May 14 19:21:35 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>>
>>
On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Thu May 14 19:21:35 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>
> Log Message:
> Ignore interception of the SIGCHLD signals.
>
>
In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>,
Roy Marples wrote:
>On 10/05/2020 18:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May 10 17:58:16 UTC 2020
>>
>> Modified Files:
>>
On 10/05/2020 18:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun May 10 17:58:16 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcpcd.c
Log Message:
Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.
Why?
On Tue, May 12, 2020 at 10:51:51AM +0200, Kamil Rytarowski wrote:
> On 12.05.2020 02:59, Joerg Sonnenberger wrote:
> > On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote:
> >> On 19.04.2020 03:06, Joerg Sonnenberger wrote:
> >>> Module Name: src
> >>> Committed By: joerg
>
On Sun, May 10, 2020 at 03:15:22PM -, Christos Zoulas wrote:
> 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:
> >
On 12.05.2020 02:59, Joerg Sonnenberger wrote:
> On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote:
>> On 19.04.2020 03:06, Joerg Sonnenberger wrote:
>>> Module Name:src
>>> Committed By: joerg
>>> Date: Sun Apr 19 01:06:16 UTC 2020
>>>
>>> Modified
On Mon, May 11, 2020 at 11:07:02PM +0200, Kamil Rytarowski wrote:
> On 19.04.2020 03:06, Joerg Sonnenberger wrote:
> > Module Name:src
> > Committed By: joerg
> > Date: Sun Apr 19 01:06:16 UTC 2020
> >
> > Modified Files:
> > src/lib/libc/gen: pthread_atfork.c
> >
On 19.04.2020 03:06, Joerg Sonnenberger wrote:
> Module Name: src
> Committed By: joerg
> Date: Sun Apr 19 01:06:16 UTC 2020
>
> Modified Files:
> src/lib/libc/gen: pthread_atfork.c
> src/libexec/ld.elf_so: rtld.c rtld.h symbols.map
>
> Log Message:
> Rename __atomic_fork to
On Sun, May 10, 2020 at 11:53:00PM +0100, Alexander Nasonov wrote:
> 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
Date:Mon, 11 May 2020 13:47:45 +0200
From:Kamil Rytarowski
Message-ID: <54178983-82d1-df3d-fd54-549a6c73f...@gmx.com>
| The only purpose of the test is to check whether misaligned program
| counter can crash the kernel (it can for NetBSD/sparc). Later, if a
|
On 11.05.2020 13:35, Robert Elz wrote:
> Date:Mon, 11 May 2020 11:03:15 +
> From:"Kamil Rytarowski"
> Message-ID: <2020050315.54b13f...@cvs.netbsd.org>
>
> | Do not fail when trying to kill a dying process
> |
> | A dying process can disappear for a
Date:Mon, 11 May 2020 11:03:15 +
From:"Kamil Rytarowski"
Message-ID: <2020050315.54b13f...@cvs.netbsd.org>
| Do not fail when trying to kill a dying process
|
| A dying process can disappear for a while. Rather than aborting, retry
| sending SIGKILL
Taylor R Campbell wrote:
> This sounds entirely reasonable. Would you like to draft an
> implementation of that?
Sure, I can look into this on the weekend.
> Presumably it would require writing a sysctl callback function for
> vm.swap_encrypt, and would somehow involve kauth, but I'm not sure
>
On Sun, May 10, 2020 at 04:18:54PM +0200, Yorick Hardy wrote:
> I think it may be better in the Makefile, since the test for amd64 already
> happens there and because the libi386 directory could conceivably
> also contain i386/non-amd64 tests.
>
> I successfully completed a build with
1401 - 1500 of 11274 matches
Mail list logo
