Probably not related. But when I took short look to the patch to see what could go wrong, I walked into the following comment in _rm_wlock(): "Assumes rm->rm_writecpus update is visible on other CPUs before rm_cleanIPI is called." There is no explicit barrier to ensure it. However, there might be some barriers inside of smp_rendezvous_cpus(). I have no idea what could happened if this assumption is not met. Note that rm_cleanIPI() is affected by the patch.
On Sat, Feb 4, 2017 at 9:39 PM, Jason Harmening <jason.harmen...@gmail.com> wrote: > Can you post an example of such panic? Only 2 MI pieces were changed, > netisr and rmlock. I haven't seen problems on my own amd64/i386/arm testing > of this, so a backtrace might help to narrow down the cause. > > On Sat, Feb 4, 2017 at 12:22 PM, Andreas Tobler <andre...@freebsd.org> > wrote: >> >> On 04.02.17 20:54, Jason Harmening wrote: >>> >>> I suspect this broke rmlocks for mips because the rmlock implementation >>> takes the address of the per-CPU pc_rm_queue when building tracker >>> lists. That address may be later accessed from another CPU and will >>> then translate to the wrong physical region if the address was taken >>> relative to the globally-constant pcpup VA used on mips. >>> >>> Regardless, for mips get_pcpup() should be implemented as >>> pcpu_find(curcpu) since returning an address that may mean something >>> different depending on the CPU seems like a big POLA violation if >>> nothing else. >>> >>> I'm more concerned about the report of powerpc breakage. For powerpc we >>> simply take each pcpu pointer from the pc_allcpu list (which is the same >>> value stored in the cpuid_to_pcpu array) and pass it through the ap_pcpu >>> global to each AP's startup code, which then stores it in sprg0. It >>> should be globally unique and won't have the variable-translation issues >>> seen on mips. Andreas, are you certain this change was responsible the >>> breakage you saw, and was it the same sort of hang observed on mips? >> >> >> I'm really sure. 313036 booted fine, allowed me to execute heavy >> compilation jobs, np. 313037 on the other side gave me various patterns of >> panics. During startup, but I also succeeded to get into multiuser and then >> the panic happend during port building. >> >> I have no deeper inside where pcpu data is used. Justin mentioned netisr? >> >> Andreas >> > _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
