| Age | Commit message (Collapse) | Author |
|
NUL-terminated.
Reduce target buffer to needed size (product name + NUL terminator).
|
|
|
|
if_timer is never set in this driver and so if_watchdog will never be
called.
|
|
|
|
remove them.
|
|
|
|
the device being initialized.
|
|
and RAIDFRAME_SHUTDOWN ioctls.
XXX Pullup-9
Reported-by: syzbot+1c20fcbe34d72cd7fbda@syzkaller.appspotmail.com
|
|
|
|
|
|
|
|
|
|
|
|
The minor numbers have only four bits for the unit number, so unit
numbers past 15 can't be represented as is. Attempting to revoke
them was once harmless, when the system made no attempt to avoid
open/detach races; now it crashes because vdevgone assumes that the
minor number can be mapped back to an autoconf device, but it's the
wrong one. With this change, we stop trying to revoke units beyond
15, because they can't be opened anyway (which may be a bug in its
own right, requiring expansion of the minor number encoding!).
Reported-by: syzbot+6634ffd48997ae9b1eb0@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=db40a795a0b078f9b3b9fa0d3b7a9addcd2534de
Reported-by: syzbot+d2df39bb3f72975c0a97@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=cbdd598287529cff9a8c4230263f7414df88db4b
Reported-by: syzbot+1404969f68424f8f6e4b@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=6e4782408d0351769215fe433986f1844a546774
Reported-by: syzbot+2a4174a65609b3a00abb@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=886bbee544c2337683e24c801f9b632630a24681
Reported-by: syzbot+c0d9e49f22e571650736@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=7fb2e5576ebae731e859283f85c97747d2824f35
Reported-by: syzbot+583ba2cdb8aa6e59a4bf@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=2af44f5245eba572ebfb222070b9fd1378854303
|
|
In some tunneling measurement cases, that improve performance.
In other cases, that keep up performance.
|
|
|
|
I deleted it in the previous commit, oops.
|
|
Tested up to mtu=9000. Hardware may allow up to mtu=16364
(frame length=16382), but this has not been tested.
- Separate calls to eqos_setup_rxdesc() from eqos_setup_rxbuf().
if m_getcl() fails, discard the packets received at that time
and reuse for the next buffer.
- Restore m_adj(m, ETHER_ALIGN) with limited conditions.
Only if MCLBYTES is greater than 2050, so it is not normally aligned.
|
|
Avoid confusion because some definitions are different bits with the same name for TX and RX.
no functional changes.
|
|
No kernel bump because this isn't documented or used in any modules,
only in dev/pci/pci.c and dev/cardbus/cardbus.c which are as far as I
know always statically linked into the kernel.
The next change, however, will require a revbump -- to make
pmf_device_register return void so we can prune vast swaths of dead
error branches.
|
|
Even if the jumbo frame setting is off, eqos will DMA transfer frames of
2048 bytes or more in increments of 2048 bytes if they are received.
If the start position of the mbuf data is shifted by ETHER_ALIGN bytes
in m_adj(), up to 2048 bytes of data will be written from the +ETHER_ALIGN
position, causing overflow of the mbuf cluster.
|
|
If suspend failed, at least we can stop it from blocking all
subsequent xhci commands or making a second suspend crash.
|
|
- Several registers needed to be initialized
- Add some register definitions
|
|
Instead, consult unp->unp_txstopped -- but the caller already
guarantees it is not stopped, so turn the conditional into an
assertion anyway.
|
|
This fixes a bug in the previous change to make mii_down wait for the
mii auto timeout to complete.
|
|
"IFQ_POLL() -> IFQ_DEQUEUE() on success (or fatal error)".
|
|
"IF_POLL() -> IF_DEQUEUE() on success".
|
|
no need to check-and-pullup to sizeof(struct ether_header). Instead, we
can simply assert it.
|
|
"IFQ_POLL() -> IFQ_DEQUEUE() on success (or fatal error)".
|
|
if it has too many DMA segments. Let the caller handle dispose of the
packet on fatal errors.
|
|
but DMA mapping fails to use DMA resource shortage.
|
|
"IFQ_POLL() -> IFQ_DEQUEUE() on success (or fatal error)".
|
|
if it has too many DMA segments. Let the caller handle dispose of the
packet on fatal errors.
|
|
No functional change.
|
|
This serves two purposes:
1. Pacifies data race sanitizers.
2. Ensures that we don't spuriously trip over the assertion if
dkclose happens concurrently with dkopen due to a revoke call.
|
|
dkfirstopen relies on reading from dk_openmask of _other_ wedges,
writes to dk_openmask must be serialized by dk_rawlock in addition to
dk_openlock. (However, reads from dk_openlock only require one or
the other).
|
|
|
|
This never fails, as is asserted in vn_lock whenever LK_RETRY is set
and LK_NOWAIT is not.
|
|
|
|
No functional change intended.
|
|
It is not possible for us to be closing a wedge whose parent is not
open by at least this wedge.
|
|
Makes the logic more clearly pair with dklastclose.
|
|
|
|
No need to take it if we're not actually going to close the parent.
No functional change intended; dk_rawlock is only supposed to
serialize dk_rawopens access and open/close of the parent, after all.
|
|
No functional change intended.
|
|
No longer necessary to have this unbalanced logic now that
dk_close_parent correctly happens under the lock in order to
serialize with dk_open_parent.
No functional change intended.
|
|
Otherwise, the following events might happen:
- process 123 had /dev/rdkN open, starts close, enters dk_close_parent
- process 456 opens /dev/rdkM (same parent, different wedge), calls
dk_open_parent
At this point, the block device hasn't yet closed, so dk_open_parent
will fail with EBUSY. This is incorrect -- the chardev is never
supposed to fail with EBUSY, and dkopen/dkclose carefully manage
state to avoid opening the block device while it's still open. The
problem is that dkopen in process 456 didn't wait for vn_close
in process 123 to finish before calling VOP_OPEN.
(Note: If it were the _same_ chardev /dev/rdkN in both processes,
then spec_open/close would prevent this. But since it's a
_different_ chardev, spec_open/close assume that concurrency is OK,
and it's the driver's responsibility to serialize access to the
parent disk which, unbeknownst to spec_open/close, is shared between
dkN and dkM.)
It appears that the vn_close call was previously moved outside
dk_rawlock in 2010 to work around an unrelated bug in raidframe that
had already been fixed in HEAD:
Crash pointing to dk_rawlock and raidclose:
https://mail-index.netbsd.org/tech-kern/2010/07/27/msg008612.html
Change working around that crash:
https://mail-index.netbsd.org/source-changes/2010/08/04/msg012270.html
Change removing raidclose -> mutex_destroy(&dk_rawlock) path:
https://mail-index.netbsd.org/source-changes/2009/07/23/msg223381.html
|
|
"IFQ_POLL() -> IFQ_DEQUEUE() on success (and fatal-to-packet errors)".
|
|
act on fatal packet errors in jme_ifstart().
|
|
all over the place (just assign m = *m_head earlier). NFCI.
|