linuxulator: Return EINVAL for invalid inotify flags
We implement all of the currently-defined Linux inotify mask bits and
flags, with the same values as Linux. Return EINVAL for unknown bits,
as Linux does.
This also moves the translation inline into linux_inotify_add_watch.
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57387
(cherry picked from commit f77d37cffdf3951b7f28b97005467241aa27c183)
ipfilter: Fix ip_pptp_pxy (PPTP proxy) length underflow
A PPTP client sending a specially crafted PPTP message with a length
smaller than the already processed fixed header can panic the system.
This resultes in a negative remaining length (a large unsigned 16-bit
number).
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.1 from
Z.ai
Differential Revision: https://reviews.freebsd.org/D57383
(cherry picked from commit 37e9d3641ba0e0da0d2bbaa26a59ee56a8cf3ee6)
krb5: Fix null dereference in SPNEGO token processing
krb5 1.22.1 erroneously removed a check from get_negTokenResp() for
successful decoding of the mechListMIC field. Restore the check to
prevent a null pointer dereference.
Commit message details obtained from upstream commit.
Obtained from: Upstream commit 4ae75cded
(cherry picked from commit efb5c07f91c5c11fb9bd32227ac74c2d08adf3cf)
ipfilter: Fix ip_pptp_pxy (PPTP proxy) length underflow
A PPTP client sending a specially crafted PPTP message with a length
smaller than the already processed fixed header can panic the system.
This resultes in a negative remaining length (a large unsigned 16-bit
number).
Reported by: Yuxiang Yang, Yizhou Zhao, Ao Wang, Xuewei Feng, Qi Li,
and Ke Xu from Tsinghua University using GLM-5.1 from
Z.ai
Differential Revision: https://reviews.freebsd.org/D57383
(cherry picked from commit 37e9d3641ba0e0da0d2bbaa26a59ee56a8cf3ee6)
krb5: Fix reachable assert when importing krb5 names
If a name token contains trailing garbage, error out from
krb5_gss_import_name() instead of crashing the process with an
assertion failure.
Commit message details obtained from upstream commit.
Obtained from: upstream commit 07818f1fd
Reported by: Aisle Research (Ze Sheng, Dmitrijs Trizna,
Luigino Camastra, Guido Vranken) to krb5-bugs
MFC after: 3 days
(cherry picked from commit fce16f60de9718be6b789f00e86141a84cd920d3)
ntsync(9): do not double-free obj when finstall() failed
Reported by: Alex S <iwtcex at gmail.com>
Sponsored by: The FreeBSD Foundation
MFC after: 3 days
netlink: Indicate that ifinfomsg uses IFT_* types
On Linux struct ifinfomsg uses ARPHRD_* values, while we used IFT_*
types (which derive from SNMP ifType definitions in RFC 1573).
Update the header to reflect this.
PR: 272144
Reviewed by: pouria
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D57334
if_bnxt: add bnxt logger module files to sys/conf/files for built-in kernel builds
The bnxt snapdump and coredump support patches added bnxt_log/{_data}.c. and listed it in
sys/modules/bnxt/bnxt_en/Makefile, but missed to add these files in sys/conf/files.
Fix up the issue by adding bnxt_log/{_data}.c in sys/conf/files.
Fixes: f85e66e655c9 ("if_bnxt/bnxt_re: add support for driver snapdump")
if_bnxt: Add support for HWRM passthrough with multiple DMA buffers
Added support for HWRM passthrough commands with multiple DMA buffers.
Also, changed the mgmt_lock to sleepable exclusive lock.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56686
if_bnxt: Fix the Unknown command 0x80000000 ioctl command error
With the latest niccli version, user will observe below
Unknown command command error when try to list the devices.
if_bnxt: Unknown command 0x80000000
Here, niccli is issuing command opcode as 0x80000000 but
driver is expecting 0x20000000 command opcode.
So, replaced _IOW(0,0,0) with the _IOC(IOC_IN,0,0,0).
Fixes: d53d7b4 ("bnxt: Fix up ioctl opcodes to support IOC_VOID along with IOC_IN")
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56685
if_bnxt: Add Firmware crashdump collection support
This patch adds support for DDR-based firmware coredump memory handling.
It detects firmware coredump capability, allocates host DDR (DMA) memory
for crash dumps, and programs the firmware with the allocated memory during
attach. The allocated memory is released during driver detach.
Also, This patch adds functions to retrieve crash dump data from host DDR
memory. The implementation handles data copying from page tables and
checks dump availability. Main function bnxt_get_coredump() copies
stored crash dump data from DDR memory to the application buffer.
MFC after: 2 weeks
Reviewed by: gallatin, ssaxena
Differential Revision: https://reviews.freebsd.org/D56684
if_bnxt/bnxt_re: add support for driver snapdump
Add a logging module which helps to log and collect the driver`s
various events and state of device data structures.
APIs help modules like l2, RoCE etc. to register and
add logs into thg buffers. A segment header is added to the
data available in buffers.
The final log messages are arranged in following fashion
|SegHeader0|Data0|SegHeader1|Data1|
Logging module provides two different kinds of buffers:
a) A large contiguous memory chunk is used to form circular buffers.
Module need to provide a number of buffers while registering to
the logging module.Please note that, since memory for the
buffers remains with the module as long as it is registered, memory
footprints of the driver could be higher so the modules should
allocate an appropriate number of buffers. Also, due to limited
[21 lines not shown]
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
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
