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?

It isn't write only variable. At line 501 original IP header can be changed, this variable keeps its copy.

In D32563#735219, @bz wrote:

Has anyone checked what this was before the epoch work came in?

LGTM.

LGTM.

Ah, sorry, I committed the fix already..

I have no objection.

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?

I think we can set *p.m unconditionally, like we do in ipfw_check_packet().

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.

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.

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.

I meant the case fwd tableargs.home.lan:8000.

Replacing _substrcmp() with strncmp(,,8) breaks the case, when "tablearg" is part of hostname:port syntax.

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.

• Fix copy/paste bug.

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.

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.

LGTM.

Hi John,

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.

Make locking similar to what we heave for IPv4.
Fix mbuf leaks and lock leaks for error case.

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?