had been replied, the reply was always delivered to the originator
synchronously.
With introduction of netgraph item callbacks and a wait channel with
mutex in ng_socket(4), we have fixed the problem with ngctl(8) returning
earlier than the command has been proceeded by target node. But still
ngctl(8) can return prior to the reply has arrived to its node.
To fix this:
- Introduce a new flag for netgraph(4) messages - NGM_HASREPLY.
This flag is or'ed with message like NGM_READONLY.
- In netgraph userland library if we have sent a message with
NGM_HASREPLY flag, then select(2) until reply comes.
- Mark appropriate generic commands with NGM_HASREPLY flag,
gathering them into one enum {}. Bump generic cookie.
when checking whether it's greater than a struct stat st_size in order
to also catch the case when st_size is -1. Previously this check didn't
trigger on sparc64 when st_size is -1 (as it's the case for a file on
a bzipfs, TFTP server etc.), causing the content of the linker hints
file to be copied to memory referenced by a null-pointer.
PR: 91231
MFC after: 1 week
operands are consumed so use the appropriate constraint modifier.
Before this change GCC used one register for both an input and an
unrelated output operand of in_addword(), causing the input to be
overwritten before it was consumed and thus breaking in_addword().
For in_cksum_hdr() and in_pseudo() this change is more or less
cosmetic.
- Fix a misspelling in a nearby comment.
Reported & tested by: yongari
MFC after: 1 week
* Add posix_memalign().
* Move calloc() from calloc.c to malloc.c. Add a calloc() implementation in
rtld-elf in order to make the loader happy (even though calloc() isn't
used in rtld-elf).
* Add _malloc_prefork() and _malloc_postfork(), and use them instead of
directly manipulating __malloc_lock.
Approved by: phk, markm (mentor)
The minimum / maximum speed was way too low / high!
minspeed = 2000 - is this for real ?
maxspeed = 767999 - is this for real ?????
Wrap everything into 8000 - 48000 boundary, just to be safe.
MFC after: 3 days
ldconfig. Build the cache in a temporary directory and only install it
if it's actually different that the installed one.
Also, use "cat tmp > real" to install the temporary file in the real
location to allow the real location to be a symlink to a writable
directory such as /var/run (where the file actually belongs).
MFC After: 5 days
Correct insecure temporary file usage in ee. [06:02]
Correct a race condition when setting file permissions, sanitize file
names by default, and fix a buffer overflow when handling files
larger than 4GB in cpio. [06:03]
Fix an error in the handling of IP fragments in ipfw which can cause
a kernel panic. [06:04]
Security: FreeBSD-SA-06:01.texindex
Security: FreeBSD-SA-06:02.ee
Security: FreeBSD-SA-06:03.cpio
Security: FreeBSD-SA-06:04.ipfw
- Mark MPSAFE since most of the locking procedures already implemented.
- Turn on inverted external amplifier sense flag for selected boards.
Tested by: bland
MFC after: 1 week
attempted to cast a struct ifnet to a struct fw_com which resulted in
data corruption.
PR: kern/91307
Submitted by: Alex Semenyaka <alex at semenyaka do ru>
MFC After: 6 days
in the first place).
- Add some XXX lines as a TODO.
- Add a cvs diff command to the generated commit script.
- Add cdiff/colordiff to the list of optional dependencies.
- Fix a problem when giving the commit mail without the headers to
mfc.pl -f, it should now work correctly.
- Bump version.
Approved by: ssouhlal (implicit)
operations before returning. Point the bus at a dummy cam_sim
structure so that any CCBs will complete immediately with a
CAM_DEV_NOT_THERE status, and ensure that any xpt_schedule() calls
on the bus's devices will immediately call the peripheral's
periph_start() routine. Also repeat the async messages because
devices that were part of the way through being probed may appear
after the original AC_LOST_DEVICE was sent, and would otherwise
never go away.
These changes make it possible to deregister a bus and free the SIM
at most stages during bus probing without the usual crashes in
camisr(). In particular, plugging in a umass device and then
unplugging it as soon as the first probe messages appeared would
almost always result in a crash. Now the device just goes away with
a few CAM errors and all references to the CAM bus, target and
device are dropped correctly.
- Only update the rx ring consumer pointer after running through the rx loop,
not with each iteration through the loop.
- If possible, use a fast interupt handler instead of an ithread handler. Use
the interrupt handler to check and squelch the interrupt, then schedule a
taskqueue to do the actual work. This has three benefits:
- Eliminates the 'interrupt aliasing' problem found in many chipsets by
allowing the driver to mask the interrupt in the NIC instead of the
OS masking the interrupt in the APIC.
- Allows the driver to control the amount of work done in the interrupt
handler. This results in what I call 'adaptive polling', where you get
the latency benefits of a quick response to interrupts with the
interrupt mitigation and work partitioning of polling. Polling is still
an option in the driver, but I consider it orthogonal to this work.
- Don't hold the driver lock in the RX handler. The handler and all data
associated is effectively serialized already. This eliminates the cost of
dropping and reaquiring the lock for every receieved packet. The result
is much lower contention for the driver lock, resulting in lower CPU usage
and lower latency for interactive workloads.
The amount of work done in the taskqueue is controlled by the sysctl
dev.em.N.rx_processing_limit
and tunable
hw.em.rx_process_limit
Setting these to -1 effectively removes the limit.
The fast interrupt and taskqueue can be disabled by defining NO_EM_FASTINTR.
This work has been shown to increase fast-forwarding from ~570 kpps to
~750 kpps (note that the same NIC hardware seems unable to transmit more than
800 kpps, so this increase appears to be limited almost solely by the
hardware). Gains have been shown in other workloads, ranging from better
performance to elimination of over-saturation livelocks.
Thanks to Andre Opperman for his time and resources from his network
performance project in performing much of the testing. Thanks to Gleb
Smirnoff and Danny Braniss for their help in testing also.
probe
Before:
5 *
freebsd (195.250.137.134) 19.086 ms 24.694 ms
After:
5 * freebsd (195.250.137.134) 19.086 ms 24.694 ms
Fixes: bin/90098
Reported by: Jeremy Chadwick <freebsd@jdc.parodius.com>
Approved by: andre
MFC after: 1 day
