per-CPU cache statistics. UMA sizes the cache array based on the
number of CPUs at boot (mp_maxid + 1), and iterating based on MAXCPU
could read off the end of the array (into the next zone).
Reported by: yongari
MFC after: 1 week
it covers the following of the uc_alloc/freebucket cache pointers.
Originally, I felt that the race wasn't helped by holding the mutex,
hence a comment in the code and not holding it across the cache access.
However, it does improve consistency, as while it doesn't prevent
bucket exchange, it does prevent bucket pointer invalidation. So a
race in gathering cache free space statistics still can occur, but not
one that follows an invalid bucket pointer, if the mutex is held.
Submitted by: yongari
MFC after: 1 week
variables rather than void * variables. This makes it easier and simpler
to get asm constraints and volatile keywords correct.
MFC after: 3 days
Tested on: i386, alpha, sparc64
Compiled on: ia64, powerpc, amd64
Kernel toolchain busted on: arm
New sysctls: kern.malloc_stats and vm.zone_stats,
mpt(4) improvements,
ifconfig(8) -k flag,
libmemstat(3) added,
libpcap updated to v0.9.1, and
tcpdump updated to v3.9.1.
MEMSTAT_MAXCALLER (8), and expose MEMSTAT_MAXCALLER via memstat.h so
that applications can check their assumptions about how many slots
are available.
Remove 'spare' memory storage in struct malloc_type, since we now
don't expose the data structure internals to applications and rely
on accessor methods, this approach to ABI stability isn't required.
MFC after: 7 days
the case of an RTM_CHANGE was specific, i.e. that it matched completely. This
led to a route change of a non-existent route changing the default route
as the radix code would simply back track to that point and hand that
route back to the routing socket code.
PR: 82974
Reviewed by: Tai-hwa Liang <avatar@mmlab.cse.yzu.edu.tw>
Ben Kaduk <minimarmot@gmail.com>
Bjoern A. Zeeb <bzeeb-lists@lists.zabbadoz.net>
Obtained from: OpenBSD with modifications.
MFC after: 2 weeks
succeed. There are many printers that return status over the read
channel, and if we wait for the status to become ready, then we can't
find the status automatically. Linux doesn't wait, nor does it ever
seem to really check the status in any meaningful way... If there
really is a problem, the writes to the bulk out endpoint will still
fail (like they would if the printer was ready and then ran out of
paper or became unready).
In addition, there are a number of printers being made that emulate
the 'status' byte by returning '0' always rather than '0x18'. This
fixes the EBUSY on open timeouts on those printer as well.
Reviewed by: the defining silence on usb@
