- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 15 2019
Sep 13 2019
Sep 11 2019
Aug 22 2019
Aug 21 2019
Aug 19 2019
Aug 12 2019
Aug 9 2019
Adding TCP folks explicitly as reviewers.
There's a couple of public IP(v6) addresses in the test scripts. We'd prefer not to have accidents with people. Can you please change them?
Aug 8 2019
Aug 7 2019
Aug 5 2019
Aug 3 2019
Aug 2 2019
Aug 1 2019
Jul 31 2019
In addition to the other comments I still nowhere see a loop that walks the entire extension header chain. If you don't do that you cannot fulfil the requirement you are trying to solve. What am I missing?
I changed my mind...
Jul 30 2019
Just as a comment: I finally figured out what's so confusing when reading this these days. The ip6q[] is the buckets and not of struct ip6q anymore; sadly struct ip6q is a public interface used inside the MAC framework so don't want to break that by renaming it.
Jul 24 2019
Grat work on the cleanup; I think apart from the license there is very few minor nits left which are acceptable.
Jul 22 2019
In D20967#456233, @shivank wrote:I have a few doubts:
- I'm not clear about the license, should the TrustedBSD be included? if yes, then how? Also, I have copied the sysctl_rules from mac_portacl, Is it infringing any copyright as of now? I've read BSD license is very open, can I mention the mac_portacl?
Hey, thank you for all the updates. There are a few more. Please let me know when you think you are done with all of them and I'll have a full look again.
Jul 17 2019
I think sys/security/mac_ipacl/design_notes.txt and sys/security/mac_ipacl/notes.txt can be removed. Should be turned into a man page really!?
Jul 13 2019
Thanks, was still on my TODO. Always happy if someone does the work for me :-)
Jun 17 2019
I have a kind-of stupid question: where in all this do you actually walk an entire header chain to the end rather than just checking the next one? Are there no cases when this might be needed?
Jun 13 2019
In D17512#445767, @bdragon wrote:Over in powerpc land, we've been chasing crashes with dpcpu and vnet as well. Our current prospective fix is https://reviews.freebsd.org/D20461 but we don't understand why it seems to fix it.
Does this patch fix your issues?
https://svnweb.freebsd.org/base?view=revision&revision=336909 has a brief explanation of the problem; can you look at the code and see if you get a similar problem, just to confirm (and for you to understand as-to why that is?
Jun 10 2019
Jun 8 2019
Jun 4 2019
Jun 1 2019
I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.
I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.
Warner if you have any further comments .. I'd like to commit this the next days. If not it'll go in by Sat 8 June.
I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.
I'd like to commit this the next days. Can someone please review? If not it'll go in by Sat 8 June.
https://svnweb.freebsd.org/changeset/base/348494 missed the Diff-Rev: tag.
May 29 2019
I just only scrolled through this and there's a few things. I am not going into detail at the moment as I'd love to give this a full review once my brain capacity for yet-another-module-thing-complication is there. It'll be helpful to later decompose this into "whitespace change" and functional change (as a lot of renaming, etc. makes this hard to read).
In D19622#441636, @tuexen wrote:In D19622#440454, @kbowling wrote:I'll register strong desire to discard fragments immediately on interface vanishing. I don't expect that to come with any significant weight, my rational is whatever makes state management easier within current codebase and usage patterns of fbsd.
Why do you want to discard a packet if the interface it was received from is going away?
The packet is there, it doesn't matter if the interface goes away after it was received. And we don't have to wait for the interface to come back before continuing processing. We should be able to just process the packet even without that interface it was received on still being present when the processing happens.
May 26 2019
In D17512#439294, @jhb wrote:I still don't understand why i386 is special in this regard. Surely i386 isn't the only architecture to ever use this type of relocation?
May 22 2019
so this happened as well with ipsec.ko not just carp.ko so we need a solution to the problem which scales. We discussed it here a bit in Waterloo and I think the only question is as to whether to use the BYTE(1) option and just put a padding byte at the end, or as to whether put a larger magic number there and actually check that the module might be compiled with the right options?
May 21 2019
Did you also want something for ipcomp?
May 18 2019
Thank you!!!! And for the .Dd changes discussed in person :-)
May 10 2019
LGTM
May 8 2019
I kept thinking which states we can really observe and when:
Handle reviewer comments:
- add SDIO disclaimer
- fix typos
- split up CMD53 function
- add one device per function (and with that re-adjust to use the parent device as we no longer cache that, add ivar support rather than having hand-rolled accessor functions)
- Use CMD52 to set blocksize
- use a sdio specific awk to generate device and vendor defines
- remove the DEFAULT implementations from the sdio_if.m file as they were only providing the general default
- rework some error handling
- rename field "smb" into more descriptive
- Use dprintfs instead of printfs in the middle of a parsing API
May 6 2019
I think a dependency was rejected. This was Cambridge Teaching material code. I would assume this is overcome by time and changes a lot since. I have no more access to these trees where this came from to see. I am abandoning it to clean up.
May 5 2019
I've fixed all requests in my internal tree but the CMD53 request (which I left a comment for what I'll do).
I'll upload a new diff the next 48 hours (need to also adjust the driver to deal with multiple devices).
May 3 2019
May 2 2019
The ip6_fragment() change seems fine if you want to go ahead and factor that out.
Apr 30 2019
Update based on feedback from marius/imp.
Apr 25 2019
Adding @tuexen as a reviewer. If my memory serves me right he worked on a small part of of tun recently.
Apr 24 2019
LGTM... waiting for more beef :-)
Apr 23 2019
In D19622#430172, @hselasky wrote:@bz: There is another bug I believe in the IPv6 VNET shutdown code.
Where is the counterpart mtx_destroy() for the following mtx_init():
void
frag6_init(void)
{struct ip6q *q6; int i; V_ip6_maxfragpackets = IP6_MAXFRAGPACKETS; frag6_set_bucketsize(); for (i = 0; i < IP6REASS_NHASH; i++) { q6 = IP6Q_HEAD(i); q6->ip6q_next = q6->ip6q_prev = q6; mtx_init(&V_ip6q[i].lock, "ip6qlock", NULL, MTX_DEF); V_ip6q[i].count = 0; }
Sorry my bad for missing the VIMAGE state problem in the initial submit.