- MP-safe drivers provide a mutex to ifmedia that is used to serialize
access to media-related structures / hardware regsiters. Converted
drivers use the new ifmedia_init_with_lock() function for this. The
new name is provided to ease the transition.
- Un-converted drivers continue to call ifmedia_init(), which will supply
a compatibility lock to be used instead. Several media-related entry
points must be aware of this compatibility lock, and are able to acquire
it recursively a limited number of times, if needed. This is a SPIN
mutex with priority IPL_NET.
- This same lock is used to serialize access to PHY registers and other
MII-related data structures.
The PHY drivers are modified to acquire and release the lock, as needed,
and assert the lock is held as a diagnostic aid.
The "usbnet" framework has had an overhaul of its internal locking
protocols to fit in with the media / mii changes, and the drivers adapted.
USB wifi drivers have been changed to provide their own adaptive mutex
to the ifmedia later via a new ieee80211_media_init_with_lock() function.
This is required because the USB drivers need an adaptive mutex.
Besised "usbnet", a few other drivers are converted: vmx, wm, ixgbe / ixv.
mcx also now calls ifmedia_init_with_lock() because it needs to also use
an adaptive mutex. The mcx driver still needs to be fully converted to
NET_MPSAFE.
and all the structures that include it.
this should not change anything while avoiding packed vs alignment
warnings from GCC 8, and potentially pessimised code generation
due to the packed marker (there are no misaligned members, just
that the per-device parts may end unaligned.)
all consumers of these members are done from the properly aligned
packet members directly, or, as a union with a 64 byte member,
also properly aligned. codegen didn't appear to change, except
for the definition of sizeof(struct driver_[rt]x_radiotap_header)
in debug info, which is not directly used anywhere.
<subsystem>_<function>_<version>_hook
NFCI
XXX Note that although this introduces a change in the kernel-to-
XXX module interface, we are NOT bumping the kernel version number.
XXX We will bump the version number once the interface stabilizes.
entry point (such as ioctl) instead.
- Attempt to autoload the module before using it.
Naming: Should the names of the hooks be:
<category>_<version>_<function>_hook_t
or:
<category>_<function>_<version>_hook_t
We should make those consistent.
These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.
HOWEVER! Some subsystems have
#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))
even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.
To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.
I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:
cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))
It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.
Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)
compatibility with BIOC[GS]SEESENT ioctl. The userland interface is the same
as FreeBSD.
This change also fixes a bug that the direction is misunderstand on some
environment by passing the direction to bpf_mtap*() instead of checking
m->m_pkthdr.rcvif.
* Make the code more readable.
* Add a panic in ieee80211_compute_duration(). I'm not sure there's
a bug here - I don't have the hardware -, but looking at the code, it
may be possible for 'paylen' to go negative. Obviously that's not the
correct way to fix it, but at least we'll see if it happens.
* Make the code more readable. In particular, declare variables as const
along the way.
* Explain what we're doing in ieee80211_send_mgmt(). The
IEEE80211_FC0_SUBTYPE_PROBE_RESP case has some inconsistencies, but
they are not inherently wrong so I'm not changing that.
* When sending IEEE80211_FC0_SUBTYPE_REASSOC_RESP frames, make sure to
zero out the 'association ID', otherwise two bytes are leaked.
* Fix a possible memory leak in ieee80211_send_probereq().
* They call M_PREPEND, but don't pass the updated pointer back to the
caller.
* They use memmove on the mbuf data, but they don't ensure that the
area they touch is contiguous.
This fix is not complete, ieee80211_crypto_encap too needs to pass back
the updated pointer. This will be done in another commit.
* Style in several places, to make the code more readable or easier to
understand.
* Instead of checking m->m_pkthdr.len, check m->m_len. m_pkthdr.len is
the total size of the packet, not the size of the current mbuf (which
may be smaller).
* Add a missing length check when handling QoS frames.
* Cast the lengths passed in IEEE80211_VERIFY_LENGTH to size_t.
* Remove the length check on scan.sp_xrates, that I added yesterday.
xrates gets silently truncated in ieee80211_setup_rates().
* Fix several buffer overflows in the parsers of the MANAGEMENT frames.
