- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Mon, Mar 25
Sun, Mar 24
This also really needs a test case.
In D43504#1014598, @gallatin wrote:
Sat, Mar 23
In D44476#1014459, @glebius wrote:In D44476#1014446, @kp wrote:When we build without VIMAGE VNET_SYSUNINIT translates to SYSUNINIT, so this patch means we leak V_icmp_rates[i].cr_rate on shutdown.
That's not exactly a critical problem, but this is technically wrong.I don't agree with that. We don't deallocate memory on shutdown in general case. We do not have a matching SYSUNINIT for every SYSINIT that mallocs. Keeping a function to deallocate memory on shutdown is the actual waste of memory - it grows kernel text, which is wired.
When we build without VIMAGE VNET_SYSUNINIT translates to SYSUNINIT, so this patch means we leak V_icmp_rates[i].cr_rate on shutdown.
Fri, Mar 22
In D43504#1013955, @glebius wrote:To put it lightly, I'd really like to see this patch performance tested.
Thu, Mar 21
I'd like to land this patch. Absent anyone raising objections I intend to do so in two weeks or so.
Tue, Mar 19
Fri, Mar 15
Tue, Mar 12
Fri, Mar 8
Fri, Mar 1
Wed, Feb 28
Feb 27 2024
In D44088#1006073, @zlei wrote:Will this be MFCed to stable branches ? I see sys/netlink/route/nexthop.c is consuming the fixed function nlattr_get_uint8():
sys/netlink/route/nexthop.c: { .type = NHAF_FAMILY, .off = _OUT(nhaf_family), .cb = nlattr_get_uint8 },
Feb 26 2024
In D44089#1005840, @melifaro wrote:I’ a bit unsure about this one - as having pointer to bool may introduce
Feb 24 2024
Feb 15 2024
Feb 13 2024
In D43866#1000883, @vegeta_tuxpowered.net wrote:In D43866#1000864, @kp wrote:I failed to apply this patch, and I think it's because you already fixed this problem in https://cgit.freebsd.org/src/commit/?id=4d19eceaefb7106d761bc9504bb0da737ae0d674
Or am I missing something else?
This is absolutely embarrassing but I can explain myself :)
I've seen memory leaking on my systems running FreeBSD 14.0 , looked at the code for releng/14.0, found the leak, patched it… I forgot that I've worked on it already before, and the commit is not in release/14.0. I see it in stable/14, though. I'm abandoning this revision.
I failed to apply this patch, and I think it's because you already fixed this problem in https://cgit.freebsd.org/src/commit/?id=4d19eceaefb7106d761bc9504bb0da737ae0d674
Feb 10 2024
Feb 6 2024
Feb 5 2024
Thanks for catching that.
Feb 4 2024
- add assert
- remove unneeded changes
Feb 2 2024
Specifically because we've seen users report panics like this one:
Feb 1 2024
In D43504#994028, @kp wrote:I'll wait for the performance impact tests
I have exactly the same commit in my queue right now.
Jan 30 2024
Jan 29 2024
Jan 27 2024
- improve test (ping 3x, to ensure that subsequent packets make it)
- when matching states also look at the original interface This is required because the expected outbound interface before we match the state is the original interface, but for inbound packets it will be the route-to'd interface (which we've now bound the state to)
Jan 26 2024
This is wrong, as I'd have seen immediately if I'd had the test send more than 1 ping.
When the second outbound ping arrives pf looks for the state on epair_one, but we've created it for epair_two, so we don't find the state and reject the packet (or more accurately, try to create a new state for it and fail because such a state already exists).
Jan 25 2024
Jan 24 2024
In D43504#993625, @tuexen wrote:Then why not change icps_tooshort to icmps_tooshort? I guess the other protocols have a proper prefix.
In D43504#993475, @gallatin wrote:Why no mib:::icps_foo? Not perfectly, but for TCP it would be mib:::tcps_foo...
Jan 23 2024
In D43504#993475, @gallatin wrote:In D43504#991958, @kp wrote:I'd expect that to have no measurable impact, but I've not tested that to confirm.
I added Olivier to the reviewers. Hopefully he can test this in his packet forwarding setup with slow machines.
I'm really not eager to have an extra instruction all over the place on every counter increment. Did you consider adding SDT probes for just the error counters, and changing the INC function to an ERR_INC or something similar? That way the happy path does not pay any cost, while the errors are still instrumented.
I didn't think of that specifically, no.
In D43504#993300, @markj wrote:The real intent behind the "function" field is that the kernel will automatically populate it with the C function containing the same probe. The idea being that you have the same provider:::name probe in two C functions, dtrace will let you enable just one of the two probes if you specify the function name. Currently that's not implemented on FreeBSD but my preference would be to avoid using it. The same applies to the "module" identifier, which on FreeBSD does get autopopulated. There are some existing probes which violate this rule. Really it's a bug that the SDT macros let you specify them at all but it's hard to fix at this point.
I don't really see the downside of having the "module" be part of the probe name. You can list probes matching a glob, so something like dtrace -ln 'mib:::icmp-*' would work too.
Include icmp6, udp and tcp counters.
In D43504#993167, @tuexen wrote:I'm wondering why we use icmp, ip, and ip6 as module and count as functions. I think in the Solaris implementation module and function are unspecified. Using a name different from what is used by Solaris is fine for me. So I really like the direction this patch is taking.
Jan 22 2024
Have separate probes for each field.