- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Nov 3 2021
In D32810#740413, @bz wrote:This leads to a lot of questions:
(a) can we check for the NULL pointer and gracefully handle it? Or at least add a KASSERT to document it?
Nov 2 2021
Oct 29 2021
It isn't write only variable. At line 501 original IP header can be changed, this variable keeps its copy.
Oct 20 2021
In D32563#735219, @bz wrote:Has anyone checked what this was before the epoch work came in?
Oct 1 2021
Sep 21 2021
LGTM.
Sep 17 2021
Sep 10 2021
Sep 6 2021
Sep 3 2021
Sep 2 2021
Ah, sorry, I committed the fix already..
Aug 26 2021
Aug 25 2021
Aug 24 2021
Aug 17 2021
Aug 13 2021
Aug 6 2021
Aug 5 2021
Jul 16 2021
Jul 15 2021
Jul 5 2021
Jun 28 2021
I have no objection.
Jun 16 2021
In D30764#691856, @markj wrote:p is a union of struct mbuf ** and void *. So wouldn't setting *p.m do the wrong thing if the packet is passed with PFIL_MEMPTR?
Jun 15 2021
I think we can set *p.m unconditionally, like we do in ipfw_check_packet().
Jun 11 2021
The intent of this review was show how we can reduce vlan handling call path. It is not targeted to be included in main stream.
May 21 2021
In D29274#682376, @kp wrote:The locking Tom cites does still need to be fixed, but I think it's mostly okay. The only missing part is the protection of schedlist and aqmlist, and those will probably be better served by NET_EPOCH than by a separate lock. (Because taking the lock in find_sched_type() doesn't protect the struct dn_alg we return from being removed after we release the lock. Being inside NET_EPOCH and waiting to complete the unload until after NET_EPOCH_WAIT should be fine.)
I'll try to post a patch for that later today.
May 17 2021
Just want to note, I'm sorry for long delay, I moved temporary to another project and dummynet overhaul is not done yet. But I plan to publish the code somewhere on guthub.
May 11 2021
I meant the case fwd tableargs.home.lan:8000.
May 10 2021
Replacing _substrcmp() with strncmp(,,8) breaks the case, when "tablearg" is part of hostname:port syntax.
May 2 2021
Apr 30 2021
Apr 28 2021
Apr 20 2021
Apr 19 2021
In D29378#657837, @markj wrote:I see a call in ipfw, I guess that needs to be updated too. Seems time to introduce a new subroutine to handle this.
Apr 16 2021
Apr 15 2021
- Fix copy/paste bug.
Apr 6 2021
Apr 5 2021
In D29576#663193, @glebius wrote:In D29576#663187, @ae wrote:Imagine, you have two or more identical SYNs, now you use INP_RLOCK(), this means they all can be handled in parallel "in the same time". This means, syncache_add() in some cases can determine that there are no corresponding entries yet - syncache_lookup() returns NULL, we still hold SCH_LOCK(), then we allocate syncache entry, populate all its fields and do SCH_UNLOCK(). Imagine, now the same things will be done by the another thread, and another. In the end we will have several the same entries added by the syncache_insert().
Is this impossible?In this case the second thread will wait in SCH_LOCK and then, once it acquires the lock, syncache_lookup will return entry created by the first thread.
In D29576#663175, @glebius wrote:In D29576#663155, @ae wrote:I doubt that it is enough to just do s/wlock/rlock/ in the syncache code. Usually we need to add the extra check that an entry was not already linked by another thread in such cases.
Nothing changes in the syncache hash locking with this patch. The patch changes to rlock of the listening socket PCB.
I doubt that it is enough to just do s/wlock/rlock/ in the syncache code. Usually we need to add the extra check that an entry was not already linked by another thread in such cases.
Apr 1 2021
Mar 30 2021
Mar 25 2021
Mar 19 2021
Mar 16 2021
I think when my work will be ready, I will commit it as separate implementation. Thus you can commit your changes to go forward with your work.
Mar 9 2021
Mar 4 2021
LGTM.
Mar 3 2021
Hi John,
Mar 2 2021
I'm working on this code and I think all this changes will be lost in the future, or they will take away my desire to merge changes.
Feb 26 2021
Feb 25 2021
Feb 18 2021
Feb 16 2021
Feb 15 2021
Feb 11 2021
Feb 9 2021
Make locking similar to what we heave for IPv4.
Fix mbuf leaks and lock leaks for error case.
Feb 8 2021
In D27500#638775, @rew wrote:The only a thing a resize operation can do is ensure that the new size is a multiple of the requested alignment and that the new size won't extend into the next partition or past the last sector of the geom.
The last patch seems to have fixed the panic for us. But I have doubts, probably we should take INP_RLOCK just before checking in6p_moptions. Any thoughts?
Let me remind what panic it is targeted to fix:
In D27500#638475, @rew wrote:ae@, thanks for the reply - I looked at g_part_bsd_resize and there’s no reference to using the offset field. The only field it uses is the start field. Let me know if you have any other concerns.
Maybe trasz@ will weigh in - is there anything glaring I’ve overlooked?