a locked route. Thus we have to use RTFREE_LOCKED(9) to get it unlocked
and rtfree(9)d rather than just rtfree(9)d.
Since the PR was filed, new places with the same problem were added
with new code. Also check that the rt is valid before freeing it
either way there.
PR: kern/129793
Submitted by: Dheeraj Reddy <dheeraj@ece.gatech.edu>
MFC after: 2 weeks
Committed from: Bugathon #6
This ensures that the value written is both compatible with
older mtree versions (which expect the value after the period
to be an integer count of nanoseconds after the whole second)
and is a correct floating-point value.
Leave the parsing code unchanged so it will continue to read
older files.
Leave then in struct vinet6 to not break the ABI with kernel modules
but mark them for removal so we can do it in one batch when the time
is right.
MFC after: 1 month
Bluetooth Network Access Point (NAP), Group Ad-hoc Network (GN) and
Personal Area Network User (PANU) profiles.
Obtained from: NetBSD
MFC after: 1 month
the example script of the manpage feeds awk(1) with values larger
than UINT32_MAX. Then awk prints a negative value, and this
messes up $BPFPROG. Trying to load the resulting bpf byte codes
with ngctl then fails.
For example, the output for PATTERN="udp and dst net 255.255.0.0/16"
should be (all in one line):
bpf_prog_len=10
bpf_prog=[
{ code=40 jt=0 jf=0 k=12 }
{ code=21 jt=7 jf=0 k=34525 }
{ code=21 jt=0 jf=6 k=2048 }
{ code=48 jt=0 jf=0 k=23 }
{ code=21 jt=0 jf=4 k=17 }
{ code=32 jt=0 jf=0 k=30 }
{ code=84 jt=0 jf=0 k=4294901760 }
{ code=21 jt=0 jf=1 k=4294901760 }
{ code=6 jt=0 jf=0 k=8192 }
{ code=6 jt=0 jf=0 k=0 }
]
The two k=4294901760 values are displayed as k=-2147483648 by awk.
Replace the awk script of the manpage example with a slower but
safer version, that doesn't really attempt to convert the byte
code printed by tcpdump from string to number and back.
PR: docs/123255
Submitted by: Eugenio Maffione, eugenio.maffione at telecomitalia.it
MFC after: 3 days
but the man page describes conceptual information about the process of
adding a user, thus it should belong to section 7.
- Remove HISTORY and BUGS sections because of the aforementioned reason.
PR: docs/130151
Submitted by: Marian Cerny <jojo@matfyz.cz>
MFC after: 3 days
work ok in C++. Note that we enable this only for gcc 4.x for any value
of x. The __null was introduced in gcc 4.1 (in fact it was commited
12 days after release of gcc 4.0) and as we have never released any version
of FreeBSD with gcc 4.0 nor ports support gcc 4.0.x this is a safe check.
Using __GNUC_PREREQ__ would require us to include cdefs.h in params.h so
we just check __GNUC__.
Approved by: kib (mentor)
Tested by: exp build of ports (done by pav)
Tested by: make universe (done by me)
more irqs as we have more cpus. This is principally useful on systems
with msi devices which may want many irqs per-cpu.
Discussed with: jhb
Sponsored by: Nokia
32-bit processes. The value matches the initial setting used by
FreeBSD/i386. Otherwise, 32-bit binaries using floating point would use
a slightly different initial state when run on FreeBSD/amd64.
MFC after: 1 week
After running a `make buildkernel', I noticed most of the Giant locks in
sysctl are only caused by a very small amount of sysctl's:
- sysctl.name2oid. This one is locked by SYSCTL_LOCK, just like
sysctl.oidfmt.
- kern.ident, kern.osrelease, kern.version, etc. These are just constant
strings.
- kern.arandom, used by the stack protector. It is already protected by
arc4_mtx.
I also saw the following sysctl's show up. Not as often as the ones
above, but still quite often:
- security.jail.jailed. Also mark security.jail.list as MPSAFE. They
don't need locking or already use allprison_lock.
- kern.devname, used by devname(3), ttyname(3), etc.
This seems to reduce Giant locking inside sysctl by ~75% in my primitive
test setup.
o no need for special country codes; it's sufficient to use the sku
o no need to specify bands w/ 2.4G frequencies, use the real values
o remove duplicate band specs
