In D19488#417164, @hrs wrote:For (2), I think the old version unconditionally runs rtsol (w/o "d") when rtsold_enable="NO", and does not when rtsold_enable="YES" because rtsold (w/ "d") will be invoked later by rc.d/rtsold should handle it. In short, the condition which determines if rtsol is invoked or not depends only on "accept_rtadv" flag. Isn't it enough?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Mar 7 2019
Mar 7 2019
bz added a comment to D19487: EXPERIMENTAL: clear IPv6-Only flag on interface if link-state goes down.
In D19487#417158, @hrs wrote:Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.
bz added a comment to D19487: EXPERIMENTAL: clear IPv6-Only flag on interface if link-state goes down.
In D19487#417165, @hrs wrote:One more comment: immediate change of the flag just after a link-down event may be problematic when the link is unstable. In such a situation, IPv4 packets can be allowed after a link-up and before another RA arrives even if the all of advertising routers keep sending ipv6only flag. We can assume that the interface should be configured to accept RA when the machine moves from a network to another, so sending a RS after a link-up then clearing ND6_IFF_IPV6_ONLY only when no RA arrives in a few seconds looks a more reasonable behavior. If at least one RA arrives after the RS, the normal handling of ipv6only flag works.
Mar 6 2019
Mar 6 2019
Update for IETF draft-ietf-6man-ipv6only-flag.
Mar 5 2019
Mar 5 2019
Thanks for updating the description; The repro scenario really should be a test case. Accept for the general idea, not for having checked the code in detail.
Mar 4 2019
Mar 4 2019
I hate manually virtualised cloners but people changed if_clone.c logic under the virtualised cloner infrastructure and I gave up on this years ago. Sorry I am not really helpful here currently. Also I think it needs more words describing the problem and part of the solution as I cannot imagine this only being a problem of tun(4) left but probably another few others?
Mar 3 2019
Mar 3 2019
Fix compilation of world with WITHOUT_{INET,INET6}_SUPPORT or both set.
Mar 1 2019
Mar 1 2019
In D19418#415948, @editor_callfortesting.org wrote:
bz accepted D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
The user space part seems fine to me now; I assume we'll see another review for the kernel parts?
Add ushort and ulong to linux/types.h.
Feb 28 2019
Feb 28 2019
Feb 27 2019
Feb 27 2019
bz added a comment to D19316: IPV4 Experimental address space usage and cleanup of code not using IN_foo.
In D19316#414645, @karels wrote:I agree with John that we should do everything we can to ...
Feb 24 2019
Feb 24 2019
Make arp code return (more) errors.
bz added a comment to D19316: IPV4 Experimental address space usage and cleanup of code not using IN_foo.
In D19316#413638, @karels wrote:I'm not actually sure of the official status of Class E, although I suspect it is still experimental/not for production use.
Rename arprequest_int() to arprequest_internal().
Feb 23 2019
Feb 23 2019
bz added a comment to D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
@rgrimes inside a jail "localhost", a bind to, e.g., ::1, might end up on an IPv6 address of the jail, normally the first one, and not on ::1 hence it won't be "localhost". It's not changing what localhost is (e.g., in /etc/hosts), it's the kernel which changes the address under the hood during the syscalls (connect being another one).
bz added a comment to D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
I like this one a lot more already. Left a few minor comments which might help.
Looks good to me
Feb 20 2019
Feb 20 2019
bz added a comment to D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
I think doing DNS things for these is not a good thing. Especially given inside an IP jail a "localhost" will give you different results.
bz added a comment to D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
Ok, so one thing at a time:
bz added inline comments to D19254: Avoid dereferencing a NULL pointer when TCP_REASS_LOGGING is enabled.
Feb 18 2019
Feb 18 2019
bz added a comment to D19218: fix nfsuserd to find a mapped "localhost" ip address and to use INET6 when INET isn't available.
I've not seen what you two said and done since I read through after you put it up; I'll have some comments but I'll be mostly afk this; I'll try to get to this Tuesday afternoon/evening. It's flagged important and open in a browser already.
Jan 26 2019
Jan 26 2019
Fix logic errors in iwm_pcie_load_firmware_chunk introduced in r314065.
Jan 25 2019
Jan 25 2019
Given the discussions in D18968 I think you'd be safe as I'd assume we don't otherwise have TCP_REASS_LOGGING in 11, do we?
I guess rrs may or may not give you a more technical feedback.
Ok, your prepared change looks good from a merge-to-stable11 perspective.
Can we also get rid of the special case pfil_ipfw with this (before/after this change)?
Also, while I like it can we break out certain changes which do not have to be part of the initial framework change, e.g., the Mellanox driver change seems to be self-contained (as others possibly are). Helps to review and understand individual parts.
Jan 24 2019
Jan 24 2019
Jan 23 2019
Jan 23 2019
I am accepting it as it seems all correct. Given you said you want an EN for this as well, you might consider to split it up into two parts so that only the real functional fix would later be part of the EN.
You may want to consider forwarding this to re@ after commit and suggest once merged to stable/12 there should be a EN about this; probably together with markj's D18906.
Jan 22 2019
Jan 22 2019
bz added a reviewer for D18887: Fix refcounting leaks in IPv6 MLD code leading to loss of IPv6 connectivity: bz.
bz added a comment to D18887: Fix refcounting leaks in IPv6 MLD code leading to loss of IPv6 connectivity.
Most of the "cosmetic" changes can be ignored if you want. The only real one is the one I marked with XXX; if the current code is correct I think it would deserve a comment on why that is. I couldn't figure it out quickly.
Jan 20 2019
Jan 20 2019
Jan 18 2019
Jan 18 2019
bz added a comment to D18887: Fix refcounting leaks in IPv6 MLD code leading to loss of IPv6 connectivity.
(a) there's one or two lines of whitespace changes in there; can we get them sorted separately?
(b) how much of this has become "reverting" changes and how much is actual change now? I wonder if, for the sake of clarity and history as well as for easier review, could be split into two parts? Is that feasible?
Jan 15 2019
Jan 15 2019
bz committed rS343065: With the sync from Dragonfly BSD in r318216 a bug slipped in (also still present.
With the sync from Dragonfly BSD in r318216 a bug slipped in (also still present
Jan 11 2019
Jan 11 2019
Hit enter too early; you might want to be slightly more verbose in the commit message as to why this change is done.
Not sure where the documentation will go but netstat -s -p ip6 says "fragments" not "packets" so this change sees correct.
Jan 7 2019
Jan 7 2019
bz added a comment to D5165: [patch] dev/bwn suppressing "bwn0: unsupported rate 0" console messages.
Ok looks like bwi doesn't need.
I like this version better than the one before. Thanks! For as much as I can say it looks OK. I haven't tested it.
bz added a comment to D5165: [patch] dev/bwn suppressing "bwn0: unsupported rate 0" console messages.
Depending on the outcome here, it look like bwi will need similar treatment?
Can you please fold some of the problem description of "why?" this change is needed in the proposed commit message; having some more information available when scrolling through source code management system logs is extremely helpful.
Dec 23 2018
Dec 23 2018
bz added inline comments to D18630: gai_strerror() - Update string error messages according to RFC 3493.
Dec 15 2018
Dec 15 2018
Sorry, a tiny tinsy bit more.
Dec 14 2018
Dec 14 2018
Also please re-gen src.conf(5)
I suggest a grep -ir timed over the src tree (ignore the .svn directory) is a good way of seeing or finding more.
I think you are still not removing /etc/rc.d/timed using ObsoleteFiles and also libexec/rc/rc.d/timed (I assume is where it's coming from given the Makefile change) is still in SVN.
Dec 13 2018
Dec 13 2018
I volunteered to look at this to get the transport unblocked. Can do tomorrow together in case I'd have a question.
Dec 11 2018
Dec 11 2018
Remove a dead file. CVS was removed in r251794.
Check libexec/rc/rc.d/Makefile:.if ${MK_TIMED} != "no"
Check tools/build/mk/OptionalObsoleteFiles.inc:.if ${MK_TIMED} == no
rm tools/build/options/WITHOUT_TIMED (and re-gen src.conf)
Dec 6 2018
Dec 6 2018
In D18420#392922, @ae wrote:I think such method can be useful. Do you plan to merge it?
Dec 3 2018
Dec 3 2018
Sorry but my understanding is that this could possibly free the softc even before lagg_clone_destroy() has finished, couldn't it?
Nov 29 2018
Nov 29 2018
Nov 27 2018
Nov 27 2018
Nov 26 2018
Nov 26 2018
Nov 24 2018
Nov 24 2018
@imp could you please comment on your architectural views (or wish-list) while there is still time? Otherwise I might have to sort it out after the facts; I am expecting to be at a point when I need to make a driver talk to some SDIO in about a week and that means I'll work on any middle-glue-code I'll see fit.
Nov 17 2018
Nov 17 2018
Improve the comment for arpresolve_full() in if_ether.c.
Retire arpresolve_addr(), which is not used anywhere, from if_ether.c.
Nov 15 2018
Nov 15 2018
I'll trust you to get the assertion right; sounds good to me.
In D12467#277167, @imp wrote:
Nov 12 2018
Nov 12 2018
Nov 9 2018
Nov 9 2018
Sorry, getting IPv4 fragments into my head is absolutely not a good idea.
Sorry; getting IPv4 fragments into my head is not a good idea.
Nov 8 2018
Nov 8 2018
bz added inline comments to D17898: in6_ifattach_linklocal: handle immediate removal of the new LLA.
Can you please site the Apple CVE and possibly the original writeup instead of a (random) reddit thing?
Update rum(4) and run(4) man pages to reflect that newer versions
To me this change seems wrong. The only caller for this function is exactly for the situation when the link-local address is missing.
If we are in the progress of "configuring" the interface and someone is already de-configuring it to me that sounds like a concurrency problem elsewhere.
This entire function seems to be based on the idea that there's a lock held around it and it's the only actor (which might very well still be coming from &Giant days of FreeBSD 4).
Nov 4 2018
Nov 4 2018
Nov 3 2018
Nov 3 2018
Update the "flag" for draft-ietf-6man-ipv6only-flag.
Nov 2 2018
Nov 2 2018
See PR 230857 for details.
Nov 1 2018
Nov 1 2018
carpstats are the last virtualised variable in the file and end up at the
bz added a comment to D17787: While debugging some epoch related races at Netflix, we discoveredfew non fundamental, but annoying issues with epoch.First, the inlining makes it difficult to profile and trace epoch.At the same time, inlining doesn't effectively happens. In....
So is it the last 5 commits on your github branch or is there anything in there from before that? Having this broken up in logical junks for review will make it a lot easier.
Oct 31 2018
Oct 31 2018