provides the correct semantics for flock(2) style locks which are used by the
lockf(1) command line tool and the pidfile(3) library. It also implements
recovery from server restarts and ensures that dirty cache blocks are written
to the server before obtaining locks (allowing multiple clients to use file
locking to safely share data).
Sponsored by: Isilon Systems
PR: 94256
MFC after: 2 weeks
Bonus: including kern.mk just to pick kernel warning flags
was an extremely bad idea anyway, because it also picked
up CFLAGS (it probably wasn't the case at the time of CVS
rev. 1.1, I haven't checked). Remove duplicate CWARNFLAGS
from CFLAGS.
so we cannot compile it with -fstack-protector[-all] flags (or
it will self-recurse); this is ensured in sys/conf/files. This
OTOH means that checking for defines __SSP__ and __SSP_ALL__ to
determine if we should be compiling the support is impossible
(which it was trying, resulting in an empty object file). Fix
this by always compiling the symbols in this files. It's good
because it allows us to always have SSP support, and then compile
with SSP selectively.
Repoted by: tinderbox
- It is opt-out for now so as to give it maximum testing, but it may be
turned opt-in for stable branches depending on the consensus. You
can turn it off with WITHOUT_SSP.
- WITHOUT_SSP was previously used to disable the build of GNU libssp.
It is harmless to steal the knob as SSP symbols have been provided
by libc for a long time, GNU libssp should not have been much used.
- SSP is disabled in a few corners such as system bootstrap programs
(sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves.
- It should be safe to use -fstack-protector-all to build world, however
libc will be automatically downgraded to -fstack-protector because it
breaks rtld otherwise.
- This option is unavailable on ia64.
Enable GCC stack protection (aka Propolice) for kernel:
- It is opt-out for now so as to give it maximum testing.
- Do not compile your kernel with -fstack-protector-all, it won't work.
Submitted by: Jeremie Le Hen <jeremie@le-hen.org>
that modify condition codes (the carry bit, in this case). Without
"__volatile", the compiler might add the inline assembler instructions
between unrelated code which also uses condition codes, modifying the
latter.
This prevents the TCP pseudo header checksum calculation done in
tcp_output() from having effects on other conditions when compiled
with GCC 4.2.1 at "-O2" and "options INET6" left out. [1]
Reported & tested by: Boris Kochergin [1]
MFC after: 3 days
Now that st_rdev is being automatically generated by the kernel, there
is no need to define static major/minor numbers for the iodev and
memdev. We still need the minor numbers for the memdev, however, to
distinguish between /dev/mem and /dev/kmem.
Approved by: philip (mentor)
in_ifaddrhashtbl in in_ifinit because error handler in in_control removes
entries only for AF_INET addresses. If in_ifinit is called for the cloned
inteface that has just been created its address family is not AF_INET and
therefor LIST_REMOVE is not called for respective LIST_INSERT_HEAD and
freed entries remain in in_ifaddrhashtbl and lead to memory corruption.
PR: kern/124384
locked and unlocked completely in userland. by locking and unlocking mutex
in userland, it reduces the total time a mutex is locked by a thread,
in some application code, a mutex only protects a small piece of code, the
code's execution time is less than a simple system call, if a lock contention
happens, however in current implemenation, the lock holder has to extend its
locking time and enter kernel to unlock it, the change avoids this disadvantage,
it first sets mutex to free state and then enters kernel and wake one waiter
up. This improves performance dramatically in some sysbench mutex tests.
Tested by: kris
Sounds great: jeff
problem where Adaptec's arcconf monitoring tool hangs after producing
its expected output.
Submitted by: Adaptec, via driver ver 15317
MFC after: 1 week
from the softc.
- Rework the watchdog timer to match other NIC drivers:
- Start a timer in fe_init() that runs once a second and checks a counter
in the softc that is identical to the deprecated 'if_timer'.
- Just adjust the softc tx timeout value when sending packets instead of
scheduling the timer.
- Use IFQ_SET_MAXLEN().
Tested by: WATANABE Kazuhiro
FIFO, as required by SUSv3. No specific privilege check is performed
in this case, as FIFOs may be created by unprivileged processes
(subject to the normal file system name space restrictions that may be
in place).
Unlike the Apple implementation, we reject requests to create a FIFO
using mknod(2) if there is a non-zero dev argument to the system call,
which is permitted by the Open Group specification ("... undefined
..."). We might want to revise this if we find it causes
compatibility problems for applications in practice.
PR: kern/74242, kern/68459
Obtained from: Apple, Inc.
MFC after: 3 weeks
performed. Otherwise if ruleset is used by given mountpoint and is empty
it's freed by devfs_ruleset_reap and pointer becomes bogus.
Submitted by: Mateusz Guzik <mjguzik@gmail.com>
PR: kern/124853
some time now so collapse calls accordingly.
o Given that gem_load_txmbuf() is allowed to fail resulting in a packet
drop also for quite some time now implement the functionality of
gem_txcksum() by means of m_pullup(9), which de-obfuscates the code
and allows to always retrieve the correct length of the IP header.
o Add missing BUS_DMASYNC_PREREAD when syncing the control DMA maps in
gem_rint() and gem_start_locked().
o Correct some bus_barrier(9) calls to do a read/write barrier as we
do a read after a write. Add some missing ones in gem_mii_readreg()
and gem_mii_writereg().
o According to the Apple GMAC driver, the GEM ASIC specification and
the OpenSolaris eri(7D) the TX FIFO threshold has to be set to 0x4ff
for the Gigabit variants and 0x100 for the ERI in order do avoid TX
underruns.
o In gem_init_locked():
- be conservative and enable the RX and TX MACs,
- don't clear GEM_LINK otherwise we don't ever mark the link as up
again if gem_init_locked() is called from gem_watchdog(),
- remove superfluous setting of sc_ifflags.
o Don't bother to check whether the interface is running or whether its
queue is empty before calling gem_start_locked() in gem_tint(), the
former will check these anyway.
o Call gem_start_locked() in gem_watchdog() in order to try to get
some more packets going.
o In gem_mii_writereg() after reseting the PCS restore its configuration.
GMAC testing: grehan, marcel
MFC after: 2 weeks
on the amd64 architecture. The amd64 architecture requires kernel code and
global variables to reside in the highest 2GB of the 64-bit virtual address
space. Thus, the memory allocated during bootstrap, before the call to
kmem_init(), starts at KERNBASE, which is not necessarily the same as
VM_MIN_KERNEL_ADDRESS on amd64.
PowerPC/AIM. Consequently, it should not be used to determine the maximum
number of kernel map entries. Intead, use VM_MIN_KERNEL_ADDRESS, which marks
the start of the kernel map on all architectures.
Tested by: marcel@ (PowerPC/AIM)
KERNBASE and VM_MIN_KERNEL_ADDRESS are no longer the same, the physical
memory allocated during bootstrap will be offset from the low-end of the
kernel's page table.
address space on the amd64 architecture. The amd64 architecture
requires kernel code and global variables to reside in the highest 2GB
of the 64-bit virtual address space. Thus, KERNBASE cannot change.
However, KERNBASE is sometimes used as the start of the kernel virtual
address space. Henceforth, VM_MIN_KERNEL_ADDRESS should be used
instead. Since KERNBASE and VM_MIN_KERNEL_ADDRESS are still the same
address, there should be no visible effect from this change (yet).
That said, kris@ has tested crash dumps under the full patch that
increases the kernel virtual address space on amd64 to 6GB.
Tested by: kris@
address space on the amd64 architecture. The amd64 architecture
requires kernel code and global variables to reside in the highest 2GB
of the 64-bit virtual address space. Thus, KERNBASE cannot change.
However, KERNBASE is sometimes used as the start of the kernel virtual
address space. Henceforth, VM_MIN_KERNEL_ADDRESS should be used
instead. Since KERNBASE and VM_MIN_KERNEL_ADDRESS are still the same
address, there should be no visible effect from this change (yet).
This is needed for correct behavior when packets are lost or reordered.
PR: kern/123950
Reviewed by: andre@, silby@
Reported by: Yahoo!, Wang Jin
MFC after: 1 week
