igc already does not panic per your own statement, so I'm not sure what you are arguing. My request is to unify lifecycle management as one commit. But now looking and iflib.c I think the igc_if_init should simply be dropped from resume and media_change so please do that instead.

@kbowling resume and media_change are not the same. They already inside a CTX_LOCK already, no panic.

It's one unit of work unifying a lifecycle issue

In D58629#1345834, @kbowling wrote:

Can you do the same for media_change and if_resume?

Can you do the same for media_change and if_resume?

Can you do the same for media_change and if_resume?

In D58585#1344817, @pouria wrote:

Nice work, do you have plan to create an I-D for it?

Nice work, do you have plan to create an I-D for it?

i'm ok with this; this could've been two or more diffs though (the debug refactor alone would be good as a single diff.)

nice catch! lets see if we can find a broadcom peep to look at this.

Root cause analysis revealed 2 kernel-space issues:

The #ifdef INVARIANTS conditional for _Static_assert() is mostly a no-op, because GENERIC enables them via "include "std.debug"".

@gallatin would you mind eyeballing this? ty!

@tuexen is currently looking to create standard compliant packetdrill scripts to check various test cases.

In D58096#1334930, @zlei wrote:

@pouria @adrian Do you want me to commit it now ?

In D58096#1335659, @vinicius_ferrao.net.br wrote:

In D58096#1334930, @zlei wrote:

@vinicius_ferrao.net.br I do not have IB devices so not able to test. Would you please test against stable/15 after I commit it ?

Hi @zlei, I've double checked and yes, everythinig was working. I was able to replicate the issue without the patch and them checking the fix after applying it and rebuilding the kernel.

In D58096#1334930, @zlei wrote:

@vinicius_ferrao.net.br I do not have IB devices so not able to test. Would you please test against stable/15 after I commit it ?

In D58096#1333045, @pouria wrote:

It's really hard to MFC this change to stable/15.

In D58096#1333064, @vinicius_ferrao.net.br wrote:

Yes. How is the procedure? I should open other Phabricator review or just attach a patch here?

In D58096#1333045, @pouria wrote:

It's really hard to MFC this change to stable/15.
Could you please prepare a patch for stable/15 too?
If you're willing to do that, I could talk to release manager.

It's really hard to MFC this change to stable/15.
Could you please prepare a patch for stable/15 too?
If you're willing to do that, I could talk to release manager.

In D58096#1332939, @vinicius_ferrao.net.br wrote:

Yes, please @pouria.

I've tested the new changes against CX-6 and CX-5, but only on x86_64. Everything is working so far. I've also run this patch in a stress test in the context of another project (a NFS over RDMA server, which is how I found out about this issue in first place) and it worked.

To test the redirect I've used 3 VMs, being a FreeBSD router plus two Linux clients. Both input and output worked fine from everyone.

we can merge it into stable/15 before its cut and/or ask the release manager to merge it from stable/15 to the release branch after its cut but before its released.

I've tested the new changes against CX-6 and CX-5, but only on x86_64. Everything is working so far. I've also run this patch in a stress test in the context of another project (a NFS over RDMA server, which is how I found out about this issue in first place) and it worked.

Do you want me to commit this one? @vinicius_ferrao.net.br