Hmm, I was still confused.
On 2025/04/10 11:08, Rin Okuyama wrote:
On 2025/04/09 14:38, Rin Okuyama wrote:
Module Name: src
Committed By: rin
Date: Wed Apr 9 05:38:01 UTC 2025
Modified Files:
src/sys/kern: subr_log.c
Log Message:
logread: Stop reading msgbuf without log_lock
On 2025/04/09 14:38, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Apr 9 05:38:01 UTC 2025
Modified Files:
src/sys/kern: subr_log.c
Log Message:
logread: Stop reading msgbuf without log_lock being held
Oops, sorry, here I made typo; s/reading/writing/
On Thu, 20 Mar 2025, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Thu Mar 20 15:04:55 UTC 2025
Modified Files:
src/sys/kern: kern_module.c
Log Message:
One more debug message to different manual vs auto unload
differentiate --^
thanks, I will take a look!
christos
> On Dec 16, 2024, at 5:26 AM, J. Hannken-Illjes wrote:
>
>
>>
>> On 15. Dec 2024, at 18:42, Christos Zoulas wrote:
>>
>> Module Name: src
>> Committed By: christos
>> Date: Sun Dec 15 17:42:34 UTC 2024
>>
>> Modified Files:
>> src/sys/kern: sys_ptrace
> On 15. Dec 2024, at 18:42, Christos Zoulas wrote:
>
> Module Name: src
> Committed By: christos
> Date: Sun Dec 15 17:42:34 UTC 2024
>
> Modified Files:
> src/sys/kern: sys_ptrace_common.c
>
> Log Message:
> PR/58896: Martin Husemann: PT_KILL will not deliver a kill signal to a stopped
> proc
Date:Sun, 10 Nov 2024 09:35:29 +
From:Taylor R Campbell
Message-ID: <20241110093534.e816384...@mail.netbsd.org>
| Yikes! Do you have a reproducer handy for this?
Yes, it turns out to be trivially easy to do, once the
bug is understood - just very rare to actua
> Module Name:src
> Committed By: kre
> Date: Sun Nov 10 00:11:43 UTC 2024
>
> Modified Files:
> src/sys/kern: kern_descrip.c
>
> Log Message:
> Make O_CLOEXEC always close specified files on exec
>
> It turns out that close-on-exec doesn't always close on exec.
Yikes!
On Sat, 5 Oct 2024, Michael van Elst wrote:
Module Name:src
Committed By: mlelstv
Date: Sat Oct 5 18:04:53 UTC 2024
Modified Files:
src/sys/kern: syscalls.master
Log Message:
New syscall requires SYSVSEM build option.
Seems to me that the new syscall should be part o
> Module Name:src
> Committed By: mrg
> Date: Thu Jul 4 05:59:05 UTC 2024
>
> Modified Files:
> src/sys/kern: vfs_syscalls.c
>
> Log Message:
> don't fd_putfile() if you haven't grabbed a ref already.
>
> the condition to call fd_getvnode() was changed, but the condition
> Date: Fri, 13 Oct 2023 17:52:07 +0900
> From: Rin Okuyama
>
> It would be really nice if we can find some systematical/reliable methods to
> figure out files that really depends on struct syncobj, e.g.. I tried
> ctfdump(1) to
> *.o for kernel modules, but I cannot extract information better th
On Thu, Oct 12, 2023 at 8:23 PM Taylor R Campbell
wrote:
>
> > Date: Thu, 12 Oct 2023 17:06:02 +0900
> > From: Rin Okuyama
> >
> > On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
> > >
> > > Module Name:src
> > > Committed By: ad
> > > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> Date: Thu, 12 Oct 2023 17:06:02 +0900
> From: Rin Okuyama
>
> On Thu, Oct 5, 2023 at 5:39â¯AM Andrew Doran wrote:
> >
> > Module Name:src
> > Committed By: ad
> > Date: Wed Oct 4 20:39:35 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_rwlock.c kern_turnstile.
Cool! Can I send a pull up request to netbsd-10?
I've not yet observed deadlocks since this was committed,
fortunately or unfortunately, although ;)
Thanks,
rin
On Thu, Oct 5, 2023 at 5:39 AM Andrew Doran wrote:
>
> Module Name:src
> Committed By: ad
> Date: Wed Oct 4 20:39:35
> Date: Fri, 28 Jul 2023 23:40:40 +0900
> From: Izumi Tsutsui
>
> > Module Name:src
> > Committed By: riastradh
> > Date: Fri Jul 28 10:37:28 UTC 2023
> >
> > Modified Files:
> > src/sys/kern: kern_tc.c
> >
> > Log Message:
> > timecounter(9): Link to phk's timec
> Module Name: src
> Committed By: riastradh
> Date: Fri Jul 28 10:37:28 UTC 2023
>
> Modified Files:
> src/sys/kern: kern_tc.c
>
> Log Message:
> timecounter(9): Link to phk's timecounter paper for reference.
Maybe it's better to refer our timecounter(9) man page?
https://man.net
Hello,
On Tue, 15 Nov 2022 10:29:56 +
"Michael Lorenz" wrote:
> Module Name: src
> Committed By: macallan
> Date: Tue Nov 15 10:29:56 UTC 2022
>
> Modified Files:
> src/sys/kern: subr_pserialize.c
>
> Log Message:
> don't KASSERT(kpreempt_disabled()) while cold
> pserialize_
Date:Tue, 04 Oct 2022 10:09:35 -0400
From:Christos Zoulas
Message-ID: <8dd220d16861eb3a890461bdf02d1...@zoulas.com>
| I always forget the O_CLOEXEC is special
| in that regard. I wish it was not, but it is difficult to fix.
POSIX is adding O_CLOFORK in the next v
On 2022-10-01 3:39 pm, Robert Elz wrote:
Date:Sat, 1 Oct 2022 13:00:04 -0400
[stuff deleted]
Even when it is called, the code is:
fp->f_flag = flags & FMASK;
where FMASK is (from fcntl.h)
#define FMASK (FREAD|FWRITE|FCNTLFLAGS|FEXEC)
and
#define FCNTLFLAGS
Date:Sat, 1 Oct 2022 13:00:04 -0400
From:Christos Zoulas
Message-ID: <8bd3a408-77fd-402c-8d6c-ad4b4a5e8...@zoulas.com>
| This is what I meant:
|
| RCS file: /cvsroot/src/sys/kern/kern_descrip.c,v
| retrieving revision 1.251
| diff -u -u -r1.251 kern_descrip
> On Sep 30, 2022, at 11:02 PM, Robert Elz wrote:
>
>Date:Fri, 30 Sep 2022 20:15:07 -0400
>From:Christos Zoulas
>Message-ID:
>
> | It does not need an extra flag (it looks in the file descriptor flags to
> | find if it needs to set or not.
>
> One of us is con
Date:Fri, 30 Sep 2022 20:15:07 -0400
From:Christos Zoulas
Message-ID:
| It does not need an extra flag (it looks in the file descriptor flags to
| find if it needs to set or not.
One of us is confused. From where in this case does anything
get the exclose flag
> On Sep 30, 2022, at 5:57 PM, Robert Elz wrote:
>
>Date:Fri, 30 Sep 2022 16:34:20 -0400
>From:Christos Zoulas
>Message-ID: <232331ad-d501-4547-b730-03590c0c9...@zoulas.com>
>
> | How about handling exclose there?
>
> That would be possible, but why? We still
On Sat, 1 Oct 2022, Robert Elz wrote:
Currently fd_affix (I mistakenly made it fp_affix in the last message...)
doesn't have a flags parameter, so to do it the way you suggest, we'd need
to alter its signature, bump to 9.99.101 ...
and add some COMPAT_09 goop for backward compability :)
..
Date:Fri, 30 Sep 2022 16:34:20 -0400
From:Christos Zoulas
Message-ID: <232331ad-d501-4547-b730-03590c0c9...@zoulas.com>
| How about handling exclose there?
That would be possible, but why? We still need higher level code to
handle the locking, which can also hand
> On Sep 30, 2022, at 10:13 AM, Robert Elz wrote:
>
>Date:Thu, 29 Sep 2022 16:47:06 - (UTC)
>From:chris...@astron.com (Christos Zoulas)
>Message-ID:
>
> | I think that the way to go is to:
> |
> | 1. Do the fd_set_exclose() in fd_affix(). That will remove m
Date:Thu, 29 Sep 2022 16:47:06 - (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| I think that the way to go is to:
|
| 1. Do the fd_set_exclose() in fd_affix(). That will remove most of the calls
|to fd_set_exclose() *and* the open-coded
In article <9275.1664462...@jacaranda.noi.kre.to>,
Robert Elz wrote:
>Date:Thu, 29 Sep 2022 08:18:28 -0400
>From:"Christos Zoulas"
>Message-ID: <20220929121828.06edff...@cvs.netbsd.org>
>
> | Log Message:
> | Add fd_set_exclose(). It is probably better to do this a
Date:Thu, 29 Sep 2022 08:18:28 -0400
From:"Christos Zoulas"
Message-ID: <20220929121828.06edff...@cvs.netbsd.org>
| Log Message:
| Add fd_set_exclose(). It is probably better to do this automatically in
| fd_affix()...
Since that only affects /dev/ptmx I'd sugg
Reverted and alternative proposed on tech-kern! Sorry for the
unilateral toe-stomping.
On Sun, 7 Aug 2022, Paul Goyette wrote:
On Sun, 7 Aug 2022, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Sun Aug 7 21:17:18 UTC 2022
Modified Files:
src/sys/kern: kern_module.c
Log Message:
module(9): Disable module autounload by default.
I
On Sun, 7 Aug 2022, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Sun Aug 7 21:17:18 UTC 2022
Modified Files:
src/sys/kern: kern_module.c
Log Message:
module(9): Disable module autounload by default.
I don't know why this was ever enabled by d
> Date: Fri, 11 Feb 2022 16:50:16 -0800
> From: Jason Thorpe
>
> > On Feb 11, 2022, at 9:53 AM, Taylor R Campbell wrote:
> >
> > That is, this was presumably meant to ensure (A) happens-before (B).
> > This relation is already guaranteed by ipi(9), so there is no need
> > for any explicit me
> On Feb 11, 2022, at 9:53 AM, Taylor R Campbell wrote:
>
> That is, this was presumably meant to ensure (A) happens-before (B).
> This relation is already guaranteed by ipi(9), so there is no need
> for any explicit memory barrier.
Is this documented in ipi(9)?
-- thorpej
> Date: Sat, 5 Feb 2022 22:47:30 +0100
> From: Tobias Nygren
>
> On Sat, 5 Feb 2022 15:17:40 +
> Martin Husemann wrote:
>
> > Modified Files:
> > src/sys/kern: subr_autoconf.c
> >
> > Log Message:
> > cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.
>
> This
On Sat, 5 Feb 2022 15:17:40 +
Martin Husemann wrote:
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> cfdriver_iattr_count() is only used in a KASSERT, so #ifdef DIAGNOSTIC it.
This doesn't seem to work as intended.
In a kernel with "no options DIAGNOSTIC" I now ge
On 2021/09/22 14:42, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Wed Sep 22 05:42:19 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksymsmmap: Add missing uao_reference(9) call for ks->ks_uobj.
Fix failure for savecore(8) and subsequent
On Tue, Aug 17, 2021 at 11:39:26PM +, Taylor R Campbell wrote:
> >
> > Log Message:
> > skip symbol tables that were unloaded again to avoid EFAULT when reading
> > ksyms.
> >
> > also restore TAILQ_FOREACH idiom.
>
> This change isn't quite right: Reading past st = ksyms_last_snapshot
> in
> Module Name:src
> Committed By: mlelstv
> Date: Sun Jul 18 06:57:28 UTC 2021
>
> Modified Files:
> src/sys/kern: kern_ksyms.c
>
> Log Message:
> skip symbol tables that were unloaded again to avoid EFAULT when reading
> ksyms.
>
> also restore TAILQ_FOREACH idiom.
This
On Thu, Jul 01, 2021 at 12:25:51AM -0400, Christos Zoulas wrote:
> Modified Files:
> src/sys/kern: vfs_vnops.c
>
> Log Message:
> don't clear the error before we use it to determine if we are moving or
> duping.
oh ffs...
*goes to soak head*
--
David A. Holland
dholl...@netbsd.org
Hmm, misleading commit log (code itself is correct). More precisely:
s/the last element of ksyms_symtabs/ksyms_last_snapshot/
Anyway, does this help you to reintroduce
"ksyms(4): Don't skip symbol tables that are soon to be freed."?
That KASSERT does not fire anymore for aarch64, as far as I ca
> Date: Wed, 2 Jun 2021 17:33:39 +0900
> From: Rin Okuyama
>
> On 2021/06/02 6:11, Taylor R Campbell wrote:
> > - KASSERT(filepos <= sizeof(struct ksyms_hdr) +
> > + KASSERT(filepos == sizeof(struct ksyms_hdr) +
> > ksyms_hdr.kh_shdr[SYMTAB].sh_size);
> ...
>
> This KASSERT fires at
Hi,
On 2021/06/02 6:11, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Tue Jun 1 21:11:52 UTC 2021
Modified Files:
src/sys/kern: kern_ksyms.c
Log Message:
ksyms(4): Don't skip symbol tables that are soon to be freed.
They will not actually be f
On Fri, 22 Jan 2021, Paul Goyette wrote:
On Thu, 21 Jan 2021, Paul Goyette wrote:
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
OK, I built and installed a new kernel+userland.
Most everything works, and syslogd seems to work fine (at least, i
On Thu, 21 Jan 2021, Paul Goyette wrote:
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
OK, I built and installed a new kernel+userland.
Most everything works, and syslogd seems to work fine (at least, it
no longer panics during startup).
HOWEVE
Ooopppsss ignore me - looks like this was already fixed and my update
missed it.
I'll retry.
On Thu, 21 Jan 2021, Paul Goyette wrote:
This change seems to break everything! As soon as I try to start
syslogd I hit the panic() that you added
[ 28.0253983] panic: kqueue_scan,1491: kq=0xff
This change seems to break everything! As soon as I try to start
syslogd I hit the panic() that you added
[ 28.0253983] panic: kqueue_scan,1491: kq=0xdc13890bc4c0 kq->kq_count(1)
!= count(0), nmarker=1
[ 28.0253983] cpu0: Begin traceback...
[ 28.0253983] vpanic() at netbsd:vpanic+0x
I believe it's this change that's made my vbox image panic at the drop of
a hat; while it occasionally panics before it even hits single user, it
also consistently panics when starting syslogd (even from single-user):
panic: kqueue_scan,1491: kq=0xc779aeff6dc0 kq->kq_count(1) != count(0),
nma
On 2020/11/05 2:45, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine
OK, this is my mistake. When I change the calls in the ptrace_common
modcmd, I should also have renamed the functions (including their
entries in sys/ptrace.h). I will commit this shortly, before I leave.
Thanks for the "recipe" for reproducing the problem - I will try it
later when I return.
On Wed, 4 Nov 2020, Rin Okuyama wrote:
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initializatio
On 2020/11/04 22:52, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module
On Wed, 4 Nov 2020, Rin Okuyama wrote:
ptrace_common_{init,fini} are called from the ptrace_common module's
modcmd routine in kern/sys_ptrace_common.c. The modcmd routine in
turn is called at module initialization time. In the case of a
built-in module, it will be called by module_init via ini
On 2020/11/04 22:31, Paul Goyette wrote:
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name: src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Commo
On Wed, 4 Nov 2020, Rin Okuyama wrote:
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't us
Hi,
On 2020/10/26 0:55, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sun Oct 25 15:55:37 UTC 2020
Modified Files:
src/sys/kern: sys_ptrace_common.c
Log Message:
ptrace_Common is a module unto itself. Don't use the ptrace module's
init/fini routines.
In article <20201019144701.a6d3bf...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Mon Oct 19 14:47:01 UTC 2020
>
>Modified Files:
> src/sys/kern: sys_ptrace.c sys_ptrace_common.c
>
>Log Message:
>Remove obsolete references
On Mon, 07 Sep 2020 at 20:47:25 +1000, matthew green wrote:
"Jason R Thorpe" writes:
Module Name:src
Committed By: thorpej
Date: Mon Sep 7 03:50:41 UTC 2020
Modified Files:
src/sys/kern: files.kern init_main.c
Log Message:
Add the ability to set an alternate cnmagic in
"Jason R Thorpe" writes:
> Module Name: src
> Committed By: thorpej
> Date: Mon Sep 7 03:50:41 UTC 2020
>
> Modified Files:
> src/sys/kern: files.kern init_main.c
>
> Log Message:
> Add the ability to set an alternate cnmagic in the kernel config
> file, e.g.:
>
> optionsCNMA
On 02.08.2020 17:50, Taylor R Campbell wrote:
>> Date: Sun, 2 Aug 2020 17:35:06 +0200
>> From: Kamil Rytarowski
>>
>> On 02.08.2020 16:44, Taylor R Campbell wrote:
Date: Sun, 2 Aug 2020 16:04:15 +0200
From: Kamil Rytarowski
On 02.08.2020 15:57, Taylor R Campbell wrote:
> B
> Date: Sun, 2 Aug 2020 17:35:06 +0200
> From: Kamil Rytarowski
>
> On 02.08.2020 16:44, Taylor R Campbell wrote:
> >> Date: Sun, 2 Aug 2020 16:04:15 +0200
> >> From: Kamil Rytarowski
> >>
> >> On 02.08.2020 15:57, Taylor R Campbell wrote:
> >>> But it sounds like the original motivation is that
On 02.08.2020 16:44, Taylor R Campbell wrote:
>> Date: Sun, 2 Aug 2020 16:04:15 +0200
>> From: Kamil Rytarowski
>>
>> On 02.08.2020 15:57, Taylor R Campbell wrote:
>>> But it sounds like the original motivation is that it triggered
>>> -Wvla...which frankly strikes me as a compiler bug since there
Le dim. 2 août 2020 à 15:57, Taylor R Campbell
a écrit :
> Why does it improve readability?
Certainly using cringe language features does not help readability.
> What else does -Wvla choke on in src/sys?
Some drm drivers, and uvm, particularly uvm_bio.c. I'd like to work
towards enabling -Wvla
> Date: Sun, 2 Aug 2020 16:04:15 +0200
> From: Kamil Rytarowski
>
> On 02.08.2020 15:57, Taylor R Campbell wrote:
> > But it sounds like the original motivation is that it triggered
> > -Wvla...which frankly strikes me as a compiler bug since there's
> > obviously no actual VLA created in sizeof;
On Sun, Aug 02, 2020 at 01:57:11PM +, Taylor R Campbell wrote:
> But it sounds like the original motivation is that it triggered
> -Wvla...which frankly strikes me as a compiler bug since there's
> obviously no actual VLA created in sizeof; as far as I can tell
> there's no semantic difference
On 02.08.2020 16:25, Paul Goyette wrote:
> On Sun, 2 Aug 2020, Kamil Rytarowski wrote:
>
>> On 02.08.2020 15:57, Taylor R Campbell wrote:
>>> But it sounds like the original motivation is that it triggered
>>> -Wvla...which frankly strikes me as a compiler bug since there's
>>> obviously no actual
On Sun, 2 Aug 2020, Kamil Rytarowski wrote:
On 02.08.2020 15:57, Taylor R Campbell wrote:
But it sounds like the original motivation is that it triggered
-Wvla...which frankly strikes me as a compiler bug since there's
obviously no actual VLA created in sizeof; as far as I can tell
there's no s
On 02.08.2020 15:57, Taylor R Campbell wrote:
> But it sounds like the original motivation is that it triggered
> -Wvla...which frankly strikes me as a compiler bug since there's
> obviously no actual VLA created in sizeof; as far as I can tell
> there's no semantic difference between sizeof(device
> Date: Sun, 2 Aug 2020 10:47:21 +0200
> From: Jarom�r Dole ek
>
> Readability first and foremost in this case.
>
> I was exploring if I can disable VLAs for the kernel altogether, this
> can't be done for now. Nevertheless, this change looked like it would
> be useful to make anyway.
Why does
Readability first and foremost in this case.
I was exploring if I can disable VLAs for the kernel altogether, this
can't be done for now. Nevertheless, this change looked like it would
be useful to make anyway.
Le dim. 2 août 2020 à 01:15, Taylor R Campbell
a écrit :
>
> > Module Name:src
>
> Module Name:src
> Committed By: jdolecek
> Date: Sat Aug 1 11:18:26 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> avoid VLA for the sizeof() calculations
Why?
Le 28/04/2020 à 09:16, Luke Mewburn a écrit :
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
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
> dis
"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 in
> 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 s
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 faile
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 r
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 tracer_
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 disc
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.
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 m
> On Apr 26, 2020, at 2:04 PM, Michael van Elst wrote:
>
> Log Message:
> fix DIAGNOSTIC build
non-DIAGNOSTIC you mean?
-- thorpej
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 th
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
> > > > Dat
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 Mes
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 Messag
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 a
On Sun, Mar 29, 2020 at 11:41:23AM +0200, Maxime Villard wrote:
> Le 23/03/2020 ? 21:02, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Mon Mar 23 20:02:14 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: vfs_cache.c
> >
> > Log Message
Le 23/03/2020 à 21:02, Andrew Doran a écrit :
> Module Name: src
> Committed By: ad
> Date: Mon Mar 23 20:02:14 UTC 2020
>
> Modified Files:
> src/sys/kern: vfs_cache.c
>
> Log Message:
> cache_remove(): remove from the vnode list first, so cache_revlookup()
> doesn't try to re-act
Le 08/03/2020 à 21:41, Andrew Doran a écrit :
> On Sun, Mar 08, 2020 at 08:34:29AM +0100, Maxime Villard wrote:
>> Le 08/03/2020 ? 01:31, Andrew Doran a ?crit?:
>>> Module Name:src
>>> Committed By: ad
>>> Date: Sun Mar 8 00:31:19 UTC 2020
>>>
>>> Modified Files:
>>>
On Sun, Mar 08, 2020 at 08:34:29AM +0100, Maxime Villard wrote:
> Le 08/03/2020 ? 01:31, Andrew Doran a ?crit?:
> > Module Name:src
> > Committed By: ad
> > Date: Sun Mar 8 00:31:19 UTC 2020
> >
> > Modified Files:
> > src/sys/kern: subr_kmem.c
> >
> > Log Message
Le 08/03/2020 à 01:31, Andrew Doran a écrit :
> Module Name: src
> Committed By: ad
> Date: Sun Mar 8 00:31:19 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_kmem.c
>
> Log Message:
> KMEM_SIZE: append the size_t to the allocated buffer, rather than
> prepending, so it doesn't
On Tue, Mar 03, 2020 at 02:55:16PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Mar 3 19:55:16 UTC 2020
>
> Modified Files:
> src/sys/kern: vfs_syscalls.c
>
> Log Message:
> don't skip the rdir check for the lazy case; breaks chroot df(1)
> Date: Tue, 3 Mar 2020 12:41:32 +0900
> From: Rin Okuyama
>
> On 2020/03/03 1:00, Taylor R Campbell wrote:
> > Include kern_crashme.c in non-DEBUG kernels.
> >
> > This is useful for simulating crashes in production to test failover.
>
> I like this.
>
> Could you please send pullup request t
Hi,
On 2020/03/03 1:00, Taylor R Campbell wrote:
Module Name:src
Committed By: riastradh
Date: Mon Mar 2 16:00:54 UTC 2020
Modified Files:
src/sys/kern: files.kern
Log Message:
Include kern_crashme.c in non-DEBUG kernels.
This is useful for simulating crashes in produ
On 24.02.2020 21:47, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Mon Feb 24 20:47:47 UTC 2020
>
> Modified Files:
> src/sys/kern: init_main.c
>
> Log Message:
> move config_init_mi() call before vfsinit(), which can trigger loading
> of VFS modules
>
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sun Feb 23 20:08:35 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_pmf.c
>
> Log Message:
> shutdown_all: take kernel_lock now that kern_reboot() doesn't.
ah, i am now guessing that having the kernel lock held
"Andrew Doran" writes:
> Module Name: src
> Committed By: ad
> Date: Sun Feb 23 20:06:30 UTC 2020
>
> Modified Files:
> src/sys/kern: kern_reboot.c
>
> Log Message:
> - If concurrent calls to kern_reboot(), only let the first do the deed.
> - Don't need kernel_lock for this (either
On 20.02.2020 22:14, Jaromir Dolecek wrote:
> Module Name: src
> Committed By: jdolecek
> Date: Thu Feb 20 21:14:23 UTC 2020
>
> Modified Files:
> src/sys/kern: subr_autoconf.c
>
> Log Message:
> protect deferred lists' manipulation by config_misc_lock, same as
> config_pending sem
> On Feb 17, 2020, at 11:19 PM, Andrew Doran wrote:
>
> Hi,
>
> On Thu, Feb 06, 2020 at 06:33:55PM +0100, J. Hannken-Illjes wrote:
>
>>> On 12. Jan 2020, at 18:49, Andrew Doran wrote:
>>>
>>> Module Name:src
>>> Committed By: ad
>>> Date: Sun Jan 12 17:49:17 UTC 20
1 - 100 of 693 matches
Mail list logo
