Searched hist:1.276 (Results 1 - 25 of 132) sorted by relevance

123456

/src/sys/netipsec/
H A Dkey.c1.276 Tue Aug 09 08:03:22 GMT 2022 knakahara Add sysctl entry to improve interconnectivity to some VPN appliances, pointed out by seil-team@IIJ.

If we want to allow different identifier types on IDii and IDir, set
net.key.allow_different_idtype=1. Default(=0) is the same as before.

/src/usr.sbin/
H A DMakefile1.276 Tue Jan 09 03:31:13 GMT 2018 christos branches: 1.276.2; 1.276.4;
Merge autofs support from: Tomohiro Kusumi
XXX: Does not work yet

1.276 Tue Jan 09 03:31:13 GMT 2018 christos branches: 1.276.2; 1.276.4;
Merge autofs support from: Tomohiro Kusumi
XXX: Does not work yet

1.276 Tue Jan 09 03:31:13 GMT 2018 christos branches: 1.276.2; 1.276.4;
Merge autofs support from: Tomohiro Kusumi
XXX: Does not work yet

/src/sys/kern/
H A Dvfs_bio.c1.276 Sat Oct 28 00:37:11 GMT 2017 pgoyette branches: 1.276.2; 1.276.4;
Update the kernhist(9) kernel history code to address issues identified
in PR kern/52639, as well as some general cleaning-up...

(As proposed on tech-kern@ with additional changes and enhancements.)

Details of changes:

* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)

* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.

* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.

* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."

* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.

* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).

* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).

* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.

* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.

[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".

[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.

1.276 Sat Oct 28 00:37:11 GMT 2017 pgoyette branches: 1.276.2; 1.276.4;
Update the kernhist(9) kernel history code to address issues identified
in PR kern/52639, as well as some general cleaning-up...

(As proposed on tech-kern@ with additional changes and enhancements.)

Details of changes:

* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)

* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.

* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.

* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."

* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.

* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).

* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).

* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.

* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.

[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".

[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.

1.276 Sat Oct 28 00:37:11 GMT 2017 pgoyette branches: 1.276.2; 1.276.4;
Update the kernhist(9) kernel history code to address issues identified
in PR kern/52639, as well as some general cleaning-up...

(As proposed on tech-kern@ with additional changes and enhancements.)

Details of changes:

* All history arguments are now stored as uintmax_t values[1], both in
the kernel and in the structures used for exporting the history data
to userland via sysctl(9). This avoids problems on some architectures
where passing a 64-bit (or larger) value to printf(3) can cause it to
process the value as multiple arguments. (This can be particularly
problematic when printf()'s format string is not a literal, since in
that case the compiler cannot know how large each argument should be.)

* Update the data structures used for exporting kernel history data to
include a version number as well as the length of history arguments.

* All [2] existing users of kernhist(9) have had their format strings
updated. Each format specifier now includes an explicit length
modifier 'j' to refer to numeric values of the size of uintmax_t.

* All [2] existing users of kernhist(9) have had their format strings
updated to replace uses of "%p" with "%#jx", and the pointer
arguments are now cast to (uintptr_t) before being subsequently cast
to (uintmax_t). This is needed to avoid compiler warnings about
casting "pointer to integer of a different size."

* All [2] existing users of kernhist(9) have had instances of "%s" or
"%c" format strings replaced with numeric formats; several instances
of mis-match between format string and argument list have been fixed.

* vmstat(1) has been modified to handle the new size of arguments in the
history data as exported by sysctl(9).

* vmstat(1) now provides a warning message if the history requested with
the -u option does not exist (previously, this condition was silently
ignored, with only a single blank line being printed).

* vmstat(1) now checks the version and argument length included in the
data exported via sysctl(9) and exits if they do not match the values
with which vmstat was built.

* The kernhist(9) man-page has been updated to note the additional
requirements imposed on the format strings, along with several other
minor changes and enhancements.

[1] It would have been possible to use an explicit length (for example,
uint64_t) for the history arguments. But that would require another
"rototill" of all the users in the future when we add support for an
architecture that supports a larger size. Also, the printf(3) format
specifiers for explicitly-sized values, such as "%"PRIu64, are much
more verbose (and less aesthetically appealing, IMHO) than simply
using "%ju".

[2] I've tried very hard to find "all [the] existing users of kernhist(9)"
but it is possible that I've missed some of them. I would be glad to
update any stragglers that anyone identifies.

H A Dtty.c1.276 Fri Mar 30 22:59:43 GMT 2018 maya branches: 1.276.2;
correct typo: and and -> and

from chris28.

1.276 Fri Mar 30 22:59:43 GMT 2018 maya branches: 1.276.2;
correct typo: and and -> and

from chris28.

H A Dinit_sysent.c1.276 Mon Dec 09 16:35:12 GMT 2013 pooka regen

H A Dsyscalls.c1.276 Wed Jul 23 11:43:29 GMT 2014 pooka regen

H A Dkern_exit.c1.276 Thu Jun 13 20:20:18 GMT 2019 kamil branches: 1.276.2;
Correct use-after-free issue in vfork(2)

In the previous behavior vforking parent was keeping pointer to a child
and checking whether it clears a PL_PPWAIT in its bitfield p_lflag. However
a child can go invalid between exec/exit event from child and waking up
vforked parent and this can cause invalid pointer read and in the worst
scenario kernel crash.

In the new behavior vforked child keeps a reference to vforked parent LWP
and sets a value l_vforkwaiting to false. This means that vforked child
can finish its work, exec/exit and be terminated and once parent will be
woken up it will read its own field whether its child is still blocking.

Add new field in struct lwp: l_vforkwaiting protected by proc_lock.
In future it should be refactored and all PL_PPWAIT users transformed to
l_vforkwaiting and next l_vforkwaiting probably transformed into a bit
field.

This is another attempt of fixing this bug after <rmind> from 2012 in
commit:

Author: rmind <rmind@NetBSD.org>
Date: Sun Jul 22 22:40:18 2012 +0000

fork1: fix use-after-free problems. Addresses PR/46128 from Andrew Doran.
Note: PL_PPWAIT should be fully replaced and modificaiton of l_pflag by
other LWP is undesirable, but this is enough for netbsd-6.

The new version no longer performs unsafe access in l_lflag changing the
LP_VFORKWAIT bit.

Verified with ATF t_vfork and t_ptrace* tests and they are no longer
causing any issues in my local setup.

Fixes PR/46128 by Andrew Doran

1.276 Thu Jun 13 20:20:18 GMT 2019 kamil branches: 1.276.2;
Correct use-after-free issue in vfork(2)

In the previous behavior vforking parent was keeping pointer to a child
and checking whether it clears a PL_PPWAIT in its bitfield p_lflag. However
a child can go invalid between exec/exit event from child and waking up
vforked parent and this can cause invalid pointer read and in the worst
scenario kernel crash.

In the new behavior vforked child keeps a reference to vforked parent LWP
and sets a value l_vforkwaiting to false. This means that vforked child
can finish its work, exec/exit and be terminated and once parent will be
woken up it will read its own field whether its child is still blocking.

Add new field in struct lwp: l_vforkwaiting protected by proc_lock.
In future it should be refactored and all PL_PPWAIT users transformed to
l_vforkwaiting and next l_vforkwaiting probably transformed into a bit
field.

This is another attempt of fixing this bug after <rmind> from 2012 in
commit:

Author: rmind <rmind@NetBSD.org>
Date: Sun Jul 22 22:40:18 2012 +0000

fork1: fix use-after-free problems. Addresses PR/46128 from Andrew Doran.
Note: PL_PPWAIT should be fully replaced and modificaiton of l_pflag by
other LWP is undesirable, but this is enough for netbsd-6.

The new version no longer performs unsafe access in l_lflag changing the
LP_VFORKWAIT bit.

Verified with ATF t_vfork and t_ptrace* tests and they are no longer
causing any issues in my local setup.

Fixes PR/46128 by Andrew Doran

H A Dsubr_pool.c1.276 Wed Feb 24 05:36:02 GMT 2021 mrg branches: 1.276.4;
skip redzone on pools with the allocation (including all overhead)
on anything greater than half the pool pagesize.

this stops 4KiB being used per allocation from the kmem-02048 pool,
and 64KiB per allocation from the buf32k pool.

we're still wasting 1/4 of space for overhead on eg, the buf1k or
kmem-01024 pools. however, including overhead costs, the amount of
useless space (not used by consumer or overhead) reduces from 47%
to 18%, so this is far less bad overall.


there are a couple of ideas on solving this less ugly:

- pool redzones are enabled with DIAGNOSTIC kernels, which is
defined as being "fast, cheap". this is not cheap (though it
is relatively fast if you don't run out of memory) so it does
not really belong here as is, but DEBUG or a special option
would work for it.

- if we increase the "pool page" size for these pools, such that
the overhead over pool page is reduced to 5% or less, we can
have redzones for more allocations without using more space.


also, see this thread:

https://mail-index.netbsd.org/tech-kern/2021/02/23/msg027130.html

1.276 Wed Feb 24 05:36:02 GMT 2021 mrg branches: 1.276.4;
skip redzone on pools with the allocation (including all overhead)
on anything greater than half the pool pagesize.

this stops 4KiB being used per allocation from the kmem-02048 pool,
and 64KiB per allocation from the buf32k pool.

we're still wasting 1/4 of space for overhead on eg, the buf1k or
kmem-01024 pools. however, including overhead costs, the amount of
useless space (not used by consumer or overhead) reduces from 47%
to 18%, so this is far less bad overall.


there are a couple of ideas on solving this less ugly:

- pool redzones are enabled with DIAGNOSTIC kernels, which is
defined as being "fast, cheap". this is not cheap (though it
is relatively fast if you don't run out of memory) so it does
not really belong here as is, but DEBUG or a special option
would work for it.

- if we increase the "pool page" size for these pools, such that
the overhead over pool page is reduced to 5% or less, we can
have redzones for more allocations without using more space.


also, see this thread:

https://mail-index.netbsd.org/tech-kern/2021/02/23/msg027130.html

/src/sys/arch/sparc/sparc/
H A Dmachdep.c1.276 Sat Jan 05 22:48:21 GMT 2008 martin branches: 1.276.6; 1.276.8;
Add missing include.

1.276 Sat Jan 05 22:48:21 GMT 2008 martin branches: 1.276.6; 1.276.8;
Add missing include.

1.276 Sat Jan 05 22:48:21 GMT 2008 martin branches: 1.276.6; 1.276.8;
Add missing include.

H A Dpmap.c1.276 Fri Feb 13 11:36:18 GMT 2004 wiz branches: 1.276.2;
Uppercase CPU, plural is CPUs.

1.276 Fri Feb 13 11:36:18 GMT 2004 wiz branches: 1.276.2;
Uppercase CPU, plural is CPUs.

/src/sys/sys/
H A Dsystm.h1.276 Mon May 28 21:04:41 GMT 2018 chs branches: 1.276.2;
add copyin_pid(), to copyin from a different user address space.

1.276 Mon May 28 21:04:41 GMT 2018 chs branches: 1.276.2;
add copyin_pid(), to copyin from a different user address space.

H A Dsyscallargs.h1.276 Sun Apr 03 01:01:46 GMT 2016 christos regen

H A Dsyscall.h1.276 Sun Feb 22 00:53:28 GMT 2015 christos PR/49684: Pierre Pronchery: readlinkat(2) return type is wrong.
/src/sys/conf/
H A DMakefile.kern.inc1.276 Sun Sep 06 07:20:29 GMT 2020 mrg branches: 1.276.2;
add support for new GCC 9 warnings that may be too much to fix
right now. new address-of-packed-member and format-overflow
warnings have new GCC_NO_ADDR_OF_PACKED_MEMBER amd
GCC_NO_FORMAT_OVERFLOW variables to remove these warnings.

apply to a bunch of the tree. mostly, these are real bugs that
should be fixed, but in many cases, only by removing the 'packed'
attribute from some structure that doesn't really need it. (i
looked at many different ones, and while perhaps 60-80% were
already properly aligned, it wasn't clear to me that the uses
were always coming from sane data vs network alignment, so it
doesn't seem safe to remove packed without careful research for
each affect struct.) clang already warned (and was not erroring)
for many of these cases, but gcc picked up dozens more.

1.276 Sun Sep 06 07:20:29 GMT 2020 mrg branches: 1.276.2;
add support for new GCC 9 warnings that may be too much to fix
right now. new address-of-packed-member and format-overflow
warnings have new GCC_NO_ADDR_OF_PACKED_MEMBER amd
GCC_NO_FORMAT_OVERFLOW variables to remove these warnings.

apply to a bunch of the tree. mostly, these are real bugs that
should be fixed, but in many cases, only by removing the 'packed'
attribute from some structure that doesn't really need it. (i
looked at many different ones, and while perhaps 60-80% were
already properly aligned, it wasn't clear to me that the uses
were always coming from sane data vs network alignment, so it
doesn't seem safe to remove packed without careful research for
each affect struct.) clang already warned (and was not erroring)
for many of these cases, but gcc picked up dozens more.

/src/sys/arch/mips/mips/
H A Dmips_machdep.c1.276 Fri Dec 23 07:15:27 GMT 2016 cherry branches: 1.276.6;
"Make NetBSD great again!"

Introduce uvm_hotplug(9) to the kernel.

Many thanks, in no particular order to:

TNF, for funding the project.

Chuck Silvers - for multiple API reviews and feedback.
Nick Hudson - for testing on multiple architectures and bugfix patches.
Everyone who helped with boot testing.

KeK (http://www.kek.org.in) for hosting the primary developers.

1.276 Fri Dec 23 07:15:27 GMT 2016 cherry branches: 1.276.6;
"Make NetBSD great again!"

Introduce uvm_hotplug(9) to the kernel.

Many thanks, in no particular order to:

TNF, for funding the project.

Chuck Silvers - for multiple API reviews and feedback.
Nick Hudson - for testing on multiple architectures and bugfix patches.
Everyone who helped with boot testing.

KeK (http://www.kek.org.in) for hosting the primary developers.

/src/sys/arch/i386/conf/
H A DINSTALL1.276 Tue Dec 20 05:35:28 GMT 2005 thorpej branches: 1.276.2;
Remove the tablet line discipline.
1.276 Tue Dec 20 05:35:28 GMT 2005 thorpej branches: 1.276.2;
Remove the tablet line discipline.
/src/sys/arch/i386/i386/
H A Dtrap.c1.276 Wed Dec 16 18:54:03 GMT 2015 maxv branches: 1.276.2;
Extend SMEP support to i386 (does not require PAE).

1.276 Wed Dec 16 18:54:03 GMT 2015 maxv branches: 1.276.2;
Extend SMEP support to i386 (does not require PAE).

/src/distrib/sets/lists/debug/
H A Dshl.mi1.276 Thu Apr 29 17:27:54 GMT 2021 christos branches: 1.276.2;
bump shlibs for bind-9.16.15
1.276 Thu Apr 29 17:27:54 GMT 2021 christos branches: 1.276.2;
bump shlibs for bind-9.16.15
/src/sys/nfs/
H A Dnfs_vnops.c1.277 Sun May 10 03:51:43 GMT 2009 yamt restore lines, esp. a vrele() call, which i mistakenly removed
in the previous. (rev.1.276)

1.276 Mon May 04 05:59:35 GMT 2009 yamt nfs_lookup: handle the case where the vnode returned cache_lookup_raw is
being reclaimed by another thread. after recent changes in cache_lookup_raw,
there's a race between cache_lookup_raw/vtryget and getcleanvnode/vclean.
PR/41028.

/src/share/misc/
H A Dacronyms1.276 Wed Dec 12 22:27:03 GMT 2018 dholland +DYAC

/src/sys/arch/alpha/alpha/
H A Dpmap.c1.276 Sat Apr 03 15:29:02 GMT 2021 thorpej branches: 1.276.2; 1.276.4;
Slight tweak to last: Our IPL gets raised to IPL_SCHED by simply *trying*
to acquire the pmap activation lock, regardless of whether or not that was
successful. So, in addition to remember if we acquired it, also remember
if we tried, and drop back to IPL_VM if so.

1.276 Sat Apr 03 15:29:02 GMT 2021 thorpej branches: 1.276.2; 1.276.4;
Slight tweak to last: Our IPL gets raised to IPL_SCHED by simply *trying*
to acquire the pmap activation lock, regardless of whether or not that was
successful. So, in addition to remember if we acquired it, also remember
if we tried, and drop back to IPL_VM if so.

1.276 Sat Apr 03 15:29:02 GMT 2021 thorpej branches: 1.276.2; 1.276.4;
Slight tweak to last: Our IPL gets raised to IPL_SCHED by simply *trying*
to acquire the pmap activation lock, regardless of whether or not that was
successful. So, in addition to remember if we acquired it, also remember
if we tried, and drop back to IPL_VM if so.

/src/lib/libc/
H A Dshlib_version1.276 Wed Aug 16 21:32:23 GMT 2017 joerg Bump libc minor to 208 for strfmon_l.
/src/distrib/sets/lists/etc/
H A Dmi1.276 Sun Dec 29 09:47:49 GMT 2024 jmmv Don't install /etc/rc.d/postfix when MKPOSTFIX=no
/src/doc/
H A DBRANCHES1.276 Sun Feb 08 21:46:04 GMT 2009 jym Document jym-xensuspend branch.

/src/sys/net/
H A Dif_ethersubr.c1.276 Wed Jul 17 03:26:24 GMT 2019 msaitoh branches: 1.276.2;
Implement VLAN hardware filter function(ETHERCAP_VLAN_HWFILTER).
First proposed by jmcneill in 2017 and modified by me.

How to use:

- Set callback function:

ether_set_vlan_cb(struct ethercom *, ether_vlancb_t)

- Callback. This function is called when a vlan is attached/detached to the
parent interface:

int (*ether_vlancb_t)(struct ethercom *ec, uint16_t vlanid, bool set);

- ifconfig(8)

ifconfig ixg0 [-]vlan-hwfilter

Note that ETHERCAP_VLAN_HWFILTER is set by default on ixg(4) because
the PF driver usually enable "all block" filter by default.

1.276 Wed Jul 17 03:26:24 GMT 2019 msaitoh branches: 1.276.2;
Implement VLAN hardware filter function(ETHERCAP_VLAN_HWFILTER).
First proposed by jmcneill in 2017 and modified by me.

How to use:

- Set callback function:

ether_set_vlan_cb(struct ethercom *, ether_vlancb_t)

- Callback. This function is called when a vlan is attached/detached to the
parent interface:

int (*ether_vlancb_t)(struct ethercom *ec, uint16_t vlanid, bool set);

- ifconfig(8)

ifconfig ixg0 [-]vlan-hwfilter

Note that ETHERCAP_VLAN_HWFILTER is set by default on ixg(4) because
the PF driver usually enable "all block" filter by default.

Completed in 305 milliseconds

123456