241003 |
27-Sep-2012 |
trociny |
MFC r240595:
In snmp_hostres, device_map table is used for consistent device table indexing. When a device has gone it is not removed from device_map table but just its entry_p field is set to NULL.
So when traversing device_map in disk_OS_get_ATA_disks() and disk_OS_get_MD_disks() check for entry_p being NULL, otherwise the bsnmpd crash is possible when a removed map entry is dereferenced.
Before the fix, for disk_OS_get_ATA_disks() the crash could be easily reproduced running:
atacontrol detach ata1
The crash was not observed in disk_OS_get_MD_disks() because currently snmp_hostres does no see md(4) disks: to get the device list it uses devinfo(3), which does not return md devices.
Reported by: Miroslav Lachman 000.fbsd quip.cz
|
223933 |
11-Jul-2011 |
ae |
Use full buffer size in read(2) call, there is no need to preserve the last byte of the buffer.
Since we call refresh_device_tbl() for any devctl event types - no need to check the first byte of buffer. Remove these checks.
Also remove logging for the case of unknown devd message. It incorrectly triggers when all devctl events are not fit into one buffer and part of unread data will be read in the next pass.
When length of data readed from devctl is equal to sizeof(buf), then try to read from socket again, to read full data.
MFC after: 2 weeks
|
214489 |
28-Oct-2010 |
uqs |
Fix CPU load reporting independent of scheduler used.
- Sample CPU usage data from kern.cp_times, this makes for a far more accurate and scheduler independent algorithm. - Rip out the process list scraping that is no longer required. - Don't update CPU usage sampling on every request, but every 15s instead. This makes it impossible for an attacker to hide the CPU load by triggering 4 samplings in short succession when the system is idle. - After reaching the steady-state, the system will always report the average CPU load of the last 60 sampled seconds. - Untangling of call graph.
PR: kern/130222 Tested by: Julian Dunn <jdunn@aquezada.com> Gustau Pérez <gperez@entel.upc.edu> Jürgen Weiß <weiss@uni-mainz.de> MFC after: 2 weeks
I'm unsure if some MIB standard states this must be the load average for, eg. 300s, it looks like net-snmp isn't even bothering to implement the CPU load reporting at all.
|