resulting in some build failures. Instead, to fix the problem of bpf not
being present, check the pointer before dereferencing it.
This is a temporary bandaid until we can decide on how we want to handle
the bpf code not being present. This will be fixed shortly.
forget to unbusy file system before its destruction.
This fixes the following warning on mount failure:
Mount point <X> had 1 dangling refs
Tested by: wkoszek
(1) bpf peer attaches to interface netif0
(2) Packet is received by netif0
(3) ifp->if_bpf pointer is checked and handed off to bpf
(4) bpf peer detaches from netif0 resulting in ifp->if_bpf being
initialized to NULL.
(5) ifp->if_bpf is dereferenced by bpf machinery
(6) Kaboom
This race condition likely explains the various different kernel panics
reported around sending SIGINT to tcpdump or dhclient processes. But really
this race can result in kernel panics anywhere you have frequent bpf attach
and detach operations with high packet per second load.
Summary of changes:
- Remove the bpf interface's "driverp" member
- When we attach bpf interfaces, we now set the ifp->if_bpf member to the
bpf interface structure. Once this is done, ifp->if_bpf should never be
NULL. [1]
- Introduce bpf_peers_present function, an inline operation which will do
a lockless read bpf peer list associated with the interface. It should
be noted that the bpf code will pickup the bpf_interface lock before adding
or removing bpf peers. This should serialize the access to the bpf descriptor
list, removing the race.
- Expose the bpf_if structure in bpf.h so that the bpf_peers_present function
can use it. This also removes the struct bpf_if; hack that was there.
- Adjust all consumers of the raw if_bpf structure to use bpf_peers_present
Now what happens is:
(1) Packet is received by netif0
(2) Check to see if bpf descriptor list is empty
(3) Pickup the bpf interface lock
(4) Hand packet off to process
From the attach/detach side:
(1) Pickup the bpf interface lock
(2) Add/remove from bpf descriptor list
Now that we are storing the bpf interface structure with the ifnet, there is
is no need to walk the bpf interface list to locate the correct bpf interface.
We now simply look up the interface, and initialize the pointer. This has a
nice side effect of changing a bpf interface attach operation from O(N) (where
N is the number of bpf interfaces), to O(1).
[1] From now on, we can no longer check ifp->if_bpf to tell us whether or
not we have any bpf peers that might be interested in receiving packets.
In collaboration with: sam@
MFC after: 1 month
fixing speed negotiation.
Also fix the mpt_execute_req function to actually
match mpt_execute_req_a64. This may explain why
i386 users were having more grief.
result, raw_uabort() now needs to call raw_detach() directly. As
raw_uabort() is never called, and raw_disconnect() is probably not ever
actually called in practice, this is likely not a functional change, but
improves congruence between protocols, and avoids a NULL raw cb pointer
after disconnect, which could result in a panic.
MFC after: 1 month
is more than one HCI node present
- Use errx(3) instead of err(3) if there is no HCI node present as errno
is 0 in this case and the resulting error message wouldn't make much sense
Approved by: emax (mentor)
If the initial buffer size (1KB) for the given group line is not big
enough, reset the offset. It helps to do not miss this line when
getrg() reallocates the larger buffer and tries to parse the line again.
PR: bin/52433, kern/55031, bin/83696, misc/97640, misc/98111
Submitted by: bsw71@mail.ru, Philip M. Gollucci, Justin Erenkrantz
Glanced at: nectar
MFC after: 1 month
setgid(2), setlogin(2) and initgroups(3). In theory they could
fail for root with some third party mac(4) policies.
Submitted by: Kostik Belousov
MFC after: 1 month
automaticly add it to an Ethernet bridge. This is intended for applications
such as qemu, vmware, openvpn, ... which open tap interfaces and need them
bridged with the hosts network adapter, the user can set up a glob for
interfaces to be automatically added (eg tap*).
that it just warns the user with a printf when it misaligns a piece
of memory that was requested through a busdma tag.
Some drivers (such as mpt, and probably others) were asking for alignments
that could not be satisfied, but as far as driver operation was concerned,
that did not matter. In the theory that other drivers will fall into
this same category, we agreed that panicing or making the allocation
fail will cause more hardship than is necessary. The printf should
be sufficient motivation to get the driver glitch fixed.
