Date: Mon, 27 Dec 2021 10:58:02 -0800 From: Gleb Smirnoff <glebius@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: Larry Rosenman <ler@lerctr.org>, current@freebsd.org Subject: Re: My -CURRENT crashes.... Message-ID: <YcoMupvrXwzEgFkb@FreeBSD.org> In-Reply-To: <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@FreeBSD.org> References: <286c830efc0e12e3e7a7e9b2ede31c28@lerctr.org> <Ycn4Y7ZUE%2BBWM3tr@FreeBSD.org> <45ee5689-b24c-51b5-d7b7-33fd73ee7dce@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 27, 2021 at 01:43:01PM -0500, Alexander Motin wrote: A> > This allows us to deduct that the callout belongs to proc subsystem and A> > we can retrieve the proc it points to: c_lock - 0x128 = 0xfffff8030521e548 A> > It is ccache in PRS_NORMAL state. And the "tmp" in our stack frame is its A> > p_itcallout. A> > A> > So there is something that would zero out most of the p_itcallout while A> > it is scheduled? A> A> So carefully zero it, but keep the lock pointer... The only way that A> comes to mind is callout_init_mtx() in do_fork() if we assume the A> process has completed and the struct proc was reused. I guess if we A> could somehow leak scheduled callout in exit1(). May be we could add A> some more assertions to try catch callout still being active there. Note that _callout_stop_safe(p_itcallout) is the only place in kernel where CS_EXECUTING is used. -- Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YcoMupvrXwzEgFkb>