times consequently, without checking whether callout has been serviced
or not. (ng_pptpgre and ng_ppp were catched in this behavior).
- In ng_callout() save old item before calling callout_reset(). If the
latter has returned 1, then free this item.
- In ng_uncallout() clear c->c_arg.
Problem reported by: Alexandre Kardanev
First, mutexed callouts are incompatible with netgraph nodes, because
netgraph(4) can guarantee that the function will be called with mutex
held.
Second, nodes should not send data to their neighbor holding their
mutex. A node does not know what stack can it enter sending data in
some direction. May be executing will encounter a place to sleep.
New locking:
- ng_pptpgre_recv() and ng_pptpgre_xmit() must be entered with mutex held.
- ng_pptpgre_recv() and ng_pptpgre_xmit() unlock mutex before
sending data and then return unlocked.
- callout routines acquire mutex themselves.
does not clear m_nextpkt for us. The mbufs are sent into netgraph and
then, if they contain a TCP packet delivered locally, they will enter
socket code again. They can pass the first assert in sbappendstream()
because m_nextpkt may be set not in the first mbuf, but deeper in the
chain. So the problem will trigger much later, when local program
reads the data from socket, and an mbuf with m_nextpkt becomes a
first one.
This bug was demasked by revision 1.54, when I made upcall queueable.
Before revision 1.54 there was a very small probability to have 2
mbufs in GRE socket buffer, because ng_ksocket_incoming2() dequeued
the first one immediately.
- in ng_ksocket_incoming2() clear m_nextpkt on all mbufs
read from socket.
- restore rev. 1.54 change in ng_ksocket_incoming().
PR: kern/84952
PR: kern/82413
In collaboration with: rwatson
panic. The panic happens when outgoing L2CAP connection descriptor is
deleted with the L2CAP command(s) pending in the queue. In this case when
the last L2CAP command is deleted (due to cleanup) and reference counter
for the L2CAP connection goes down to zero the auto disconnect timeout
is incorrectly set. pjd gets credit for tracking this down and committing
bandaid.
Reported by: Jonatan B <onatan at gmail dot com>
MFC after: 3 days
parallel ng_pptp_rcvdata():
- Add a per-node mutex.
- Acquire mutex during all ng_pptp_rcvdata() method.
- Make callouts protected by mutex. Now callouts count as
netgraph writers, but there are plans to allow reader callouts
for nodes, that have internal locking.
- Acquire mutex in ng_pptp_reset(), which can be triggered
by a message or node shutdown.
PR: kern/80035
Tested by: Deomid Ryabkov <myself rojer.pp.ru>
Reviewed by: Deomid Ryabkov <myself rojer.pp.ru>
either reader or writer flag on item in the function, that
allocates the item. Do not modify these flags when item is
applied or queued.
The only exceptions are node and hook overrides - they can
change item flags to writer.
the code, i.e. ng_fec_init() is called with the ifp->if_softc pointer and
NOT with the ifp pointer.
PR: kern/85239
Reviewed by: brooks
MFC after: 1 day
it fixes. I believe the problem lives somewhere outside ng_ksocket,
but until it is found, let the node be working.
PR: kern/84952
PR: kern/82413
MFC after: 3 days
IFF_DRV_RUNNING, as well as the move from ifnet.if_flags to
ifnet.if_drv_flags. Device drivers are now responsible for
synchronizing access to these flags, as they are in if_drv_flags. This
helps prevent races between the network stack and device driver in
maintaining the interface flags field.
Many __FreeBSD__ and __FreeBSD_version checks maintained and continued;
some less so.
Reviewed by: pjd, bz
MFC after: 7 days
data link type of the hook. It will be used to ease autoconfiguration
of netgraph and also to print warning messages, when incompatoble nodes
are connected together.
At the end of ng_snd_item(), node queue is processed. In certain
netgraph setups deep recursive calls can occur.
For example this happens, when two nodes are connected and can send
items to each other in both directions. If, for some reason, both nodes
have a lot of items in their queues, then the processing thread will
recurse between these two nodes, delivering items left and right, going
deeper in the stack. Other setups can suffer from deep recursion, too.
The following factors can influence risk of deep netgraph call:
- periodical write-access events on node
- combination of slow link and fast one in one graph
- net.inet.ip.fastforwarding
Changes made:
- In ng_acquire_{read,write}() do not dequeue another item. Instead,
call ng_setisr() for this node.
- At the end of ng_snd_item(), do not process queue. Call ng_setisr(),
if there are any dequeueable items on node queue.
- In ng_setisr() narrow worklist mutex holding.
- In ng_setisr() assert queue mutex.
Theoretically, the first two changes should negatively affect performance.
To check this, some profiling was made:
1) In general real tasks, no noticable performance difference was found.
2) The following test was made: two multithreaded nodes and one
single-threaded were connected into a ring. A large queues of packets
were sent around this ring. Time to pass the ring N times was measured.
This is a very vacuous test: no items/mbufs are allocated, no upcalls or
downcalls outside of netgraph. It doesn't represent a real load, it is
a stress test for ng_acquire_{read,write}() and item queueing functions.
Surprisingly, the performance impact was positive! New code is 13% faster
on UP and 17% faster on SMP, in this particular test.
The problem was originally found, described, analyzed and original patch
was written by Roselyn Lee from Vernier Networks. Thanks!
Submitted by: Roselyn Lee <rosel verniernetworks com>
It does not work with ng_ubt(4) and require special driver and firmware.
Obtained from: Marcel Holtmann < marcel at holtmann dot org >
Submitted by: Rainer Goellner < rainer at jabbe dot de >
MFC after: 3 days
there are at least two versions of the adapter. Version 1 (product ID 0x2200)
of the adapter does not work with ng_ubt(4) and require special driver and
firmware. Version 2 (product ID 0x3800) seems to work just fine, except it
does not have bDeviceClass, bDeviceSubClass and bDeviceProtocol set to required
(by specification) values. This change forces ng_ubt(4) to attach to the
version 2 adapter.
Obtained from: Marcel Holtmann <marcel at holtmann dot org>
Submitted by: Rainer Goellner <rainer at jabbe dot de>
PPPoE modes. The interface was declared obsoleted before 5.3-RELEASE.
When running as access concentrator ng_pppoe(4) supports both modes
simultanously. When running as client mode can be swicthed in ppp(8)
configuration.
Approved by: re (scottl)
an item may be queued and processed later. While this is OK for mbufs,
this is a problem for control messages.
In the framework:
- Add optional callback function pointer to an item. When item gets
applied the callback is executed from ng_apply_item().
- Add new flag NG_PROGRESS. If this flag is supplied, then return
EINPROGRESS instead of 0 in case if item failed to deliver
synchronously and was queued.
- Honor NG_PROGRESS in ng_snd_item().
In ng_socket:
- When userland sends control message add callback to the item.
- If ng_snd_item() returns EINPROGRESS, then sleep.
This change fixes possible races in ngctl(8) scripts.
Reviewed by: julian
Approved by: re (scottl)
a DLT_NULL interface. In particular:
1) Consistently use type u_int32_t for the header of a
DLT_NULL device - it continues to represent the address
family as always.
2) In the DLT_NULL case get bpf_movein to store the u_int32_t
in a sockaddr rather than in the mbuf, to be consistent
with all the DLT types.
3) Consequently fix a bug in bpf_movein/bpfwrite which
only permitted packets up to 4 bytes less than the MTU
to be written.
4) Fix all DLT_NULL devices to have the code required to
allow writing to their bpf devices.
5) Move the code to allow writing to if_lo from if_simloop
to looutput, because it only applies to DLT_NULL devices
but was being applied to other devices that use if_simloop
possibly incorrectly.
PR: 82157
Submitted by: Matthew Luckie <mjl@luckie.org.nz>
Approved by: re (scottl)
Provide a backwards compatible way to have the extra macro by defining
PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that
want/need to have the same driver on 5 and 6 with pccard attachments.
Approved by: re (dwhite)
struct ifnet or the layer 2 common structure it was embedded in have
been replaced with a struct ifnet pointer to be filled by a call to the
new function, if_alloc(). The layer 2 common structure is also allocated
via if_alloc() based on the interface type. It is hung off the new
struct ifnet member, if_l2com.
This change removes the size of these structures from the kernel ABI and
will allow us to better manage them as interfaces come and go.
Other changes of note:
- Struct arpcom is no longer referenced in normal interface code.
Instead the Ethernet address is accessed via the IFP2ENADDR() macro.
To enforce this ac_enaddr has been renamed to _ac_enaddr.
- The second argument to ether_ifattach is now always the mac address
from driver private storage rather than sometimes being ac_enaddr.
Reviewed by: sobomax, sam
- Do not edit pullup_len outside M_CHECK macro.
- Do not reimplement NG_FWD_NEW_DATA().
- Remove redundant check for item being not NULL.
Submitted by: ru
hack MSS of packets outgoing via interface with small MTU, to workaround
path MTU discovery problems.
Written by Alexey Popov, with some cleanups from me. There are also plans
to improve mpd port, so that it uses this node, instead of doing MSS
hacking in userland, when 'enable tcpmssfix' option is on.
Submitted by: Alexey Popov <lollypop@flexuser.ru>
Note: len gets intialized to 0 for sap == NULL case only to
make compiler on amd64 happy. This has nothing todo with the
former uninitialized use of len in sap != NULL case.
Reviewed by: glebius
Approved by: pjd (mentor)
