https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=137089
--- Comment #3 from xelah-freebs...@xelah.com ---
(In reply to Hiren Panchasara from comment #2)
The servers involved have long since been retired, so I no longer have a way to
test if it still happens.
--
You are receiving this mail beca
On 01/23/15 15:13, VANHULLEBUS Yvan wrote:
Hi.
On Wed, Jan 21, 2015 at 03:16:21PM +0100, Andrei Brezan wrote:
Weird subject, maybe.
I'm running FreeBSD-10.0-RELEASE with PF as firewall and racoon for
IPSEC. The IPSEC tunnel is between the FreeBSD box and a Fortinet
appliance.
The IPSEC tunnel
kostikbel added a subscriber: kostikbel.
kostikbel added a comment.
Also would be nice to further split the patch into the mechanical change of the
cc_exec/cc_migration macros, and the real fix(es). From what I read, the patch
is correct, but it is currently noisy, which makes reading harder an
Hi!
q1)
I assume that libpcap has builtin support for checking if sysctl
net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy.
Correct?
q2)
This should mean that all normal sniffing tools like tcpdump, tshark,
ngrep, argus, etc do NOT need any specific options in order to use
zerocopy
jhb added a subscriber: jhb.
jhb added a comment.
Hmm, I do think the idea of a kernel test framework should be discussed in its
own right. I have implemented a much simpler one on my own for unit tests of
locking primitives that you can see here. These worked by declaring tests in
linker set
On Thu, 29 Jan 2015 12:25:25 +0100 (CET) el...@sentor.se wrote
> Hi!
>
> q1)
> I assume that libpcap has builtin support for checking if sysctl
> net.bpf.zerocopy_enable is set to 1, and if so uses zerocopy.
> Correct?
>
> q2)
> This should mean that all normal sniffing tools like tcpdump, tshar
rrs added a comment.
To answer jhb and kostikbel
1) Yes this does address the two issues that Hans re-write of the callout
system did without changing the KPI.
There may be other bugs as well, but with the test framework and the old
code I could reproduce both issues
(spin lock held to
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1705
To: arybchik, gnn
Cc: freebsd-net
___
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1704
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1703
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1702
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1706
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1701
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
REVISION DETAIL
https://reviews.freebsd.org/D1692
To: arybchik, gnn
Cc: freebsd-net
__
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to add Approved by: gnn (mentor) to your commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1700
To: arybchik, gnn
Cc: freebsd-net
__
gnn requested changes to this revision.
gnn added a comment.
This revision now requires changes to proceed.
If you look at other drivers you'll see they have #define'd macros for the
locks, rather than direct calls. This allows us to name the lock in the macro.
See, for instance, this example
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1699
To: arybchik, gnn
Cc: freebsd-net
___
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1698
To: arybchik, gnn
Cc: freebsd-net
___
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1708
To: arybchik, gnn
Cc: freebsd-net
___
gnn requested changes to this revision.
gnn added a comment.
This revision now requires changes to proceed.
__predict_false rarely, if ever, does the right thing. Have you run any
benchmarks to show that this improves performance?
REVISION DETAIL
https://reviews.freebsd.org/D1697
To: arybchi
gnn accepted this revision.
gnn added a comment.
This revision is now accepted and ready to land.
Remember to put Approved by: gnn (mentor) in the commit message.
BRANCH
/head
REVISION DETAIL
https://reviews.freebsd.org/D1694
To: arybchik, gnn
Cc: freebsd-net
___
imp added a comment.
I agree that the kernel test framework should be done differently as well.
I didn't realize the number of mechanical changes my request to use the macros
produced :(
INLINE COMMENTS
sys/sys/callout_test.h:1 I'm not sure that the callout_test.h belong in sys.
Seems like n
jhb added a comment.
To be clear, I'm fine with updating my tests to a different framework, but I
think it's worth discussing what that looked like.
I also had to explicitly drop Giant in my test module handler.
I do think it's probably better to explicitly ask tests to run instead of
having k
rrs added a comment.
Imp:
I can see how we can easily move callout_test.h out of sys. That really
should be in the module/tests/callout_test/ dir.
But where would you suggest the global framework file go if not sys?
REVISION DETAIL
https://reviews.freebsd.org/D1711
To: rrs, gnn, rwatson, adr
rrs added a comment.
jhb
The only reason I put the test stuff in this patch is its the only way to
validate the patch, and
that is something we really need in the callout system is a way to validate
that its working
correctly since this stuff tends to be very subtle and a bit of a head banger
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314
Garrett Cooper,425-314-3911 changed:
What|Removed |Added
CC||r...@freebsd.org
---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have problems to understand how combination of nat and stateful
ruleset for ipfw should work. There is no good guides, and most guides
uses old "divert" which is different from in-kernel nat, as far as I
understand.
Problem is, if we want to al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 30.01.2015 03:37, Lev Serebryakov wrote:
> Is here better way to have nat and stateful ruleset?
Actions like "create-dyn-allow" and "create-dyn-deny" will be very
nice, BTW :) But looks like it is hard to add, as now dynamic rules
are "replaced
On 1/30/15 8:37 AM, Lev Serebryakov wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have problems to understand how combination of nat and stateful
ruleset for ipfw should work. There is no good guides, and most guides
uses old "divert" which is different from in-kernel nat, as far a
29 matches
Mail list logo