- User Since
- Aug 29 2014, 12:11 PM (177 w, 1 d)
Sun, Jan 14
Thu, Jan 11
Seems this came in in r271976 with D775 after VIMAGE was in the tree.
You don't need to set the CURVNET() that early (only after the switch) it seems but it shouldn't matter.
Looks OK to me.
Sun, Dec 31
Dec 17 2017
Reading the comment I though "oh so it was actually a bug in netstat" and might squid be doing. Then I saw the patch. This needs a way better description for the commit message! Also a reference to the commit that changed the original behaviour now making this necessary.
Dec 7 2017
Dec 5 2017
Nov 14 2017
Oct 20 2017
Oct 12 2017
Oct 11 2017
Oct 6 2017
Just from the proposed commit message this smells like it should be at least two or three individual changes and commits, e.g., mb_dupcl() sounds like it's a standalone change?
Oct 2 2017
Sep 25 2017
I think chaining mbufs together after doing LRO re-assembly is asking for too much.
It took a while to get all the different HW LRO cases sorted out; this is likely just going to add extra delay?
Just asking for the whitespace changes ;)
Aug 13 2017
I'd say go ahead for now; seems to make life better at least.
Jul 30 2017
I think your description could be a bit more clear as I got confused. I think after re-reading it I now understand what you mean. Can you try to describe the sequence of events step by step here on how this gets triggered (especially how the new entry appears before we set it to NULL overwriting a new one?)?
Is this a consequence of https://svnweb.freebsd.org/base?view=revision&revision=297816 or independent of it?
Jul 27 2017
Jul 21 2017
Close for now; still need to track down but ETIME currently.
Jul 2 2017
Jun 14 2017
I am very much with @jhb in this case. Having written DDB and netstat support to easily, quickly, and without the need to think debug problems without having to switch the tool I normally use for system administration is a big plus.
Jun 10 2017
Well a python script won't help me with a base system crashdump on boot if it's not installed.
Jun 9 2017
if you drop support from netstat what's the alternative to get this information out of crashdumps then?
Jun 8 2017
Thanks for the #define !
Hmm I wonder if the entire struct can be exposed rather than just the class as not all "CPU_CLASS_CORTEXA" are the same and hwpmc will want to choose depending on .. hmm never mind; it's reading that directly from a register, so this will be fine. Thanks for doing it!
May 26 2017
Can you make a first patch which is just "Remove unused variables"? That way removing the functional changes is a lot easier.
Also when you have to go back in 5 years and wonder what this all was.
The 0xff should probably a #define somewhere but that's unrelated. I think we've done something similar for the timer code in the past; not sure in which review or tree that ended up.
I have had the same diff in my local tree for ages. I am sure I mentioned it somewhere (bug report, follow-up to the commit, or just IRC).
May 19 2017
May 18 2017
Did the other changes get in already or are they in a different review? I will try to see what this one does in a different setup during the next days (I hope).
I really don't like the idea of losing the #ifdefs.
There are people how are trying to figure out the costs of these things (like me, possibly for CAPSICUM) and having the ifdef really helps.
May 12 2017
Could this please be multiple individual changes.
The function argument change is completely independent of the struct reordering.
May 9 2017
May 7 2017
Have you tested this for various combinations, including unbound sockets?
I think in case of unbound sockets this will no longer work, as I don't think INP_IPV would be set at that point yet, are they?
May 5 2017
So, looking at http://fxr.watson.org/fxr/source/netinet/tcp_usrreq.c#L317 (tcp6_usr_bind) I see we clearly set INP_IPV depending on whether (a) it's IPv6 only, (b) it's a v4mapped address on an IPv6 socket, or (c) worst case to check it's an IPv6 socket with an unspecified address (in which case we (unless people use BINDANY (case I did not check) will always bind to an IPv6 address).
May 4 2017
Does udp6_connect() have a similar problem to tcp6_usr_connect()? Looks like it.
Apr 27 2017
I am confused by the description of "with checksum offloading disabled" on a loopback interface. Did you mean to say that you force it to calculate the checksums on loopback rather than just setting the flag that checksums are ok as would be the default? I think it would be good to re-phrase this as there is no "offloading" on loopback.
Apr 6 2017
@tuexen right, assume you run with syn-cookies only, how do you mitigate the replay; I thought that is the actual problem we are looking at (whether or not there is a syn-cache in use).
Question: do we add time dependent bits somewhere so we could simply check if the syn-cookie itself is outside a possible replay-window? I know this does not entirely close the race, but I don't see how this would differ from the proposed "global" solution but would be working independent on whether a syn-cache is also used or not. Am I completely missing a point here? I think 4987 mentioned something along these lines but it's been ages since I last looked at SYN problems.
Mar 21 2017
See reference 
Mar 20 2017
This is on a single CPU. Can you please give me a reference for "the page walks must be coherent" as my understanding from the cited pages and the blog post referenced is that they must not be.
@kib ok, this may be a secondary problem; change my sentence to "Analysing what happened we found that with the out-of-order CPU model we would kick off the page table walker and find the 0 pte entry." The problem remains that the store has not been committed yet and a speculative walk will only see the old (zero) pte.
Add Robert to Cc:
Mar 18 2017
Mar 17 2017
It is unclear to me why I had chosen the different order in r302156 but on a quick glance this looks OK.
Mar 1 2017
Feb 28 2017
Feb 14 2017
Feb 10 2017
Jan 27 2017
Just on principle. Too bad Sam 's not here.
Jan 23 2017
Jan 19 2017
Jan 14 2017
I should add that I used the "request changes" because I want clarification first. You will notice that just swapping out the macros will not really make sense in both cases.
Stupid question; why are you using the COMPAT macro and not the IN6_IS_ADDR_V4MAPPED()?
Seems you are talking one thing but testing another?
Jan 13 2017
Jan 12 2017
otherwise looks good.
Jan 11 2017
I'd say get it in and @rwatson and I can figure out the other bits...
Jan 10 2017
Jan 7 2017
Ok, just for my understanding, can you confirm that the commit message really means "if m_pullup does not have to do anything, then the mbuf does not need to be writeable"? Or in other words "if the requested memory region is already contiguous and nothing needs to change, the mbuf does not need to be writeable"?
Jan 5 2017
You can also just use Submitted by: bz
Dec 11 2016
I've not read in detail through the ip6_fastfwd.c code but I am fine with the other changes.
Dec 10 2016
I guess it's just my way of seeing things:
(1) fixing the check on options which is wrong
(2) as a consequence fixing possible TSO problems that might currently occur.
Dec 9 2016
Seems like this is a more conservative solution to avoid possible offload problems.
Dec 5 2016
This is multiple independent changes. The "rcvif" statistics changes are all non-functional noise to my understanding and should be factored out and committed separately. It'll help to review the functional changes a lot easier.
Nov 17 2016
Sep 28 2016
Just a random comment...
Sep 14 2016
Aug 31 2016
Aug 28 2016
Aug 27 2016
Aug 21 2016
Aug 18 2016
Aug 16 2016
I did not review the change but for arm64 things seem to be working again:
I downloaded the raw diff in the best way I could and applying it to HEAD I get:
Aug 11 2016
Jul 30 2016
Jul 26 2016
Given I am only asking for an extra comment, this seems to look OK to me. I have not tested or applied the patch.
Jul 17 2016
If I am not mistaken the function calls are for modules (especially 3rd party) while we should use the macros in the kernel (unless I misremember something here)?
Jul 14 2016
Is this sudden problem possibly related to glebius' callout changes? I am not properly tracking things but if invariants changed and weren't reflected in the callers, that might explain.