Vararg functions have a different calling convention than regular
functions on amd64. Casting a varag function to a regular one to
match the function pointer declaration will hide the varargs from
the caller and we will end up with an incorrectly setup stack.
Entirely remove the varargs from these functions and change the
functions to match the declaration of the function pointers.
Remove the now unnecessary casts.
Lots of explanations and help from: peter
Reviewed by: peter
PR: amd64/89261
MFC after: 6 days
o fix contention window
o silently discard received frames that are too short
o simplify lookup of 802.11a channels (we know they exist)
o fix short preamble support
o add short slot support
o fix eifs settings
o many consistency tweaks
share devclass pointers, a mistake I've encouraged in the past) and
move the declaration of the pci_driver kobj class from cardbus.c to
pci_private.h so that other drivers can inherit from pci_driver.
devclass's parent pointer if the two drivers share the same devclass. This
can happen if the drivers use the same new-bus name. For example, we
currently have 3 drivers that use the name "pci": the generic PCI bus
driver, the ACPI PCI bus driver, and the OpenFirmware PCI bus driver. If
the ACPI PCI bus driver was defined as a subclass of the generic PCI bus
driver, then without this check the "pci" devclass would point to itself
as its parent and device_probe_child() would spin forever when it
encountered the first PCI device that did have a matching driver.
Reviewed by: dfr, imp, new-bus@
went away in the generated files? This didn't happen on my amd64
test machine but did when I committed it on my other i386 machine.
I need to figure this out since a regen on the amd64 doesn't fix it
now. For now make the build work again. Matt caught this before
my local mirror caught up.
This fixes reconnect after, for example, tcp idle disconnection.
Previously this would fail if a normal user tried to bind to a privileged
port.
Submitted by: cel@citi.umich.edu
MFC after: 1 week
hacking:
- Remove all spaces at eol.
- Improve style(9) in most frequently edited functions.
- In em_encap() push variables for 82544 workaround in the block
where they are only used.
- In em_get_buf() remove unused variable.
errors from rn_inithead back to the ipfw initialization function.
- Check return value of rn_inithead for failure, if table allocation has
failed for any reason, free up any tables we have created and return ENOMEM
- In ipfw_init check the return value of init_tables and free up any mutexes or
UMA zones which may have been created.
- Assert that the supplied table is not NULL before attempting to dereference.
This fixes panics which were a result of invalid memory accesses due to failed
table allocation. This is an issue mainly because the R_Zalloc function is a
malloc(M_NOWAIT) wrapper, thus making it possible for allocations to fail.
Found by: Coverity Prevent (tm)
Coverity ID: CID79
MFC after: 1 week
but not 'fragment reassemble'), which can cause some fragments to get
inserted into the cache twice, thereby violating an invariant, and panic-
ing the system subsequently.
Reviewed by: mlaier
MFC after: 1 day
o lock the list walk
o malloc a results buffer instead of copying out one result at a time
using an on-stack buffer
o fix definition of ieee80211req_scan_result so size of variable-length
information elements is large enough to hold all possible ie's
(still only return wpa+wme, at some point may return all)
o make rssi+noise data signed; they should've been so all along
o add a bit more padding for future additions while we're here
o define a new ioctl for new api and add compat code for old ioctl
under COMPAT_FREEBSD6 (temporarily enabled local to the file)
Reviewed by: Scott Long
MFC after: 2 weeks
to have a value that's not been used before; this fixes the problem
where the first traversal of the scan list did nothing because the
entries were initialized with the current generation number (a
separate issue)
MFC after: 1 week
This fixes a bug in the previous commit.
Found by: Coverity Prevent(tm)
Coverity ID: CID253
Sponsored by: TCP/IP Optimization Fundraise 2005
MFC after: 3 days
change the mbuf pointer and we don't have any way of passing
it back to the callers. Instead just fail silently without
updating the checksum but leaving the mbuf+chain intact.
A search in our GNATS database did not turn up any match for
the existing warning message when this case is encountered.
Found by: Coverity Prevent(tm)
Coverity ID: CID779
Sponsored by: TCP/IP Optimization Fundraise 2005
MFC after: 3 days
that currently can't be triggered. But better be safe than sorry
later on. Additionally it properly silences Coverity Prevent for
future tests.
Found by: Coverity Prevent(tm)
Coverity ID: CID802
Sponsored by: TCP/IP Optimization Fundraise 2005
MFC after: 3 days
route MTU.
This bug is very difficult to reach and not remotely exploitable.
Found by: Coverity Prevent(tm)
Coverity ID: CID162
Sponsored by: TCP/IP Optimization Fundraise 2005
MFC after: 3 days
