Dimitris Papastamos wrote:
> On Mon, Jun 13, 2016 at 08:42:35AM -0700, Philip Guenther wrote:
> > On Sun, 12 Jun 2016, Dimitris Papastamos wrote:
> > > I was building ports and at the same time started chromium and the
> > > kernel panic-ed.
> > >
> > > This has happened a few times in the last week. It started happening at
> > > some point towards the end of May. It is not easy to reproduce locally.
> >
> > Thank you for the report! When you say "not easy to reproduce locally",
> > do you mean you _can_ semireliably reproduce it, such that if we found a
> > suspicious commit to revert you would be able to be pretty sure whether it
> > was really fixed? If so, what's your best guess on how to tickle it?
>
> Hi,
>
> I had a look at this. I am currently exploring the possibility that
> the crash could be due to this patch from May 26th 2016:
>
> "Make amaps use less kernel memory (2nd try)"
>
> Not verified this yet in any way, just thought I would post early in
> case anyone has any ideas.
It looks unrelated. Even with reverting the amap diff the unp_gc panic
occured here.
> I also reviewed the patch from Aug 28th 2015:
>
> "Rework the UNIX domain socket garbage collector, including ideas from
> {Free,Net}BSD"
>
> but I did not see an issue with it. In the trace that I posted it
> seems to crash on line 905 in unp_gc() in sys/kern/uipc_usrreq.c:
>
> 899 /* close any fds on the deferred list */
> 900 while ((defer = SLIST_FIRST(&unp_deferred)) != NULL) {
> 901 SLIST_REMOVE_HEAD(&unp_deferred, ud_link);
> 902 for (i = 0; i < defer->ud_n; i++) {
> 903 memcpy(&fp, &((struct file **)(defer + 1))[i],
> 904 sizeof(fp));
> 905 FREF(fp); <-- here
> 906 if ((unp = fptounp(fp)) != NULL)
> 907 unp->unp_msgcount--;
> 908 unp_rights--;
> 909 (void) closef(fp, NULL);
> 910 }
> 911 free(defer, M_TEMP, sizeof(*defer) + sizeof(fp) *
> defer->ud_n);
> 912 }
>
> The address that it crashes on seems to be aligned and not fiddled
> with. So I suspect memory was unmapped and later on triggered a uvm
> fault when accessed via FREF().
>
