On 01.07.20 17:58, Luis Chamberlain wrote: [...] >>> >>> Ah, well that would be a different fix required, becuase again, >>> br_stp_start() does not untangle the correct error today really. >>> I also I think it would be odd odd that SIGSEGV or another signal >>> is what was terminating Christian's bridge stp call, but let's >>> find out! >>> >>> Note we pass 0 to the options to wait so the mistake here could indeed >>> be that we did not need KWIFSIGNALED(). I was afraid of this prospect... >>> as it other implications. >>> >>> It means we either *open code* all callers, or we handle this in a >>> unified way on the umh. And if we do handle this in a unified way, it >>> then begs the question as to *what* do we pass for the signals case and >>> continued case. Below we just pass the signal, and treat continued as >>> OK, but treating continued as OK would also be a *new* change as well. >>> >>> For instance (this goes just boot tested, but Christian if you can >>> try this as well that would be appreciated): >> >> >> Does not help, the bridge stays in DOWN state. > > OK thanks for testing, that was fast! Does your code go through the > STP kernel path or userpath? If it is taking the STP kernel path > then this is not the real culprit to your issue then. I have no idea and I cannot look into this right now. I can test patches as compile,reboot and test is almost no effort. FWIW, this is just the network of a KVM guest of libvirts default network no longer working, maybe you can reproduce this on x86 as well?
