| #
238600 |
|
18-Jul-2012 |
glebius |
Merge r230119, r238498 from head:
------------------------------------------------------------------------
r230119 | csjp | 2012-01-15 02:51:34 +0400 (вс, 15 янв 2012) | 9 lines
Revert to the old behavior of allocating table/table entries using
M_NOWAIT. Currently, the code allows for sleeping in the ioctl path
to guarantee allocation. However code also handles ENOMEM gracefully, so
propagate this error back to user-space, rather than sleeping while
holding the global pf mutex.
Reviewed by: glebius
Discussed with: bz
------------------------------------------------------------------------
r238498 | glebius | 2012-07-15 23:10:00 +0400 (вс, 15 июл 2012) | 2 lines
Use M_NOWAIT while holding the pf giant lock.
Approved by: re (kib)
|
| #
226801 |
|
26-Oct-2011 |
glebius |
Sync pf(4) and pfsync(4) with head, merging lots of important bugfixes
required for normal operation of pfsync(4). Revisions merged:
r226531 | bz | 2011-10-19 13:34:40 +0400 (ср, 19 окт 2011) | 4 lines
Fix an obvious locking bug where we would lock again rather than unlock.
r226532 | bz | 2011-10-19 14:04:24 +0400 (ср, 19 окт 2011) | 12 lines
Pseudo interfaces should go at SI_SUB_PSEUDO. However at least
pfsync also depends on pf to be initialized already so pf goes at
FIRST and the interfaces go at ANY.
Then the (VNET_)SYSINIT startups for pf stays at SI_SUB_PROTO_BEGIN
and for pfsync we move to the later SI_SUB_PROTO_IF.
This is not ideal either but at least an order that should work for
the moment and can be re-fined with the VIMAGE merge, once this will
actually work with more than one network stack.
r226533 | bz | 2011-10-19 14:08:58 +0400 (ср, 19 окт 2011) | 4 lines
In the non-FreeBSD case we do not expect PF_LOCK and friends to do anything.
r226535 | bz | 2011-10-19 14:16:42 +0400 (ср, 19 окт 2011) | 5 lines
Adjust the PF_ASSERT() macro to what we usually use in the network stack:
PF_LOCK_ASSERT() and PF_UNLOCK_ASSERT().
r226536 | bz | 2011-10-19 15:04:49 +0400 (ср, 19 окт 2011) | 8 lines
De-virtualize the pf_task_mtx lock. At the current state of pf locking
and virtualization it is not helpful but complicates things.
Current state of art is to not virtualize these kinds of locks -
inp_group/hash/info/.. are all not virtualized either.
r226544 | bz | 2011-10-19 17:13:56 +0400 (ср, 19 окт 2011) | 12 lines
Fix recursive pf locking leading to panics. Splatter PF_LOCK_ASSERT()s
to document where we are expecting to be called with a lock held to
more easily catch unnoticed code paths.
This does not neccessarily improve locking in pfsync, it just tries
to avoid the panics reported.
PR: kern/159390, kern/158873
Submitted by: pluknet (at least something that partly resembles
my patch ignoring other cleanup, which I only saw
too late on the 2nd PR)
r226609 | glebius | 2011-10-21 15:11:18 +0400 (пт, 21 окт 2011) | 4 lines
In FreeBSD ip_output() expects ip_len and ip_off in host byte order
PR: kern/159029
r226623 | glebius | 2011-10-22 02:28:15 +0400 (сб, 22 окт 2011) | 5 lines
Fix a race: we should update sc_len before dropping the pf lock, otherwise a
number of packets can be queued on sc, while we are in ip_output(), and then
we wipe the accumulated sc_len. On next pfsync_sendout() that would lead to
writing beyond our mbuf cluster.
r226655 | glebius | 2011-10-23 14:05:25 +0400 (вс, 23 окт 2011) | 5 lines
Correct flag for uma_zalloc() is M_WAITOK. M_WAIT is an old and
deprecated flag from historical mbuf(9) allocator.
This is style only change.
r226656 | glebius | 2011-10-23 14:13:20 +0400 (вс, 23 окт 2011) | 5 lines
Absense of M_WAITOK in malloc flags for UMA doesn't
equals presense of M_NOWAIT. Specify M_NOWAIT explicitly.
This fixes sleeping with PF_LOCK().
r226660 | glebius | 2011-10-23 18:59:54 +0400 (вс, 23 окт 2011) | 22 lines
Fix from r226623 is not sufficient to close all races in pfsync(4).
The root of problem is re-locking at the end of pfsync_sendout().
Several functions are calling pfsync_sendout() holding pointers
to pf data on stack, and these functions expect this data to be
consistent.
To fix this, the following approach was taken:
- The pfsync_sendout() doesn't call ip_output() directly, but
enqueues the mbuf on sc->sc_ifp's interfaces queue, that
is currently unused. Then pfsync netisr is scheduled. PF_LOCK
isn't dropped in pfsync_sendout().
- The netisr runs through queue and ip_output()s packets
on it.
Apart from fixing race, this also decouples stack, fixing
potential issues, that may happen, when sending pfsync(4)
packets on input path.
Reviewed by: eri (a quick review)
r226661 | glebius | 2011-10-23 19:08:18 +0400 (вс, 23 окт 2011) | 13 lines
- Fix a bad typo (FreeBSD specific) in pfsync_bulk_update(). Instead
of scheduling next run pfsync_bulk_update(), pfsync_bulk_fail()
was scheduled.
This lead to instant 100% state leak after first bulk update
request.
- After above fix, it appeared that pfsync_bulk_update() lacks
locking. To fix this, sc_bulk_tmo callout was converted to an
mtx one. Eventually, all pf/pfsync callouts should be converted
to mtx version, since it isn't possible to stop or drain a
non-mtx callout without risk of race.
- Add comment that callout_stop() in pfsync_clone_destroy() lacks
locking. Since pfsync0 can't be destroyed (yet), let it be here.
r226662 | glebius | 2011-10-23 19:10:15 +0400 (вс, 23 окт 2011) | 2 lines
Fix indentation, no code changed.
r226663 | glebius | 2011-10-23 19:15:17 +0400 (вс, 23 окт 2011) | 4 lines
Merge several fixes to bulk update processing from OpenBSD. Merged
revisions: 1.148, 1.149, 1.150. This makes number of states on
master/slave to be of a sane value.
Approved by: re (kib)
|