Searched hist:1.504 (Results 1 - 25 of 36) sorted by relevance

12

/src/usr.bin/make/unit-tests/
H A Ddirective-export-impl.mk1.1 Tue Dec 29 01:45:06 GMT 2020 rillig make(1): add test that explains how variables are exported

Exporting the variables at the right time and with the correct values is
a subtle issue. The current implementation carefully marks variables as
ready to be exported, then exports them and at the same time tries to
export as few variables as possible, to avoid memory leaks. This test
describes and explains how all this works in detail.

This test also justifies that the call to Var_ReexportVars happens in
the make process itself, not in the child processes, no matter whether
these are created with vfork or (only theoretically) with plain fork.
This has changed in compat.c 1.217, job.c 1.390 and main.c 1.504 from
2020-12-27.

H A Ddirective-export-impl.exp1.1 Tue Dec 29 01:45:06 GMT 2020 rillig make(1): add test that explains how variables are exported

Exporting the variables at the right time and with the correct values is
a subtle issue. The current implementation carefully marks variables as
ready to be exported, then exports them and at the same time tries to
export as few variables as possible, to avoid memory leaks. This test
describes and explains how all this works in detail.

This test also justifies that the call to Var_ReexportVars happens in
the make process itself, not in the child processes, no matter whether
these are created with vfork or (only theoretically) with plain fork.
This has changed in compat.c 1.217, job.c 1.390 and main.c 1.504 from
2020-12-27.

H A DMakefile1.258 Tue Dec 29 01:45:06 GMT 2020 rillig make(1): add test that explains how variables are exported

Exporting the variables at the right time and with the correct values is
a subtle issue. The current implementation carefully marks variables as
ready to be exported, then exports them and at the same time tries to
export as few variables as possible, to avoid memory leaks. This test
describes and explains how all this works in detail.

This test also justifies that the call to Var_ReexportVars happens in
the make process itself, not in the child processes, no matter whether
these are created with vfork or (only theoretically) with plain fork.
This has changed in compat.c 1.217, job.c 1.390 and main.c 1.504 from
2020-12-27.

/src/usr.bin/make/
H A Dcompat.c1.221 Mon Feb 01 21:04:10 GMT 2021 rillig make: always use vfork, never fork

Before compat.c 1.217, job.c 1.390 and main.c 1.504 from 2020-12-27, the
exported make variables were exported from each freshly forked child
process. There was no practical difference though between exporting the
variables from the parent process or the child process since these two
processes share the same address space, except that the forked process
is very limited in what it may actually do. This limitation was
violated on a regular basis.

When an exported variable referred to a variable that used the :sh
variable modifier, this led to a fork from within vfork, which is not
allowed. Since 2020-12-27, exporting the variables is done from the
main process, which prevents this situation from ever occurring.

Since that day, there is no need anymore to distinguish between vfork
and fork, which removes any need for the macro.

H A Djob.c1.504 Fri May 09 20:35:43 GMT 2025 rillig make: move ContinueJobs further up, to eliminate a forward declaration

Reword a debug log message from "Restarting" to "Continuing", as the
child process is not started again from the beginning.

1.411 Mon Feb 01 21:04:10 GMT 2021 rillig make: always use vfork, never fork

Before compat.c 1.217, job.c 1.390 and main.c 1.504 from 2020-12-27, the
exported make variables were exported from each freshly forked child
process. There was no practical difference though between exporting the
variables from the parent process or the child process since these two
processes share the same address space, except that the forked process
is very limited in what it may actually do. This limitation was
violated on a regular basis.

When an exported variable referred to a variable that used the :sh
variable modifier, this led to a fork from within vfork, which is not
allowed. Since 2020-12-27, exporting the variables is done from the
main process, which prevents this situation from ever occurring.

Since that day, there is no need anymore to distinguish between vfork
and fork, which removes any need for the macro.

H A Dmain.c1.526 Mon Feb 01 21:04:10 GMT 2021 rillig make: always use vfork, never fork

Before compat.c 1.217, job.c 1.390 and main.c 1.504 from 2020-12-27, the
exported make variables were exported from each freshly forked child
process. There was no practical difference though between exporting the
variables from the parent process or the child process since these two
processes share the same address space, except that the forked process
is very limited in what it may actually do. This limitation was
violated on a regular basis.

When an exported variable referred to a variable that used the :sh
variable modifier, this led to a fork from within vfork, which is not
allowed. Since 2020-12-27, exporting the variables is done from the
main process, which prevents this situation from ever occurring.

Since that day, there is no need anymore to distinguish between vfork
and fork, which removes any need for the macro.
1.504 Sun Dec 27 05:16:26 GMT 2020 rillig make(1): re-export variables from the actual make process

Since make uses vfork if available, re-exporting the variables happens
in the address space of the main process anyway, so there is no point in
mentioning anything about "our client process" anywhere.
H A Dmake.h1.248 Mon Feb 01 21:04:10 GMT 2021 rillig make: always use vfork, never fork

Before compat.c 1.217, job.c 1.390 and main.c 1.504 from 2020-12-27, the
exported make variables were exported from each freshly forked child
process. There was no practical difference though between exporting the
variables from the parent process or the child process since these two
processes share the same address space, except that the forked process
is very limited in what it may actually do. This limitation was
violated on a regular basis.

When an exported variable referred to a variable that used the :sh
variable modifier, this led to a fork from within vfork, which is not
allowed. Since 2020-12-27, exporting the variables is done from the
main process, which prevents this situation from ever occurring.

Since that day, there is no need anymore to distinguish between vfork
and fork, which removes any need for the macro.

/src/sys/kern/
H A Dinit_main.c1.504 Fri May 17 03:34:26 GMT 2019 ozaki-r branches: 1.504.2;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern
1.504 Fri May 17 03:34:26 GMT 2019 ozaki-r branches: 1.504.2;
Implement an aggressive psref leak detector

It is yet another psref leak detector that enables to tell where a leak occurs
while a simpler version that is already committed just tells an occurrence of a
leak.

Investigating of psref leaks is hard because once a leak occurs a percpu list of
psref that tracks references can be corrupted. A reference to a tracking object
is memorized in the list via an intermediate object (struct psref) that is
normally allocated on a stack of a thread. Thus, the intermediate object can be
overwritten on a leak resulting in corruption of the list.

The tracker makes a shadow entry to an intermediate object and stores some hints
into it (currently it's a caller address of psref_acquire). We can detect a
leak by checking the entries on certain points where any references should be
released such as the return point of syscalls and the end of each softint
handler.

The feature is expensive and enabled only if the kernel is built with
PSREF_DEBUG.

Proposed on tech-kern
H A Dkern_exec.c1.504 Sat Dec 05 18:17:01 GMT 2020 thorpej branches: 1.504.4;
Refactor interval timers to make it possible to support types other than
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
data) and "struct ptimer" (per-process timer data, which contains a
"struct itimer").

- Introduce a new "struct itimer_ops" that supplies information about
the specific kind of interval timer, including it's processing
queue, the softint handle used to schedule processing, the function
to call when the timer fires (which adds it to the queue), and an
optional function to call when the CLOCK_REALTIME clock is changed by
a call to clock_settime() or settimeofday().

- Rename some fuctions to clearly identify what they're operating on
(ptimer vs itimer).

- Use kmem(9) to allocate ptimer-related structures, rather than having
dedicated pools for them.

Welcome to NetBSD 9.99.77.
1.504 Sat Dec 05 18:17:01 GMT 2020 thorpej branches: 1.504.4;
Refactor interval timers to make it possible to support types other than
the BSD/POSIX per-process timers:

- "struct ptimer" is split into "struct itimer" (common interval timer
data) and "struct ptimer" (per-process timer data, which contains a
"struct itimer").

- Introduce a new "struct itimer_ops" that supplies information about
the specific kind of interval timer, including it's processing
queue, the softint handle used to schedule processing, the function
to call when the timer fires (which adds it to the queue), and an
optional function to call when the CLOCK_REALTIME clock is changed by
a call to clock_settime() or settimeofday().

- Rename some fuctions to clearly identify what they're operating on
(ptimer vs itimer).

- Use kmem(9) to allocate ptimer-related structures, rather than having
dedicated pools for them.

Welcome to NetBSD 9.99.77.
/src/sys/arch/i386/conf/
H A DALL1.504 Thu Dec 22 11:05:55 GMT 2022 nat Driver for DaynaPORT SCSI/Link (dse.4).

Written by Hiroshi Noguchi, of which an updated version was posted to
port-mac68k in 2001.

Attachments were added to kernel configs for platforms that already had
the Cabletron (se.4) driver added, although other platorms may benefit.

Reviewed on tech-net by Izumi Tsutsui.
/src/distrib/notes/common/
H A Dmain1.504 Sat Feb 08 15:50:29 GMT 2014 maxv add myself
/src/share/man/man4/
H A Doptions.41.504 Tue May 21 16:45:19 GMT 2019 sevan Sort Keywords section
H A DMakefile1.504 Tue Feb 09 03:19:50 GMT 2010 cnst New aibs(4) driver for ASUSTeK AI Booster (ACPI ATK0110) hardware monitor
with limit support.

http://thread.gmane.org/gmane.os.netbsd.devel.kernel/35654

Reviewed by <pgoyette>, <jruoho> and <tech-kern>.
/src/sys/dev/usb/
H A Dusbdevs1.504 Fri Aug 22 03:22:25 GMT 2008 matt Add APPLE ETHERNET
H A Dusbdevs.h1.504 Sat Aug 30 03:29:56 GMT 2008 matt Regen.
H A Dusbdevs_data.h1.504 Thu Aug 28 21:41:51 GMT 2008 jmcneill Regen.
/src/usr.bin/xlint/lint1/
H A Dcgram.y1.504 Mon Jun 17 04:14:02 GMT 2024 rillig lint: accept C23 attributes at the beginning of a type declaration

The switch to GCC 12 brings support for C23, and localtime.c uses it to
mark [[maybe_unused]] parameters.

For now, accept C23 attributes independently from the language level. In
the end, the whole tree with the exception of the tools should be
switched to C23 mode instead of the current C99 mode.

For now, don't actually mark the argument as possibly unused, as lint
currently ignores __attribute__((__unused__)) as well.
H A Dtree.c1.504 Sun Jan 29 18:16:48 GMT 2023 rillig lint: fix definition of __func__
/src/distrib/sets/lists/tests/
H A Dmi1.1000 Tue Dec 29 01:45:06 GMT 2020 rillig make(1): add test that explains how variables are exported

Exporting the variables at the right time and with the correct values is
a subtle issue. The current implementation carefully marks variables as
ready to be exported, then exports them and at the same time tries to
export as few variables as possible, to avoid memory leaks. This test
describes and explains how all this works in detail.

This test also justifies that the call to Var_ReexportVars happens in
the make process itself, not in the child processes, no matter whether
these are created with vfork or (only theoretically) with plain fork.
This has changed in compat.c 1.217, job.c 1.390 and main.c 1.504 from
2020-12-27.
1.504 Mon Nov 12 09:03:52 GMT 2012 njoly Adjust for tests/lib/{libbpfjit,libsljit} debug entries.
/src/sys/net/
H A Dif.c1.504 Wed May 11 14:58:01 GMT 2022 andvar fix various typos in comments.
/src/sys/arch/amd64/conf/
H A DGENERIC1.504 Mon Aug 20 15:04:51 GMT 2018 maxv Add support for kASan on amd64. Written by me, with some parts inspired
from Siddharth Muralee's initial work. This feature can detect several
kinds of memory bugs, and it's an excellent feature.

It can be enabled by uncommenting these three lines in GENERIC:

#makeoptions KASAN=1 # Kernel Address Sanitizer
#options KASAN
#no options SVS

The kernel is compiled without SVS, without DMAP and without PCPU area.
A shadow area is created at boot time, and it can cover the upper 128TB
of the address space. This area is populated gradually as we allocate
memory. With this design the memory consumption is kept at its lowest
level.

The compiler calls the __asan_* functions each time a memory access is
done. We verify whether this access is legal by looking at the shadow
area.

We declare our own special memcpy/memset/etc functions, because the
compiler's builtins don't add the __asan_* instrumentation.

Initially all the mappings are marked as valid. During dynamic
allocations, we add a redzone, which we mark as invalid. Any access on
it will trigger a kASan error message. Additionally, the compiler adds
a redzone on global variables, and we mark these redzones as invalid too.
The illegal-access detection works with a 1-byte granularity.

For now, we cover three areas:

- global variables
- kmem_alloc-ated areas
- malloc-ated areas

More will come, but that's a good start.
/src/sys/dev/pci/
H A Dpcidevs.h1.504 Fri Jan 24 17:47:17 GMT 2003 thorpej Regen; Tweak a Promise description.
H A Dpcidevs_data.h1.504 Sun Feb 02 18:53:17 GMT 2003 bouyer Regen: add SiS 651 host bridge.
/src/sys/arch/i386/i386/
H A Dmachdep.c1.504 Fri Dec 06 17:53:52 GMT 2002 junyoung Get rid of #ifdef CPUDEBUG. CPU signature is always displayed.
/src/distrib/sets/lists/base/
H A Dshl.mi1.504 Mon Nov 02 10:13:19 GMT 2009 plunky switch build to use libevent-1.4.12-stable from external

Completed in 854 milliseconds

12