mwl: return ENOMEM when rx buffer allocation fails
The malloc() failure path returned error, which is 0 at this point,
so callers would treat the allocation failure as success.
Return ENOMEM instead to correctly propagate the out-of-memory condition.
Reviewed by: adrian
Differential Revision: https://reviews.freebsd.org/D42282
kldload: Improve error handling
Address a failure in linker_load_module (sys/kern/kern_linker.c) to
verify that an already-loaded module matches the version requirement,
which caused the method to return the error (EEXIST). This was then
propagated back up to kldload, which incorrectly printed that the module
had already been loaded.
Add a lookup to modlist_lookup2 to distinguish between the two cases:
- A module is already loaded that is of the correct version, so the
error EEXIST should be returned
- An already-loaded module is of the incorrect version, so the error
ENOEXEC is returned (changed from ENOENT)
Reviewed by: imp, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57002
net/pecl-oauth2: Rename to net/php-oauth
Rename to avoid confusion between implemented protocol and library
version. Also, pecl repository is deprecated.
PR: 295762
Sponsored by: UNIS Labs
LinuxKPI: 802.11: lock down mac80211 downcalls
Add lock assertions and "might_sleep" annotations to various
mac80211 operation downcalls into the driver.
Make sure the code to these is all covered by locks--pushing more wiphy
lock into the code--or lock assertions as well. Split up parts of the
MC code up into an unlocked and locked version to avoid recurive locking.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
mt76: mt7921: depend on lindebugfs and turn debugfs support on
Add the missing MODULE_DEPEND() calls for lindebugfs.
It is unfortunate that they are shared code between various bus
implementations. Ideally we would leave the MODULE_DEPEND() calls
in the debugfs.c file instead of adding extra #ifdef guards to the
bus attachment files.
Turn debugfs support on for mt76(core) and the mt7921 module for now.
Sponsonred by: The FreeBSD Foundation
MFC after: 3 days
mt76: mt7921: terminate fw log messages with \n
In order to make the firmware messages spewed on the console readable
write one message per line and not one very long line.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
mt76: ensure net80211 com instance before returning from driver load
Do as we have done for iwlwifi (f808c43ad923, bee60c989745) add a
completion event for device registration which calls into 802.11
and creates the wifi "device" (net80211 com instance).
This is needed as otherwise the deferred work in the mt76 drivers
(mt7915, mt7921, mt7925, mt7996; but not the 7615 [*]) would make
driver loading return before the wifi device is there. We would then
continue, e.g., during rc startup and race possibly trying to create
a vap (wlan interface) with the underlying device not being registered
yet and fail.
[*] the 7615 does not seem to do this asynchronously so is fine.
Sponsored by: The FreeBSD Foundation
Tested on: 7921, others to be tested at time
MFC after: 3 days
callout: ddb: resolve symbol of callout function
In the ddb show callout function try to resolve the symbol of the
callout function to improve debugging. In my case I went through
various callouts from show ktr to check what they were and this saved
me opening lldb/gdb next to it (and still having the old kernel as
the panic to debug was upon reboot).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: rlibby
Differential Revision: https://reviews.freebsd.org/D57521
lindebugfs: improve an error message
In case the fill function fails do not report (read/write) but the
actual operation only given we can easily determine it.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
Reviewed by: dumbbell, emaste
Differential Revision: https://reviews.freebsd.org/D57523
LinuxKPI: 802.11: force update of net80211 crypto key flags
Several drivers (rtw8x, mt76) do not announce the supported ciphers suites
in the wiphy instance. This means we never populate net80211 ic_cryptocaps
on device creation and thus not announcing any supported hw crypto
offload forcing a fallback to software crypto.
However when the mac80211 (*set_key) succeeds we know we can offload
crypto. At that point the net80211 key flags have IEEE80211_KEY_SWCRYPT
set which we want to clear. Historically the net80211 API does not
allow this though there should be no ill side effects (base on a
quick code inspection). We thus have to DECONST the key argument
for now. It is expected that with MFP support this will need to
become a common operation and the API will need to change as we
will only get the information of some details from the driver on a
per-cipher case when the (*set_key) downcall returns.
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
mt76: mt7921: prevent PM from scheduling another delayed work on detach
Amongst others mt76_connac_pm_unref() is calling mt76_connac_power_save_sched()
which will (normaly) re-schedule the pm_work.
In various parts we also cancel that work, also during PCI detach ("shutdown",
"remove" in LinuxKPI terms).
However we also keep calling mt76_connac_pm_unref() in the detach path and thus
we get to a point where we re-scheduled the work but then the device goes away.
At that point LinuxKPI delayed work has a callput pending which is embedded in
the work structure (pm_work). The moment we free the device that structure
and callout is gone but the callout is still on the list and once that list
is walked we panic.
Simply prevent mt76_connac_power_save_sched() from getting to the point of
possibly re-scheduling the pm_work by setting pm->enable to false in the
beginning of the detach path.
The are likely more paths which will need the same treatment as the code
is by far anything from "symmetric" (that is the attach path is highly
[6 lines not shown]
linudebugfs: fix simple_attr_write_common() kernel buffer
With 2cf15144daf7e we added a kernel buffer for parsing input copying the
user buffer into that. The problem is that we only copy exactly as many
bytes as the user supplied. printf 1 would have a write_size of 1, while
echo 1 would have a write_size of 2 (1\n). But in order to check and
parse we need a terminating '\0'.
Overallocate the kernel buffer by 1 and make sure it is always '\0'
terminated.
Remove the check that the string needs to be of different length than
the write_size as this will always fail unless the user passes in, e.g.,
"1\02\n\0" somehow in which case we won't bother as kstrto*ll() will
not only handle the '\n' but also stop at '\0' and should be fine or
it will fail and we will error.
In theory we could use a static buffer here as well as we know a maximum
possible length of digits plus \n and \0 and take a min of that buffer
[8 lines not shown]
LinuxKPI: 802.11: improve hw_crypto key operations
mt7921 would happily receive traffic (MC/BC) and decrypt it correctly
when hw_crypto was used but TX would only have garbled data in frames.
The problem came from the fact with keys for which we do not have an
address the driver will pick the "sta" information from different places
(driver view of sta or vif).
In the downcall this is signalled by the sta argument being NULL as
the linux keyconf has no address field.
Us passing the sta for first the pairwise key and then also for the
group key likely overwrote the pairwise key on the sta and allowed
the MC/BC RX operations to succeed anyway (the observed behaviour).
Software crypto was fully fine for mt7921 and showed no problems.
Looking some other drivers:
- iwlwifi/mld picks the ap_sta if the sta argument is NULL; thus it
[11 lines not shown]
LinuxKPI: 802.11: set undefined link in TX control info
We are not doing MLO yet so set the undefined link bit in the
TX info control message in case a driver checks if the TX would be
link specific.
Sposnored by: The FreeBSD Foundation
MFC after: 3 days
LinuxKPI: 802.11: add print masks for tx status flags
Add print masks for tx status flags and use them in the TX tracing
in order to more easily debug TX problems.
As a result it was easier to determine that some dirver like the mt7921
(or mt76) do not always zero the status bits of the tx status information
(it is a union with the control bits passed on TX) and thus we get bogus
values back (rather than having flags in a different place than we thought).
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
