1. membar_sync is not necessary here -- only a store-release is
required.
2. membar_consumer _before_ loading l->l_pflag is not enough; a
load-acquire is required.
Actually it's not really clear to me why any barriers are needed, since
the store-release and load-acquire should be implied by releasing and
acquiring the lwp lock (and maybe we could spin with the lock instead
of reading l->l_pflag unlocked). But maybe there's something subtle
about access to l->l_mutex that's not obvious here.
- The ratecheck() is for just in case. All of the interrupts might occur
only once, but I don't know whether it's true or not. For the fan failure,
it seems it occurs only once.
- All of the interval is 60s.
- This change might fix small race between ifconfig down and an interrupt.
If the race really exists, txeof() is called and it's not so dangerous.
The rxeof is blocked in the beginning of ixgbe_handle_que().
- This change makes consistent with ixgbe_handle_que().
- Found and OK'd by knakahara.
We may still need a mechanism to serialize access to the portsc
registers between xhci_roothub_ctrl and xhci_suspend/resume, but the
bus lock is no longer that, and holding the bus lock across
usb_delay_ms may lead to deadlock by blocking the softints that wake
usb_delay_ms.
This doesn't work -- polling mode only works when all other CPUs are
quiesced and the current one is running sequentially without
preemption.
Also not clear whether this does anything useful. Maybe we need a
mechanism to block new xfers until resumed, but this wasn't that.
This no longer serializes access to the portsc registers, also used
by ehci_roothub_ctrl, but it does pose a potential deadlock with
softints to wake usb_delay_ms. So the bus lock doesn't help here,
and may cause deadlock.
This isn't quite correct, but it avoids a deadlock:
- *_roothub_ctrl holds bus lock, waits in usb_delay_ms for kpause
- softint waits for bus lock, holds up kpause wakeup
The deadlock is new since recent changes to hold the bus lock over
upm_start/upm_transfer. Making this change regresses to other
problems:
- *_suspend/resume and *_roothub_ctrl often touch the same portsc
registers
- roothub_ctrl_abort needs to wait for ubm_rhctrl to complete.
When the bus lock was held across both, a noop served here, but we
can't hold the bus lock across both, so that doesn't work.
However, these problems -- which we've had for a long time -- seem to
be less bad than the deadlock. So let's avoid the deadlock for now
and then work out another way to serialize suspend/resume/rhctrl and
aborts.
Candidate fix for PR kern/56739.
Refactoring work in man.c r. 1.40 from twelve years ago introduced a
regression where input from the -m option was appended rather than
prepended to the search paths. Problem reported by C. Chapman on
netbsd-users.
This is written under proc_lock and read without it in usb_add_event,
so using atomics pacifies the sanitizer. No memory ordering needed
because the value isn't actually used until the softint runs, using
it under proc_lock. Kind of a micro-optimization, but let's avoid
contention on proc_lock in the common case of no usb_async_proc set
up (why is this a system global, anyway? and why is there a softint
if usb_add_event always runs at IPL_NONE?).
Reported-by: syzbot+1b2fa68535e5b0f3dcaa@syzkaller.appspotmail.com
riastradh