Lower the accepted upper bound for bd_rtout to INT_MAX in order to
prevent passing negative values to timeout_add().
While here, protect against unsigned wrap around during addition of
bd_rdStart and bd_rtout since it could also cause passing negative
values to timeout_add().
Reported-by: syzbot+6771e3d6d9567b3983aa at syzkaller.appspotmail.com
Since we now have an attachhook, the actual interrupt handler is installed
late, after we enable interrupts. If the interrupt pin used for inteldrm(4)
is shared with another device, we may end up being called before the actual
interrup handler is installed resulting in a null-pointer dereference.
Fix this by adding an explicit check that the interrupt handler function
pointer has been set.
ok matthieu@, jsg@
Rename some variables in tls_decrypt_ticket().
Rename mlen to hlen since it is a hmac (and this matches hctx and hmac).
Rename ctx to cctx since it is a cipher context and ctx is usually used to
mean SSL_CTX in this code.
In unattended mode do a reboot even if things go wrong and
additionally install a watchdog to do a reboot after 30 minutes if the
script gets completely stuck.
A half upgraded system that reboots at least gives us a chance that it
will come back and we can fix it. Just having it sit there isn't
It would be nicer if the watchdog were kernel based...
implement SIOCGIFSFFPAGE so ifconfig can get transceiver info.
the controller has an i2c read operation that's almost exactly what we
want, except it only does 64 bytes at a time, so this is pretty simple.
- use NULL for pointer comparisons and assignments.
- in level comparisons, use PTP_LEVELS instead of magic constants
- eliminate some superfluous variables in pmap_free_ptp()
Since ppb(4) properly allocates bus ranges for attached devices,
the hotplug code doesn't need to do the same. Also the hotplug
code only configured a single bus and did that before the proper
allocation ran, so there was no chance for hotplugged ppb(4)s to
have children busses.