Searched hist:226801 (Results 1 - 5 of 5) sorted by relevance
| /freebsd-9.3-release/sys/contrib/pf/net/ | ||
| H A D | pf_table.c | diff 226801 Wed Oct 26 15:25:36 MDT 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) |
| H A D | if_pflog.c | diff 226801 Wed Oct 26 15:25:36 MDT 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) |
| H A D | if_pfsync.c | diff 226801 Wed Oct 26 15:25:36 MDT 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) |
| H A D | pfvar.h | diff 226801 Wed Oct 26 15:25:36 MDT 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) |
| H A D | pf_ioctl.c | diff 226801 Wed Oct 26 15:25:36 MDT 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) |
Completed in 135 milliseconds