- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Sep 26 2019
Sep 18 2019
Switch to using callout_init_mtx to let the callout system acquire the pause lock.
Sep 17 2019
Sep 14 2019
Sep 13 2019
Sep 3 2019
This was largely committed by mmacy last year.
Aug 19 2019
Aug 10 2019
Aug 9 2019
Jul 29 2019
This looks like it does what is described. As I understand, the use of delivered_data will be covered by a separate review. It looks like this will slightly change the way sacked_bytes is calculated. The change is probably a good thing, but it is worth verifying (and I haven't done this yet) that the updated calculation will work correctly.
Jul 18 2019
Jun 19 2019
Jun 12 2019
Jun 8 2019
Jun 7 2019
In my local tree, I added functions to generate fake machine check records and exercise the logic now found in mca_process_records(). It appears to work correctly. I *think* this is now ready to land.
Changes based on review:
- Switched to using STAILQ_CONCAT to refill the free list.
- Dropped redundant calls to resize the free list.
- Centralized the logging logic to reduce code duplication.
Jun 6 2019
Jun 5 2019
May 31 2019
Incorporate feedback from @jhb.
Try 2:
Maintain the last N records in the mca_records list. N is user-configurable and defaults to -1 (unlimited; the current behavior).
In D20482#442176, @jhb wrote:So I have had tools in the past that parsed the list from the kernel. See https://github.com/freebsd/freebsd/compare/master...bsdjhb:libsmbios_ecc. At the very least I think there should perhaps be a tunable/sysctl to control the behavior.
May 24 2019
In D20109#437264, @hselasky wrote:@glebius: Multicast destruction is deferred. When we destroy a multicast address we need to call the if_ioctl of the belonging network interface to remove any multicast addresses. That's the problem. I think draining is a good way to implement a safe solution instead of using refcounts. Then we ensure that the ifnet is in a certain state when the multicast destruction callbacks are invoked.
May 23 2019
In the interests of avoiding discussion fragmentation, I am adding the feedback from the transport working group meeting today.
Apr 25 2019
Accepting the inp change as transport role to unblock the review.
Apr 18 2019
In D19960#429052, @bz wrote:That said, there are vendors who list it (maybe not on the forwarding plane) but as RFC compliance supporting it:
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/ipv6.html
I agree with @bz about ideal process. I also agree with @kristof about the practical implications of this feature. :-)
Apr 13 2019
Mar 18 2019
I'm confused how a RST could have tripped this assert. In that case, len should have been 0 and ((th_flags) & (TH_SYN | TH_FIN)) == 0 should have been true (i.e. neither SYN nor FIN was set). In other words, it looks to me as if a RST should already pass the assert without tripping it. Can you explain further what I'm missing?
Feb 21 2019
Thanks!
Feb 12 2019
Approved.
(FYI, the revision looks incorrect. It looks like it should have been r342597.)
Please feel free to commit with "Approved by: jtl".
Please feel free to commit with "Approved by: jtl".
I assume this is the stable/12 version of D19150?
Feel free to commit with "Approved by: jtl"
Feel free to commit with "Approved by: jtl".
Feb 1 2019
Jan 13 2019
Please commit with "Approved by: jtl"
Jan 11 2019
Has this landed yet?
By the way, in the commit message, please make it clear that this simple "allows" you to more easily use arc if you want your changes to be reviewed. It doesn't require it in any way, shape, or form. And, we're not changing any expectations regarding when someone will get review.
I'm OK with importing the code as an option for developers to use. I'd be wary of specifying that there is a "plan" to convert existing test cases unless there is general buy in to do that.
Regardless of what the group says, it seems like we'll probably want to support both for a transitional period. Given that, this change seems OK. @emaste , do you agree?
Since make clean runs first, I'm assuming the only things left will be things with flags set? If so, what you propose is probably correct (and we don't need the rm/chflags/rm "dance" optimization).
Dec 17 2018
LGTM; would appreciate also hearing @rrs's opinion.
Nov 16 2018
Nov 9 2018
In D17914#382797, @markj wrote:I'm writing a regression test for this to stick under tests/sys/netinet. I'll see if I can add test cases for D17922 as well.
Yeah, I saw this shortly before seeing this review. I agree we should fix it.
Nov 8 2018
If alignment is important, we can (theoretically) do something more intelligent to maintain it. However, I think this is both safe and good enough for an emergency fix.
Nov 2 2018
Oct 18 2018
In D17609#375841, @mjg wrote:I think this is a very questionable idea. In my experience clang does *mostly* not re-read. For all cases you are adding a function call.
See vfs_ref/vfs_rel or fsetown as examples.
Can you show me a specific function which compiles to multiple reads of gs just to get curthread?
In D17604#375736, @kib wrote:I definitely agree with the genoffset.sh changes.
On the other hand, I am not sure that we need to restore volatile qualifiers in the thread_lite, instead of removing them in the struct thread. The manipulations of the critnest level and pin count should use barriers, and I believe that the thread_lite patch and some of its follow-ups just did that. Volatile relied on the compiler-specific semantic to get similar effect.
Oct 16 2018
Fix stupid syntax error.
In D17503#374613, @sbahra_repnop.org wrote:Let's merge from upstream if possible.
In D17492#374619, @sbahra_repnop.org wrote:Ok, call should be fine as well! In all cases, seems like writers are synchronized and any other usage is in the context of a protected section. CI also passes (though I haven't run it through SPARCv9+ and ARM, but we already have RMO and TSO coverage, nothing specific to ARM / SPARC with these changes).
Thanks again Jon. These are great.
Oct 13 2018
Please make the two changes suggested by bz@ and then feel free to commit this. I think its OK to ask re@ to commit this during the freeze. (I also won't be upset if they say "no".)
Oct 12 2018
Oct 11 2018
In D17492#373625, @sbahra_repnop.org wrote:Ok. I caught up with Matt offline. This doesn't solve the problem at hand. The API is not being used as intended in some areas, so we will work to address that. I would advise against merging this in as it doesn't address the underlying issues:
- Some usage of epoch records is re-entrant: This is not supported. Supporting this would require atomic usage that would be, expensive. We have an easy fix for that.
Oct 10 2018
In D17503#373574, @sbahra_repnop.org wrote:In D17503#373529, @jtl wrote:In D17503#373490, @sbahra_repnop.org wrote:See previous note in D17492 regarding the assumption that write-side functions are *not* called with-in a read-side critical. Does FreeBSD require that this is permitted?
See my comments in that review.
Regardless of whether that is true, it seems like this change would still be safe. Do you agree?
Is it expected by the kernel that ck_epoch write-side functions are safe to call on records that are already in a read-side critical section?
Helping me understand the intended use-case will allow me to answer accurately. There is further validation needed beyond poll.