In D17492#373575, @sbahra_repnop.org wrote:The above change should not have any impact if ck_epoch is being correctly used. For that reason, it's good to go. However, I am concerned about a larger problem.
For barriers, we do assert that the caller is not in a read section. However, the CPU's record may still be in a read section. So, maybe we do violate the reader/writer assumption there, too.
As long as the CPU record does not require re-entrance support, that's fine. The requirement is that the record that is used to issue a write-side request is not in a read-side section. We can lift this restriction, but I'll need to validate a few things. Is the kernel violating this restriction at the moment? I had trouble understanding that from the example given, because if the tick handler has a dedicated record, there is no problem and then the above change is a no-op.
If the above constraint is being violated, then I'll get back to you tonight as I'll want to do some additional validation.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 10 2018
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?
In D17492#373479, @sbahra_repnop.org wrote:Thanks much for this. Note that the assumption here is a writer thread *should not* be calling ck_epoch_synchronize or write while inside of a read-side critical section. In other words, the active bit must be set to 0. In this situation, the invariant is not violated. If inside a read-side critical section, bets are off. Is the assumption or requirement here that it be safe to call synchronize from with-in a read-side critical section? If so, there are a few other areas we could fix up.
The other half of the original diff is now in D17503.
Split the commit into two parts. In this part, just fix the early epoch calls.
Oct 9 2018
Oct 6 2018
Oct 5 2018
FYI, it looks like there was a typo in the description:
Oct 4 2018
Looks good. Please commit with "Approved: jtl (mentor)".
Sep 8 2018
Hi. I know I'm late to the party, but I have three comments:
a) I could be wrong, but I don't think there is any guarantee this won't be called simultaneously for two different groups at the same time. (The groups could be in different VNETs, for example.) In that case, two different invocations could be working on the function's static variables at the same time. That may produce unexpected results. (Granted, it would take an unusual series of events. But, I think we've all seen highly unusual events occur.)
b) I don't think the const variable also needs to be static.
c) It seems like the rate limiter should really be per-group, so I would suggest adding the lastprint variable to the inpcblbgroup struct.
Aug 23 2018
FYI, something didn't look right doing my tests. So, I'm going to delay committing this until I can satisfy myself that it behaves correctly. That will almost certainly mean I miss the code freeze. C'est la vie!
- Limit the ipq structure to the kernel to eliminate a buildworld failure. (And, why should we make userspace code import the sys/queue.h header for a structure they don't need anyway?)
- Address @jhb's nit.
Aug 22 2018
In D16471#357964, @j-nitrology.com wrote:D16626 expanded on these changes and was recently committed. I believe we can close this one out.
Aug 21 2018
Aug 18 2018
LGTM (with minor change noted in-line).
In D16626#356917, @rrs wrote:This version incorporates all of Jonathans comments and suggested improvements. Thanks
Jonathan!!!
Aug 14 2018
Aug 6 2018
Jul 28 2018
Jul 27 2018
Jul 25 2018
Jul 24 2018
Never mind. It looks like this is a display issue, and you really are deleting them.
It looks like you're keeping the code by moving it to the modules directory? At this point, I think it just makes sense to delete it.
Jun 18 2018
In D15706#336213, @micchie.gml_gmail.com wrote:In D15706#335628, @rwatson wrote:In D15706#334870, @micchie.gml_gmail.com wrote:In D15706#334711, @jtl wrote:In D15706#334605, @rwatson wrote:Didn't quite catch this before it was committed. This isn't really a destructor, it's a close notification. Rather than confuse matters, as sockets have UMA destructors as well, this should probably be so_notify_close.
Yes, I caught that when I asked the submitter about the placement of the "destructor". But, once I figured out it was a close notification, I should have changed the name. Mea cupla.
Before changing this, let me see if I can confirm what the Linux implementation does.
Thanks, it is intended to be equivalent to sk_destruct() callback in struct sock in Linux.
Is the Linux sk_destruct called on socket close, or on socket destruction? If we want an actual socket destructor, we can add one of those [instead / as well], called from the socket destructor function.
It is literally destructor, which is called when the final reference count drops to zero. So probably we should define so_dtor() as destructor (so keep the name) and call it after SOCK_UNLOCK() in sofree(). (in Linux it is invoked without locking socket).
Jun 15 2018
In D15706#334605, @rwatson wrote:Didn't quite catch this before it was committed. This isn't really a destructor, it's a close notification. Rather than confuse matters, as sockets have UMA destructors as well, this should probably be so_notify_close.
I've spent some time thinking about this a bit, and I have the following comments. (Some may seem contradictory, but please bear with me. :-) )
Jun 14 2018
Jun 13 2018
Address @markj's feedback by always defining the vmd_kernel_rwx_arena member of the vm_domain struct.
Jun 12 2018
Update the zone(9) manpage.
Jun 11 2018
Okay, really without the cruft this time. (Hopefully...)
I'll try to look at this review this week.
Get the correct version of sys/vm/vm_kern.c (with the troubleshooting stuff removed).
Numerous updates:
- Address @alc's concerns by adding a new arena for allocations with non-standard permissions. Import a 2MB-aligned address block at a time into the arena. Release space back to the parent arena when able. But, only do this for architectures with superpages.
- Plumb M_EXEC through malloc(9).
- Fix BPF by reverting most of rS317072.
- Add a note to the manpage that not all architectures will enforce execution permissions.
This passes my "sniff test", but it would be better to get @pkelsey to review it.
I think there are more changes needed.
Jun 8 2018
The submitter spoke to me in person at BSDCan and answered my questions.
In D15691#331801, @alc wrote:Overall, I think that this is a good idea, but the implementation has the following problem. The allocation of one executable page will block the promotion of the surrounding pages to a superpage mapping.
Jun 7 2018
Incorporate review feedback from @jhb.
I added a few basic comments while I ponder the rest...