What appears like a bug is that return code for rxeof is checked to start the taskqueue.
If it is an optimization not to call the taskqueue it is at least better to do it in the callers ?
The other point is why coding the taskqueue if it is never scheduled (except for more_tx maybe) ?

I'm planning to commit the dev on behalf of emeric 08/21, please make any comments before. :)

In D7396#194103, @fabient wrote:

Any news on the review ?

Any news on the review ?

Le 27 janv. 2017 à 20:05, jhb (John Baldwin) <phabric-noreply@FreeBSD.org> a écrit :

jhb added inline comments.

INLINE COMMENTS

fabient wrote in link_elf_obj.c:561
Do you mean it is better to resolve filename at upper level even if we need to open file again ?

So do you have a use case where the filename isn't already the full path? linker_load_module() in kern_linker.c already passes the pathname (not the basename) to this function.

Correctly generated from head.
Added a fix support callchains for software events.

In D7396#153730, @andrew wrote:

We should be using the EABI unwinding function. The location of any given register on the EABI stack is compiler specific so we shouldn't hard code it.

Commited as r290982

From internal review: Adding missing priority field when notifying acquire to userland.

Is there any more comment to fix it ?
lstewart@ do you prefer the no rollback in case of error (will do the same as packet loss) ?
both solution is are better than keeping the code like this.

commited as r286890

Commited as r280759

Commited as r289025

commited as r289023

In D3783#78030, @jhb wrote:

I guess we are using non-char types to store these values in other places? Otherwise I imagine the compiler would have complained about storing too-large values. Would be nice if that's the case to find the places that are storing this in a larger value and fix those as well to catch this in the future.

Fix emaste@ comments

In D2970#71255, @lstewart wrote:

This change seems inadequate given that we would have set TF_SENTFIN and updated snd_max. I haven't followed through all the implications of not reverting those changes, but if we're going to attempt a state rollback we'd better make sure we get it right. I'm also a bit unclear on some details in the original report given that an RTO would reset snd_nxt to snd_una and get us out of any permanent pickle. I'm not a fan of rollbacks in general as they're fragile. What's the use case where a rollback here matters?

() added before commit